One of the key selling points of adopting an SOA approach to system design is flexibility and adaptability; i.e., reduced future cost and faster time to market. The biggest flaw in this argument is that it is not SOA as a design approach that returns these benefits but rather a properly designed and effectively managed SOA Governance process that makes these benefits a reality.
The problem is how do you transform a culturally entrenched legacy process of governance based in traditional “stove-pipe” application design to a process that achieves the benefits of SOA? The answer is “horizontal” and “vertical” governance approach.
What do I mean by a horizontal and vertical governance process? Let me start by putting forth an SOA governance mission statement…
“To never let how we process business dictate how we conduct business.”
Further clarified by a governance scope statement…
“How we process business is the governance responsibility of the “Service Provider Domain.” How we conduct business is the responsibility of the “Service Consumer Domain.”
Thus the vertical governance body is the group comprised of business unit leaders responsible for the underlying systems that provide the transactional services and the horizontal group is one comprised of business leaders that consume the services or represent the (external) consumers of the services.
The vertical (service provider) governance is focused on building services that accurately and efficiently maintain the “logical to physical” relationship between each constructed service and the physical legacy applications and data stores supporting the service. In other words, their responsibility is to ensure that every service developed is accurately and efficiently tied to the underlying “systems of record” with full audit and compliance tractability. They understand how a transaction is processed and guarantee the accuracy and accountability of those transactions. This body also manages the legacy systems migration and “sun-setting” activities. As more services are built providing services based on ubiquitous semantic capabilities, the use of old redundant capabilities in the underlying “stove-pipe” legacy systems can be “shut off” ultimately allowing the entire system to be retired.
The horizontal (service consumer) governance is focused on how those services are delivered to the consumer in an efficient and engaging manner that results in a positive experience for the consumer. They are responsible for governing the delivery of services consistent with the corporate mission, strategy and business plans. Their mantra is…
- What services need to available?
- To be delivered to which constituents?
- Across which channels?
- In what priority and timeframe?
They do not have direct governance over the underlying physical systems that process the business. They are only aware of the services that have been constructed exposing their capabilities. They are however responsible for defining the roadmap for when those services need to be delivered, who will they be delivered to (consumers) and how they will be delivered (channels).
Finally, the glue between the two governance bodies is the Enterprise SOA Governance team. Their role is to ensure that the needs of both service providers and service consumers are met. They are also responsible for validating that all enterprise level requirements like Security and Service Level Agreements are met.
The following diagram represents the various horizontal and vertical domains for a Health Insurance company.
Figure 1
Next is a diagram of an SOA reference architecture “stack” with the top three layers identified as the focus of the Horizontal Governance group and the bottom three layers the focus of the Vertical Governance group.
Figure 2
The most critical value of this split between horizontal and vertical governance is that it creates a barrier to force the governance participants away from traditional “stove pipe” thinking. Vertical governance (i.e., the body that governs the requirements of the service providers within the company) does not have the power to dictate how a service will be delivered and consumed. Conversely, Horizontal Governance (the body that represents the requirements of the service consumers) does not have the power to add new legacy systems to the infrastructure or dictate which systems should be used to process the services they are consuming.
This model provides a way to organizationally and culturally “re-tool” the company away from their traditional “system delivery” mentality towards a service provider and service consumer mentality.
It is also important to point out that the business process layer is governed by the governance body responsible for determining how we “conduct” business not the body responsible for how we “process” business. That is because in the above SOA model, the business process layer is more focused on providing flexibility in how we conduct business rather than flexibility in how we process business (which is managed at the business service layer.) The business process layer does not create new business services like “Credit Check” or Order Status” but rather orchestrates these services consumed from the service layer into adaptable and flexible ways for them to be consumed by the service consumer.
This model also forces the Vertical Governance group to develop services that enterprise oriented, i.e., designed on semantic data models, channel agnostic, and compliant with enterprise security and service level standards.
As stated at the beginning of this article:
- The SOA Architecture team facilitates both of these governance bodies and synchronizes their efforts. They also manage the process for resolving conflicts between the two governance bodies.
- The Horizontal Governance group drives the technology roadmap and system development plan.
These concepts are too lengthy to describe here so I will leave them to a future article.
Conclusion
The whole purpose of SOA governance is to come up with a way to radically transform the people, process, platforms and practices of the company into a model that can successfully deliver on SOA’s promises. You need to impact all 4 of these “P’s” to be successful. This transformation needs to radically impact the cultural thinking and organizational territories of the company. The model put forth in this article helps you achieve these objectives by creating a mechanism for clearly de-marking and articulating the business responsibilities and accountabilities into the two newly established business domains (those who provide and those who consume). Once this distinction is established, the business leaders (rather than IT or Architecture) will be positioned to drive the necessary organizational and cultural changes needed to support their new responsibilities by providing a model that clearly articulates business accountability around producing and consuming services.
