Linthicum’s Challenge: Where does SOA stop and EA start?

Tom Graves, David Linthicum, and I recently got into an interesting discussion on Twitter as the result of a, EBiz blog post by David, where he makes the statement that Good SOA is the same as Good EA.  (See 'Do SOA and enterprise architecture now mean the same thing?' Yes, they do’).  Both Tom and I maintain that SOA is a good practice for an EA to endorse, but that it does not equate to good EA.  In this post, I’ll answer the question “why?”

I’ll include the last few tweets for context.  Tom started the thread by noting that he disagreed with David’s premise. I joined in.

nickmalik thx @tetradian for pointing out @DavidLinthicum - SOA *is* good IT arch but EA is far more than IT arch, so SOA != EA.

Tom noted

tetradian @DavidLinthicum SOA is a (useful) *style* of architecture, not architecture itself - EA must include what happens when the power goes down

David replied, quoting my tweet and responding (emphasis added):

DavidLinthicum RT @nickmalik & @tetradian SOA *is* good IT arch but EA is far more than IT arch, so SOA != EA.<-Love to hear where SOA stops and EA starts.

So this post is about answering David’s question: where does SOA stop and EA start?

Let’s start with the mission of Enterprise Architecture.  In a prior post, I discussed the mission, vision, and business capabilities of Enterprise Architecture.  To quote from that prior post:

Enterprise Architecture exists to do two things:

1. to Envision an organization that includes the strategic and operational changes that leaders require and demand, and
2. to Guide changes to the structure of the organization, and the actions of the business units themselves, so that the vision becomes reality.

Look carefully.  Do you see anything about SOA in that mission… or even information technology? 

Enterprise Architecture envisions an organization in its entirety (structures, responsibilities, roles, processes, systems, information, and technologies).  We don’t get to choose to ignore some parts of the puzzle and focus on other parts.  When you solve a problem, you have to consider all of the factors that will come into play.  Enterprise Architecture is accountable for guiding changes to organizations where those changes are necessary to solve a problem. 

What problems are we solving?  Usually, we focus on problems created when an organization is not ready… ready to respond to a new business strategy, ready to respond to a competitive threat, ready to respond to a market opportunity, ready to respond to change.  There are many ways to focus on the problems of the business.  Below are a few that fall within the scope of Enterprise Architecture:

1. To make sure that the business has decision making mechanisms in place that create trust, apportion accountabilities, measure and report on results, and encourage accountability. 
2. To make sure that the organization’s abilities (and flaws) are well understood and documented, so that when a change is proposed, valid and useful information is available to the business to make decisions, approach trade-offs, and focus resources on the specific issues that could prevent the business from making that change. 
3. To make sure that the business frames their strategies and goals in a manner that is aligned with their intent, are prioritized to minimize internal conflicts, and clarifies the specific, measurable, actionable, realistic, and time-bound (SMART) tactics that must be implemented in order to make them come to pass.
4. To insure that potential innovations in the marketplace, environment, and competitive space have a fair and reasonable mechanism for being considered.  This has the effect of creating the “funnel of ideas” that the IT group can use to feed in potential technical innovations.  The same funnel, BTW, is used to feed in information about competitive threats, new business opportunities, product innovations, etc.
5. To insure that appropriate models of information are created and to guide the development of information management practices that help to reduce the complexity and difficulty of managing the consistency, accuracy, reliability, timeliness, and security of the information assets of the business.
6. To insure that the processes used by the business to perform core or supporting business functions are well understood, and that the appropriate attention is paid to making process improvements when the business strategy demands it.
7. To guide the development of business services that allow for the simple composition of business processes in such a way that the information can flow readily to the appropriate people, that the customer is delighted with the result, and that the stated business goals of the business can be met in a timely and agile manner.
8. To guide the development of technology services that allow for the simple composition of business systems in such a way that the systems are reliable, available, and appropriately manageable, so that the business is not constrained in their ability to create the necessary compositions implied in the prior step.

Depending on how you define SOA, Service Oriented Architecture is either item 7 (business services) and 8 (information services), or just item 8 (information services), in the list above.  Occasionally, SOA is used to describe a mechanism that can support item 5 (information quality mgmt), but recognize that SOA, at its finest, is not sufficient to actually accomplish that item.  It is useful, and very valuable, but not sufficient. 

So, David, the answer to your question… what does EA do that rises above and beyond SOA?  The answer is listed in items 1, 2, 3, 4, 5, 6, and depending on your definition of SOA, 7 above. 

Other than that, SOA is really great.