| Backgrounder: |
SOA Policy
While the importance of SOA policy is widely acknowledged, the area remains shrouded in considerable confusion. This article is aimed at addressing the pressing need for clear SOA policy concepts and practical advice that discussions with our members increasingly reveal. Our starting point is to provide overall organizational context in terms of a suggested governance framework. Above all else our research indicates that SOA policy is but one part of a complex SOA jigsaw. We therefore layout the detailed conceptual foundations for SOA policy in the form of an update on the Planning and Provisioning Policy View of the SAETM Meta Model. We then provide some specific illustrations of policies along with policy definition templates with examples. Finally we relate this advice to the process guidance that we have been unfolding in previous articles.
by Paul Allen
Introduction
We have consistently advised that in order to minimize costs, maximize quality and manage risks we need new, more comprehensive ways of structuring and managing the software portfolio in agile response to business needs. At the same time around the world, governments are introducing more and more regulations. Governance crosses the full range of how a business is run in terms of the guidelines, policies, procedures, and practices that exist at every level of the firm.
SOA provides the potential to address these apparently conflicting issues of agility and governance very effectively. Each service is specified in the form of a contract between consumers and providers. This helps an organization gain control over its assets by:
clearly marking out lines of accountability
ensuring responsibility and authority come together as much as possible
identifying missing or inadequate control points.
However this line of thought begs a particularly important question: How do we ensure governance of SOA itself? A popular response to this question is to point out that SOA policy must be defined and managed and that the process of SOA must be compliant with this policy. In fact everyone seems to be agreed that one of the defining features of SOA is a particular emphasis on policy. While MDA1 and DSL2 approaches are strong in areas such as software patterns and structure, policy is one of the key missing pieces required for effective governance of software aligned to business needs.
While the importance of policy is not in dispute, time and again we find in our discussions with members, the meaning and content very often is in dispute because there are many types of policy that will be governed in different ways. Policies relating to service profiles and usage, for example, will be subject to automated governance – defined in the registry and monitored at the ESB level providing automated runtime governance. In contrast policies relating to architecture, design and sourcing will be the subject of governance board review following completion of particular tasks and deliverables. Yet it is common that only the former type of runtime policy has been considered in planning SOAs because the vendor community has been very vocal in drawing attention to the latest technology product that supports it.
Of course governance actions on all types of policy should be recorded and auditable in some common format but judgment decisions made by a review board are no less important than automated governance, and in many cases will lead more directly to significant business agility being maintained.
This article takes the lid off the policy can, examining the concept, setting it in overall context and providing illustrations. |
Home