SOA, Redefined

Once upon a time, SOA (short for Services Oriented Architecture) was the king of IT Hype; for years people talked incessantly about it, attempted to extol its virtues and many tried using it within their own enterprise environments. SOA has had mixed success over the years, but that's somewhat hard to measure for a number of reasons, including:

1. There were conflicting definitions for it to begin with - some viewed it more as a practice or design approach, others viewed from a product perspective and still others saw it as a standards focused phenomenon. 
2. What SOA was has morphed quite a bit from where it began - it has changed so much in fact that it can hardly even be referred to in its own context any longer. We'll explain that in a minute. 
3. It was never entirely clear from the initial hype, what the real benefits of SOA would be if adopted. That has changed somewhat since the mid-to-late 2000's but that's only because the solution context evolved.

SOA drives design on the right side of this picture...

So, let's back up for a moment and first look at what SOA at several different points over the past decade. 

In the misty depths of the turn of the new millennium...

• In 2004, innovations in software engineering - notably the notion of Object Oriented programming techniques and languages along with pattern-driven design had begun to change the perception that applications must handle redundant tasks each time they faced them. In other words, the notion of software that could be shared as services through abstracted interfaces was becoming popular. The core design concept was extrapolated outwards to an enterprise scale and the first serious discussions about SOA as a practice or set of architectural principles began in earnest. 
• On a parallel track, the W3C (World Wide Web Consortium) Microsoft and several other companies began plotting out a standard communications protocol for linking software objects or services across the Internet. The standard, later called SOAP (Simple Object Access Protocol) was part of a larger set of W3C standards including XML, XHTML, CSS, DOM, WSDL and UDDI which when taken together would provide standard approaches toward encoding data, passing it and locating the places it was hiding as well as defining the format for how to display it. SOAP was adopted in 2003. 
• Also around this time a set of data management technologies emerged; partially based on EAI (Enterprise Application Integration) and ETL (Extract Transform & Load), that linked SOAP with Services concepts in the context of data movement. This new technology was called the Enterprise Service Bus (ESB).

fast forward to 2006-2008...

• A vast array of products have been restructured to accommodate the design principles which have matured somewhat. These products were formerly application server platforms and other governance management tools among others. The "SOA Stack" had been born.
• Industry hype probably reached its apex around this point. SOA projects were popping up everywhere and the idea of what SOA meant was little clearer.
• That definition focused on key design principles (such as "loose coupling" and "encapsulation" both borrowed from Object Oriented Design) and core elements of the stack (which had just evolved) - so the typical SOA solution would follow the principles and use the stack (starting with an ESB, then applying a UDDI registry, governance tool, business process manager and the appropriate app server / container, such as weblogic or websphere etc.)
• Java figured prominently in the SOA landscape, which only makes sense given that SOA evolved partially from Object Oriented Design techniques and principles. Thus, a great many of the SOA projects chose J2EE as the development language because it was designed to support OOD. 
• Some larger organizations, like the DoD, wanted to take this all further and bundle identity management and infrastructure services along with SOA initiatives. This was the beginning of a transition from consolidated hosting environments to Cloud Services in the Federal ecosystem. 
• On the commercial side, something called Software as a Service began to emerge at this time (it had in fact been around before then but got rebranded as SaaS). It involved the notion of a subscription to get thin client applications served directly from the service provider.  
• Virtualization becomes an interesting way to not waste CPU cycles in the datacenter.

2010

• Dave makes contact and the next generation of HAL computers malfunctions yet again! - sorry couldn't help throwing in the obscure sci-fi reference...
• Smart phones conquer the world. This part is accurate - it did happen and it came as a bit of surprise. It also changed the way we looked at development platforms, delivery platforms and 'object communication.' RESTful services, which had been around for awhile, got a huge boost in large part to the explosion of 'apps' being developed and deployed to IOS and Android devices. SOA would never be the same...
• Let's not forget DropBox, Google Drive and a 100 other Cloud offerings that began appearing around this time. Infrastructure got sexy.
• Oh, and everything turned "Agile."

2012 - 2014

• The longest war in American history still isn't over yet. When it started, enterprise IT was still largely mainframe driven - ten years later - what diversity we find...
• The popularity of Object Oriented Programming has hit the skids so to speak. This is because the scripting languages have overtaken J2EE in popularity as those languages support Agile and mobile platforms better (J2EE is still around of course, but then so is Cobol - the coding is on the wall). 
• People seldom refer to SOA projects anymore - or SOA has become synonymous with application architecture where organizations have more or less adopted the principles. Often times now its being done with REST instead of SOAP.

So, now that our tour of the past decade has brought us full circle back to the present; how would we go about defining SOA in 2014? Wikipedia defines it almost as a single pattern - others - like Thomas Erl - have written very interesting books on it.

Services Oriented Architecture (SOA), Redefined

SOA represents a nexus of design principles and standards for internet-driven applications. There is an implied reliance on specific toolsets that support the resulting services created based upon those principles and standards, but those tools do not define SOA any more than Object Oriented Design is defined by Eclipse. In other words, you could conceivably use any number of other tools to produce a solution that might conform to those principles or standards.  

The notion of enterprise services, Managed Services and Software as a Service (thus much of Cloud Computing) are natural extensions of the core SOA concept, but aren't SOA (anymore than SOA is OOD even though it is largely derived from it). SOA or for that matter OOD can be used to help facilitate parts of these other solutions. 

In the context of our blog here, I like to think of SOA and OOD has subcategories within the practice of Application Architecture (which itself fits within Solution Architecture). Management of enterprise services which may have been created using SOA fits into Infrastructure Architecture. Obviously, when one works on an application service that is intended to have a Cloud or SaaS element to it (or must rely on enterprise services to function), multiple architecture tiers or practice areas will be involved - which is another good reason to have IT Architects who can handle it all, right?

opyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Application Architecture, Defined

As part of our initiation of the IT Architecture Journal, we've been trying to help define the landscape - we're continuing that trend today with an introduction to Application Architecture. These definitions are being provided as a foundation - both for IT Architecture education in general but also as part of our larger goal to help harmonize industry terminology and expectations regarding IT Architecture. And of course these articles also serve as a foundation for us as we delve into more detailed or specific topics later. Like so many other aspects of Architecture - there is quite a lot of overlap and complexity connected to Application Architecture.

