As a regular reader of CrossTalk: The Journal of Defense Software Engineering for several years, I was delighted to receive this month's issue in the mail. The September 2007 issue is subtitled and dedicated to Service-Oriented Architecture. Excellent! Who better to elucidate the precepts of SOA and discuss the ongoing transitions and transformations engendered than the U.S. military services' IT operations? Here are organizations which understand both structured and ad hoc, inter-organizational business processes:
- ground-pounders calling in air support, often across service branch boundaries;
- military airlift services provided across service branches;
- close working relationships between Special Operations personnel and delivery and support from the service branches;
- shared procurement (the F35 Lightning II "JSF" comes to mind, as well as JTRS radios).
There are literally thousands of other examples. And the transition of not only U.S. forces, but joint coalition forces to Network-Centric Operations, shows the understanding that many warfighters and support personnel have for the smoothly-integrated, information-superiority style of 21st century military missions.
Both the publisher's introduction, discussing total assurance needs across integrated organizations based on SOA principles, and the final-page BackTalk article, quoting the Wikipedia SOA definition "...a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services," show promise. Information services means a wide array of services after all, not just IT systems, not just computers.
I was happiest with the article Four Pillars of SOA article, though not with its third pillar (Technology Evaluation). While I agree that Pillars One and Two are important (Strategic Alignment and SOA Governance), it's Pillar Four I'm voting Most Important Pillar of the Year (MIPY?)-a change of mindset is absolutely critical to getting value from SOA, from integrating business and technology architecture, from recognizing and integrating business processes and services, either technically or in more ad hoc fashions. Some mindset changes that active SOA Consortium member Victor Harrison, Partner at CSC, tells me he has run into include
- thinking of business processes as dynamic opportunities for collaboration as opposed to static and prescriptive sequences of tasks;
- focusing on business agility (responsiveness to changing business and mission conditions) rather than immediate process automation savings;
- continuous delivery of value-producing services, as opposed to "boil the ocean" complex project implementation (this one reminds me of one of the key tenets of the Agile Alliance);
- controlling expenditures by focusing on piecemeal delivery of services rather than the huge payments engendered by delivery of large, monolithic applications;
- thinking of the extended enterprise becomes more real, with more opportunities to integrate not only within the enterprise but across the service- or supply chain;
- behavioral specification becomes the first activity, as opposed to selection of an implementation followed by documentation of apparent behavior.
So, OK, not a bad article, at least augmented with Victor's list!
Overall, however, the issue disappoints by constantly conflating SOA and Web Services. The first full article is not about SOA at all, but entirely about Web Services. Certainly Web Services are one way to integrate IT systems (there are dozens of others), and certainly discussing how to assure secure interconnections is relevant to building IT systems. But it's not the SOA story.
There's a reason that we at the SOA Consortium say that "Achieving the benefits of service-oriented architecture requires significant changes for both IT and business executives". If it was simply a matter of technology, what would business executives have to do with it?
Our own Brenda Michelson, Program Director for the SOA Consortium, has it right: the only way out of the SOA "trough of disillusionment" is realizing and agreeing that SOA is not about the underlying technology, but about "enabling organizations to create, and adapt to, change".
The good news is that at the very next meeting of the SOA Consortium, in Jacksonville this month, we'll not only be discussing SOA but the adoption of SOA in the United States military (specifically the Army). This is the beginning of a long journey for the Army, and we at the Consortium are delighted and honored to be part of it (and help in what ways we can, by sharing experiences). It promises to be an interesting journey, and I hope you'll join us.
I also hope to read an issue of CrossTalk in a year or so dedicated to how SOA enabled the US military services to change and adapt to change!
Recent Comments