DOI: 10.1145/1400181.1400191
Diagnosing the symptoms of failing to accommodate critical software architecture properties that often result in the demise of projects.
IT LOOKS LIKE today is finally the day that we all knew was coming, it was only a matter of time. An ambulance has just pulled up to haul away Marty the Software Manager after having been pummeled by his boss for failing to deliver on promises of cost savings, improved software reuse, and reduced time to market that had been virtually guaranteed by merely adopting service-oriented architecture (SOA). Everything was supposed to be so different. As opposed to the currently unfolding scenario involving an ambulance, Marty’s mental vision of the future had been one of a Brinks truck speeding to the scene to relieve his coffers from buckling under the strain of overflowing cash.
Should anyone really be surprised? After all, Marty is probably still sporting the hook in his mouth from having been reeled in by Victor the Vendor’s SOA fishing pole. The hype and propaganda sprinkled onto the bait that Marty swallowed must have caused a mind-numbing sense of euphoria that resulted in business and technical justification for his decisions to be ignored. Marty had been successfully convinced that his project was the only one not cashing in on the booming SOA silver-bullet bonanza.
PHO TOGRAPH BY ROY L. ANGELES
Despite Marty’s headlong charge into the SOA arena, he would have had difficulty describing it the same way three times. In his defense, however, many others have different ideas about what SOA is and is not. Thankfully, I have the benefit of a teenage daughter in the household so there
is no shortage of expert opinion on any topic. Out of curiosity, I asked her what she thought was meant by service-oriented architecture. She told me that this was an approach used to construct the shops where she buys her fashionable apparel. There are certainly different opinions about what SOA might be, but this one might be a bit extreme.
Some might say they are doing the SOA tango by merely using XML, WSDL, SOAP, and UDDI technologies. Others may believe they are reverently saluting the SOA flagpole if they are using workflow and their classes are stateless. In actuality, SOA describes an architectural style that is indepen-
dent of using a particular technology. This architectural style involves advertisement of services in some form of a registry that users can discover, introspect, hook up to, and invoke at their discretion. Sure, SOA is enabled by technologies such as those mentioned here, but others such as CORBA and DCOM have been enabling it for years.
For some software organizations, the primary dilemma is not so much about deciding whether or not adoption of SOA would help realize their development objectives, but instead, determining which technologies and design tactics should be used to do so. Not all SOA users or prospective users
References:
Archives