The definitions we provide here are not meant to be mere academic representations of some well understood a priori knowledge, but rather are based on experience from many years of architecture practice. The goal here is to provide the most pragmatic explanations possible - and to clearly link what might otherwise appear to be conflicting concepts. In other words, we are attempting to demystify IT Architecture.

First, let us address the overlapping or conflicting terms. Application Architecture is often referred to as System Architecture, Systems Engineering or even Software Architecture or Design (or even Software Engineering). All of these terms are roughly analogous and can fit neatly within the scope of Solution Architecture (which is itself a subset of IT Architecture), yet there are aspects of Application Architecture practice which are stretching the bounds of what it encompasses. Even within some of these other terms there lies deeper hierarchies of sub-terms; for example within Software Engineering we'd likely find both Object Oriented Design and GoF (Gang of Four) Pattern Design. When we begin to discuss SOA (Services Oriented Architecture) and SAAS (Software as a Service) then things will get even more complicated as we will see.

Application Architecture would be focused mostly within the Business Tier of this view

Application Architecture, Defined
Application Architecture is the set of design activities and artifacts associated with the production or management of solution logic. Solution logic is the set of business rules and functions that support key processes or workflows associated with any given organization. While Application Architecture requires and / or manipulates data and sits atop an infrastructure it often viewed separately from those elements in organizations where infrastructure as a service or data management organizations are in place. There are usually clear delineations regarding where application responsibility ends and data or infrastructure etc. begin.

Application Architecture generally follows systems and software design guidelines or expectations; so an Application Architect would likely use UML to create Class diagrams to help model data for their application, whereas a Data Architecture would likely use an ERD or Dimensional to do something similar (even though both are working with the same data in that context).

Application Architecture is represented in most of the major EA Frameworks; in TOGAF and FEAF it is referred to as Application Architecture, in Zachman it Systems. In DODAF it is roughly equivalent to Systems and Services Views.

Skills Required
To work as an Application Architect, you'll need the following skills:

• The ability to design and problem solve.
• The ability to use UML notation to capture standard designs.
• The ability to apply standard patterns or create / define your own.
• An understanding of the underlying technologies involved. Object Oriented design in Java is generally quite a bit different than scripting with JavaScript and Perl in a LAMP stack. 
• The ability to understand and harness / exploit an Application Development Lifecycle and associated tools - this is referred to in industry as Application Lifecycle Management (ALM). 
• The ability to translate business needs into business logic and to define integration of that logic within the system environments available. 

A Note about SOA
So, what makes SOA a game-changer for Application Architecture? Basically it has to do with implied integration across other "tiers" of the overall Solution Architecture. SOA brings with it a sort of mega-pattern for design that includes expectations for data access and infrastructure exploitation and thus it is sometimes hard to abstract these non-application elements of the solution. While it's easy enough to abstract all this from the developers (you simply give them the guidance and the self-service development environments) for the architect it's not so simple. We'll be talking about this more soon...

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The Difference Between IT Architecture & Subject Matter Expertise

This is a question that comes up very frequently in my line of work, although it isn't always posed as a question. The question in its most generic form goes something like this - "how much specific technical expertise should an Architect have." That's a tough one isn't it, especially if one considers themselves an IT Architect as a opposed to something much more specific (let's say a Hyperion or Informatica Architect).

We've defined IT Architecture in this blog but we haven't covered Subject Matter Expertise in great detail yet. What does it mean to be a SME?

Subject Matter Expertise, Defined
Being a Subject Matter Expert requires an in-depth understanding in one specific topic; that topic can be a field of practice, a theory or some particular product or tool (or set of related products). In the context of IT, that expertise necessarily implies the ability to perform any related tasks (configuration, design or development) at a more or less 'master' level. This further implies that the SME role often actually encompasses several typical roles; Architect, Lead Developer and Administrator.

So, this definition obviously begs a number of interesting questions:

1. Should Architects be expert in one or more technologies?
2. Can Architects become experts in many (or all of) the various technologies they work with?
3. How important is the discipline or practice of architecture as compared to Subject Matter Expertise?
4. Can someone who is only expert in one area then handle or deal with a large heterogeneous environment?

All of these questions are being driven to some extent by the expectations of organizations that would hire Architects or SMEs. Part of the dynamic that's present these days is that many enterprises want both things (the Architect and the SME) but only want to pay for one person to do it - thereby merging the roles. In some of those cases, this desire is somewhat justified in that there may be relatively little design effort required but a great deal of configuration, follow-on development and many coordinated deployments.

But is that really a question of whether one ought to have an SME skill set as opposed to an IT Architecture skill set - or is it a question of whether the assignments and team composition is correct? Let's consider some reactions to all these questions:

• It is not realistic to assume that any one technical resource will become expert in every technology within their particular environment. It is also not necessary.
• Architecture is much more focused on design than deployment - granted it plays an oversight role once things have left the drawing board, but that merely means the Architect is available for other design duties. It is unlikely in most cases that the designer will be the best development resource (either due to higher cost or the fact they spend more time designing than developing).
• Architects and SMEs can work together - as separate roles - quite effectively. There is no reason that both or either role has to be full-time - they can be brought in as necessary.
• It will be necessary at times for Architects to "dive-in" to one specific area or another to solve a problem. Sometimes in doing this the Architect then becomes an expert in that area. In many other times, the Architect understands the common technical standards, the underlying principles and perhaps key features but does not become the expert. That's ok as well, as long as what the Architect is trained to do is solve problems - regardless of the technology involved and that others have similar dedicated roles and skills sets that complement the team.

I've heard folks voice concerns that they want Architects who can implement rather than merely design. This is an interesting situation and perhaps reflects a bit the relative lack of consensus surrounding IT Architecture in industry. If we were to compare ourselves to our brick and mortar brethren, how common would it be for us to expect a building architect to be scaling a high rise to place beams or pour concrete or even to determine the proper layout of pipes and wires. The traditional architect designs with all of those considerations in mind, works with engineers and contractors to solve problems and is ultimately responsible for the outcome of the project. He / she is in an expert in what they do but not an expert in every possible technology involved in building today's high-rises.

