by Manuel Rosa and André de Oliveira Sampaio
Achieving a global enterprise architecture vision that provides mechanisms and tools to enrich the information required for application, process, and project portfolio management
Oracle Enterprise Repository
The ownership cost of technology assets can, and usually does, become significant. The need to centralize, monitor and control the contribution of each technology asset becomes a paramount responsibility for most organizations.
In Service Oriented Architectures (SOA), it is vital to manage the service, the main component of this architectural strategy, and its components. The service's reuse benefits can easily be diminished without correct analysis of its dependencies and impacts.
Using Oracle Enterprise Repository as the central point of SOA artifacts' cataloguing makes it possible to obtain a holistic vision and develop synergies between different SOA 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 and its tools are mandatory to achieve any measure of SOA success, their value still passes incognito in most organizations, mostly due to the lack of visibility and the detached view of the SOA initiatives. A number of problems jeopardize the visibility of these initiatives, primarily understanding and measuring the value of SOA governance and its contribution: SOA governance tools are usually inadequate for anyone outside of the technical domain (business analysts, project managers, or even some enterprise architects), and are especially harsh at the CxO level.
A governance strategy is fundamental for SOA and cannot be complete without a global enterprise architecture vision that provides mechanisms and tools to enrich the information required for application, process, and project portfolio management.
By creating a formal, common, representational model, a language (graphic and textual), and standard viewpoints, and by extending the basic capabilities of a SOA governance tool, we can leverage the information for a greater scope and number of analysis possibilities (e.g., time-based, dependency).
To tackle those challenges, Link Consulting has brought Oracle Enterprise Repository's main functionalities and its own Enterprise Architecture Management System (EAMS) together in a full SOA governance + enterprise architecture solution. The Enterprise Architecture Management System—Oracle Enterprise Edition combines the architecture management solution with Oracle Enterprise Repository to deliver a product specialized for SOA governance. It gathers the best of two worlds (SOA and EA) in a solution that enables SOA governance projects, initiatives and programs, and provides an easier mechanism for exchanging information with the business, other operational areas and project management.
In this article, we describe how an organization can leverage the best EA and SOA governance practices and, with the help of adequate exploration and communication tools (like Oracle Enterprise Repository and EAMS), achieve and maintain the level of quality and visibility that is required for SOA and SOA governance initiatives.
Understanding and implementing effective SOA governance is imperative to ensure coherence and the basic objectives of SOA initiatives:
The importance and the difficulty of achieving these objectives steeply increases with both the number of services and their complexity. It is therefore crucial to implement a strategy-based on rules, policies, procedures, standards and best-practices-that supports a long-term vision of SOA endeavors and the decision-making process, and that controls the effort involved in the design, implementation and maintenance of the services.
While Oracle Enterprise Repository lets SOA architects leverage each service, adding value to SOA solutions, there is more we can do with the correct view on SOA governance information.
Though a solid governance strategy is fundamental for SOA, it is not complete without a global enterprise architecture vision that provides the correct mechanisms and tools to enrich the information needed for application and project portfolio management.
By creating a formal, common, representational model, a language (graphic and textual), and standard viewpoints, and by extending the basic capabilities of a SOA governance tool, we can increase scope and the number of analysis possibilities (e.g., time-based analysis, dependency analysis, etc.).
To address those issues, we have combined Oracle Enterprise Repository with EAMS, in order to keep architectural representations up-to-date with minimum effort. EAMS can generate on-the-fly organization-wide architectural blueprints (models, maps or diagrams) based on information gathered from Oracle Enterprise Repository.
SOA governance is based on simple and intuitive concepts, but is very difficult to implement in its own full range-often because not every role in the organization understands its real value or its real objective. The problem resides in the way 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 features stakeholders from different backgrounds and with different competencies: SOA governance specialists; SOA architects; enterprise architects, operations, security, quality assurance specialists, business analysts, etc. Every role has different objectives and needs regarding SOA, and its significance varies from one to another.
If this group passes SOA information to their peers by simply handing over unstructured information, it can easily become an obstacle for SOA and SOA governance adoption. The information may not be present in the repository, or if it is, it may be too technical for some audiences; unstructured models may need to be produced manually, over and over again, which is time consuming.
As the main SOA repository, Oracle Enterprise Repository can provide only some views of the information out-of-the-box, leaving some role needs and concerns at least partly unaddressed. Through the usual harvesting mechanisms, technical information is collected from Oracle Service Bus, UDDI, directly from Service Contracts (Web Service Definition Languages), OEM, or other sources, to Oracle Enterprise Repository. But there is still a gap to fill for enterprise or business architects/analysts or project managers who, without some kind of treatment of that information, cannot make full use of the advantages of a SOA governance practice.
As we can see below, the dependency network between assets can feel too complex, and it can be hard to detect standard relationship patterns.
Clearly, while it provides great insight into an asset's direct dependencies, the Navigator doesn't fulfill all architects' needs on impact analysis. A successful SOA governance initiative relies more on the quality of information than on its quantity—or at least on how well we can perceive that quality.
Filtering out unnecessary information and correlating assets through connection patterns can be fundamental for higher-level impact analysis, such as application architecture analysis, not to mention the services 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 information to predict dependencies and impacts between different projects.
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) can be 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 align the services being developed with the organization's business concepts, formalizing such relationships within Oracle Enterprise Repository.
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. 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, by describing them in an unambiguous fashion, and by expressing the relationships between the concepts, we are defining the language, the model.
This step may seem trivial to some, but it is far from it. Throughout the years we have used one simple technique to validate if indeed a concept is commonly understood by the various stakeholders: we simply ask them to count the number of instances of that concept (i.e. how many Applications the company currently has). If the results vary more than 20%, there is a high probability that there is a communication problem. The technique assumes that the stakeholders can count the elements and are not participating in a guessing game.
This meta-model is the foundation for the communication, whether spoken or written/drawn. The model for SOA should never be a silo; SOA has a surrounding environment: people, processes, ongoing projects, etc. By combining part of the holistic view of enterprise architecture we can add value and broaden the reach of the base technological assets of Oracle Enterprise Repository's meta-model, thus creating more robust foundations for the SOA initiative and establishing a clearer symbiotic embrace with the organization's IT transformation programs.
Communication surrounding the topic has many vehicles, including applications, reports, mails and presentations that encompass SOA-related information. The need for a broader audience stems from different stakeholder concerns not limited to the content but also to the media, the form in which the information is transmitted. 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 efficiently. Drawings and diagrams can often transmit information more concisely and precisely than textual language. Oracle Enterprise Repository's Navigator is a powerful tool for representing direct relationships between SOA artifacts, but it can't offer an aggregated/structured view, like a diagram, a blueprint.
To communicate with diagrams, we must unequivocally assign a representation element to each concept that is part of the meta-model. There are several notations and other efforts to normalize the representation and the structure of SOA-related information.
An interesting exercise is to consider a combination with EA notations to broaden the scope (e.g., ArchiMate).
The views/diagrams are more than just a set of symbols--they have rules and viewpoints that establish not only how the view should be constructed and viewed. With a defined meta-model and established representation of each concept, the next step is to identify and specify the viewpoints. With all three defined we get our model and communication vehicles. As we'll see in "Making it Work," below, EAMS brings those kinds of views over the already collected information, now catalogued in Oracle Enterprise Repository.
SOA assets are subject to time and cannot be fully analyzed without a perception of lifecycles, stages, transitions and changes. Take almost any practice in IT and the acronym SMART will arise. The letter of interest in this case is the T - time-bound. To truly govern SOA we require a complete view of the past/present/future, as-was/as-is/to-be. Communication must address not only what was executed and decided, but also what the current situation or landscape is and what is planned.
Impact analysis of current tools might encourage the false idea that anyone can assess solely on a snapshot at a single point in time. By correlating common project management practices with service lifecycle stages, we can provide a comprehensive view on the as-was, as-is and to-be of projects and their impacted services. This is critical, since projects can originate service production, reuse, retirement or change, and that can affect the whole organization's SOA.
In this example, we can observe two different scenarios regarding project portfolio management through SOA governance. It depicts how different kinds of actions made on services from each project can impact decision making, whether it is promoting a service reuse in the future, or creating a new version of a service and impacting current subscribers, or even predicting problems on reusing components reaching the end of their lifecycles.
Recognizing the assets' dynamic nature brings into play the need for an adequate approach to their representation. If the content being depicted in a diagram is not by nature static, why should we consider only static snapshot-like diagrams and maps? The answer is two-fold:
The SOA repository (Oracle Enterprise Repository) is the central element for SOA governance initiatives. It works as a common channel for managing and governing metadata for any type of SOA asset. It maps the direct relationships and interdependencies that connect those assets. This improves impact analysis, and promotes and optimizes asset reuse. Built-in harvesting mechanisms obtain design or run-time environments or even other sources or catalogs (like application or information catalogs).
To expand Oracle Enterprise Repository's basic usage and leverage from common SOA governance practices, we need to extend its meta-model by creating new concepts/assets and relationships; to capture more information from other catalogs (or Excel spreadsheets, CMDBs or even project management tools); and use business-meaningful patterns.
Because a time dimension is also fundamental to provide a comprehensive view on the evolution of SOA assets, the models should not be constrained to that specific moment in time when an architect used his or her Visio skills. The best way to correlate this dimension with SOA is through the SOA assets' lifecycles - automatically if possible. By saving the information from the past and present, and by predicting it for the future, one can make a better informed decision.
If we do all this, we will have a complete set of concepts detailed enough for us to provide solid and structured diagrams and blueprints, meaningful dashboards and reports, but also to provide a unique timeline visualization over the main SOA governance assets.
EAMS must be put in place to automatically generate these kinds of views or representations.
Working with Oracle Enterprise Repository as the fundamental and central SOA/SOA governance point, and taking advantage of its harvesting tools, here we present some examples of common dashboards or structured blueprints generated by EAMS. Various stakeholders are provided the view they need to leverage SOA and the information present in Oracle Enterprise Repository:
One of the most common use cases for the creation of a new service is a request from the Business Analysis team.
With this approach, business analysts could search for a functional model taxonomy for something related to a business objective, whether for a service or an informational entity, and its relationships with services. They would easily detect if their needs were met with any of the services available, and only after that would arise the inquiry to the SOA architect or SOA governance specialist about the real possibility of reusing/changing/creating a service. The impact to business and technology would be clear and the best decision could be made accordingly.
In this cycle it would also be convenient to consult the operations team about the infrastructure's adequacy, security specialists about security concerns, and more. And all stakeholders would have some kind of representation of the information present on Oracle Enterprise Repository, allowing them to make an informed decision. Below we present a set of dashboards and blueprints that show the simple added value that EAMS provides to SOA governance, but the most important thing to remember is that the information is already in Oracle Enterprise Repository.
All the services are listed. Information about their subscribers and lifecycle stages provides a generic view of the information present in the repository.
Includes all services and analytical data about implementation costs, development hours, or even reuse gains, by calculating over the number of reuses. These types of dashboards provide at-a-glance insight into SOA program ROI.
Includes all services, and the use of analytical data (typically collected from a runtime environment) to measure and control their performance.
A blueprint that graphically represents the functional taxonomy of all services, arranged in containers and sub-containers. Each color represents a different lifecycle stage (the time interval selected is from 21-12-2001 to 23-04-2002) (Figure 10).
The same blueprint as above, but with another time interval selected (08-10-2008 to 08-02-2009). This blueprint shows which services were already retired within this interval: the color red represents that specific lifecycle stage (Figure 11).
A blueprint that graphically represents the IT taxonomy of all the services, arranged in containers and sub-containers (business services, entity services, utility services, etc.), for a selected time interval. This blueprint also shows the dependencies between the services from each layer (Figure 12).
This blueprint represents the service itself in the middle, and around it all the related concepts, like projects, stakeholders, subscribers and providers, informational entities or business processes.
The previous blueprint is a simple example of the usage of relationship patterns. Most tools present every relationship in a relationship chain, making no attempt to adapt the visualization to other levels of abstraction or macro-level stakeholder concerns. With EAMS we can detect relationship patterns and configure generated views accordingly.
The following figure depicts, on the left, an example of a more detailed dependency view, starting from two providing applications and leading to a consumer one. The example on the right abstracts from some part of the detail and presents information more adjusted to a high-level application integration view.
This blueprint represents the technical components of a service-in this case, harvested from Oracle Service Bus (like proxy service, business service, XSDs or WSDLs), surrounded by its providers and subscribers, divided by their type.
Enterprise Architecture Management System (EAMS) is an automation-based solution that enables the efficient management of enterprise architectures. The solution uses configured enterprise repositories-in this context, the Oracle Enterprise Repository-to provide users with automation functionalities. EAMS provides capabilities to create, customize and analyze repository data, architectural blueprints, reports and analytic charts.
Oracle Enterprise Repository is one of the central elements of the Oracle SOA governance solution. Oracle Enterprise Repository provides the tools to manage and govern the metadata for any type of software asset, from business processes and services to patterns, frameworks, applications, components, and models. Oracle Enterprise Repository maps the relationships and interdependencies that connect those assets to improve impact analysis, promote and optimize their reuse, and measure their impact on the bottom line. It provides the visibility, feedback, controls, and analytics to keep your SOA on track to deliver business value. The intense focus on automation helps overcome barriers to SOA adoption and streamlines governance throughout the lifecycle.
Automatically harvesting SOA assets from Oracle Service Bus, or Oracle SOA Suite onto Oracle Enterprise Repository (then exchanging this information with an UDDI-compliant system), guarantees that the assets in runtime are also present on the design-time repository. Several runtime metrics can also be obtained from SOA Management Pack, which allows SOA governance design and runtime closed-loop view to be attained in a single catalog.
Oracle Enterprise Repository core capabilities include:
Link's Enterprise Architecture Management System-Oracle Enterprise Edition (EAMS-Oracle Enterprise Repository Edition) gathers the better of two worlds (SOA and EA) in a solution that enables SOA governance projects, initiatives and programs.
The solution combines advantages and features from both products in a symbiotic tool that enhances the quality of SOA governance initiatives and programs.
By integrating EAMS with Oracle Enterprise Repository, all the information contained in the repository is made available by EAMS, and with it, the increase of features.
Taking a closer look on a component level, the solution is composed of the data source and the out-of-the-box configuration of blueprints, dashboards and reports.
Critical to IT governance, SOA governance should be understandable by all interested stakeholders, because its practice can guarantee that the correct services are created, promoting their reuse and evolution; that the correct information is available to support decision making; and that visibility over existing enterprise assets is enabled.
Still, Oracle Enterprise Repository is technically oriented, and some views on information are not directly available. Successful communication of SOA governance requires a common vernacular, symbol set and structured viewpoint. By deriving the fundamental concepts and mapping practices from enterprise architecture, the information from Oracle Enterprise Repository can be filtered, organized and leveraged according the needs of everyone involved. As the provider of a higher layer of insight on SOA governance information, EAMS provides a set of functionalities fundamental for bringing together not only SOA architects or developers, but also business and other parts of IT.
Transformation initiatives are complicated in any discipline, whatever its maturity level. The steps may be simple, but their implementation often is not, due to lack of adequate tools manpower and/or sponsorship. The tools must evolve to accommodate consolidated non-silo repositories, gaining cross-organization sponsorship by providing value to the various areas inside an organization. With heterogeneous concerns, the representations must deliver what is intended, and they must be managed and created with the aid of automation mechanisms in order to avoid an excess of human effort in keeping them up-to-date.
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 Instituto Superior Técnico, INESC and INOV, in a one-year program.
André de Oliveira Sampaio 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.