SOA IS A HACK

Anyone reading my expositions must recognize that most of these writings were created when I was teaching software design courses in the masters of software engineering program at Carroll University. Thus, a good part of the tone I have strived for is that of provocation, and stimulation to think about the problem. The following piece was written in 2008 after reading a piece on SOA - which used to be called web services. Today I came across a blog by UncleBob Martin on SOA and I decided to recreate my original exposition here.

Here is the email I sent my class introducing them to my discussion of SOA.

##BEGIN PASTE##
First, thanks to StudentX for continuing the discussion with the link to the article by Craggs on reasons for failures in SOA projects.

Second, anecdotal pieces by consultants that contain no factual data should always be considered with skepticism. This statement comes from my background as a scientist who wandered into the “software engineering” arena. My primary criticism of “computer science” has long been (I recall arguments with my wife in the 80’s over this point) that it has little to do with the scientific method.

I recognize that I’m thinking at an idealistic level but many of the problems described in Craggs’ article can be considered from my perspective. Consider the following quote from the Craggs’ article:

“SOA is not just something that can be “installed and switched on.” It’s a lengthy process, involving the business as a whole rather than just IT. As already discussed, for example, failure to involve the business units with SOA design decisions will result in an implementation almost guaranteed to fail to match expectations.”

This is the problem my son brought up – that the various groups within the organization could never get together to create an integrated domain-object model (DOM). In addition to the cultural mismatch, there was probably also a physical separation between groups. But I say, as indicated by the above quote, that there has to be significant integration of the cultures in the various functional organizations to do the SOA integration too. Just because it’s SOA, doesn’t make this problem go away. I’d rather work on integrating the disparate systems by putting them into the same DOM than speculate with SOA.

I got a chuckle out of the following quote from Craggs’ piece because it could have been taken out of a classic systems and analysis book (Kendall & Kendall, Whitten & Bentley, etc.) published in the 80s. This is nothing new – this problem has been around for a long long time. No silver bullet here.

“But the last reason for failure to meet expectations is by far the most common and can be truly devastating. Companies repeatedly build great strategies and plans for SOA, only to find that when execution is attempted, there are countless roadblocks and inhibitors to success. The cross-departmental interchanges never happen, resource availability becomes a problem, and attempts to gain agreement on service specifications descend into endless bickering. These issues typically stem from a lack of buy-in for SOA at the senior management level.”

And finally, the last quote really comes back to my original challenge of *how* the SOA was going to solve problems. This is a reformulation of the ‘South Park Underpants Gnomes’ problem.

“Another common frustration is being unable to get budget approval to support an SOA implementation. A major contributor to this problem is having a poorly prepared business case.”

Thanks for your indulgences – feedback is welcomed – this is an important topic.
##END PASTE##

Doktat Pontificates on
Systems Integration
or
DON'T BURY YOUR SKELETONS

Since 2001-2002 I have been pondering the move to systems integration via web services (we first studied web services in CSC560 in spring 2002). Conceptually, the idea seems plausible, but I heard the first warning shots several years ago during a web seminar. The participants were discussing attempts to create web services architectures and were finding unacceptable performance and were experiencing difficulties locating the source of the problems. The message was that when an organization moves in this direction, it should have a clearly defined strategy for how the system will be tested and criteria for what will be acceptable performance. Recently (spring 2008) an article appeared citing survey results indicating that most of those surveyed thought their IT departments incapable of implementing a system with the degree of sophistication required by a web services architecture. Subsequent discussions in the CSC560 course prompted the following.

For purposes of discussion, consider the schematic below. Here we see the integration of three different systems running on three different platforms using three different languages

encapsulating the business logic of three different databases. Basically each system is converted to a service by wrapping with an xml-based layer that assumes responsibility for marshalling/un-marshalling requests for that system's resources. The business logic remains encased in the language of the system; the methods of which are invoked via the xml wrapper. Integration of these disparate systems is implemented by an architecture shown here as the services oriented architecture (SOA). If we consider each of these systems "legacy" systems (and I'm using the term legacy to imply any system not accompanied by an automated suite of unit tests), one must wonder where in the system the tests will reside. So, from my perspective, we have just overlooked a nasty problem that the magic of web services isn't going to solve. I don't think this type of approach is the way to solve integrating systems with different platforms and different languages supporting business logic. The following schematic suggests an alternative approach to this problem. The platform problem is handled by JDBC drivers that handle the communication with the database.

The critical difference is the movement of the business logic from the platform and language-dependent system into a domain object model which is where the integration should occur. Organizations refusing to deal with this problem are not facing the real problem. The translation and integration of the business logic into the domain object model would provide enormous advantages and set a better foundation for moving towards a progressively complex future. It is clear that the best path to managing complexity is via POJOs that can be tested independently and this requires an integrated domain object model. Thus, in my opinion, the use of web services for integration of an organization's disparate systems is a hack. Who would want the responsibility of managing such a monster when at its very foundation lurk the nightmares that prevent a clear and fear-free testing strategy with no clear way to test its network performance?
Am I saying no web services at all? Consider the schematic below. Note that the marshalling/un-marshalling of xml-based requests can be handled by the front-end controller displayed there.