Common mistakes to avoid when designing distributed SOA systems
By Jason Tee
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."
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.
06 Feb 2013