The Top 5 Pitfalls for SOA - ASPE

The Top 5 Pitfalls for SOA 

A WHITE PAPER PREPARED FOR ASPE TECHNOLOGY 

www.aspetech.com toll-free: 877-800-5221

Top 5 Pitfalls for SOA 

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 1 – 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... 2 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. 

1 Universal Modeling Language, http://www.oma.org 

2 “The Bus Effect” - Attributed to Grady Booch, source unclear (Grady Booch, Object Solutions, 

Addison-Wesley?) 

White paper prepared for ASPE Technology 

Authorship © 2008, Objectech Corporation. All rights reserved.


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." 3 

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. 

3 Often attributed to Grady Booch – http://gsehl.editme.com/TestingQuotes 




4 - Over-standardization – One Size Fits All 

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

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 

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

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 

4 Ubiquitous saying – citations as long ago as the 1800s 

5 Jack Greenfield, et. al. - Software Factories - Wiley 

6 Douglas K. Barry - Web Services and Service-Oriented Architectures – Morgan Kaufmann 




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

The Top 5 Pitfalls for SOA - ASPE

Create successful ePaper yourself

Delete template?

Save as template?