ServiceTechMag.com > Archive > Issue LII: July 2011 > Mapping Service-Orientation to TOGAF 9 - Part I.V: Methodology, Processes, Steps, Principles
Fillipos Santas

Filippos Santas

Biography

Filippos is an IT Architect for Credit Suisse Private Banking in Switzerland and a SOASchool.com Certified SOA Trainer, Analyst, Architect, Consultant, and Security Specialist. Additionally, he is certified by The Open Group on TOGAF 9 and by IBM on the Rational Unified Process V7.0. In the last 10 years, Filippos has been the lead for the analysis and architecture of a number of successful SOA projects and for transforming legacy architectures to service-oriented architectures, primarily in the financial sector. His achievements include the conceptual and physical design of the international insurance claims service network that connects insurance policies, customer companies and state authorities in 44 countries across the globe, combining legislation, business processes, business rules, business objects, knowledge bases and different platforms.

Filippos recent work with Credit Suisse has been as an SOA Architect, combining the profitable and established functionality of legacy systems with centralized business process services, decentralized business rule services, domain specific BOMs and entity services and end-to-end traceability to business requirements and processes.

Contributions

rss  subscribe to this author

Bookmarks



Mapping Service-Orientation to TOGAF 9 - Part III:
SOA Governance Models for Service Inventories in TOGAF

Published: July 15, 2011 • Service Technology Magazine Issue LII PDF
 

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:

  • Layers
  • 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).


Conclusion

The next article will conclude this series.


References

[REF-1] SOA Governance. Thomas Erl et. al. April 2011.