|
Page 1 of 10
By John Michelsen and Jason English, iTKO, Inc.
Originally Published on GTRA (Government Technology Research Alliance)
Executive Summary
Leading enterprises and public institutions are universally moving toward a more federated approach to systems: highly distributed, reusable and flexible methods for delivering the software required to support operations. SOA (Service-Oriented Architecture) allows a division to build process workflows that consume the best of the component technologies already published or in development by other organizations as Services. A Federated SOA offers the promise of greater agility, and purportedly less integration headaches and effort between different authority domains and divisions, as all of the Services should follow common design patterns.
However, there are good reasons why divisions often built and maintained their own monolithic application silos: who else could they trust? How can you be sure that a third party would deliver the required functionality, if they are not "on the line" to make it work for you? Realizing an effective Federated SOA strategy in mission-critical theatres, whether they are business transaction networks, or military scenarios, requires establishing horizontal trust between peer units, with services managed outside of the vertical chain of command.
SOA Governance is the practice of aligning technology with the operational charter of the organization. Technology pundits, consultants and vendors each have their own particular recommendations for establishing and enforcing good policies for software, atop the distributed authority domains and constantly changing technology components of the SOA application for business. But for Government entities and the teams that develop their own infrastructure today, the governance challenge takes on a new dimension. Those who consume technology services must be accountable along with the publishers who create and offer services.
This accountability goes far beyond compliance to technology protocols. Will the delivered application meet the workflow requirements, with complete process accuracy, and at the necessary scale? A Center of Excellence in SOA Policy Certification is required to ensure that all of the players in the Federated SOA are responsible publishers and consumers of shared technology assets. The certification process must happen at design, build and runtime of the SOA application.
There are three types of SOA Policy that each organization must take responsibility for: structural, behavioral, and performance. The more specifically defined and enforced these policies are throughout the SOA Governance Lifecycle, the more effective the combined results of the Federated SOA will be. The end result? All the agility, efficiency and reuse the participating organizations expected from SOA, with a level of quality that fosters the trust needed to make structural, behavioral and performance policies a reality.
This paper will refer to government organizations as a case study on SOA Governance. However, architects and developers in the business computing arena can draw valuable lessons from the complex integration and quality challenges faced by federal agencies.
Net-Centric or SOA?
Note that in this paper, we will often use the terms “Net-Centric” and “Service-Oriented” interchangeably to define SOA. Many government institutions use “Net-Centric” to describe a shared and collaborative set of software capabilities that are leveraged in a very SOA way. For our purposes, either term works.
There are three types of SOA Policy that each organization must take responsibility for: structural, behavioral, and performance. The more specifically defined and enforced these policies are throughout the SOA Governance Lifecycle, the more effective the combined results of the Federated SOA will be. The end result? All the agility, efficiency and reuse the participating organizations expected from SOA, with a level of quality that fosters the trust needed to make structural, behavioral and performance policies a reality.
|