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?