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 I Published: June 27, 2013 • Service Technology Magazine Issue LXXIII PDF

The costs of technology assets can become significant and the need to centralize, monitor and control the contribution of each technology asset becomes a paramount responsibility for many organizations. Through the implementation of various mechanisms, it is possible to obtain a holistic vision and develop synergies between different assets, empowering their re-utilization and analyzing the impact on the organization caused by IT changes. When the SOA domain is considered, the issue of governance should therefore always come into play.

Although SOA governance is mandatory to achieve any measure of SOA success, its value still passes incognito in most organizations, mostly due to the lack of visibility and the detached view of the SOA initiatives. There are a number of problems that jeopardize the visibility of these initiatives: Understanding and measuring the value of SOA governance and its contribution – SOA governance tools are too technical and isolated from other systems. They are inadequate for anyone outside of the domain (Business Analyst, Project Managers, or even some Enterprise Architects), and are especially harsh at the CxO level.

Lack of information exchange with the business, other operational areas and project management – It is not only a matter of lack of dialog but also the question of using a common vocabulary (textual or graphic) that is adequate for all the stakeholders. We need to generate information that can be useful for a wider scope of stakeholders like Business and enterprise architectures. In this article we describe how an organization can leverage from the existing best practices, and with the help of adequate exploration and communication tools, achieve and maintain the level of quality and visibility that is required for SOA and SOA governance initiatives.


Understanding and implementing effective SOA governance has become a corporate imperative in order to ensure coherence and the attainment of the basic objectives of SOA initiatives:

  • develop the correct services
  • control costs and risks bound to the development process
  • reduce time-to-market

The criticality and difficulty of achieving these objectives steeply increases with both the increase of the number of services and services’ complexity. It is therefore crucial that a strategy is implemented to support a long-term vision of SOA endeavors, based on rules, policies, procedures, standards and best-practices, to best support the decision process and to control the effort involved in the design, implementation and maintenance of the services. A correct SOA governance model answers key questions:

  • How can an existing service be leveraged to add value to other SOA solutions?
  • Which decisions need to be made in your organization to have effective SOA, and who should make them?
  • How can SOA decisions be monitored?
  • Which structures, processes, and tools should be defined and deployed?
  • Which metrics are required to ensure that an organization’s SOA implementation meets their strategic goals?
  • How can your Project and Application Portfolios be leveraged through SOA?

These questions can be partially answered by the information collected from different sources into SOA governance repositories, like Oracle Enterprise Repository (that we will use as an example throughout this article). Nevertheless, this may not be enough to answer all of them, at least not directly.

Although a solid governance strategy is fundamental for SOA, it is not complete without a global enterprise architecture Vision that provides mechanisms and tools to enrich the information needed for an application and project portfolio management.

By creating a formal common representational model, a language (graphic and textual), and standard viewpoints, and extending the basic capabilities of a SOA governance tool, one can leverage the information for a greater scope and number of analysis possibilities (time-based, dependency).

Addressing a Wider Audience

SOA governance is based on rather simple and intuitive concepts, but is very difficult to implement in its own full range. This is often due to the fact that not every role in the organization understands its real value or objective. The problem resides in the way that information is transmitted from the SOA Governance Center of Excellence to the rest of the company’s audience.

In a typical SOA governance approach, a SOA Center of Excellence [REF-1] is comprised by stakeholders from different backgrounds and with varying competencies, therefore guaranteeing that each perspective of a SOA initiative is covered. Those stakeholders can be SOA Governance Specialists, Enterprise Architects, Operations, Security, Quality Assurance Specialists or Business Analysts. It becomes clear right from the start that every role has different objectives and needs regarding SOA, and that its significance varies from one to another.

Even though this group often concentrates the core SOA knowledge in an organization, the information still needs to be passed on to their peers, and handing over unstructured information that doesn’t fully meet the target-audience needs can easily become an obstacle for SOA and SOA governance adoption. This can be simply because the information is not present in the repository, or, if it is, is too technical for some audiences. It may sometimes even just be from the need of having to produce some of the information manually, therefore becoming time-consuming, from unstructured models over and over again.

