Manuel Rosa

Manuel Rosa


Manuel Rosa began his career participating in Enterprise Architecture projects in Portugal, Brazil and Luxembourg, mainly focusing on Application and Business Architectures. In the past few years, Manuel has coordinated the development of SOA Governance programs and has also been responsible for various SOA Governance projects in major Portuguese enterprises in the telecom and utilities industries, as well as SOA projects in Spain. He is currently SOA Governance Practice Leader at Link Consulting.

Manuel was a speaker at the 5th International SOA, Cloud + Service Technology Symposium in London. He is currently a teaching assistant on the subjects of Enterprise Architecture I and II for the POSI postgraduate degree provided by Intituto Superior T├ęcnico, INESC and INOV, in a one-year program.


rss  subscribe to this author

André Sampaio

André Sampaio


André de Oliveira Sampaio (MSc), is a Senior Consultant of Enterprise Architecture for Link Consulting in Portugal, and has participated in and coordinated various Enterprise Architecture projects in Portugal, Brazil and Luxembourg. As a professional, André has been involved in several major transformation projects, most of which in the financial services and public administration sectors.

André is responsible for the development of the Enterprise Architecture Management System (, and has published work centered around the themes of Enterprise Architecture, Enterprise Transformation, System Theory, Service-Oriented Architecture and Formal Viewpoints.


rss  subscribe to this author


Promoting Organizational Visibility for SOA and SOA Governance Initiatives - Part II Published: July 24, 2013 • Service Technology Magazine Issue LXXIV PDF

Abstract: This is the second article in a two-part article series. Read the first part of this article here.

Keeping Up with Change

As is the case for everything else, SOA assets are subject to the passage of time and can't be fully analyzed without a deeper understanding of their lifecycles, stages and transitions. Take almost any practice in IT and the "SMART" acronym is applicable, of which the letter "T" for time-bound is of particular importance. A complete view of the past to future is necessary to truly govern SOA. Channels of communication not only need to encompass what was executed and decided, but also what the current situation or landscape is and what is planned for the future.

A false premise of the impact analysis of current governance tools is that an assessment that is based solely on a snapshot taken from a single point in time can be performed. By correlating common project management practices with service lifecycle stages, we can provide a comprehensive view of the past, present and future states of projects and the services they impact. This comprehensiveness is critical, since projects experience service production, reuse, retirement and change that can affect the entire organization's service-oriented architecture.

In Figure 1, two scenarios depicting project portfolio management through SOA governance show how different kinds of actions performed on services from each project have an impact on decision-making. Actions can range from promoting future service reuse and creating new services that impact current subscribers to predicting problems that arise when components that have reached the end of their lifecycle are reused.


Figure 1 - An example of SOA project portfolio management.

  • Yellow - If the dates for each service lifecycle stage can be predicted, a service that is awaiting development can be reused and its specification impacted.
  • Red - Adopting a future perception of services prevents problems that are caused by reusing services due for upcoming retirement.

Recognizing the dynamic nature of SOA assets means that an approach for the representation of these assets is necessary. Why should only static snapshot-like diagrams and maps be used, if the content that is being depicted is in fact dynamic and not static in nature? The answer is two-fold:

There is a lack of suitable approaches and guidelines that encourage practitioners to capture the necessary lifecycle information. Although practitioners may capture lifecycle timestamps regarding the assets themselves, the lifecycle of the relationships between the assets is never captured. Does this lack not jeopardize the quality of the results of the impact analysis in some way?

The majority of the tools available are not prepared or designed to provide and maintain dynamic representations of the assets.

Making it Work

The SOA repository is the central element of SOA governance initiatives. There are several tools currently available on the market that can provide this functionality as a common channel for managing and governing metadata for all asset types. They map the direct relationships and interdependencies that connect those assets, improving the impact analysis process and promoting and optimizing asset reuse.

Management and governance tools usually have harvesting mechanisms in order to obtain design or runtime environments, or use other sources like application and information catalogs. Several steps can be taken to expand the basic utilization of these tools and leverage from common SOA governance practices.

Note that the following are only references to the activities that can increase value for a typical SOA governance initiative and address commonly neglected aspects. Refer to SOA Governance: Governing Shared Services On-Premise & in the Cloud [REF-1] for a comprehensive methodology on SOA governance.

The following activities can help increase value for SOA governance initiatives:

Extending the SOA Meta Model

  • New concepts, assets and relationships that complement the information natively collected to the SOA repository are created.
  • Additional metadata that broadens the target audience for the SOA governance initiative is added.

Capturing Information

  • Information from the design and runtime environments is collected.
  • Information from the other catalogs is captured according to the meta model extension, in order to enrich the SOA repository and provide a more complete view of the SOA assets and their relationships with other concepts.
  • Project portfolio information from typical project management tools is captured and synchronized with SOA assets, to ensure alignment with current project management practices and to decrease the resistance to change.

Defining and Using Business-Meaningful Patterns

  • The application of patterns like Entity Abstraction [REF-4] provides project managers and business analysts with the tools to use SOA and services as a catalog of functionalities that have important intrinsic business objectives. This is usually supported by information architectures, common information/data models or industry-based reference models.
  • A functional taxonomy that is specific to the organization (use reference models) and applicable to relevant SOA assets is defined.

These activities can be completed at normalization and awareness workshops to achieve the following:

  • In addition to defining SOA assets and concepts, their semantics need to be detailed and practical examples provided to guarantee that they can be commonly understood.
  • The stakeholders' concerns and objectives need to be identified to obtain greater support and sponsorship from different organizational areas.
  • The notations need to be specified and representation viewpoints strictly aligned with stakeholder concerns.
  • Impact analysis and graphic representation definitions that are derived from stakeholder concerns and notations need to be implemented by automated generation-based mechanisms or tools, such as:
    • diagrams/blueprints
    • dashboards
    • timeline visualization
    • reports

Figure 2 - Closing the gap to provide SOA across the organization.

SOA Governance Dashboards

Various types of dashboards and structured blueprints that enable stakeholders to leverage SOA and the information held in SOA repositories are discussed:

SOA Dashboard

All of the services are listed, and information about their subscribers and lifecycle stages provide a generic view over the information presented in the repository.


Figure 3 - A screenshot of a SOA dashboard view.

SOA Investment Control Dashboard

All of the services and their analytical data about implementation costs, development hours and reuse gains are calculated over the number of reuses. This type of dashboard provides direct insight into the SOA program's ROI.


Figure 4 - A screenshot of a SOA investment control dashboard view.

SOA Control Dashboard

The services, and the use of analytical data that is typically collected from a runtime environment, are displayed to measure and control their performance.


Figure 5 - A screenshot of a SOA control dashboard view.

SOA Governance Blueprints

The following are types of structured blueprints that can be used to leverage SOA and information stored in repositories:

Functional Model-Based Service Catalog Blueprint

This blueprint represents the functional taxonomy of services by graphically listing them in their container and sub-container arrangements. Each color represents a lifecycle stage, with the time interval starting at 21-12-2001 and ending at 23-04-2002.


Figure 6 - A screenshot of a functional model-based service catalog blueprint.

The same blueprint with a time interval of 08-10-2008 to 08-02-2009 is shown in Figure 7. The services that have been retired within this interval can be identified, as the color red specifically represents this lifecycle stage.


Figure 7 - A screenshot of a functional model-based service catalog blueprint.

IT Taxonomy-Based Service Catalog Blueprint

This blueprint lists all of the services arranged in containers and sub-containers to graphically represent their IT taxonomy (business services, entity services, utility services) in a given time interval. The dependencies between the services from each layer can be viewed in this blueprint, as shown in Figure 8.


Figure 8 - A screenshot of an IT taxonomy-based service catalog blueprint.

Service Context Blueprint

The service is represented in the middle and is surrounded by related concepts, which include projects, stakeholders, subscribers and providers, informational entities and business processes. Figure 9 shows a blueprint that exemplifies the usage of relationship patterns. Many tools visually present relationships in a relationship chain and don't attempt to adapt the visualization to other levels of abstraction, or to macro-level stakeholder concerns.


Figure 9 - An example of a service context blueprint.

The left panel of Figure 10 depicts a detailed dependency view that starts from two provider applications and leads to a consumer application. The example shown in the panel on the right further abstracts from a selection of the detail to present a higher-level application integration view.


Figure 10 - The level of abstraction is adapted in a view with relationship patterns.

Service Integration Blueprint

This blueprint represents technical service components that are harvested from the Oracle Service Bus, including proxy services, business services, XSDs and WSDLs. The components are surrounded by the providers and subscribers before being categorized according to type (Figure 11).


Figure 11 - A screenshot of a service integration blueprint.

Use Cases for New Functionality

One of the most common use cases for service creation is when new services are required by business analysts. Business analysts can search for a functional model taxonomic approach that aligns with their business objectives, whether for a service or an informational entity and its relationship with the services.

The available services are confirmed to be either able or unable to meet the objectives, after which an inquiry is directed to the SOA governance specialists regarding service reuse, modification and/or creation. Business and technological impacts are clarified to facilitate the decision-making process, which concludes with the selection of the most suitable option.

This cycle simplifies the process of consulting with the operations team about infrastructural adequacy, security specialists about security concerns, and so forth. Each stakeholder will be provided with a representation of the information in the SOA repository, which will facilitate the decision-making process.


By carrying out critical functions in the overarching domain of IT governance, SOA governance activities can be commonly performed across the organization to provide tangible benefits. These benefits are further achieved by ensuring that the correct services are created to promote their reuse and evolution and that the correct information is available to support decision-making, and by promoting visibility over the existing enterprise assets.

Many SOA governance tools are too technical for certain audiences, and some dashboard and blueprint views may not even be directly available. Structured viewpoints, a common vernacular and a symbols legend are fundamental for enabling successful communication within SOA governance initiatives. Deriving basic concepts and mapping practices from the enterprise architecture allows information in the SOA repository to be filtered, organized and leveraged to meet a variety of needs.

The aspect of time is essential to achieve a comprehensive view of the evolution of SOA assets, so that the models aren't constrained to representing only specific points in time. An effective method of introducing time into SOA is to implement automation into the lifecycles of SOA assets.

Transformation initiatives are complicated in any discipline, regardless of maturity level. The steps can be simple, but their implementation may be much less so as a result of a lack of tools, expertise and/or sponsorship. Tools need to consistently evolve to accommodate the consolidation of non-silo repositories, and gain cross-organization sponsorship by providing noticeable value to different areas of the organization. Similarly, representations need to deliver and fulfill organizational objectives, and be managed and created with the aid of automation mechanisms to reduce maintenance efforts.


[REF-1] S. Bennett, T. Erl, C. Gee, R. Laird, A. Manes, R. Schneider, L. Shuster, A. Tost, C. Venable. SOA Governance: Governing Shared Services On-Premise & in the Cloud. Toronto: Prentice Hall, 2011.

[REF-2] D. L. Moody. The "Physics" of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. Vol 35, Issue 6. November 2009.

[REF-3] T. Erl. SOA Principles of Service Design. Toronto: Prentice Hall, 2008.

[REF-4] T. Erl. SOA Design Patterns. Toronto: Prentice Hall, 2009.

[REF-5] R. Krauss, E. Morsella. "Communication and Conflict." M. Deutsch, P. T. Coleman, eds. The Handbook of Conflict Resolution: Theory and Practice. San Francisco: Jossey-Bas Publishers, 2000. pp. 131-143