Governance relies on policy, people, process and technology to guide business activity and deliver consistently positive outcomes. Effective governance channels business activity towards the ‘right’ path by making the right actions the path of least resistance.  Policy management is used to specify the correct behavior, detail exception thresholds, and define corrective actions or notifications.  Leading application services governance platforms deliver advanced policy management by conforming to a flexible architecture, covering significant policy categories, and spanning all lifecycle phases.

Flexible policy management architecture enables distribution and separation of policy enforcement points (PEP), policy decision points (PDP), and policy information points (PIP). Additionally, flexible policy management architecture provides self-service access, automates policy decisions, and integrates disparate policy enforcement points.

A complete Application Services Governance Platform covers the following policy categories:

• Design-time Policy
• Run-time Policy
• Security Policy
• Developer access Policy
• Service and API Lifecycle Management Policy
• Application Lifecycle Management Policy

Teams commonly use design-time policies, lifecycle and code time policies, and run-time policies across service, API, and applications.  To reduce ‘policy islands’, a cohesive Application Services Governance platform will provide end-to-end coverage across all lifecycle phases (e.g. plan, design, develop, test, deploy, manage, evaluate, re-use, deprecate, and retire).

Policy Management Architecture

Teams craft policy definitions using policy management interfaces, and the application services governance platform store the policy definitions in policy information points (PIP).  Policy information points are commonly databases, configuration files, or repositories.  Policy enforcement points (PEP) monitor system interactions and compare behavior to policy thresholds.  Policy enforcement points may determine an interaction crosses a policy threshold (e.g. exceeds rate limit, message sent unencrypted, CPU utilization exceeds limit) or delegate the comparison to a policy decision point (PDP).  Policy enforcement points and policy decision points may both take remediation actions. Common policy decision points are SOA governance registries, identity management and entitlement services, authorization servers, and cloud controllers.  Common policy enforcement points are API gateways, mobile gateways, HTTP interceptors, Enterprise Service Bus’ (ESB), or firewalls.

Flexible policy management architecture provides self-service access, automates policy decisions, and integrates policy enforcement points.  When consumers use self-service access and choose their own policy tiers, application service adoption efficiently scales.  Automated policy decisions reduce operations expense and maximize solution consistency.  Integrated policy enforcement points expand policy coverage across the environment and lifecycle phases.

Lifecycle Phases

Teams commonly use design-time policies, lifecycle and code time policies, and run-time policies across services, APIs, and applications.  To reduce ‘policy islands’, a cohesive Application Services Governance platform will provide end-to-end coverage across all solution components and all lifecycle phases (e.g. plan, design, develop, test, deploy, manage, evaluate, re-use, deprecate, retire).

API management portals and SOA Governance Registries must work together to synchronize API and back-end service policies.  Additionally, API lifecycle stages synchronized with backend service implementation stages.  An API Governance experience may provide a straightforward set of lifecycle stages (e.g., created, published, deprecated, retired, blocked) that may be customized by the development team.  SOA Governance Registries facilitates service metadata management and governance across design, implementation, test, and run-time operations.  Figure 1 below depicts the intersection of the API governance and service governance views.

Figure 1: API Governance and Service Governance Views

Application delivery governance requires a unique set of promotion and demotion policies tied to funding, design reviews, security reviews, and test results.  Application Services Governance Platforms should span project inception, development, quality assurance, production deployment, production management, maintenance, and retirement.  Figure 2 illustrates service implementation activities governed by application delivery governance.

Figure 2: Implementation activities governed by application services delivery governance

Policy Management Categories

A complete Application Services Governance Platform manages, stores, decides, and enforces:

• Design-time Policy
• Run-time Policy
• Security Policy
• Developer access Policy
• Service and API Lifecycle Management Policy
• Application Delivery Management Policy

Figure 3. Application Services Governance Policy Categories

Design-Time Policy Management and Enforcement

Design-time polices ensure:

• Developers use a common naming convention for artifacts
• Enforcement of standards (e.g.: schema standards, namespace naming conventions and interoperability validation across services)
• Service and API versioning (e.g.: version numbering policies, policies for creating/approving new versions, revisions and restoration policies)
• WS-I Compliance
  • Basic Profile (BP)
  • Simple SOAP Binding Profile (SSBP)
  • Attachments Profile (AP)
  • Basic Security Profile (BSP)
  • Lifecycle promotion policies via checklist/policy enforcement
  • Project teams publish their services in the repository
  • WSDL and XML Schema validation

Run-time Policy Management

A complete Application Services Governance platform governs and manages the following run-time policy categories:

Service Level Agreement Monitoring & Reporting

○  Tenant and subscriber rate limiting

○  Service-aware and tenant-aware load balancing policies

○  Private tenant partitions to reduce ‘noisy neighbor’ impact

○  Trigger notifications based on service usage thresholds

Billing and metering policies

