Here is the email I sent my class introducing them to my discussion of SOA.
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.
Doktat Pontificates on
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
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.