Service Oriented Architecture (SOA) is one of the most important developments in recent IT history. Everyone has something to say about SOA, and a huge industry has grown up around tools, languages, platforms and frameworks for SOA. In addition there are a sometimes bewildering number of standards to learn.

All of this produces a strong sense of urgency to get started. There are, however, several pitfalls which can seriously delay or completely derail an effort to implement an SOA.

1 Foundation of Sand

Confusion about where to start is one of the most common pitfalls on the way to a service oriented architecture. Which data should be warehoused? How do we achieve timely and reliable data updates? What services do we need? Which existing systems should be exposed as services, and how?

All of these questions, and more, can be answered by modeling your enterprise. This entails analyzing your enterprise's data and processes – specifically looking at data and process normalization, understanding the interactions and interdependencies of existing systems and data stores, and pin-pointing bottlenecks, and redundancies.

I'm talking about creating a detailed object model – using UML¹ – with use case, package, class, activity and sequence diagrams, at very least. The service oriented architecture is a profoundly object oriented architecture – a logical outgrowth of many decades of OO research. The ability to use this model to uncover existing (and potential) problems, and to design both an IT architecture and its components is critical to making a successful transition to SOA.

In fact, this might very well be critical to simply staying in business! In addition to the obvious analysis and design benefits, an up-to-date object model is fantastic documentation. If only one person really understands a system, and then gets hit by a bus...² well... you get the point. The practice of maintaining an up-to-date enterprise model is a very good idea – SOA or not.

Creating this model is a two stage process.

First, you need to understand your existing IT landscape. What data is where? Which processes need which data? How does everything fit together now – before any changes are made on the way to an SOA. No successful architecture can be built until the current IT implementation is fully understood. Otherwise we risk building our house on a foundation of sand. This might be thought of as the base, or current model.

Next, the current and future requirements of the enterprise (including SOA) are analyzed and worked into the model – giving us a start on the future SOA based model. The tools used include enterprise patterns, re-factoring techniques, various software metrics, and others.

Since the enterprise model is fundamental to both current understanding and future development, it is the logical first step towards SOA.

2 Over-reaching, Biting Off Too Much at Once

The only reasonable excuse for adopting a new technology is to increase productivity. Why endure the disruption, cost and risk of new technology unless the “payback” is worth it in terms of improved production and quality? The promises of SOA are very tempting, and the productivity gains are well documented, it would be easy to say “let's just replace everything!” It's not that simple.

No matter what the technology, the first result of transition is a loss of productivity. It stands to reason; you have abandoned one technology where you have considerable expertise, and have adopted a new technology where you are a rank amateur. The reality is that mistakes will be made, and things will need to be done over before you have clawed yourself up the learning curve far enough to begin to show improved productivity as a result of the new technology.

The only reasonable way to address this is to begin with a small project – one which is needed but not currently mission-critical. If, as is very likely, it takes more time to implement, needs some re-working, and even needs a re-start, it won't severely damage the enterprise's IT operation.

There is a second, very real, benefit to proceeding this way: you will be grooming some in-house expertise for future projects. The personnel who have “taken their knocks” on this project will be very well suited for leadership roles in other projects. The new projects won't have to re-live the pains of the first project – since they will have some history on-board.

Remember, it's not only the new architecture that needs to be learned, but the tools, techniques and platforms have their own learning curves too.

3 Poor choice - over reliance on tools

"A fool with a tool is still a fool." ³

It seems unnecessary to point out that SOA is a concept – an architecture – but my experience is that IT departments seem to forget this on a regular basis. Concepts are analyzed and designed by human minds, not software tools. No tool, however sophisticated, can analyze an enterprise's IT strategy, design a response, and implement the solution; they are, after all, just assistants.

I'm not advocating the avoidance of tools, by no means, but I can't over-emphasize the human factor. A thorough understanding of principles and practices is absolutely necessary. The hammer doesn't build the house, the carpenter does.

There is an insidious facet to tools – they have their own agenda, their own way of seeing things. There is nothing inherently wrong with that, except that if the tool-user isn't well versed in the underlying technology, the tool will impose its way on the developing system. This often results in over-complication, mis-matched solutions and arbitrary implementation.

In fact, over-reliance on tools can contribute to the 4^th pitfall – Over Standardization.

4 Over-standardization – One Size Fits All

“When all you have is a hammer, everything looks like a nail”⁴

Basing an entire enterprise's IT architecture on one or two solutions (tools, languages, structures, etc.) inevitably produces exactly the opposite result promised by SOA – a rigid, hard to change system. These results don't achieve the productivity gains at the core of the SOA promise.

This is especially true at the service level. Whether services are purchased, contracted for, or built in-house each one must be analyzed, designed and implemented on a one by one basis. There is a very good chance that one or more services would benefit from a different language, tool or platform.

This can be difficult to apply. Many tools and platforms are expensive. Personnel have been trained on these systems, the cost has been sunk. It is, however, very important not to fall into this trap. Designs are like one size fits all clothing, it may fit everyone, but it doesn't fit anyone well. Remember, analysis and design is a process of revealing structure and form (guided by requirements), not imposing it.

This is one good reason to consider purchasing “off the shelf” services, or having services custom built by outside vendors (outsourced). SOA, outsourcing and software factories⁵

5 Bad advice / technical knowledge – Power of the internal "expert" ⁶

This is a particularly vexing problem. You have probably been exposed to one of these “experts”, it is by no means limited to SOA projects. They know all the buzzwords. They can cite chapter and verse from a formidable bibliography of technical literature.

Management is lulled into a false sense of security – the expert has all of the answers, or so it seems. The IT staff is intimidated – the expert has the blessing of management, and appears to have special knowledge.

Unfortunately, the expert hasn't a clue how to achieve any of this; all talk, no action. Projects bog down in endless analysis – analysis paralysis. Remember that the measure of a successful project is running code, not the weight of the documentation.

This is really a management problem. To solve it requires management, both from the traditional top-down and from the bottom-up approaches. The “expert” needs to go. There are several approaches possible.

Outside consultants can be of considerable help here. Their expertise can either validate or repudiate the “expert's” proclamations. Since consultants aren't as tightly bound in the politics of the organization, they are more able to call out the emperor's new clothes.

It may also be necessary for co-workers to do extra work – to show the viability of alternative approaches. Extra work is never a popular option. It may also be politically risky to speak out.

In the end education is the answer; education of Management and education of co-workers. The better everyone understands the technology, the less disruptive the “expert” becomes.

- - -

Bibliography

Web Services and Service-Oriented Architectures: The Savvy Manager's Guide by Douglas K. Barry, Morgan Kaufmann, ISBN: 1558609067

Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services by Thomas Erl, Prentice-Hall, ISBN: 0131428985

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, by Gregor Hohpe, Bobby Woolf, Addison-Wesley, ISBN: 0321200683

Object Solutions: Managing the Object-Oriented Project, by Grady Booch, Pearson Education,ISBN: 0805305947

Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, by Jack Greenfield, Keith Short, Steve Cook, and Stuart Kent, Wiley, ISBN: 0471202843