Enterprise Architecture, TOGAF and SOA

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.

SOA as a cost cutting tool

‘Cost kills initiative’ is a common occurrence in most of the IT departments. SOA being a newer technology has its own challenges and costs, so should SOA be treated like an investment, whose benefits of will be available at some point in future. The truth is SOA like any other evolution has its plus and minus and if properly planned and executed can be an effective cost cutting tool; before we get into that, let us look at how costs build up in an IT organization and how SOA can affect that.

Any initiative requires process, people and technology for its actualization. Process and technology again in turn require people to support it. The whole support chain leads to requirement of ‘Specialty Teams’ or ‘Center of Excellences’. Each such team is basically a cost center having equipment, office, power, communication, infrastructure and management costs. So the easiest way to cut costs is to reduce the number of the ‘Specialty Teams’. SOA is technology evolution of loosely coupling system using standards. The emphasis is on standards, leading to creation of ‘Specialty Teams’ which are aligned with industry and current trends and best of all could be shared across multiple initiatives, sharing being the second biggest benefit of SOA.

Also the ‘Specialty Teams’ need people with special skills meaning a specialist in that specific technology or process. On an average a specialist costs at least two times than a generalist who has similar experience but not the in-depth knowledge of that particular subject. Also generalists are easier to find than specialists. As SOA advocates standards the ‘Specialist Teams’ support technology and process which themselves are standards, thus replacing the need for an specific technology specialist with SOA technologist. For now SOA technologist are specialists, but with the adoption rate continuously going up pretty soon they will be considered as generalists, mush like Web Programmers, only a few years back they were considered specialists and hard to find.

The third biggest area where SOA helps in reducing cost is by promoting resource and infrastructure sharing, it work the same way as corporate having technology standards. As over a period of time more and more projects use same technology (SOA) they can use resources from a shared pool reducing the ‘Total Cost of Ownership’ across the projects. It is different story to get the first project to build that infrastructure in most of America as the cost and return on investment is calculated on per project basis, scaring away the any project manager from being the first project.

Probably the most touted and most understood cost benefit of SOA is in the way the applications and projects are designed and developed themselves, having reusable components, which can have their own lifecycle, leading to smaller, and more manageable, more reusable components.

Another not much discussed benefit of SOA is the loose coupling it provides between provider and consumer, which helps in changing the provider implementation without impacting the consumer. This has tremendous potential in terms of cost saving where changing or upgrading a provider implementation is a regular phenomenon.

Hi,

My name is Raj Arora and I’ve been around 12 years as an enterprise architect with last 5 years focused on SOA and governance.  I’ve been working on application development integration stuff for 22 years or so and I guess that makes me an ancient man… and I lead a couple of software product development and support teams back in India for banking industry. Both the products did pretty well, one had an installation base of about 60,000 and other of about 100,000.

I am new to blogging but from the other blogs I’ve read, I think I can do this!  I am going to try to type in a lot of my thoughts on a regular basis… I know easily said than done, wish me luck..

Raj

Need for a SOA framework?

Yesterday an old friend of mine asked if I could suggest a framework for SOA. Isn’t SOA an Application Architecture Evolution and not a technology, so can there be frameworks for it? But having worked with him over multiple years and having deep respect for his technology prowess, I had to give it a second thought. In the end when rubber-meets-the-road and architecture moves from concepts to its actualization, it needs to be guided by frameworks and patterns. So it is very much legit to talk of patterns and frameworks for SOA, a purist will probably kill me for it.

I have always been a big fan of frameworks, Wikipedia defines them as “basic conceptual structure used to solve or address complex issues”. Remaining in this definition, first thing one has to talk about is what is the problem set the framework is supposed to solve. Different situations have different problem sets, so no one framework can meet the requirements of varied situations. SOA is complex and covers complete gambit of an organization and it is defined on following dimensions:

• Organizational Readiness
• Approach to SOA
• People
• Governance
• Processes
• Architecture
• Technology
• Tools
• Infrastructure
• Operations
  

I can talk about frameworks and patterns for each of these area but with due respect to my friend I will restrict it to Technology and Tools . From the breadth of questions, I have seen following reoccur more often and are good fit for defining initial requirements for a framework:

• Will service be always called using XML data format or the clients can use NV, Binary (FastInfoset) data formats?
• Is there a need to support service chaining, passing of clients session and context may be required between services?
• Can a client running on the same machine by pass the overheads of a network call and make a local call the service implementation?
• Should service support both SOAP or REST message protocols?
• Should service support Synchronous / Asynchronous calls?
• Should service always validate the incoming data or can it by-pass validation from a set of trusted sources?
• How the changes in service implementations will be managed through versioning and how the Incompatible versions will be managed?
• Can the choice of implementation (configuration) separated out from design giving maximum flexibility?
• Does service require authentication and authorization and is this required for all consumers or can be ignored for trusted consumers?
• How the error will reported back to consumers as SOAP fault or as part of response?
• How will service be monitored?
• Can a execution rate of a service be limited in case of a system overload?
• How is a service metrics acquired for SLA management?
• 
  

This are a very wide range of requirements and in my limited knowledge, I have not come across a single tool or technology which covers every one of them. Does this mean that the only choice is custom framework, which anybody who has written one knows is very costly, challenging and at times frustrating process. Given that not all the above requirements apply to all, you may get a tool or framework which meets your requirements, but the odds are not good for such a good fortune. Most of the bigger SOA implementation sites I know of have taken a tool like Axis or Spring and build custom tooling around it. You may want to do that if you are looking for long term investments, but for shorter terms I will recommend using either a free tool like Axis/Spring or a commercial product like Weblogic , Websphere and building scripts around them. Over a period of time move to your own tooling by enhancing it functionality-by-functionality.