A SOA repository can only provide some views over the information out-of-the box, and some roles’ needs and concerns are therefore not fully addressed. Through the usual harvesting mechanisms, technical information is collected from service buses, UDDI Registries, directly from service contracts, monitoring/operational systems or other sources, to a SOA repository. But there’s still a gap to fill for Enterprise or Business Architects / Analysts or Project Managers who, without some kind of treatment over that information, can’t make use of the full advantages of a SOA governance practice.


Figure 1 – The SOA Information Cycle, role-oriented.

A Catalog is Not Enough

Even though SOA governance tools are complete and offer a set of functionalities out-of-the-box for the common integration architect, developer and even for operation teams, they nevertheless still feel rather complex when the project manager or the business analyst try to use them. The asset type list is usually long and has a lot of details that these types of roles don’t need to be confronted with. The dependency network between assets is often insufficient and complex, and the most important part of it, the detection of patterns, is somewhat neglected.

SOA Governance as Part of IT Governance

By filtering out the information that’s not needed and correlating assets through connection, patterns can be fundamental for higher level impact analysis. For instance, a "simple" SOA/API Repository can be used for some Application Architecture analysis without even mentioning the services that some applications can provide or subscribe.

The same happens while managing Project Portfolios. If you can extend service lifecycle information with estimate dates for each stage, you can use that and predict dependencies and impacts between different projects. Another fundamental aspect is the relationship between SOA and the Information Architecture (often through the definition of a Common Data/Information Model), or Business/Process Architecture (through Business Processes) that can very useful for Business Analysts. They tend to search in SOA Repositories for business concepts and not for technical aspects, so it’s fundamental to have this alignment between the services being developed and the organization’s business concepts to formalize such relationships within the SOA Repository.


Figure 2 – SOA governance as part of enterprise architecture

Establishing a Common Model

Communication is critical. Human communication can be analyzed as a matter of encoding information (formulating a sentence), transmitting that message (speaking), and decoding the message (listening and understanding). Successful communication requires clear channels of transmission, and shared codes. Misunderstandings result from mistranslated messages, or from gaps or extraneous noise in the message [REF-5]. The information encoding is achieved by combining both syntax and semantics.

In the current context, it is straightforward to assume that, when we need to ensure an effective communication process surrounding the subject, the least one can do is to define a common vernacular. By establishing the concepts allowed, describing them in an unambiguous fashion, and expressing the relationships between the concepts, we are defining the language, the model.

This metamodel is the foundation for communication. SOA has a surrounding environment, the people, the processes, the ongoing projects, and by combining part of the holistic view of enterprise architecture, we can add value and broaden the reach of the base technologic assets that compose typical SOA governance tools, thus creating more robust foundations for the SOA initiative and establishing a clearer, symbiotic embrace with the IT transformation programs of the organization.

Communication vehicles include our applications, reports, mails and presentations that encompass SOA-related information. Any current SOA governance tool will be able to present lists and tables containing the services, the WSDLs, and so forth. The need for a broader audience encompasses different stakeholder concerns. Current tools are designed for technical roles and have no focus on other roles inside the organization. As pointed out by (Moody, 2009) [REF-2], a quarter of our brain is dedicated to vision, more than the sum of all the other senses. Our brain likes to receive information in a visual way, and it can process it in quite an efficient way. We defend that in many cases, drawings and diagrams can transmit the information in a more concise and precise way than through textual language.

To communicate with diagrams, we must unequivocally assign a representation element to each concept that is part of the metamodel. There are a number of notations, and other efforts to normalize the representation and the structure of SOA related information. Let’s begin with the notation established by books in the Prentice Hall Service Technology Series from Thomas Erl [REF-3] where each concept matches a specific symbol and the aggregation and organization of the later aid the organization in the endeavor of transmitting the correct vision of each principle or pattern.


Figure 3 – Notation examples

Technical diagrams are more than just a set of symbols; they have rules, they have viewpoints, which help establish how a given view should be constructed. With a defined metamodel, the next step is to identify and specify the viewpoints. With all three defined we get our model and communication vehicles, as explored further in Part II of this article.


[REF-1] Prentice Hall Service Technology Series. SOA Governance: Governing Shared Services On-Premise & in the Cloud by Stephen Bennett, Thomas Erl, Clive Gee, Robert Laird, Anne Thomas Manes, Robert Schneider, Leo Shuster, Andre Tost, Chris Venable ,

[REF-2] Moody, D. L. (2009, Novembro). The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 35

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

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

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