InfoQ

InfoQ

InfoQ

En | 中文 | 日本語 | Br

562,907 Jan unique visitors

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Article: SOA Governance: An Enterprise View

Posted by Stefan Tilkov on Aug 20, 2008

Sections
Enterprise Architecture
Topics
SOA ,
Governance
Tags
OASIS ,
Service Contracts ,
policy

In a new article, SOA architect Michael Poulin explains the necessity for SOA governance to ensure an SOA initiative's success, and explains the role the OASIS SOA Reference Model and the accompanying SOA Reference Architecture assign to SOA Governance. Michael observes SOA governance specifics from the enterprise perspective and illustrates them with several examples of SOA Governance policies.

In addition to the SOA Reference Model, Michael introduces the OASIS SOA Reference Architecture, currently in public review:

The SOA RA PRD 1 has recognised the role of enterprise social structure within SOA. Indeed, actions of the participants of the service interaction – service consumers and providers – have business or technical meaning only to the people and organisational units “with needs” and those “with capabilities”. As a consequence of this, we may say that if a social structure changes, the same actions may get different meaning than before. Even more, if a consumer expects the same meaning of the service actions in different social structures, it is likely that the service has to behave differently and provide different results (or RWE) in different social structures to meet such expectation.

Michael points out that SOA Governance is not the only governance an enterprise has to be concerned with:

Nevertheless, SOA Governance does not replace Enterprise Governance, or Business Governance, or IT Governance. We have to remember that there is a world besides SOA.

According to the author, SOA Governance applies to four major aspects of service structure and service use:

  • Service structure – the minimal set of elements that constitute a service within element relationship and operational models (development, integration and deployment policies)
  • SOA infrastructure – the “plumbing” that provides utility functions that enable and support the use of the service (deployment and run-time policies)
  • Service inventory – the requirements on a service to permit it to be accessed within the infrastructure via public interfaces, manually and automatically (management policies)
  • Participant interaction – the consistent expectations with which all participants of the service interaction are expected to comply (reachability and run-time policies)

Michael concludes with examples of SOA Governance policies that have proven to be useful to him in the past:

Areas of Applicability

Policy Examples

Governance Process

  • Service Governance Roles include: Service Owner, Service Provider, Service Consumer, Service Steward, Service Registrar, etc.

  • Service Governance Board includes representation from business, architecture, delivery and systems operations groups. The governance group is responsible for:

    • Defining and maintaining governance directives and policies

    • Granting of design and implementation exceptions when possible

    • Compliance reporting to the Management.

  • Governance policies and controls may be monitored and enforced by the Service Registrar as well as by corresponding Review Boards and Architectural Bodies

Development Stage

  • Design and development of the service has to have very strong reason(s) to be allowed going with an exception from the policies compliance

  • Service design has to be based on and take into consideration business execution context of the required business task. The business execution context should be able to outline what elements of the service are likely to be changed in the future.

  • Service design has to consider recommendations on the business operational scenarios for those who might use the service. If such scenarios are identified, business approval and sign-off are required.

  • Services should minimise or totally hide their internal constraints from the consumers.

  • A Service has to compensate for internal problem processing transparently to the consumers and never expose its internal execution constraints on to the consumers.

  • Service interfaces and service body (implementation) must adhere to the corporate security policies

  • The Service owner must provide service classification (business, infrastructure, etc.) and scope definition (business unit, enterprise, external, etc.) for each released service

  • “Avoid setting up processes that demo well for three services without considering how it will work for 300” (SOA RA PRD 1).


Production Stage

  • All business services are required to maintain a Service Contract for each consumer they support.

  • All services are required to publish Service Descriptions

  • If the service does not require a Service Contract, its service level agreement has to be published in the Service Description

  • All services are required to adhere to a versioning strategy that provides all consumers with opportunities to migrate to the latest supported version(s) of a service.

  • All Service Descriptions have to be published in the Service Description Repository

  • All run-time service policies have to be published in the Service Policy Repository

  • Run-time service Policies may refer to other policies. Policies may be applied by the Policy Enforcement Point (PEP) interceptors and enforced by the Policy Decision Point (PDP) mechanisms

  • “…consider whether the display of status and activity for a small number of services will also be effective for an operator in a crisis situation looking at dozens of services, each with numerous, sometimes overlapping and sometimes differing activities” (SOA RA PRD 1)

Check out Michael Poulin's article, "SOA Governance: An Enterprise View" for more information.

  • This article is part of a featured topic series on SOA

No comments

Watch Thread Reply

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.