even realize they have options when it comes to how they should use SOA to develop their software. Unfortunately, the SOA lemmings who fail to consider these options have the potential for actually causing negative impacts to their software architectures as opposed to capitalizing on some of the benefits that SOA truly does offer.

I wonder which straw finally broke Marty’s SOA back. In an effort to be good SOA practitioners, did Marty’s software staff generalize some services to such an extent that they were not able to meet even their own product’s needs? The idea of developing distributed infix services sounded good, but the performance impacts of remote process invocations to simply add and subtract numbers might have been a bit of an SOA stretch. Even though these infix services were written with the hallmark SOA qualities of being discoverable, stateless, composable, and not dependent on any other services, Marty fell into a trap that many projects seem to be falling into these days. He did not align his architectural and design decisions to the beacons characterizing his project’s objectives: Quality Attributes.^a Instead, he let rampant SOA hype and propaganda blind him. As a result, he couldn’t see that the relentless pursuit of flexibility had trumped the importance of performance and usability in his product.

Perhaps Marty’s misfortune was an aftereffect of firing all of his systems engineers due to a belief that adoption of SOA transformed the traditional software lifecycle into one where the only relevant activities are ones of development and integration? There is a great deal of money to be saved by assuming that jack-in-the-box architectures will just pop up amidst a haphazard collection of services without having to invest time and effort associated with traditional software engineering approaches.

There might still be yet another possibility at the root of Marty’s looming ambulance ride: did he choose the wrong level of abstraction with

a Non-functional properties that drive software architecture (L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, 2nd edition, Addison Wesley, 2003).

not all soa users
or prospective
users even realize
they have options
when it comes to
how they should use
soa to develop their
software.

which to implement SOA? As opposed to service users hooking into them directly at the “stub” level, there are often circumstances where a service layer encapsulating such stubs has the potential of improving important properties that include performance, availability, and survivability. Specifically, performance can be improved by short-circuiting remote method invocations in the event that requested information has been previously fetched. Availability can be improved by the service layer hooking up to alternate service providers in the case of failures or SLA violations. Survivability can be improved by providing service users with some fidelity of response even if connectivity to the actual service provider is temporarily unavailable.

As just suggested, the benefits of encapsulation should not be ignored when selecting the tactics with which to best implement SOA. In fact, even in the context of my daughter’s rather interesting definition of SOA, she recognizes the value of encapsulation, “Dad, I can enjoy my clothes without having to know any of the details of how they were made.” Perhaps your SOA usage tactics should heed such wise words and similarly hide applicable implementation details from service users? Why should a user of an extremely simple service be bothered with having to know about UDDI, for example, when a resulting side effect might be to write more code to connect to the service than required to implement the service itself? A pre-

ferred implementation from a Quality Attribute realization perspective might be to hide UDDI from clients beneath a thin service layer.

Adoption of SOA is not about throwing a switch where roll-up-the-sleeves engineering can suddenly be avoided or where time and money unexpectedly become available with which to properly identify services using business process analyses. Sure, some development activities might be shortened as the result of reusing certain components or purchasing others, but, how often is one able to actually purchase preexisting services that provide a product’s core “business logic”? How many software managers are actually willing to add risk to their development schedules to find out how a particular service imminently required can be generalized to meet the needs of unknown or future users? In order to realize SOA’s benefits, engineering and planning are still required as opposed to just hoping that a bunch of random services glued together by a workflow engine will get the job done.

Sadly, Marty did not make it to the hospital. Whichever combination of misguided business decisions and implementation tactics may have finally led to his demise, Marty was DOA—dead on arrival—just like his SOA project. It did not have to be this way. Adoption of SOA did not constitute authorization for Marty to ignore best practices or to show contempt for common sense. Yes, Marty’s architecture was flexible, but of what value is flexibility when other critical architectural properties have been ignored or trumped?

How is your SOA health? Do you presume that SOA can only be enabled by Web services? Do you believe that the benefit of properties such as performance and abstraction are only important in “old-fashioned” architectures? Have you aligned your usage of SOA to your Quality Attributes? Pay close attention to how you answer, you will not want to miss the warning signs of a possible DOA with SOA in your future.

 

Alex E. Bell ( [e-mail]) is a software architect with The Boeing Company.