Grace Lewis, senior member of the technical staff at the Software Engineering Institute, is leader for the SOA and Cloud Computing theme at SATURN 2011, which will be held May 16-20 at the San Francisco Airport Marriott in Burlingame, California.
We often say that architecture should be prescriptive and not descriptive. However, enforcing architecture is not an easy task, which is why people are starting to talk about architecture governance as a way to be prescriptive about architecture.
On a related note, even though service-oriented architecture (SOA) is an architectural style for designing and developing distributed systems, it is interesting that SOA governance often exists in organizations separate from architecture governance or is the only type of specialized IT governance.
I believe there is a two-way relationship between architecture and SOA governance that can be exploited for mutual benefit:
- SOA governance as a way to enforce SOA architectural principles and conformance of software implementation to software architecture
- Software architecture as an enabler of SOA governance
SOA governance is the set of policies, rules, and enforcement mechanisms for developing, using, and evolving service-oriented systems, and for analysis of the business value of those systems [Simanta 2009 (PDF)]. In general, there are three types of SOA governance:
- Design-time governance: Includes elements such as rules for strategic identification, reuse, development, and deployment of services, as well as policies to enforce consistency in aspects such as use of standards, reference architectures, and processes.
- Runtime governance: Includes policies and enforcement rules to ensure that services are executed according to policy and that important runtime data is logged.
- Change-time governance: Applies to maintenance and evolution of service-oriented systems and includes policies and enforcement rules for maintenance and evolution of all elements of service-oriented systems as well as communication of changes to stakeholders.
There are multiple SOA governance models that include the definition of policies related to architecture, such as the models proposed by organizations such as AgilePath, CBDi, IBM, Oracle, SOA Software, and Software AG. Examples of these policies include
- Standards compliance
- Use and execution of architecture evaluations
- Templates for architecture documentation
- Adherence to blueprints, patterns, and reference architectures
Architecture governance is defined by The Open Group as “the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level” and includes “… controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization [TOG 2006].” The loosely coupled nature of service-oriented systems enables system elements to evolve independently. Therefore, the type of control that is implied by the definition of architecture governance is key to following and preserving SOA architectural principles.
The ability to meet SOA architectural principles and obtain the benefits that they promote depends on aspects that are not part of the architecture and that can only be enforced by SOA governance. Some examples:
- Reusability depends on proper service identification that guarantees that all services represent independent and cohesive business/operational tasks.
- Service discovery depends on the quality of the information in the service registry.
- Standardization is bound by the set of standards and respective versions defined by the enterprise architecture.
- Composability should abide by policies regarding ownership of services and information security.
A key to SOA governance implementation is adding control to a system without creating a lot of extra work for developers and users. One approach is governance automation in which the burden of ensuring compliance and enforcement gets pushed to the SOA infrastructure. There are tools and SOA infrastructure components in which some governance automation is built in.
Some aspects of governance that can be automated (or semi-automated) include
- workflows for proper service identification
- service deployment procedures
- compliance with regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and Sarbanes-Oxley (SOX)
- compliance with internal security policies
- runtime measurements and logging
- management of service-level agreements
- conformance to reference architectures
Architectural constructs can be custom developed for aspects of SOA governance that are critical for SOA implementation and are not covered (or are implemented differently) by the SOA infrastructure elements and SOA governance tools.
In essence, SOA governance can be embedded into architecture governance (or the other way around) as a way to prescribe important architecture principles and architecture can be used as a mechanism for governance automation such to enforce these principles without a lot of extra work for developers and users. Seems like a perfect match!
– Grace Lewis, SEI
[Simanta 2009] Simanta et al. “A Scenario-Based Technique for Developing SOA Technical Governance.” Software Engineering Institute. http://www.sei.cmu.edu/reports/09tn009.pdf (2009) [PDF]
[TOG 2006] The Open Group. The Open Group Architecture Framework (TOGAF). 2006. http://www.opengroup.org/architecture/togaf8-doc/arch/index.html