This content is part of the Essential Guide: EA in transition: Guide to keeping up with disruptive technologies

Common mistakes to avoid when designing distributed SOA systems

In an effort to gain some insight into how to best approach application design and architecting distributed SOA based systems, TheServerSide reached out to Arnon Rotem-Gal-Oz, the author of SOA Design Patterns, for his insights on the topic.

Is your organization dabbling in service-oriented architectures (SOA)? Are you hesitant to move forward because you don't want to waste resources doing things the wrong way? What if you could find out what it takes to avoid the common pitfalls that lead to so-so SOA? Why not take a peek behind the curtain with the wizard of distributed systems architecture, Arnon Rotem-Gal-Oz (@arnonrgo), the author of the Manning publication SOA Patterns? Here's what TheServerSide discovered when it did just that.

Building flexible and pluggable systems with SOA

SOA based principles shouldn't be thought of as being mysterious, hard to learn, or magical. SOA is simply a good way to build distributed systems because it's componentized and flexible. However, organizations run into trouble when they don't understand the fundamentals. We asked Arnon, Architecture Director for the Enterprise Division at NICE Systems, where SOA projects tend to go awry most often. His reply? "They get the granularity of their service size wrong. They need to Goldilocks-size it…not too big or too small."

You need to Goldilocks-size your SOA components…not too big and not too small.

Arnon Rotem-Gal-Oz, Author of SOA Patterns

Organizations generally have to make tradeoffs between flexibility in business processes, performance and reusability. As just one example, fine granularity means more calls and more network traffic. Coarser granularity means less network traffic but more information retrieved with each call. Experience is the old-fashioned way to figure these things out. However, you can also avoid reinventing the wheel by reviewing this insightful master thesis on Service Granularity in SOA Projects: A Trade-off Analysis by Claudia Steghuis .

Don't hold on too tight

Modeling your interactions to figure out how to compose services together properly is crucial. Ending up with a solution that is too tightly coupled is a common error. It can be very difficult to manage a monolithic system – although it's really a matter of scale. A tightly coupled system allows you to control all the components and see everything in a single view. That can be very attractive from an administrative standpoint if you have a small, simple solution. But Rotem-Gal-Oz warns that once you go over a certain size, or if you have an army of developers, you lose agility, and here is why:

  • Tightly coupled systems have many dependencies between different parts of the system
  • With tightly coupled systems developers have to wait for other team members before moving on to the next project stage
  • With tightly coupled systems, software can't evolve freely since implementing changes takes a huge amount of time

This kind of lumbering pace for development simply isn't acceptable in an age of continuous deployment and it hampers the application lifecycle management (ALM) process. Smart organizations know that technology, requirements, interfaces and other aspects of computing are prone to change. SOA componentizes systems so you have smaller pieces that are easier to manage. That doesn't just make development more agile for the web. It also creates an environment where mobile development is simpler since you want lots of flexibility on platforms that are very resource-limited.

Fitting the pieces together

Of course, having more pieces in your SOA puzzle means managing lots and lots coupling. Arnon says this isn't a bad thing, "Learning how to make things work together is actually a benefit. You can get new behaviors you didn't anticipate when you started out." The extra effort that goes into modeling and understanding your business processes from a SOA standpoint isn't a bug, it's a feature.


Have you found using patterns to be helpful or painful when doing application development? Let us know what you think about the industry's love affair with software patterns.


Recommended Titles

SOA Patterns Arnon Rotem-Gal-Oz
Design Patterns: Elements of Reusable Object-Oriented Software Richard Helm
Head First Design Patterns Eric Freeman
Patterns of Enterprise Application Architecture Martin Fowler

Dig Deeper on Software development techniques and Agile methodologies

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.