In DC, the air is thick with SOA

I frequently take my young daughters to Washington, DC, to see and learn about people (and technology) that made a difference in our world -- from the Lincoln Memorial to the National Air & Space Museum to the International Spy Museum.

Lately, this town has also been the scene of new thinking around SOA, as well as discussion of how to overcome older, calcified ways of thinking about how applications are built, deployed and used.

IBM and Georgetown University put on a very impressive program last, week, to launch one of the first SOA college-level programs. Will our future technology and business leaders be trained to think in loosely coupled ways? At the event, speakers attempted to unravel the organizational and human-nature issues that muck up SOA efforts. As reported in ComputerWorld, organizations as varied as Marriott and the US Air Force both are grappling with the organizational change required to make SOA succeed.

Steve Wolf, senior enterprise architect at Marriott International, is quoted as observing that the greatest hurdle to SOA "is retraining developers to think of composing applications as an iterative approach, rather than using the traditional waterfall method, where the development process lacks collaboration and is highly compartmentalized." Developers tend to be a fiercely independent bunch, which in a way goes against the collaborative essence of SOA. "Developers in different departments must learn to reuse a service that can calculate a hotel room rate, instead of re-creating it each time they build a new application that includes those calculations. However, he noted, people don't typically like to rely on others for this type of work," Wolf is quoted as saying.

The Air Force doesn't seem to worry as much about hospitality and leaving mints on pillows, but nevertheless also runs up against similar issues. Fiefdoms seem to be the main obstacle to Air Force SOA: Harvey Reid, chief engineer of the U.S. Air Force's Global Combat Support System, is quoted as saying that program officers are reluctant to share their applications. "Program officers are king, and determining who is going to do the coordinating [of services] is a tough problem," he said. The Air Force is attempting to address the issue by insisting that agreements be forged between various operational groups.

James Taylor, blogging from this week's Brainstorm BPM/SOA event in DC, reports on how the Congressional Office of Management and Budget (OMB) is able to "eat the elephant" -- develop the business and technology framework for e-gov, which has the non-trivial task of getting various the federal agencies to "use common elements of enterprise architecture across the large IT budgets involved in government," dictated by a 535-member board of directors with multiple and almost always conflicting political agendas (the House and Senate, of course).

Taylor quotes Richard Burk from the OMB, who described how OMB's e-gov system supports its constituencies, which are internal users and citizens. OMB sets three key criteria for the success of an initiative: 1) Completeness (how much of it is done); 2) Usage (who uses it, for what, what percentage); and 3) Results (what return on this investment).