IT and building construction are both similar and different at the same time. But the core question of expanding complexity is fundamentally the same. The more complex your environment, the more likely you will need a division of labor, and at one end of the spectrum you will find the Architect who has design command of all the relevant technologies within a unified solution context. At the other end you will have SMEs who know everything there is to know about individual pieces of that puzzle. Occasionally this is one and the same person - but not very often - nor should it be.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Principles of Integrated Design

When people think about design they often visualize the Apple product line or user interface experts coming up with cool graphics to deploy in websites. Design in IT is much more than that though; while they are many individual piece parts of an overall lifecycle that are concerned with specific design tasks, say like the User Interface, the entire lifecycle itself is also driven by the need to create functional systems. This holds true for both hardware and software, as well for complex enterprise initiatives like ERP or even Cyber Security.  If we consider "Design" as a verb - the activity which produces something - then "Architecture" is the noun which design creates. "Integrated Design" represents the ability to conduct design activities within a uniform enterprise context.  Integrated Design is highly analogous to IT Architecture as a practice field; however there are some aspects of design which seem to go beyond the bounds of what most folks considered Architecture.

To get a better sense as to how Integrated Design, is applied let's look at some typical enterprise IT projects.  In projects such as a legacy migration or an ERP transformation you're likely to find the following types of design activities:

• Enterprise Architecture
• Data Modeling
• Data Architecture Design
• Business Process Modeling
• User Interface Design 
• User Experience Design (and yes this is somewhat different as User Experience crosses platforms and technologies these days)
• Application & Service Design
• Infrastructure and / or Network Design

These tasks are generally vital to the success of an overall project, yet many if not most of them happen in design "stovepipes."  The concept of Integrated Design is similar to how some people view Enterprise Architecture except that Integrated Design is less focused on formal frameworks or specific EA tools - in other words it is more likely to provide an all-encompassing umbrella for all types of design activity.  For example, some people might not consider a detailed Network Design or Data Center Design to be part of an Enterprise Architecture although others might - there is no standard definition or boundary. Integrated Design however, is a more flexible, perhaps even Agile way to tackle what is in fact one of the biggest challenges most enterprise face today - complexity.

Design and Architecture often merge in user interfaces or "Digital Experience" solution

The complexity we're referring to is the ability to reconcile and align all of the various designs (and design activities) associated with a complex enterprise or specific enterprise initiative into a single solution utilizing a unified lifecycle management framework.

There are three simple principles behind Integrated Design:

1. All design activities must share the same lifecycle methodology and automation framework. Integrating models or architectures can sometimes be referred to as meta-integration and as the name implies it represents an added layer of complexity to an already complex project. A shared automation framework does not have to be an EA tool.
2. All designs must be targeted to the shared capabilities.  There are finite set of capabilities associated with any given solution. By pegging or mapping each design to its relevant solution capabilities we achieve and maintain automatically a certain level of integration. 
3. All design (on the project or within the solution) is related. While some designs may only be complementary rather than dependent, all designs and thus all later functionality have relationships to one another. Understanding those relationships up front is perhaps the greatest risk reduction technique available in IT today.  These relationships are both broad and narrow in nature (and can extend down to the data element level).

Design is and always will be a creative endeavor; however, if we keep in mind the principles of Integrated Design we can see how that creativity can be merged along with systems engineering to produce innovative and successful solutions.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Business Architecture, Defined

There are a number of disciplines within IT Architecture that tend to overlap, part of this is because the definitions haven't achieved industry wide status (for example, various EA Frameworks define similar functions with different terms and they also often use the same terms differently). Part of the problem in this case though, has to do with the relative ambiguity regarding how and where IT Technology and Business drivers can or should mix. There is also some confusion in relation to where Business Analysis ends (as a practice) and where Business Architecture begins. We will help to answer some of these questions in this post.

Business Architecture has many potential components and drivers

First, let's attempt to apply a standard definition to the practice area:

Business Architecture - This represents the entire set of design activities associated with translating business needs and expectations into technical solutions. Those design activities include the following typical tasks and / or artifacts: Context Maps, Concept Mapping, Process Engineering, Capability Maps, Business Rule Definition, Conceptual Data Modeling, Domain Modeling, Class Definition, Object Definition and Business Glossaries. This list is not exhaustive but it does highlight that Business Architecture includes both analysis and design. It also shows that there are clear intersections with data and application (system) architecture. Business Architecture tends to be the first area of design focus within the overall lifecycle of any given solution or set of solutions.   

So, in reality there are many people who work as Business Analysts that in fact perform Architecture tasks. On the flip side, many architects are asked to define and manage requirements or otherwise work side by side with business stakeholders and analysts to help better understand workflows and data contexts. The lines here are indeed fuzzy as the type of architect asked to do all of this may be referred to variously as a Solution Architect, Data Architect, Project Architect or perhaps even something else. Use of the term "Business Architect" is still relatively uncommon. The reason for this is most likely that many organizations want Architects who can perform those upfront Business design activities but also follow that with more specific types of solution design tasks and artifacts.

Business Architects often use EA tools to perform these types of activities; products like Mega or Troux allow Business Architecture to managed in the context of TOGAF driven enterprise. Other tools can be used to manage governance, application policies, business rules and other types of design artifacts.

Another important aspect of the role of Business Architects is their focus on Lifecycle Management. Now, we will address Lifecycle Management in more detail in another upcoming post, but the key elements involved are Governance and Portfolio coordination. So, Business Architects also often help to oversee Governance processes, help develop Business Cases, estimate project costs and schedules and otherwise support portfolio planning processes.

When we view all of this in the larger context of IT Architecture, it is worth considering the larger question whether all architects ought to have some experience working on the "business side" of solutions in order to better understand why some projects fail and how to better align business goals with IT reality. Another facet of this topic is the notion of what an Architecture Manager does. That is a role that isn't necessarily associated with Business Architecture per se but nevertheless includes quite a number of similar tasks and artifacts. Any IT Architecture manager (regardless of the type of architecture being performed) must be able to manage project planning, cost estimation and other types of team collaboration activities.

We will examine many of the terms and concepts introduced here in greater depth in upcoming posts.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Introducing Design Patterns

