EA + SOA = SOEA ?

The two concepts Enterprise Architecture and Service-Oriented Architecture are merging. I’m tagging more and more links to both the EA and the SOA categories in my GotzeTagged.

In DMReview’s Enterprise Architecture and Service-Oriented Architecture Fad or Foundation? Part 1, Rex Brooks and Russell Ruggiero writes:

… to truly see the outlines and parameters of what is called EA, and from that perspective begin to understand how a SOA enables an EA, we need to get up to suborbital or low orbit viewpoint at least, and it could be argued that we need to get all the way out to the viewpoint of our moon to see the entire environment within which these concepts work. The fact is that the word enterprise is by no means restricted to a business, or even an industry, nor does it refer to a particular time in the life of an organization. The enterprise encompasses the entire life cycle of an organization or an organism.

Brooks and Ruggiero talk about the perspective of the economic or ecological lifecycle, and finds that in EA today, we need to be explicit and put in place the kinds of mechanisms that can conduct constant review and institute quality assurance as a matter of course and, in effect, institutionalize the cycle of build, use, learn, assess, build (adjust/rebuild), use, learn, etc., ad infinitum.

I look forward to Part 2 of this story.

In the same direction, CBDi Journal’s March issue offers Enterprise Framework for SOA by David Sprott and Lawrence Wilkes, who present a generic approach to integrating the SOA framework requirements with existing frameworks (including Zachman).

SOA is the enabler for contextualising the enterprise in various domains, including what Sprott and Wilkes calls federated ecosystems.

No EA without a focus on standardisation, and here SOA offers some real challenges. But SOA is also promising a lot, being standards-based in its nature.

In Where Open Standards Fit into the Application Integration Puzzle, Linthicum et al suggest a categorization of open standards:

• Service standards (WS-* ?)
• Format standards (e.g., “EDI, XML and SOAP”)
• Orchestration standards (e.g., BPEL)

The information-oriented application integration approach of today emphasises format standards, Linthicum et al notes, and suggest that tomorrow’s approach must be an orchestration-oriented application integration, which they describe as follows:

However, as we’re getting better at real time information exchange between systems, the trend has been to view application integration at a higher level of abstraction, or through business processes or services. This approach allows those exchanging information between various applications to view the information flow in the context of a business model, or business processes that define business logic, sequence, sub-processes, hierarchies of processes, etc. In other words, the ability to control application integration through abstract business process automation abstractions that also accounts for lower level mechanisms such as transformation and intelligent routing.

Hmmmmm. I am not sure these abstract abstrations are the best explanation, I’ve heard, but I do agree that we need to move towards a new approach.

In many ways, I support the ideas behind orchestration-orientation, but I also think that there is a need to focus on service-orientation and the service standards, and indeed also to talk about format standards.

So, all the standards are in play, is what I am suggesting. Nothing’s sacred. But, as Tim Bray reminds us (via Dave Winer):

You have to shoot the engineers and ship at some point, right?

The argument is that a standard shouldn’t change all the time. XML is just XML 1.0 and it’s good that XML was frozen (XML1.1 never worked), because now we have a core, common format standard, on which we can build both service standards and orchestration standards.