March 10, 2007 Leave a comment
There are bushmen wandering in the Kalahari who have heard the term SOA. It has been an industry buzzword for the last 3 – 4 years. However, definitions of SOA are as varied as they are widely spread. To try to untangle these definitions we need to start from the ground up.
Services are simply the next evolution in how we write code. They are the next level of abstraction, the next unit of re-use and encapsulation and the next software paradigm. 10 years ago we talked about objects, 5 years ago it was components and now it is services.
Service Orientation is to services as object orientation was to objects. When we build applications in a service orientated manner we are thinking about our application in terms of the interaction between services. Where we had APIs we have service contracts and where we had shared types we have schemas or data contracts. Instead of clients and servers we have service consumers and service providers.
This explains some of the confusion that surrounds the acronym SOA. When some people are talking about SOA they mean Service Oriented Applications and Service Orientation in general as opposed to Service Oriented Architecture. Another factor that adds confusion is that SOA and Web Services have been used interchangeably to mean the same thing when actually it is quite possible to develop service oriented applications and design service oriented architecture without using web services at all.
Finally we come to SOA where SOA stands for Service Oriented Architecture. This has almost nothing to do with the software development concepts we have just discussed because the “Services” are not the same. In Service Oriented Architecture the services are Business Services and SOA in this context means “architecting” your IT infrastructure so that it is both strategically aligned with and decoupled from the business services it supports. While Service Orientation is a technology that can facilitate this architectural decoupling from a software perspective, they are not the same thing.
The reason we are all obsessed by decoupling these days has to do with complexity. Both the business and IT challenges we face are inherently and increasingly complex. Complexity is here to stay. The people who handle complexity most efficiently and robustly will win whether it’s because they are fastest to market or incur the lowest costs or offer the greatest value or achieve the greatest flexibility.
Decoupling and modularization are efficient. They create agility and facilitate reuse. A group of climbers ascending a mountain who are all roped together get some benefits in terms of security and communication however, they must all take the same route, normally the slowest easiest route that is accessible to the least skilled of their team. They must all travel at the same pace, normally the slowest pace, the one at which their weakest least fit member travels. They must all encounter the same risks at the same time. An avalanche that takes out one member is likely to get the rest, either because they are all bunched up or because they are all roped together and get dragged along. They are not resource efficient. Before they embark on the first step of the journey they must have sufficient resources in terms of food and equipment to get the whole team to the summit and back. They must always attempt each challenge en route in the same order, i.e. the order in which they are roped together or they must stop and go through a reordering process. If one member is injured or falls sick the whole team must stop or slow down or the ascent may have to be cancelled. These factors make them slow and places some if not many mountain tops completely out of their reach.
The same group of climbers that ascended using different routes at different paces and at different speeds and times incurs none of the above disadvantages and gets all of the benefits of being a team if they use radio, GPS and thermal imaging to provide the same security and communication the rope used to provide.
Complex, non-linear, tightly-coupled systems tend to fail in non-predictable and catastrophic ways. The point at which they fail tends to coincide with or result from a change in the state or behaviour of one of the components. This has been described as the domino or ripple effect which in reality doesn’t even begin to describe the problems faced by modern complex systems because both falling dominos and ripples are simple and linear. Non-linear systems have feedback loops and echoes which can exacerbate, magnify or accelerate failures. In complex systems a single event or action can cause a multiplicity of other events or actions which are not the same or in the same order each time.
Complexity and non-linearity are here to stay. These are inherent in the problems we are trying to solve so they are non-negotiable. We cannot do something complex in a simple way except by abstracting the complexity and that simply moves the complexity somewhere else, it does not reduce it. In fact it can add new complexity. Even simply hiding the complexity of a system behind a simple interface can cause problems in terms of its use, for instance it can make resource intensive processes seem otherwise. The only feature we can mitigate to any great extent is the coupling and this is why so much of our effort is addressed here.
How do we benefit from strategic alignment ? Really, when we say strategic we mean “from the strategic level on down” and the alignment means that IT infrastructure is modeled on the business services it supports. The most obvious benefit is that the IT infrastructure is designed to support not only the business as it is today but as it will be tomorrow, it has the businesses strategy engineered into it. It is proactive and not reactive. This makes the business agile because when it needs to change it doesn’t have to wait for the IT infrastructure to be re-engineered to support that change either because the systems have been engineered to allow for change or because their decoupling allows for change in one without necessarily requiring change in the other. When it comes to capacity management (one of the most arcane and yet most critical arts in both Business and IT Management)** the clear mapping of business processes and services onto IT services and processes is of enormous benefit. Key business volume indicators (BVIs) can be identified and profiled to find their resource footprints. What does a BVI cost the business in network bandwidth, system memory, processor cycles, disk space etc. Which systems are involved or affected? If the business plan involves increasing a BVI (e.g. doubling sales) the knowledge of that BVI’s system footprint enables IT to quickly establish if current capacity will support the increased business and if not, which systems will have to be scaled by how much to meet increased demand and how much will that up-scaling or out-scaling cost ? If IT cannot answer these questions in a timely and accurate manner when business decisions are being made this is a constraint on the agility of the business and a risk to the success of business strategy.
**If you really want to get a handle on this talk to Capacity Management specialists Capacitas or arrange to attend one of their excellent seminars.