Design Patterns are an important part of software engineering today, but what many folks don't realize is how ubiquitous they are becoming within the full spectrum of IT activities. Part of the reason this is the case is due to the flexible nature of Patterns.  Mastering Design Patterns is a critical part now of most IT Architects' roles and from a larger perspective is also becoming increasingly import for most enterprises.

Before discussing how to manage Design Patterns, we first need to define what they are:

Design Pattern - This represents a description and (usually) a visualization of some specific aspect of a larger design solution. Patterns can employ standard or non-standard notation and may or may not be used as Enterprise Architecture (EA) artifacts. The most important characteristic of a Pattern is that it encapsulates at least one significant design principle. Patterns are usually combined to produce comprehensive solutions.  Patterns can also be used as code "templates/stubs" to facilitate rapid development of applications and services. 

Beyond this basic definition, Patterns can mean many things to many different types of IT specialists. For example, Cyber Security experts can manage Patterns as mechanisms for modeling Threat behaviors. Network Engineers can view combinations of Data Center layouts and hosting configurations as Patterns. Data Architects could, if they wished, view prototypical Conceptual Models as Patterns and in fact a Canonical Model could be considered a specific type of Data Pattern applied across multiple enterprises. This sounds a little strange perhaps because many people associate the concept of Patterns with Object Oriented Programming and the original Gang of Four book of OOD patterns. Yet, there is nothing that explicitly states anywhere that Patterns have to be limited to application design (Object-Oriented or otherwise).

The flexibility of the Design pattern is simultaneously both its greatest asset and drawback.  It's an asset because it allows architects, developers and engineers the flexibility to define re-usable solutions for common design challenges. It's a drawback because it tends to promote decentralized management (or perhaps no management at all) of design artifacts and may also lead to more situations where solution elements are designed out of context of one another.  So how do we manage something that is flexible, effective yet often disruptive? Here are five suggestions for how to master Design Patterns:

1. Create your own Design Pattern Taxonomy - Keep in mind that there is no standard approach from industry as to how an organization (or individual) ought to manage patterns (unless of course you wish to blend it with your EA approach and integrate them within one of several EA Frameworks). So what's being recommended here is to create a taxonomy of the types of Design Patterns you think you may need. This might include application patterns, data patterns, UI patterns etc. - whatever makes sense.

2. Come with a Standard approach for Pattern Visualization - Many people like to use UML for this but quite frankly there's some design problems that UML isn't so great in representing. The benefit of using UML is that it should make alignment with your ALM easier (in most cases).

3. Come up with Standard Template for Pattern Description - You'll need to ask yourself here just how much information is required. While this shouldn't become a huge specification you will need to provide enough information so folks not involved in the original design won't have to come back and ask what you really meant.

4. Standardize your own Design Terminology - As we all know there's many ways to describe the same thing. Building a glossary that can support all of the Design Patterns you may create will come in handy for you and your enterprise. (again for those who are already utilizing an EA approach you can probably borrow from that or at least make sure that any Patterns not managed as part of the EA share common terminology).

5. Align your Design Patterns with your ALM / SDLC - This is perhaps the most important of the five recommendations. The majority of enterprises are already working with some sort of Application Lifecycle Management methodology. Often times ad hoc Design Patterns don't get "baked in" to the ALM. This can lead to much confusion and generally makes the overall design approach somewhat less efficient than it might otherwise be.

Design Patterns are meant to accomplish three critical things:

• Increase the speed of the design process.
• Ensure that lessons learned are adopted.
• Reduce overall costs by finding ways for certain capabilities to be reused. 

Actively managing Design Patterns helps to ensure that all three goals can be achieved.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Data Architecture, Defined

Someone asked me what at first sounded like a very straightforward question last year; "what is Data Architecture" - or more precisely, what does it mean to you. Usually, I'm not usually at a loss for words when it comes to expounding upon IT Architecture related topics - but it occurred to me at that moment that my previous understanding of what Data Architecture really represents is or has been a little flawed or perhaps just outdated. So I gave a somewhat convoluted and circumspect answer.

Where does Architecture fit within this picture?

The nature of what's occurring in the Data domain within IT is itself changing - very quickly and somewhat radically. The rise of Big Data and proliferation of User Driven discovery tools represents quite a departure from the previous more deterministic view of how data ought to be organized, processed and harvested. So how does all of this effect Data Architecture as a practice within IT (or more specifically within IT Architecture)?

But before we dive into the implications of the current revolution and its subsequent democratizing of data, we need to step back and look again the more traditional definitions as to what Data Architecture represents. I'll start with a high level summary view:

Traditional Data Architecture can be divided into two main focus areas; 1 - the structure of the data itself and 2 - the systems view of whatever components are utilized to exploit the data contained within the systems. Data in itself is the semantic representation or shorthand of the processes, functions or activities that an organization is involved with. Data has traditionally been subdivided (at least for the past several decades) into two categories; transactional and knowledge-based or analytic (OLTP vs. OLAP). 

Now we'll move to a traditional summary definition of Data Architecture practice:

Data Architecture is the practice of managing both the design of data as well as of the systems which house or exploit that data. As such, this practice area revolves around management of data models and architecture models. Unfortunately, the application of Governance within this practice is sporadic and when it does occur is often split into two views: governance of the data (models) and governance of systems (patterns and configurations). 

So, that seems to be fairly comprehensive; but is it? Where does Business Intelligence fit in - is it part of the data management or system management - is it purely knowledge focused or does it also include transactional data? For that matter, do Data Warehouses only concern themselves with analytic data or can they be used to pass through transactional data to other consumers? And isn't Big Data both transactional and analytic in nature? And BTW- how do you model Big Data solutions either from a systems or data modeling standpoint? Now - we start to begin seeing how things can get confusing.

We also need to take into consideration that there has been an attempt made to standardize some of this from an industry perspective - it's referred to as the Data Management Book of Practice or DMBOK. I think in some ways it's been successful in attempting to lay out an industry taxonomy (much like ITIL did) but not as successful in linking that back into the practice of Data Architecture. The following diagram represents an attempt to map the two together...

There isn't a one to mapping between DMBOK and data architecture practice, but it's close

