Meant for Each Other: Enterprise Architecture and SOA
Enterprise Architecture is an infrastructure and a set of Machines constructed in order to manage a chaotic, dynamic, unpredictable, complex, organic, prone to error, frustrating, Enterprise IT, which has to support an ever increasing, dynamic portfolio of products and services, through constant "ASAP, Now, Right-Away" modifications of business processes.
That is a formulation of my practical experience, as described in The Rise of the Machines: A new Approach to Enterprise Architecture. The outcome of an Enterprise Architecture is a Management Framework upon which, or rather, inside which, the Enterprise lives; physically.
Yet, if you consider the usual approach to Enterprise Architecture, you'd normally find committees, standards, governance, and smart people being in the confirmation pipe of business and technological initiatives.
Under this paradigm, the success of an EA Office is measured by the popularity of its staff members and of its guidelines and procedures. And see this Extended Enterprise Architecture Maturity Model to have an idea of what I mean.
Nevertheless, some recently published articles (see References) started a discussion around the differences and the similarities that exist between Enterprise Service-Oriented Architecture and Enterprise Architecture.
I believe these thoughts will finally change the perception of both EA and SOA: EA will shake off its image as a "documentation, procedures and guidelines" body, repositioning itself as a practical, implementation-oriented discipline aimed at the creation of an Enterprise Management Infrastructure, while SOA will be repositioned, no longer as an Integration/Interoperability architecture, but rather as an Enterprise Management architecture.
That being said, it's no wonder that hardly a week goes by without an industry expert maintaining another piece is missing in the current SOA offerings (which are still integration-oriented). Recently in the Lost & Found section one could find Registries/Repositories, Information Management, Events, Semantics & Ontologies and so forth.
But for "SOA as the ultimate foundation for Enerprise Management" – an approach I've been practicing for years now - there's nothing new in all these experts' discoveries. One cannot manage without knowing what the managed objects are, including their inter-relations (=repository/cmdb). To manage heterogeneous and distributed objects, an agreement must exist on the managerial language (ontology) and its different, contextual semantics (policies); the manager should make its decisions based on pre-defined rules (Business Rules Engines, policies) and if a real-time managerial response is required, it must be listening to events (event-based).
There are, clearly, other infrastructures and machines to add to this picture. For instance, grid/utility computing is an essential part in the real-time Enterprise, for the Manager has to dynamically allocate and decommission resources (any kind of resource: human, software, hardware) as the need arise. Don't be surprised than to find, any day now, grid in the SOA lost & found – it is a natural progress for SOA in its way to become an Enterprise Architecture.
I would like, therefore, to proceed from the EA/SOA convergence point and propose a new acid test - a simple requirement, that if met, we can mark √ on our Enterprise Architecture (as an Infrastructure and a set of machines :) ) endeavor. That will be the subject of my next post.
The sequel to this post is An Acid Test for Enterprise Architecture
Koch's IT Strategy: Enterprise Architecture vs. SOA: Pick the Winner
Real World SOA: Is SOA a Part of Enterprise Architecture, or Does it Replace it?
By 3:53 PM, at
Muli - Just discovered your blog and it's great. Looking forward to the next post, when the acid test is unveiled...
Muli - Excellent post and EA definition. I added your definition to my soon-to-be-expanded list of EA definitions...:)
Great summary, and interesting thoughts on the evolution of EA - help keep it moving away from it's ceremonial past...
Great Blog. I like your article about social pressure.
You said 'there is nothing new'. Every time I present S.O.A. to architects they say that there is nothing new and that they never have done their job differently. At the end of the day, why are current EA so complex, not flexible at all ?
I think that there is something new with Web Services & SOA : the same standard worldwide, and the benefits are much more important than a service oriented approach. This lead to the same revolution as the Internet. S.O.A standardize machine to machine interactions the same way HTML standardize man to machine interaction.
It has never been done before.
Shahar, Scott, François: Thanks for dropping by. Robert, Dan and Aurélien, you're "returning customers" already :), so double thanks here for your company.
François, as to your comment: assuming that by "standards" you referred to WS-* (and not to REST, POX, RSS… which all assist in the machine-to-machine interactions), I do not share your enthusiasm… it's too complex for me. Still, I do think that the idea behind "Web Services" is fabulous and that together with XML (this time not as an idea, but rather as a concrete, working standard) they are as dramatic in their contribution to our life as HTML was. As for the WS-* - well, I have written in this blog some detailed posts about their angst.
I share your opinion. By "standards", I referred to HTTP, XHTML, CSS (real standards widely deployed), so REST/RSS.
WS-* are more software vendors standards rather than real standards. Let's read my comment with this in mind and I think we share the same enthusiasm.
The fact is that software vendors quickly understood that to continue to sell their infrastructure products, they had to add 'standard' and 'open' on the boxes...
Neither let someone say that Web Services = SOAP. Web Services are XML over HTTP calls. :-)