By Robin Bloor, Partner
The (Probable) Pitfalls of SOA
By Robin Bloor, Partner
It’s a little early to report on the pitfalls of SOA. Most companies haven’t gotten far enough to get into trouble yet. There have been a few false starts, where companies confused BPM with SOA (BPM is just a part of SOA) and were forced to back track and pay attention to the infrastructure, as their BPM initiatives expanded. I have also heard reports of companies confusing an ESB with SOA – primarily because some ESBs come loaded with expanded capability and meet a fair portion of the fundamental SOA requirements. You can evolve an ESB into a full-fledged SOA environment, but you can also end up with a kind of halfway house.
Expressed mathematically: BPM + ESB < SOA.
Given the failure of the various technology-driven initiatives of the past, it is highly likely that some of the current SOA initiatives are doomed to flounder for similar reasons. Here are a few ways in which I think this is likely to occur:
1. The Big Project
It happened with relational database. It happened with 4GLs and with object orientation, and with ecommerce, so it’s pretty much destined to happen to a few companies with SOA. Someone in a senior position will “see the light” and decide to reorient the organization completely around SOA. They’ll begin by launching a project that is huge, ambitious and doomed.
The problem with across-the-board SOA is that it requires very extensive software infrastructure that isn’t completely available yet. Creating the infrastructure on the fly will deter if not derail the giant SOA initiative.
2. Ignoring Identity Management
Identity management is so critical to SOA that when we advise customers on where to start with SOA, we almost always advise that they start with Identity Management. Without identity management SOA security is impossible.
3. Failing To Organize For SOA
SOA may well change how a company is organized in the same way that the PC did and client/server systems did, although more profoundly. SOA alters the way that business process change occurs which in turn changes the way the business organizes and manages staff. With SOA, IT’s focus moves more to technical development and the technical support of company systems. The business side (with the assistance of business analysts) starts to take control of the design and evolution of business processes. The concept of an “application” starts to fade.
4. Lack of unified repository
SOA effectively unites all the development environments that a company uses. In most organizations there will be several ¾ some Microsoft perhaps, with a little bit of Oracle in some places and, maybe, some Java-based Eclipse arrangement. All of this has to be transformed into a unified (but loosely-coupled) development environment, which means a repository is required. Conceptually the development repository is the source code for the SOA registry. However, right now very few companies (and as far as we know no large companies) actually have a development repository.
5. Lack of SOA Governance
In the pre-SOA world, IT used to build-test-implement (or, in the case of packages, test-implement). So IT does its stuff and the user department, for its part, does data take-on then tests and eventually accepts. The hand-over is fairly neat and clean. With SOA there is no simple dividing line. In any development the user department and IT will both be represented to some degree on the team. Explicit governance is needed to ensure that systems don’t go into production in a chaotic way.
Of course there are more than five possible pitfalls. Unfortunately, we only have room for five in this article. In December, I’ll give you another five to think about.