One of the areas that the DMBOK has fallen short is Big Data; my guess is that they will need to rethink their framework once again relatively soon to accommodate what's happening in the real world. In the diagram above, we have a somewhat idealized view in that we've targeted a unified governance approach for both data modeling and data systems.

Let's take a moment and discuss the challenges presented by the advent of new Big Data and BI technology. We'll start with BI - let's say your organization is using Oracle's BI suite - Oracle Business Intelligence Enterprise Edition (OBIEE). Within OBIEE you have a more or less semantic / metadata management tool called Common Enterprise Information Model (CEIM). It produces a file (or files) that maps out the business functionality of all the reports or dashboards associated with the solution. Where does that fit from an architecture standpoint? It has a modeling like interface but it isn't a 3rd normal form model or even a dimensional model. It represents a proprietary Oracle approach (both as an interface and modeling approach). It allows you to track dimensions, data hierarchies and data structures - so it is a viable architecture management tool for BI (at least for OBIEE instantiations). But some traditional Data Architecture groups would not view this as something the architects would manage - it might handed off to OBIEE administrators. This situation is not unique to Oracle of course, it applies to IBM / Cognos and other BI tools as well and there's a whole new class of tools that are completely driven by end users (rather than structured in advance from an IT group).

Now let's look at Big Data. Many of the Big Data tools require command line interface management and programming in order to create or change core data structures. There is no standard modeling approach for Big Data as it encompasses at least 5 different major approaches (as different say as 3NF is from Dimensional). How does an architecture group manage this? Right now, in most cases it's not managed as data architecture but more as data systems architecture. The problem here is obvious; just as organizations have finally gained some insight into the data they own or manage - a giant new elephant as entered the room. How is that new capability going to impact the rest of the enterprise - how can it be managed effectively?

Back to the original question - what is Data Architecture. I'd like to suggest that the practice of Data Architecture is more than the sum of its traditional activities. Data Architecture is the practice of understanding, managing and properly exploiting data in the context of problems any given organization has to solve. It is not limited by prior classifications or practice but has a consistent mandate to be able to represent and hopefully govern in some fashion data as an asset (internally or shared collaboratively). Data Architecture as we know is going to change quite a bit in the next two years and that's a very good thing.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Exploiting SharePoint as an Architecture Repository

Enterprise Architecture (EA) as a practice has gained quite a bit of traction over the past decade. Where EA hasn’t taken root yet, Solution Architecture is often practiced. One of the biggest challenges to the adoption of any type of IT Architecture practice or department is the ability to integrate it into the larger solutions lifecycle of any given organization. This is typically a challenge for the following reasons:

1. The culture of the organization isn’t sure about the value proposition for architecture.
2. The working model between architects and the rest of the solutions team isn’t always clear at the beginning.
3. The architecture practice / department lack the tools to do its work or properly communicate back to the rest of the organization.  

Of these three elements of the problem, we’re going to focus on the last one. Usually, there is always some level of resistance to doing anything new within an IT group and of course it takes time to find the right working models for how to implement new processes or capabilities. In the case of IT Architecture, having a tool available at or near the start-up of  a practice makes a huge difference though in helping to resolve the first two issues and ultimately will lead to greater overall success of the endeavor.

SharePoint as a repository is basic - but it does meet several core requirements

Architects tend to use a variety of tools to do their jobs; for example a typical EA may utilize the following software to support a typical data architecture project:

• Microsoft Visio – for free-form design / modeling
• CA ERwin – for ERD or dimensional modeling
• A UML tool – for developing Use Cases, Sequence Diagrams etc.
• Specific tools to support individual software packages (BI, Hadoop)
• Ontology Modeling or mind Mapping
• Network Design tools

All of these tools produce their own architecture “artifacts” or files. There is a also a class of software out that specifically tries to unify all of this information by providing both design interface and architecture repository. The best known of these tools includes IBM System Architect, TrouxMetaverse Mega and Sparx EA. There are quite a few advantages to using this type of software but surprisingly few architecture practices actually deploy them and often when they do try to deploy them they don’t “stick.” In other words, some aspect of the deployment fails or adoption is restricted for other reasons – for example due to a lack of licensing to make the architecture accessible to all of the stakeholders who actually need to be involved. So what happens when an organization deploys an IT architecture practice without any dedicated tool support for it?

In many cases, when an architecture group isn’t given clear guidance on what tools to use; the ability to define and develop clear processes becomes highly problematic. One of the first things an architecture practice or department ought to be doing is defining exactly what patterns or designs are standard for that organization. This set of decisions then tends to manifest itself into design templates in whatever tools happen to be available. Without any standard tools then it almost impossible to accomplish this vital step. Without standard views of the design patterns, then the ability to consistently capture design and apply it in a uniform fashion across projects suffers. The lack of design tool also tends to imply not having a repository as well. Without a repository, architecture artifacts then get managed as content by whatever means may be available in the enterprise:

• Shared folders
• CMS or portal
• QA or other backlog or PLM tools

Of these available options, the use of an existing Content Management / Portal capability represents the best opportunity for organizing an Architecture practice when a dedicated architecture  repository tool is unavailable. Shared folders have access issues and a serious lack of functionality and many QA/PLM also tools share the same cost issues associated with architecture repositories. While any CMS / Portal will work for what’s being described here; I’ve zeroed in on SharePoint due to the sheer volume of the enterprise organizations now using it. Those organizations that don’t already have

SharePoint deployed internally now also have access to SharePoint in the Cloud on Office 365 at fairly reasonable rates (although it takes a while to figure out how to order and configure the options focused on SharePoint only).

SharePoint isn’t always the easiest tool to work with, but it does support some of the key capabilities needed to help establish, unify and organize an IT Architecture practice; those include:

1. The ability to save and version control any type of content.
2. The ability to support complex publishing (e.g. through a basic wiki). 
3. Some application capability (in this case, through the use of List web parts in SharePoint).

While many or perhaps most installations of SharePoint don’t really support Collaboration very well, the SharePoint online solution is now being bundled with Yammer which opens this open up as the 4th major capability. Once you have your architecture “platform” in place, you can go back and align your designs process approach with the “public face” of the practice. A typical SharePoint Architecture site might include the following elements (see the diagram below):

