As Service Oriented Architecture (SOA) has evolved an opportunity to close the gap between the Business Architecture and Technical Architecture. This is however not realizable by just “adding” SOA to an existing EA program. SOA will change EA, and if not aware of this challenge introducing SOA into an organization is sure to fail. SOA has gone through an exceptional evolution during the last couple of years, not only in terms of the hype that often follows new paradigms, more importantly the very conception of SOA has evolved. This evolution has changed the level of abstraction on which SOA operates; it has evolved from a technical discipline to encompass some of the aspects normally seen as key elements of the discipline of Enterprise Architecture (EA). The reason for SOA transition into the discipline of EA lies in the goals of EA and SOA, which are fundamentally identical. The goal of EA within an organization has been described through the use of different maturity models, these maturity models are essentially “the normal path” of EA. Maturity models for SOA are also starting to emerge, but as augmented in this article, the goals of EA and SOA are the same. It is necessary to align the paths of EA and SOA on a common path. To do this it is necessary to identify where EA and SOA correlate so that redundant work is eliminated. One of the main challenges here is to acknowledge that SOA will create artifacts similar to EA. Who owns these artifacts? Are they a part of EA or SOA? The discussion of whether SOA is part of EA, or EA is part of SOA is probably a matter or perspective – they change each other. A change of such proportions that it must be taken into consideration if this change is in fact not a new discipline. This article advocates for the correlation of EA and SOA is resulting in a special type of EA and SOA called Service Oriented Enterprise Architecture.
Journal of Enterprise Architecture