○  Rate limiting service and API interactions

○  Throttle service and API interactions

Entitlement and Authorization via XACML, e.g., who can access which service, API, application, or resource for what purpose

○  WS-SecurityPolicy enforcement

○  Throttling maximum connections to systems via policy

○  Caching responses via policy

○  Attribute-based access control

○  Role-based access control

Infrastructure Provisioning

○  Define and enforce auto-scale limits.  Infrastructure resource pool constrained between minimum and maximum run-time instance thresholds

○  Limit provisioning administration activity based on permission policies assign to user role

Service mediation policies

Using a zero coding approach and only policy/rule authoring and configuration, teams may define policies that:

○  Automate routing of messages based on content-based rules: i.e. send alerts for all orders where the order value is greater than the customer’s credit limit.

○  Turn off services or reroute based on time of day or other aspects.

○  Transform message format

Security Policy Management and Enforcement

Beyond basic authorization and authentication, a comprehensive Application Services Governance Platform supports API subscription approval policies and API token expiration policies.  Role-based access control (RBAC) and fine-grained entitlement based access control policies may be associated with users, services, and APIs.  Attribute or Claim based access control is available via XACML, WS-Trust, or OpenID. Security policies may be attached to services, APIs, or resources.

Developer Access Provisioning Policies

Developer subscription, usage, and access may be managed and governed.  Developer self-service subscription policies may capture developer information and trigger approval workflow.  Role-based access controls may be applied to developer provisioning.  The Application Services Governance Platform should support multiple roles (e.g. API creator, API publisher, and API subscriber).

Service and API Lifecycle Management Policies

Teams may define custom gates and checklist items to govern and manage the service and API lifecycle processes. Lifecycle stages and stage transition policies may be defined and extended by administrators. Approval policies (supports multiple approvers) can be setup to control stage transitions.

In addition to checklist/approval based manual lifecycle governance policies, users can establish automated validation rules (using pre-built validators or custom Java-based validators) and define lightweight WS-HumanTask based process workflows or complete BPEL business process orchestration.

Application Delivery Management Policies

Web services and Web APIs are just one type of solution artifact that should be managed by the governance platform.  Teams must also govern and manage application lifecycle promotion and versioning.  Development teams may define custom gates, checklist items, and promotion/demotion rules to govern and manage application lifecycle processes.

Common Policy Management Scenarios

Teams commonly implement the following design-time, service and API lifecycle management, and run-time policies.

Common Design-Time Policies

The platform’s governance registry user interfaces commonly manage and govern WSDL validation, WS-I compliance, and XSD reuse.  Complementary API Manager user interfaces manage and govern API subscriptions and API promotion meta-data.  API promotion meta-data includes keyword tags used to categorize APIs, developer documentation used to help developers evaluate APIs.  Both service and API views enforce design-time checkpoints to ensure adequate documentation and promotion meta-data is defined before publication.  Subscription and usage reports help teams understand API adoption (by version, by API) and usage (by version, by API).  By understanding API adoption and usage, API business owners and API architects can intelligently invest future development resources, properly plan API infrastructure scale, and rationalize the API portfolio

Common Service and API Lifecycle management Policies

Teams using a governance registry (for services), API developer portals (for APIs), and project development interface (for service implementation projects) commonly utilize lifecycle management policies that include versioning schemes, promotion approval authority, and checklist conditions that must be passed before promotion.  During demotion, the reason is captured and workflow triggered to rectify open issues.

Common Runtime Policies

In conjunction with message intermediary enforcement points (i.e. ESB and gateway proxies) and identity entitlement decision services, an Application Services Governance Platform is commonly used for service response caching, service throttling, service load-balancing, and XACML-based access control.

Sample Governance Model

Within these three broad categories (i.e. design-time, lifecycle-time, run-time), teams may configure advanced policy decisions and enforcement. The Application Services Governance Platform should support defining high-level service descriptions independent of low-level service definitions.  The following best-practice end-to-end service governance model is recommended:

1. Build a namespace/organizational hierarchy that correctly defines the business areas.

2.  Business analysts use the service definition interface to create a set of high-level service definitions that map to the eventual model

3.  Using Eclipse modeling technology or third-party tools, teams may build a canonical data model using XSD.

4.  A governance registry helps maintain the consistency of this by finding shared schemas across services and notifying when changed.

5.  As services are refined to create real WSDLs or technical definitions tie these to the high-level service descriptions.

6.  The governance registry should automatically catalogues WSDLs in the correct namespace hierarchy.

7.  Application Services Governance Platform Dashboards provide an overview of the state of services, the number of services, the lifecycle stages of services, schema re-use and other overview to understand the overall progress.

Recommended Reading

Policy Management Requires More Than a SOA Registry

Application Services Governance

Governance Registry Brings Integrity to SaaS Platform

Gartner’s analysis of WSO2 SOA Governance

API and SOA Convergence