In a Network Computing
2007 reader poll, Service Oriented Architecture topped a survey of the most despised tech buzzwords. Despite this result, its an approach that technologists are increasingly relying on to share information across once-siloed applications. With it organizations can extract more business performance data in near real-time, vastly improving business intelligence.
SOA is not a new approach to software design. “It's an architectural style that has existed ever since the birth of distributed computing environments,” says Dr. Stephane Gagnon, Professor of Operation and Information at the University of Quebec in Outaouais, meaning some of the notions have been around for decades (a fact that might explain some peoples' frustration with the label). SOA has been gaining traction lately following the arrival on the market of development environments which allow IT professionals to develop interfaces using Web Services Description Language (WSDL). Web services are the primary means by which SOA operates, and some believe that building an SOA using WSDL is the ideal approach. But SOA doesn't have to use Web services it may be deployed using a wide range of technology, including REST, RPC, DCOM and CORBA.
Speaking at a Honeycomb web conference, Dick Burk, Chief Architect and Manager of the Federal Enterprise Architecture Program, described how he is using an SOA approach to develop collaboration across the federal government. He advises moving slowly when setting up an SOA therefore allowing the organization to mitigate the security risk, which is always a concern with open architecture, and also focus on all important business processes. Burk described a specific example of where his team was able to deploy SOA across a particular department and then extend it across multiple lines of business.
The example he cited was the Mortgage Insurance Business (around since 1937) in the Department of Housing and Urban Development (HUD). The agency works with approximately 11,000 lenders and insures around 5,400 mortgages a day. “We started by identifying the functions and processes of this business, which included loan insurance, monitoring of lenders, and financial management,” says Burk. There were roughly thirty applications at headquarters supporting these functions and processes and the field offices had built another eleven cusp systems to support their particular needs. With so many systems spread all over the country, the mortgage insurance business was crying out for a collection of networked services that could communicate with one another.
Working with the owners of the business who had direct responsibility for these functions and processes Burk and his team walked through the business asking the obvious architecture questions: What is your business? Do we have the functions correct? What is the performance you want to see in 3-5 years?
“We didn't change the business,” says Burk, “what we did is made some minor modifications to the systems supporting it. We recognized some functions that were unique to this business, as opposed to other areas of HUD, and developed modules for these.” Burk also identified common processes that were utilised by the Mortgage Insurance Business and cut across other areas of the business. These included customer relationship management (CRM), reporting, and financial support, which were involved in providing other services like helping renters through public housing agencies, or providing block grants to cities and states to help clean up lousy areas of town, or helping the homeless. “In these instances it was enterprise wide systems that we invested in. We built them for this target architecture but we were then able to leverage them across the entire department.”
The transition from the old architecture of forty-one systems through a set of transition planning stages to the target architecture, which included nine core systems and four cross cutting systems, took about three years. But in this case the SOA architecture served as a useful mapping tool ensuring that the services created by the IT department properly represented the business view. However, with development costs of around $9 million (which didn't include the infrastructure), it's evident that reengineering existing systems architecture is not for the faint hearted.
“We spent 4 months with program officials to determine the ROI,” says Burk. In a purely technical sense the outcomes were clear; a reduction in the number of systems by 80 percent, a minimizing of functional overlap in the mortgage insurance line of business, a more modernized technology base for the HUD which was brought into line with other agencies, and a decrease in the total cost of ownership from $28 million to $16 million.
Translating the savings and investment into business terms was possible only by exploiting the responsiveness obtained through a common architecture and not just looking at it from a technology perspective. Overall the project increased the number of loans processed per day, identified faster the number of lenders who were illegally discriminating, identified earlier the lenders providing HUD with bad loans, and identified non-viable lenders therefore allowing the department to respond faster to potential problems.
According to Gagnon, “the Federal Enterprise Architecture initiative is a beautiful effort of bringing together both enterprise and technical perspectives in one environment.” Which is by definition exactly the SOA approach, by starting with services and developing groups of loosely coupled software that carry out business processes every service is created to bring value to the business in some way and is traceable back to the business architecture.
More information on the project is available at: http://www.egov.gov/