Services are the building blocks of SOA, and like building blocks of a house or a building, the quality will define the value of the finished product. In this case, the SOA itself. Thus, spending...

Organizations are often mystified at how to implement Service Oriented Architecture (SOA). Leaders yearn to sprinkle magic ‘SOA pixie dust’ on their IT organization and transform design and development processes. But holistic architectures are not created by accident. Best practices are forged through the application of engineering discipline and rigor.

Many Global 2000 companies are not ready to embrace services. The design and development teams must first learn how to properly govern their IT processes. Teams should document change and release management plans, monitor application and service availability metrics, measure software quality, track developer productivity across the software life cycle, enforce security policies and service level agreements, re-use standard application frameworks and infrastructure definitions, actively manage service and application portfolios, define release roadmaps, describe applications and services using models and metadata, and consolidate infrastructure.

Enterprise architecture and IT Infrastructure Library (ITIL) are IT practices that facilitate the adoption and implementation of best practices across development and operation teams. Standard governance principles, augmented by service oriented extensions, enable teams to consistently and comprehensively apply service design best practices and achieve the benefits touted by SOA evangelists.

Governance refers to the programs and processes that an organization puts in place to ensure that things are done right, where “right” means in accordance with best practices, architectural principles, federal regulations, and other determining factors. SOA governance refers to the programs and processes used to govern adoption and implementation of SOA. SOA is an approach to application development that requires fundamental changes to design and development techniques, infrastructure, and culture. SOA also requires new levels of collaboration across project teams and across organizational boundaries. Given the amount of behavioral change required by SOA adoption, governance programs and processes are critical to the success of a SOA initiative.

A SOA infrastructure should provide tools and services that support governance processes. As part of a SOA governance effort, an organization should define policies that dictate or provide guidance for service creation, service testing, service utilization, service management, and service versioning. For example, SOA policies should provide guidance for issues such as:

• Service Development Methodologies
  o Application-factoring rules
  o Naming conventions
  o Service styles
  o Interface definition standards
  o Methods for ensuring reliability and transaction integrity
• Configuration management
  o Dependency identification
  o Service classification
  o Service registration
• Release management
  o New service deployment and staging
  o Service provisioning
  o Client provisioning
• Service monitoring and control
  o Thresholding, notification and alerting
  o Event correlation and fault management
  o Consumption and utilization tracking
• Service level management
  o SLA negotiation
  o Compliance tracking and reporting
  o Service level improvement process
• Problem Management
  o Error tracking and resolution
  o SLA monitoring and escalation
• Change management
  o Methods for dealing with regulatory requirements
  o Service modification
  o Service versioning
  o Service testing
• SOA infrastructure
  o Preferred products
  o Product selection guidelines
• Security
  o Methods for implementing security based on risk factor
  o Methods for assessing security risks

This list is long, but it barely scratches the surface. From a practical perspective, SOA architects should extend existing development governance processes to embrace services and implement the aforementioned categories. Toward this end, architects should identify owners of current software life cycle, operations, and management processes, and petition the owners for inclusion of SOA guidelines. For example, project management processes should start measuring the time required to design and develop integration projects. The quality assurance group could start measuring and publishing defect metrics during the development, test, and production lifecycle phases. Systems analysis teams should compare functional requests to existing service catalogues. Design review processes should be extended to include an impedance analysis comparing the application domain model to a common, canonical model. Operational processes can be extended to include monitoring and managing services.

Unfortunately, some organizations do not have baseline IT processes and artifacts in place. When project management, testing, and design review processes and artifacts are non-existence or deficient, SOA stakeholders must first lobby the IT organization for a structural change. The structural changes involved will lengthen the time required for organizations to achieve a real SOA success story.

To ensure compliance with SOA best practices, development and run-time infrastructure should support the management and maintenance of governance policies. SOA infrastructure is a category of technology products that provide mechanisms to impose checkpoints during various phases of the software development lifecycle to verify that services and/or projects comply with these policies. A SOA infrastructure should provide mechanisms that support manual and automatic approval and exception processes.

Without SOA governance, SOA initiatives are doomed to fail. Infrastructure and development processes must be extended to embrace service governance. SOA proponents must ensure that a proper governance foundation is in place before promoting the organization’s ability to achieve SOA benefits.

Back to Articles, including SOA, BPM & BA