In this series of articles we examine the correspondence and synergies of Service-Orientation and The Open Group Architecture Framework. In Part I and
Part II of this article we went through the phases related to architecture definition, service design and implementation,
architecture adoption and vision, the main roles, and the implementation of multiple service inventories using hierarchies of the TOGAF ADM. In the process we examined the synergies between the two methodologies.
In this article we go deeper into governance topics and examine how different SOA governance models can be applied in the TOGAF ADM and its hierarchies.
SOA Governance Models and the SGPO
SOA Governance [REF-1] allows for three different governance models for the inventories:
- Centralized: There is only one architecture and governance body for all Inventories. This is the default setting if there is only one inventory in the enterprise. (Figure 1)
- Independent: Each Inventory has its own architecture and governance without a centralized architecture and governance body. (Figure 2)
- Federated: There is one architecture and governance body for each inventory, but there is also one central architecture and governance body that has overall control. (Figure 3)
Central term, in the definition of SOA Governance, is defined as the SOA Governance Program Office (SGPO). An SOA Governance Program Office (SGPO) is an organizational entity comprised of trained SOA governance specialists, enterprise architects, and other types of IT decision makers. The SGPO is the authority that defines and enforces the on-going activities and rules associated with SOA governance. The SGPO can use other governance programs in various IT departments.
In this article we assume that the SGPO, or a set of SGPOs, is the only governance institution in the organization. This assumption includes all architecture and governance institutions in the organization that support SOA, implying that all architecture and IT governance activities at enterprise level and domains and inventories belong to the responsibilities of the SGPO. This means that we examine an SGPO with a rich scope, a characteristic of a successful SOA deployment.
In this article we will not elaborate further on the responsibilities of the SGPO. These are well presented in [REF-1].
Figure 1 – The Centralized SOA Governance Model
Figure 2 – The Independent SOA Governance Model
Figure 3 – The Federated SOA Governance Model
Governance for Each Inventory
In part II of this article we saw that the TOGAFADM can be employed in layers in order to support:
- the architecture and implementation of several domains for an organization
- the architecture and implementation of a service inventory for each domain
- the architecture and implementation of services for each inventory
Each additional layer of the ADM cycle introduces new architecture and governance requirements. The recommendation of TOGAF is that:
- if there is only one architecture and one governance team, layering of the ADM should not be applied
- if there is more than one architecture team (and thus more than one governance team) then the ADM can be layered and each team can be responsible for each cycle or layer
Given the SOA Governance models, the above recommendations of TOGAF imply that:
- in the Centralized governance (and architecture) models layering of the ADM should not be applied
- in the Independent governance (and architecture) models the ADM can be layered and each SPGO is responsible for each cycle
- in the Federated governance (and architecture) models the ADM can be layered and each SPGO is responsible for each cycle and/or layer
This seems simple and intuitive at first sight, however; the complexity arises from the combination of these three dimensions listed below per governance model:
- Architecture phases in the ADM
- Governance phases in the ADM
In the following sections we examine each governance model separately applied to the service inventory analysis and implementation. The SOA Governance models do not go deeper into the analysis and implementation of each service (the capability architecture in TOGAF). Nevertheless, the SOA Governance defines processes for the governance of each service and all of these can be adopted by TOGAF. In this paper we concentrate on the governance of service inventories.
ADM Layers in the Independent Governance Model
In the independent governance model we have a separate architecture team per service inventory. The architecture of each inventory is defined in Phase B (Business Architecture), C (Information Systems Architectures) and D (Technology Architecture) of the TOGAF ADM. The correspondence between the architecture artifacts of the Independent Governance Model per service inventory, and the TOGAF phases in which these artifacts are produced for each segment of the architecture (i.e. for each inventory), is depicted in green in Figure 4.
The independent governance model assumes also a separate governance team per service inventory. The governance of each inventory is related to the implementation of the architecture in the inventory. This corresponds to Phase F (Migration Planning), G (Implementation Governance) and H (Architecture Change Management) of the TOGAF ADM. The correspondence between the governance teams of the Independent Governance Model per service inventory and the TOGAF phases in which the governance is exercised in each segment of the architecture is depicted in brown in Figure 5.
Figure 4 – Independent Architecture in each Inventory in the TOGAF ADM
Figure 5 – Independent Architecture and Governance in each Inventory in the TOGAF ADM
ADM Layers in the Federated Governance Model
In the federated governance model we have a separate architecture and governance team per service inventory, but all these teams are controlled by a centralized architecture and governance team. Similar to the independent governance model, in Figure 6 we depict:
- in green the correspondence between the architecture artifacts per service inventory and the TOGAF phases in which these artifacts are produced for each segment of the architecture
- in brown the correspondence between the governance teams per service inventory and the TOGAF phases in which the governance is exercised in each segment of the architecture
The function of the centralized SGPO at enterprise level is to define the different domains, the set of standards and constraints under which each of the domains is to be architectured and governed by its own architecture and governance bodies.
The centralized SPGO operates at the Strategic Architecture layer and defines the architecture of the enterprise (the domains, the segments) in Phases B, C and D, and governs in Phases F, G and H. This is depicted with blue in Figure 7.
Figure 6 – ADM Layering of Federated SOA Governance of Service Inventories (I)
Figure 7 – ADM Layering of Federated SOA Governance of Service Inventories (II)
ADM Layers in the Centralized Governance Model
In the centralized governance model there is either:
- a single enterprise service inventory
- a single SGPO responsible for multiple domain service inventories, independent of their ownership
The first case results in a single layer and we will not examine it further.
The second case though deserves some attention. It corresponds to a federated model, where the individual inventory governance bodies have been merged to one centralized SGPO. Although the governance is common in all the inventories, the inventory blueprints can be different. The common governance and architecture is depicted with blue and the separated inventory architectures are depicted with green in Figure 8.
However, as mentioned earlier in this document, TOGAF does not recommend this kind of layering in the presence of a single governance and architecture team for all architecture segments. TOGAF's recommendation in this case results in a single layer of the ADM, where a single team is running the ADM several times, once for each inventory. This is depicted in Figure 9.
Figure 8 – Application of service-orientation in each Process or Service.
Figure 9 – Recommended ADM Layering for Centralized Governance and Architecture of Service Inventories
Benefits of the approach
The previous sections provided a meaning in the layering of TOGAF by using concepts of service orientation, the architecture segments are the SOA domains with their service inventories. We showed that different layers have different objectives in an SOA context, and therefore they can be architected and governed by teams with different skills. Enterprise governance is found at the top layer, service inventories and domain governance are found at the second layer, while analysis and design of services in individual projects is at the third layer, although the governance of these projects (the implementation of the inventory) is still in the second layer. This makes it easier for big organizations to define the appropriate layers, and thus the appropriate scope and responsibilities for each architecture and governance body.
On the other hand, the distinction of the SOA Governance Program from the Governance System is important in the SOA Governance [REF-1]. The usage of the TOGAF layering and the TOGAF ADM provides a powerful visualization and a set of concrete phases to the SOA governance models. Using the TOGAF visualization it becomes clear that SGPOs have different objectives at different layers (Strategy vs. Segment Architecture) although they all may follow the same architecture and governance phases (process). It is like introducing an additional dimension (the TOGAF ADM Phases) to the main SOA project delivery phases (Service Inventory Analysis, Service Analysis and Design).
The next article will conclude this series.
[REF-1] SOA Governance. Thomas Erl et. al. April 2011.