• A Design Pattern Wiki – This is how stakeholders can access your architecture.
• A Business Glossary – This can include the ontology and core business terminology.
• Data Dictionary – This is where architecture meets data; very few organizations have comprehensive data dictionaries, even fewer make them available publicly.
• Architecture Governance Portal – Architecture requires both technical and business input – that Governance can be managed using simple web part Lists for tracking, approval etc.
• Technology Catalog – While SharePoint is not recommended as a comprehensive IT asset management solution, it can be used to capture all reference architectures and information about deployed technology (using a wiki and / or lists). 

In an upcoming post, we will talk more about how architecture patterns are managed using this type of approach or traditional EA repositories.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The Key Qualities of Effective Enterprise Roadmaps

One of the most important and challenging tasks that IT architects are often asked to participate in or even lead is the development of enterprise roadmaps. Roadmaps differ from schedules or integrated master schedules in that they are meant to represent the realization of capability goals rather than just merely tracking project tasks, milestones or intended delivery dates. Often times Enterprise Roadmaps do however provide the starting point or reference framework for all schedules related to the enterprise goals highlighted.

There is no standard format for a Roadmap because it is more than anything a Strategy, or a starting point for everything else that's to follow. More than that, Roadmaps are quite often used as "What If" tools as well - providing multiple potential paths to achieve organizational goals. There are quite a few software tools that provide various types of Road-mapping features. The types of tools most likely to have these features are Enterprise Architecture suites, but it is important to keep in mind that Roadmaps can be built from scratch if necessary.  An important question you might be asking yourself is why are Architects asked to contribute or lead this type of strategic activity; here's the answer:

1. Because Architects are tasked to manage the solution from a holistic perspective and thus must be involved to some extent in tempering the expectations of the organization in relation to what is or isn't technically feasible. It's generally customary to allow the person who must execute a plan to be involved in developing it.

2. Because most Architects are trained to be able to take complex situations and provide visual reference artifacts that help illustrate both the problem and the solution in an effective manner. Sometimes this is done using standard modeling notation, like UML, other times it's dictated by the feature sets of the software used to create Roadmaps. Sometimes though, it is completely unique - coming from the mind of the Architect.  The common denominator is the ability to take highly technical information and make it relevant and understandable to just about anyone without over-simplifying it to the point where its meaningless. This, as one might imagine, is a bit tricky.

3. Because Architects are trained to look for dependencies, constraints and risks at both a holistic and a detailed level. If this examination occurs up front during the Road-mapping process, the initiative has a much higher likelihood of success.

Once embarked on Road-mapping exercise, the most important qualities of a successful roadmap to strive for include:

1. The ability to illustrate capabilities in context (both with one another as well as existing constraints and future expectations of the organization in question).

2. The ability to illustrate sequential implementation while highlighting inter-dependencies. This of course doesn't have to be as detailed as an Integrated Master Schedule but it does need to be able to illustrate the highlights - those areas which will have the most impact or the greatest risk.

3. The ability to illustrate the core business challenges or problem sets being tackled.

4. The ability to properly define and prioritize chunks of capability.

5. The ability to visualize the roadmap in such a way to emphasize the linkage between core goals and outcomes.

6. The ability to serve as a communication tool or facilitation mechanism. (as the roadmap is often used to generate internal support or pursue funding)

7. A sense of realism and an understanding of the business impacts of what's being recommended. Architects are often the go-to resource when developing IT cost estimates and business case justifications because of this ability.

Building a Roadmap can be a daunting task, but putting the right people in charge is a good way to start.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Why Requirements Still Matter

IT Architects deal requirements in many contexts; there are requirements associated with the management of architecture itself, the requirements of the enterprise which drive an entire portfolio and the more specific detailed requirements associated with solution design. Today, we're going to examine the requirements in the context of Solution Architecture - a domain where Agile is sometimes interpreted as a "requirements-free zone."

These days, requirements management is often misunderstood or under-appreciated in IT. Many people have used migration to Agile methodologies as an excuse to discard requirements or rethink how they’re used to support most projects.

In the overall lifecycle of lifecycles, requirements becomes critical in establishing traceability

One of the key tenets of Agile application development is not to over-think technical requirements in advance. The premise is that it’s usually impossible to accurately predict the details, which would invariably lead to costly rework after the fact—as opposed to an Agile approach of incremental refinement.

So who’s right? Do Agile advocates make a convincing case that a too-precise definition of requirements is counterproductive, or does the more traditional view of requirements management make more sense? Before we answer that question, let’s review several pertinent factors:

• Not all IT projects involve coding (for example, software development).
• Even Agile methodology includes some level of requirements definition.
• Many, if not most, organizations track “functional” level business requirements, a task usually managed by business analysts.
• The majority of people who collect and manage requirements don’t follow a specific methodology, since it’s often considered less important than the follow-on development or implementation activities. What’s more, most people don’t realize that requirements management is a collaborative activity.

Maybe both camps are wrong, or perhaps both approaches suffer from a similar flaw. Traditional requirements management and Agile requirements represent two ends of a spectrum—and each assumes the other end is ineffective.

Common Ground

As in most things, the truth lies somewhere in between. Not all requirements are the same, so they shouldn’t all be managed the same way. Either camp could go wrong in this area. Also, the main reason that requirements management has come under criticism isn’t that defining solutions up front is intrinsically wrong, it’s that defining solutions out of context is.

Followers of both traditional Waterfall and Agile techniques can fail to define solutions in context. The difference is that with Agile, the flawed results are more likely to be noticed early. Context can be lost when a team develops requirements without:

• End-user input
• Stakeholder input
• Use cases and test cases
• Mechanisms for validation and incremental development
• Integration of business and technical requirements processes.

It’s worth pointing out that the controversy over whether requirements management is a worthwhile practice hasn’t led to widespread insight into how it can be corrected. Instead, it has led to sporadic use of requirements or a complete disregard for them. Meanwhile, even with Agile, the success rates of IT projects haven’t improved all that much.

The Best of Both Worlds

Requirements management is the most logical place to integrate business and technical processes and teams. Instead of moving from one either/or philosophy to another, we should take the best elements of each camp and create a better approach.

