One of the biggest challenge for an enterprise architect is ‘How does SOA fit in Enterprise Architecture?’. Should this be an issue? After all the architecture frameworks like TOGAF who have very open implementation and should be able to support to SOA by default. A deeper analysis reveals that one has to extend TOGAF to implement SOA it its true spirit.
In this article we will look at how to incorporate SOA in TOGAF ADM (Architecture Development Method). TOGAF is a very open and probably most comprehensive enterprise architecture framework available today, it is defined by ‘The Open Group’ and more information is available at http://www.opengroup.org/togaf/.
First let us look at where are the difference between SOA and TOGAF? At philosophical level they differ in two main areas:
(a) TOGAF is mostly a top down approach, while SOA is cross of ‘Top Down’ and ‘Bottom Up’ approach. Given that most of the SOA implementations are not new development but reuse of existing applications, they tend to be ‘Meet in the Middle’ implementations.
(b) TOGAF considers ‘Requirements Management’ as central theme and builds various architecture phases around it. In SOA world there are a larger number of stake holders and interest groups, service interfaces and agreements have central role, leading to governance being the central theme.
Considering these difference one needs to extend TOGAF, and I suggest the following approach to ADM based SOA:
In this model there is a tighter coupling between Business Architecture, Information Systems Architecture, Technology Architecture and Opportunity and Solutions, and they have been represented as a single block ‘Service Architecture and Design’. The idea is to show the more iterative approach between these phases and the direct impact they have on each other. Using this approach the capabilities of the existing systems start influencing overall architecture at much earlier stage, more like a bottom-up approach and the iterative implementation makes it ‘Meet in the Middle’. Also given that with new more powerful devices are providing capabilities which once were exquisite domain of applications, there needs to be a closer co-ordination between Systems Architecture and Technology Architecture.
The other main point not note is that Service Agreements along with Requirements are treated as central to all phases and governance need to be applied at all stages.