To hear Benjamin Moreland tell it, service-oriented architecture governance is a constant corporate battle against techno-clutter. To keep SOA development from spinning out of control, Moreland requires that before anyone publishes a new service to the company’s SOA registry of reusable code, IT support must be lined up.
SOA-related stories
* SOA driving interest in virtual data warehouses
* Teams embrace all-inclusive SOA
* SOA testing tools facilitate collaboration
Committed to committees
SOA planning is committee work, and it often requires that IT architects meet to assess a steady stream of proposals for services to run on the corporate network. “In P&C, we have a high-level project governance process and an SOA architectural steering committee,” Moreland says.
The SOA steering committee includes application architects who assess proposed new services based on such criteria as supportability, reusability and adherence to the company’s SOA reference architecture. Service designs are brought to the steering committee’s bimonthly meetings, at which the architects score the proposals and render their collective decision: approve or disapprove.
The Hartford is using those meetings plus a workflow manual to drive the process under which SOA service proposals are approved by senior IT architects. Moreland says the company plans to automate much of that approval process later this year or early next year through workflow tools that integrate with its UDDI registry.
It all starts at the top
Internal SOA proponents are a critical factor in the top-down governance equation, especially when SOA is an unfamiliar acronym to many software developers. To infuse SOA governance best practices throughout an IT culture, it’s critically important to have a senior-level cadre of SOA-knowledgeable application architects, says Christopher Crowhurst, vice president and principal architect at Thomson Learning, a Stamford, Conn., business unit of Thomson Corp. that provides technology and assessment services worldwide. Crowhurst functions as the firm’s principal SOA evangelist, but he works closely with senior IT architects in Thomson Learning’s four major lines of business.
“Each of our major lines of business has its own IT organization,” he says. “Each also has a chief IT architect, whose job is to spread Thomson’s SOA-reference architecture and development principles within their groups.” Collectively, Thomson Learning’s lead SOA architects are responsible for defining the criteria under which services are proposed, accepted, implemented, versioned and ultimately decommissioned.
As is the case with The Hartford, the IT group in Thomson Learning demands that an ongoing support model be nailed down before a new service gets approved. “Under our SOA maturity model, we consider the steps necessary to move from envisioning a new service to deploying and operating that service,” Crowhurst says. “We view a service’s maturity from the consumer’s point of view, by their ability to depend on that service in run-time. Consequently, we focus on service-level agreements, security and other concerns from the consumer’s point of view.”
Nevertheless, the SOA governance focus at Thomson Learning has a strong top-down orientation. Much of the impetus has come from the company’s CTO, Crowhurst says. “We’ve changed to a more centralized organization structure, under which the CTO is demanding compliance with [the company’s SOA reference architecture]. Under SOA, we now focus on services rather than platforms and allocate resources around services, which run across diverse platforms.”
"We’ve changed to a more centralized organization structure, under which the CTO is demanding compliance with [the company’s SOA reference architecture]. Under SOA, we now focus on services rather than platforms and allocate resources around services, which run across diverse platforms."
- Christopher Crowhurst, vice president and principal architect at Thomson Learning, of Stamford, Conn.
Count on COBIT
Many enterprises have fairly simple top-down governance and planning procedures, often focused on a primary SOA proponent within the IT groups. Others have developed elaborate management structures to oversee their SOA environments. Standard Life Assurance, an Edinburgh, Scotland, insurance company, takes the latter approach.
Derek Ireland, group tech solutions manager at Standard Life, describes the firm’s interlocking business and IT governance processes, which are consistent with Control Objectives for Information and related Technology (COBIT), a widely adopted IT-governance best-practices framework.
“We use the COBIT framework as the basis for our IT governance,” Ireland says. “We have mapped our processes onto the COBIT processes. Our SOA is a key part of our current IT, and we have formal roles, policies and processes that govern the evolution of our technological direction.”
Under the COBIT framework, Standard Life distinguishes between IT investments that contribute to the ongoing evolution of its SOA infrastructure, and those that deliver business capabilities in an SOA environment.
Ireland explains that the first category of investments — SOA infrastructure — is governed by an IT technical board, a technical directions team and specialized technology-specific teams. The IT technical board, which consists of senior IT execs, is responsible for the governance of IT direction. Below that group is the technical directions team, which consists of IT architects who are responsible for ensuring execution of the mandates and directions handed down by the IT technical board. Technology-specific teams execute specific IT projects under the supervision of the technical directions team and the IT technical board.
SOA projects aimed at delivering business capabilities have to meet the same criteria as any other IT project before they get the green light. “The decision to execute a project will be based on its relative business case in comparison to other projects,” Ireland says.
"The decision to execute a project will be based on its relative business case in comparison to other projects."
- Derek Ireland, group tech solutions manager at Standard Life
SOA governance in design time
Once a new SOA project is authorized, Standard Life’s IT groups enforce companywide development practices through mandatory corporate-standard development tools. In this way, tight SOA governance is implemented actively down to the level of programming code.
According to Ireland, “Our SOA is defined through design patterns at three levels: architectural (high level), design (technology independent) and implementation (technology specific). These patterns are then encapsulated in an executable [SOA] software framework delivered as a product to our application development teams.” The company’s SOA executable software framework automates several design-time activities, including code building, unit testing and software deployment.
Policy-driven control over software deployment is one of the most critical aspects of design-time SOA governance. Standard Life automates software deployment at all levels, from integration test, through system test, acceptance test and production.
“Developers do not have the ability to deploy to our run-time infrastructure without the automated build and deploy procedures,” Ireland says. “This means it is not possible to implement SOA business services that are not built on top of our executable software framework.” In this way, Standard Life ensures that the firm’s SOA reference architecture is followed closely in design time on all authorized projects, ensuring that newly built services consistently enforce company policies and practices.
Service registries are the chief enforcement point for both design-time and run-time governance at Standard Life. The company has one registry for design-time governance and another for run-time, Ireland says. “We have a run-time Business Service Directory implemented on IBM’s [Universal Database] and encapsulated within our executable SOA software framework . . . We also have a business service catalogue for analysis and design-time information, including service descriptions, schemas, service owners and version release notes.”
Standard Life has not implemented a UDDI registry, citing that technology’s lack of support for some run-time attributes that it requires. However, other enterprises are implementing UDDI in their SOA environments or strongly leaning in that direction.
UDDI enforcement
MedicAlert Foundation is a nonprofit membership organization that runs a hosted network service in which critical medical information is provided to patients, healthcare providers, payers and first responders. “SOA governance is a new concept for MedicAlert,” says Jorge Mercado, the firm’s lead IT architect and principal SOA proponent. “We have some [SOA governance] roles and policies, but we have no design-time enforcement yet of those policies,” he says.
The company is still evaluating commercial UDDI registry products and associated workflow and policy tools. It is considering eventually implementing an administrative workflow for controlling which developers can create Web services artifacts and who can promote those artifacts to whatever UDDI registry the firm implements.
The U.S. Defense Information Systems Agency (DISA) has implemented a design-time Systinet UDDI registry in an ongoing effort to institute a comprehensive SOA governance environment. Under that program, DISA also has implemented a Systinet policy-management tool that controls which developers can publish what types of services to the registry under what circumstances, says Dennis Nadler, CTO with Merlin International, a Vienna, Va., systems integration firm working with the agency.
DISA’s UDDI registry automatically performs compliance checking on all new services that anyone attempts to publish to make sure they implement valid DISA-standard Web Service Description Language, Nadler says. In addition, developers are required to classify services in the registry, using DISA-standard classifications that refer to service-access profiles with associated attributes and run-time policies. “One classification will be ‘public/Web services,’ which refers to services that are available throughout the Department of Defense. Another will be ‘public/internal,’ which refers to services that will only be accessible from within DISA,” Nadler says.
SOA governance in run-time
DISA’s UDDI registry may soon have a run-time governance role as well, Nadler says. The agency is implementing AmberPoint’s run-time SOA management product and plans to integrate that infrastructure with the Systinet UDDI registry. When a new service is registered along with its security, QoS and other run-time policies, AmberPoint will automatically become aware of the service and start to enforce the policies through agents installed at various inspection points throughout the SOA environment. The agents will inspect the flow of message traffic, filter and process messages based on their contents and headers, and apply appropriate policies to that traffic.
DISA is examining the issue of where best to deploy which SOA run-time management inspection points, Nadler says. One issue is that the agency may deploy more than AmberPoint for run-time SOA policy enforcement. It also may implement XML firewalls, network load balancers and traffic management appliances from other vendors.
Each of these products will have its own software and/or hardware agents that implement its own range of policies. Each also will have its own policy-administration tools and administration console.
Run-time SOA management agents must enforce the company’s security policies, says Crowhurst of Thomson Learning. “In operations, we’re heavily focused on security. One of the criteria for evaluating a service design is whether it implements our identity and access-management policies, especially with respect to federated identity standards.”
He says XML firewalls are the most appropriate agents for enforcing SOA security policies. And he bemoans that there are no industry standards under which a single administrative console can supervise a heterogeneous network of XML firewalls, SOA management run-time agents and other policy enforcement points.
Tool time
For run-time SOA governance, it’s important to have a centralized policy console to administer distributed enforcement points, The Hartford’s Moreland says. That company plans to implement one vendor’s SOA management infrastructure product across its entire P&C group.
It plans initially to deploy SOA management agents in a gateway model — in other words, at intermediary points in the message flow. Later on, according to Moreland, the company will move toward a hybrid deployment model that places run-time policy-enforcement agents at gateways and at SOA endpoints, such as application servers.
The Texas Health and Human Services (HHS) Commission is in the process of acquiring a design-time UDDI registry, and wants to integrate that registry with run-time policy enforcement points in HHS’ enterprise service bus () middleware infrastructure.