As the IT world encountered SOA as the new answer to some old problems, not few in the technological sphere thought that it’s rather a temporary marketing hype than a new paradigm. Well, SOA is still here, meanwhile in its second hype cycle and there are still many voices which are afflicted by doubts about the real essentials. Especially from a technological point of view, not few are asking about the true innovations that SOA will bring along, making it distinguishable from other conversant architectural paradigms.
In fact, you will discover most of the well known, established design principles that are considered crucial, even before the days of SOA. In order to fully understand the core ideas and motivations for an SOA (at least as a technologist), we are in need for a more holistic view, taking an IT systems surrounding into account. We have to leave our well known homy place and face the delightful world of economics, value added and return on invest – in short, the rough world of an enterprise.
The frame set – Enterprise Software
Enterprise Software has one major goal – to support the surrounding business, contributing to and improving the economic value added. Now we could stop, having determined its main motivation. But that’s no justification for adopting SOA. It seems that SOA must introduce some promises on increasing that value added (otherwise business wouldn’t be interested). In fact, SOA asserts to increase the enterprise agility when it comes to alterations in the companies strategy that have to be reflected by the affected software. That’s because of the inherent interconnection between the internal organization and processes of the business on one side and the IT systems that reflect the underlying business model on the other side.
Talking about Enterprise software, there’s usually a large number of software systems with complex cross-dependencies that are grown organically over time. Those dependencies are manifold – there may be muliple departments and external business partners involved. In addition to that, you’ll find a heterogeneous landscape of different technologies and plattforms, but in exchange some business logic that’s implemented repeatedly in multiple applications (i.e. think about applications that have to comply to some tax laws, forcing the same calculation of some fees within different systems).
From the viewpoint of the enterprise, such an inhomogeneous application landscape looks like a nightmare when it comes to changes or adoption. Every application may be well structured and balanced in it’s own (that’s the perspective an individual developer may possess), but now we are looking at a whole bunch of applications that have to act in concert. From this perspective, if you want, we face a kind of meta architecture – the architecture of the architectures of those single applications. And this one isn’t DRY, well unitized or even cohesive by nature (take a look back at our tax law example. If the law changes, we have to adopt the new caclulations in every single application – that’s not very DRY).
Requirements for a meta architecture
In order to minimize the impact of inevitable changes due to business agility, such a meta architecture have to meet some challenges due to maintenance and further development. But wait, most of those challenges seem to be much the same as in maintaining and evolving individual applications, only the focus have shifted to a superior perspective. Under this impression, the ideas and principles of an SOA doesn’t differ much from those concepts of established architectural paradigms – this may be a major cause for some irritations and doubts about the true innovations of SOA, at least from a technological point of view. As learnt, that view is only half the truth. We also have to take the demands of the business into account, and from this point of view we obtain a rather new sight.
In order to react to market changes or business reorganizations, the enterprise is in need of a highly flexible system. It must be composed of a set of some building blocks that can be assembled, reconfigured or rearranged in a flexible way. The agile and easy composition of cooperating building blocks should enable the business to respond quickly to new requirements.
Because the business drives the organizational strategies and processes that have to be reflected by the software, those building blocks should be evaluated and regarded under the business value they can achieve (they should offer a clear defined meaning on the business level). Under this aspect, every such building block have to represent a clear business oriented service. That’s why those building blocks are called services – not from a technological point of view but rather from a business perspective (so a Service oriented Architecture is more precisely a ‘Business Service’ oriented Architecture)
In order to take full economical advantage of single services its desirable to reuse them in different contexts. If there’s only one Service for a certain business functionality (remember the tax law example), then there’s also one single place for changes. Remember that such a service exists only once within the whole enterprise, reducing redundancies (lifting the DRY principle on the enterprise level). Therefore it’s indispensable that services are potentially accessible amongst all involved participants at any time.
There are two dimensions of Independency: Firstly, all fundamental business services should be self contained compared to its functionality. A change on one service should only have local effects and shouldn’t affect the whole system, avoiding additional adaptions due to side effects.
Secondly, the inhomogeneous technical landscape is a fact that can’t be fighted. Therefore the interaction of services must be seamless and transparent, thus independent of technical plattforms or specific products.
In order to answer quickly to new business demands, services should be easily re-composable. Hence, a tight coupling between services isn’t wanted. If loosely coupled, we’re also able to combine and recombine arbitrary fundamental services to achieve some higher services for upper (business driven) goals (so services can be composed and recomposed fairly often to build or modify enterprise solutions).
Especially when considering business processes, we need a new way of cutting business functionality. Where nowadays process logic is for a good part hidden inside single applications (even most of the time implicitly within certain layers), we now have to separate those implementation artifacts that change often from the ones that are fairly stable (considering decomposition and encapsulation). Under this point of view, fundamental business services are representing more stable artifacts, whereas business processes are representing more fluid artifacts that span over a whole bunch of different departments resp. applications.
Because the focus isn’t longer on a single application but on a whole application landscape, we need a rather simple modell of structuring in order to keep track of all those building blocks. Of course there are also far more participants to consider. They all have to play together, thus they all need a simple representation model in order to communicate effectively.
As seen, most of the described requirements and proposed solutions to meet those requirements aren’t new or even innovative inside the IT world. It’s understandable that there are doubts about SOA, especially when only seeing the technological side. In order to understand SOA we have to come up with a broader, holistic view, based on two dimensions:
Firstly, we have to look at enterprise software not only from a technological angle, but bringing it together with the business, enterprise software is embedded within. Business demands as the main driver for enterprise systems now put its own demands on software. Under this point of view, we have to evaluate software not only from a technological side, but mainly from the requirements the business applies to enterprise software. That’s the core idea behind the ‘buzz phrase’ Business-IT-Alignment.
Secondly, the focus of SOA goes explicitly beyond the scope of a single application but rather to a holistic view across many applications that must work together somehow (i.e. extracting commonly used functionnalityout of the single applications, providing a single service that can be used by all applications) in order to represent a seamless business model. Not the single application is important any longer, it’s rather about the cutting, dicing and composition of individual components with a clear business functionality, no matter where they come from.
Within this holistic view, SOA is rather an architectural conglomerate of concepts, a set of heuristics and guidelines for building enterprise wide software systems than a concrete architecture. It represents a technology independent high level blueprint for a kind of meta architecture in a way that the main building blocks that are created and exposed as services offer a consolidatet view of the whole enterprise IT.
In this entry we’ve set the stage for looking and evaluating SOA, especially for the rather technical minded. In the following entries we will take a deeper look at services, new technical challenges (cross department security, long running transactions), Business Process Management, the Enterprise Service Bus and so forth.
If you have any suggestions for additional topics, please give me a note.
Stay tuned …