Far from abandoning requirements as a central part of every project, it’s time to start advocating their use in all projects. Here’s why: Requirements are the foundation of all good design and architecture, all portfolio and project management, and all project or solution collaboration. If compiled properly, they capture vision and thinking from a diverse spectrum of team members and document the solution as it’s progressing.

As we said, not all projects need to apply requirements the same way. Conditional requirement approaches might be applied to these project categories:

• Pure Development: Little or no code reuse. This might involve a more Agile approach, including more experimentation and more test-driven or scenario-driven requirements.
• Commodity Development: Significant use of existing libraries or software packages. This might focus more on integration and performance requirements. For example, an existing knowledge base may support more detailed technical requirements.
• User Interface-Driven Solutions: Much more focused on event-driven expectations and extensive user stories.

Requirements don’t have to predict all aspects of a solution, and they can be corrected or updated as the solution emerges. They can easily become evolutionary in nature. The bottom line is, don’t skip them. Compiling them now can save you a lot of trouble later.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The Practice of Architecture Assessments

One of the most common tasks that an IT Architect will be asked to do across the course of their career is the Architecture Assessment. It is more common to conduct these if one is working as a consultant rather than an architect on an internal team, but even in those instances it is likely that an IT Architect will have to perform at least a few of these.

In the context of a larger solution lifecycle, the Architecture Assessment tends to occur most often in the initial phases (Discover, Analyse etc.), however assessments can occur at any point within the lifecycle as part of a problem-solving exercise or can occur entirely outside of the scope of any given solutions lifecycle. Assessments are disproportionately (in relation to time / dollars invested) important activities for a number of reasons:

1. It represents a dedicated effort to validate or discount core assumptions
2. It provides a mechanism for honest feedback (w/o fear of retribution)
3. It allows for rapid problem-solving and design exercises in environments where that might not otherwise occur.

Assessments are not a clear part of any particular EA Framework methodology (they may be implied in some sense), however that doesn't mean that they should be conducted in a haphazard manner. Assessments should be planned, estimated and designed in order to provide clear outcomes (be they recommendations, design deliverables or both).

Problem Space analysis is one of the techniques used with assessments - it can apply
both to the business and technical aspects of a project

An Architecture Assessment is also different than other traditional Architecture activities in that the expectation is generally that third-party personnel are more likely to perform them. The reasons for this include the following:

1. Assessments are one of the key tools involved in IT oversight activities (sometimes referred to as Independent Validation and Verification or IV&V).
2. It is more likely that an accurate assessment can be obtained by architects / investigators without a vested interest in the project. 
3. The skillset of the person doing the assessment is critical - it needs to be an architect and not merely a technical or product expert. This is the only way to ensure that all options / alternatives are properly considered / assessed. 

So what exactly is an Architecture Assessment? A typical assessment tends to include the following categories of activity:

• Information Gathering  
• Design & Project Review
• Design & Project Recommendations

An assessment also typically includes one or more types of specific analysis as well:

• Analysis of Alternatives
• Root Cause Analysis
• What if Analysis
• Feasibility Analysis
• Trade off Analysis
• Problem Space Definition & Resolution 

One way to capture alternatives is through Decision Trees.

Perhaps the most important function that an Architecture Assessment can provide is a mechanism to challenge assumptions and combat complacency. One of the main reasons that IT projects fail today is because there is generally no incentive or expectation to raise issues or problems. Rather than being viewed as a healthy activity - identification of the problems is feared in itself and thus ensures even more pain later on when the issue finally surfaces (which they always do).

