SOA Governance: Governing the Service Factory
- Essential Competencies for Succeeding with SOA
- Service Development Lifecycle Control Points
- The Service Development Domain
- The Service Operations Domain
- Case Study
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
- "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning"
- —Rick Cook
Chapter 3, "Building the Service Factory," discussed the value of establishing a service production line to automate SOA development activities, and outlined the tasks, roles, and responsibilities needed to establish such a service factory. Chapter 3 also described a set of work products whose adoption can implement practical SOA governance for the Plan & Organize and Program Management Controls domains introduced in Chapter 2, "SOA Governance Assessment and Planning."
This chapter covers a practical approach for governing both the operation of the service factory and the management of services after they have been deployed to production.
Essential Competencies for Succeeding with SOA
An organization needs certain core technical competencies if it is to succeed with SOA. Good SOA governance is all about developing these competencies and creating governance mechanisms that ensure the service factory runs as smoothly and as efficiently as possible. The following subsections define these core competencies.
Effective Requirements Collection
The old adage "garbage in, garbage out" perfectly expresses the importance of capturing requirements correctly. It is simply impossible to build good software without precise functional and nonfunctional (i.e., technical) requirements. SOA has the major advantage that services should represent some clear agreement or contract between the consumers and developers. As long as good naming standards are used, the purpose of each service invocation (operation) should be instantly clear to both business and IT staff.
There is an important degree of judgment to be made in terms of the effort made in capturing and reconciling requirements from all prospective consumers of a new candidate service. In an ideal world, all potential consumers of each service will be canvassed for their specific requirements, and a service designed that accommodates the full set of needs expressed:
- This has the theoretical advantage of reducing any need for future reversioning of the service, and encouraging maximum reuse (both major positive goals).
- Unfortunately, it has the practical disadvantage of consuming a significant amount of analyst resources, and potentially adding complexity and cost to the development of the first version of the service.
The current balance of opinion is that some kind of 80/20 rule applies: 80% of potential consumer requirements can probably be decided by a skilled analyst with 20% of the effort of an exhaustive study. Defining optimum service granularity, service design, and quality of documentation is as important an enabler of future reuse as an exhaustive initial consumer and requirements analysis.
Creating and publishing a catalog of requirements is critical to encouraging reuse and avoiding unnecessary duplication. Creating a high-level business process model and a common glossary of business terms is a critical precondition to creating a requirements catalog.
An excellent practice is to define the nonfunctional requirements, together with criteria for testing and acceptance of the service, at the same time as the requirements are being captured.
Competency in Service Design
Although service architecture and technical details beyond the scope of this book, we need to make some comments in terms of governing the service design process:
- It is essential to have a formal set of critical architectural work products to guide service designers. These include architectural principles that must be followed, architectural decisions that need to be complied with, recommended design patterns, and a formal target production. A best practice followed by many large organizations is to create an architecture review board (ARB) that is responsible for maintaining the vitality of such architectural assets.
- A strongly recommended best practice is to encourage (ideally mandate) regular service design reviews that include as wide a range of technical talent as possible. This has the joint advantages of optimizing the design of each service, promoting consistency, ensuring compliance with standards and best practices, and, not least, helping to grow the architectural skills of the more junior team members through on-the-job mentoring.
Competency in Service Development
Modern software development kits (SDKs) or tools make the physical SOA development processes relatively straightforward, and using them promotes consistency of technical approach and high quality. In this chapter, we discuss some work products that can help to monitor and assist service development.
Competency in Service Testing and Deployment
A reputation for quality is hard to gain and easy to lose. Thorough testing and an efficient and error-free deployment process are essential to gaining and maintaining a reputation for quality. Again, we describe some work products to help govern these processes.
Competency in Operational Management and Monitoring of Services
One of the easiest ways to lose a reputation for quality is to have products that perform badly or that keep breaking down, so we also address this important area from a governance perspective.