When compared to the cost of the rest of a typical IT project (and any potential loss or cost overruns associated with problems that aren't identified or managed in a timely fashion), a relatively brief assessment exercise is generally less than 1% of total cost yet could make the difference between success or failure...

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

The Top Questions in a Build vs. Buy Analysis

Software is the lifeblood of most IT departments. So it’s logical that determining when to buy a packaged solution versus building a custom one for a given business requirement is one of the most common types of decisions they have to make. A "Build vs. Buy analysis" often represents a key component in a typical Architecture Assessment.

Usually, making the “Buy versus Build” decision involves both technical and business resources. How it’s done varies greatly from one enterprise to the next. Some organizations spend a significant amount of time deciding, while others focus more on analyzing the “buy” choices once it’s been determined that custom development isn’t going to happen. Still others bypass most of the process altogether and dive head first into a “buy” commitment.

For the folks who know for sure that they’ll be buying, the big question is often, “When?” This post will focus on situations where the buy decision hasn’t yet been made.

The Architect’s Role

IT architects are often asked to help facilitate the process. While they’re usually not the ones charged with making the decision, they’re often the people who provide the recommendation. If there is to be any formal analysis process, then the architect tends to conduct it.

Making the build-versus-buy decision necessarily precedes any product selection process. It should – but doesn’t always — come after some sort of preliminary needs assessment or strategy activity. If a strategy was developed, the capability might be defined at a functional level and even sequenced on a roadmap, though not defined in very much detail. The more information, the better of course, but even if there’s relatively little data to start with, some of the key questions you’ll need to ask will remain the same.

So, what are the most important questions to ask when approaching a Build vs. Buy analysis?

1. Is it really just build versus buy, or is it more complex? In other words, is there a third or even fourth option to include in your analysis? The most common of these include do nothing (or don’t do it yet) and build some, buy some (then you have to determine what proportion for each). It’s understood that many types of Commercial Off the Shelf Software, or COTS, are meant to be customized somewhat – like when you build reports in Cognos or Oracle BI tools. Other COTS require or allow very little customization. Understanding how customization ought to occur and how it’s handled in a particular package is vital to making an accurate assessment.
2. Is the solution redundant with an existing capability (either custom or COTS) and if so, is there a logical migration path to the new capability? And how will that transition be impacted by the buy versus build decision? This question generally implies that a transformation is in progress, and that usually involves added dependencies and constraints.
3. Do you already have a support model in operation or one in the works? For example, if you are thinking about expanding existing Oracle e-business applications, then having an Oracle standard LDAP tool might make more sense than a homegrown one. Also, support includes having people on-site or off who can troubleshoot issues for you in near-real time.
4. Does the business case (or basic proposition) align better with one option versus another? If the value proposition is that some type of ERP-like capability is needed near-term, then building something homegrown might be faster than deploying a major ERP COTS package.
5. Is your organization capable of delivering a custom solution based on the stated requirements? Not every IT shop can do everything – understanding your internal limitations will make a big difference in the overall solution. By the same token, some internal groups will place limits on what COTS (or even hardware needed by COTS) they will support.
6. What is the overall cost of doing one option versus another? Some folks refer to this as “Total Cost of Ownership.” It usually reflects the full lifetime expense related to the solution. It’s obviously more difficult to estimate this up front for a custom solution than it is for COTS, but that doesn’t mean that the COTS approach is always cheaper. Very often, answering this correctly requires some advance work in understanding support costs for existing systems in your own environment.
7. If someone expressed an initial expectation or preference up front, validate why. This is fairly important as it may indicate that the buy or build decision has been more or less made before the analysis even began. In this type of situation, the stakeholders may want the analysis mainly to provide support for and a risk assessment of their initial decision. So, you might ask yourself, what if the stakeholders’ initial decision is wrong? That’s a tricky situation since you generally don’t want to be in the habit of trying to deny the wishes of your employers. However, if you feel that there is a serious issue surrounding their direction, document it in the risks and note the possible mitigation that choosing alternatives might provide.

The format you use to highlight the results of the analysis can vary. More often than not, PowerPoint is used to convey the key results of the activity back to the stakeholders. In that presentation, capture the following elements:

1. Description of the Requirement.
2. Goals for the Analysis (and Process).
3. Description of the Technical “Problem Space” / Context.
4. Identification of Options (Build versus Buy, or More).
5. Ratings Matrix (with Explanation of Weights / Priority Applied).
6. Solution Recommendation.
7. Risk Assessment and Issues.

When conducting an analysis like this, the most important thing to remember is that there often aren’t slam dunk answers. In other words, the advantages between one versus another option may not be overwhelming. There may also be trade-offs to consider that help refine the recommendation. Ultimately, the answer that comes closest to being accurate is the one that assimilates client needs and constraints the best.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Understanding Master Data Management

I was speaking with someone before on the topic of Master Data Management (MDM) - it occurred to me not too long after we began the conversation that we more than likely had differing perspectives as to what Master Data Management really meant. That's inspired me to write this post to talk a little bit about how better to understand MDM.

MDM is one of the key focal or practice areas for Data Architects today; although the overall success rate for Master Data Management is not as high as it should be given the number of years it has been an industry standard solution. There are many reasons for this and we will address those in greater depth in future posts.

MDM, The Core Concept:Let's start with what Master Data is not, Master data is not:

1. Meta-data, which is a description  of data  (or data about data as it's commonly referred to as).
2. Ontology,  Taxonomy or Vocabulary - Master data can be derived from these but is not in itself a      formal semantic construct.
3. Software Tool - ultimately, Master Data is technology-agnostic; it is a logical construct which can be defined through various modeling tools and realized through a variety of data management software solutions.  At the point where Master Data becomes tightly coupled with any one software tool or any one modeling technique it will likely loose a great deal of its potential value to the enterprise.

So, then what is it? How would we characterize what can become Master Data or not ?

1. It may be considered "data of record" or an authoritative data source, but it might not be also. Data of record implies that there is a system of record with sanctioned data elements that are not meant to be repeated throughout the enterprise across other systems. Or this might refer to data entities which are determined to be unique and authoritative across the enterprise regardless of their current use (in a system).
2. Master data is reference data, sort of. If we consider that reference data is a definitive set of element definitions or entities associated with any particular business domain, sub-domain or problem space. In this capacity, Master Data may serve multiple roles, including: discovery, registry or repository access, data dictionary foundation.
3. Benchmark - this is a critical consideration; any data entities defined as Master Data elements within an enterprise are unlikely to remain unchanged or unmodified. Eventually there will be variations of Master Data sets, these variations must be tracked back to their source and there must also be a mechanism whereby others in the enterprise can understand where, why and how those modifications occurred 'atop' the core sets of Master Data. Thus the Master Data is a baseline or benchmark wherein the data chain of custody can be managed or tracked. 
4. It can be a canonical data model or data exchange model - this is important in cases where the core data architecture has not yet been designed or deployed, or in cases where it is anticipated that there will be a major or radical transformation of the existing architecture to a new one. The model can contain Master Data elements or sets within it.

MDM in Today's Implementations
Much of what we refer to now as MDM solutions have been borne out of previous product solutions that were describe as meta-data management solutions. For many of the MDM solutions on the market, the "repository or registry" architectural construct / pattern is how this capability is harnessed.  Another architectural approach related to MDM might be referred to as the middleware design - this extends MDM into data transport and is focused on supporting accurate message translation. And of course there are solutions that combine both aspects.

One of the most important aspects of MDM is identifying what constitutes Master and Reference Data

Perhaps we can consider that there are at least two philosophical approaches to MDM:

• Passive MDM - This is most closely aligned to the original Meta-data management solutions with a central repository to support discovery and high level data reconciliation.
• Active MDM - This is most closely aligned with solutions stemming from EAI, Middleware, ETL based solutions where data reconciliation rules are being applied at multiple levels and in more detail.
• Hybrid MDM - Both solutions are relatively weak in dealing with bi-directional reconciliation focused heavily on transactional systems (it is much easier to reconcile historical data from multiple sources than real-time data from multiple sources).  Hybrid MDM applies both previous techniques and new ones to tackle the most problematic use cases.

It is clear to anyone who has worked with database development and data-system integration that having the ability to reconcile data sources adds tremendous value to the enterprise helping to improve performance, integrity and overall efficiency. Being able to do some of this automation using COTS tools is even more appealing, however there is still a set of processes which ultimately takes precedence here if one is to deploy a successful MDM solution. The enterprise data governance approach must be defined first, the data and business environment must be modeled and if ownership of data sets is to be handed off to user groups (either fully or partially) the impact to both governance and model maintenance must be considered and mitigated in advance.

As we've discovered with nearly every IT technology and product over the past 40 years - implementation without process or architectural considerations leads to many issues, often more issues than existed before the technology was introduced.  This is no exception with MDM - the most important thing to consider here is that deployment of MDM software can significantly impact or influence both solution performance and integrity but proceeding without working through the implicit architectural / enterprise issues is risky.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More