EA & Services Oriented Enterprise (SOE)

Services Orientation, Hype or Hope?

Structuring the Enterprise around Services

By J. Schekkerman

The terms Enterprise Architecture (EA), Services Oriented Enterprise (SOE), Service-Oriented Architecture (SOA) and Service Oriented Computing (SOC) are being exposed to an ever wider and more influential audience. Unfortunately, as with many "new concepts" there is a common misunderstanding about prior ideas and practices from which they are derived. Accordingly, these terms will be bandied about as buzzwords and/or marketing hyperbole assaults.

This section is a preemptory effort to provide both a basic and somewhat advanced understanding of these terms: why they are important to us, where they come from and what this means for business & information technology (IT). As with most innovative concepts that seemingly come into vogue in a sudden and haphazard manner, there is both a history leading up to its short sojourn in the spotlight of popular perception and a predictable fade unless popular uptake makes it a structuring paradigm of the Enterprise. With reference to EA, SOE, SOA and SOC, it is fairly certain that they will have their role in this paradigm shift.

Frequently asked questions that revolve around this topic include: What is SPA? What is SOE? What is SOA? and what is SOC and how are they interrelated? To answer this multipart question, let us first try to gain the proper perspective for being able to see the overall Enterprise Architecture landscape. This is commonly called the Heliview. This view refers to the landscape from a chopper at a few thousands meter height and, that is an apt metaphor, since at that height and from that perspective we see a larger picture. We see the mountain ranges not just the mountain in front of us, or the trail we are hiking up through the trees in the foothills and lower slopes. We see the checkerboard layout of farmlands. We see the green meandering paths of the watershed streams and rivers, and this is appropriate to the level of Enterprise Architecture (EA). In this view an enterprise is seen simply as an organization or a part of an organization, rather than in the specific context of public or private, business or government, academic or non-profit. This is a good start.

Enterprise Architecture in the Context of Services Orientation

However to truly see the outlines and parameters of what is called EA, and from that perspective begin to understand how a SOE and SOA can enable an EA, we need to get up to suborbital or low orbit viewpoint at least, and it could be argued that we need to get all the way out to the viewpoint of our moon to see the entire environment within which these concepts work. The fact is that the word enterprise is by no means restricted to a business, or even an industry, nor does it refer to a particular time in the life of an organization. The enterprise encompasses the entire life cycle of an organization or an organism.

Enterprise Architecture Services Model

After having achieved the desired scope of view, we can apply that perspective, the perspective of the economic or ecological lifecycle, to provide measures to ensure an extended life beyond the restrictions of the individual biological entity model we necessarily bring with us. Enterprises, like cultures, outlive individual members, and those life cycles require us to extend our vision further than our own lives. In many areas in our lives, such as in educational institutions, the familial clan or kinship networks, governments, etc., we take this viewpoint for granted, but in EA, we now need to be explicit and put in place the kinds of mechanisms that can conduct constant review and institute quality assurance as a matter of course and, in effect, institutionalize the cycle of build, use, learn, assess, build (adjust/rebuild), use, learn, etc., ad infinitum. This presupposes, of course, that the "de facto" starting point for this process is where an enterprise or organization happens to be at that the point when it is decided to begin this process of building and deploying an EA. Some comprehensive review is not required to start. In effect, gaining the correct perspective should allow an enterprise to refocus on the immediate with that larger focus still in mind. Such reviews or foundational reports have their place, but, unless an enterprise is at its founding point, the larger picture can be developed while the more functional aspects of current operations and immediate planning based on immediate findings take precedence in simply getting the process moving.

Differences between hype or Hope

In the next diagram that is showing the business version of the Extended Enterprise Architecture Framework (E2AF) the concepts of SPA, SOE, SOA, SOC and STP are positioned on the framework to help the readers to understand the relative position of these concepts related to the E2AF. Around the E2AF, 4 Critical Success Factors (CSF) are positioned that are critical for the success of implementing Service Orientation in your organization and which makes the difference between Hype or Hope.

Services Paradigm Adoption (SPA)

Services orientation presents an ideal vision of a world in which resources are cleanly partitioned and consistently represented in terms of services. Therefore the Services Paradigm has to be adopted by the Enterprise to structure the Enterprise in terms of Services. So the Enterprise aspect areas of Business, Information, Information-Systems and the Technology Infrastructure has to be decomposed in terms of functional Services. Doing that at a consistent and consequent matter will deliver loosely coupled functional services that can be outsourced or insourced or brought together in so called shared services centers.

Adopting the Services Paradigm by your Enterprise and implementing it in an appropriate way, will deliver the Enterprise more flexibility, adaptability and agility then organizations that don't want to adopt the Services Paradigm.

• Analyse a certain part of the organizational business process and decompose them into several smaller business process. For example, Order Processing System of an organization can be decomposed into smaller business processes such as checkInventory(), processPayment(), updateInventory() etc.
• Identify if any of the smaller business processes are re- used or can potentially be reused in other organizational business process. For example, checkInventory() can also be used by the Stock Management application within the organization. The reusable business processes are strong candidates for operating as Services.
• Draft the required inputs to these business processes and define what the specific outputs they must produce. Attention must be paid to keep these inputs and outputs generic so that the Service remains reusable and are capable of providing Service to changing business models. For example, processPayment() service at present might only accept check payment but should be flexible enough to support Card payment in order to support changing business needs. Hence, the input to the processPayment() Service must be defined in a generic fashion.
• Identify, if these Business processes are already implemented as an IT system within the organization. If yes, then analyse the Business critical factor for all the existing applications to identify which ones need to be converted to SOA. For example, if a clothes retailer no longer accepts refund/exchange of goods, we do not need to consider to look into Refund/Exchange application.
• Identify, what Services operate together, what are the dependencies between various Services.
• Find out, if the Services will be used only internally or will be opened to external consumers also. This will have impact on the definition of the Services.
• Identify, whether the Services operate in a synchronous or asynchronous manner. What is the permissible response time for the Services?

Services Oriented Modelling

A number of important activities and decisions exist that influence not just integration architecture but enterprise and application architectures as well. They include the activities from the two key views of the consumer and provider.

The activities that are typically conducted by each of the roles of provider and consumer. Note that the provider's activities are a superset of the consumer's activities (for example, the provider would also be concerned with service identification, categorization, and so forth). In many cases, the differentiation of the roles comes from the fact that the consumers specify the services they want, often search for it, and once they are convinced of the match between the specification of the service they are looking for, and that provided by a service provider, they bind and invoke the service as needed. The provider, in turn, needs to publish the services they are willing to support; both in terms of functionality and most importantly in terms of the QoS that consumers will require. This implicit contract between consumer and provider might mature into an explicit contract in terms of SLAs; negotiated either electronically or through business and legal venues.

The activities described above can be depicted to flow within the service-oriented modeling.

The process of service-oriented modeling and architecture consists of three general steps: identification, specification and realization of services, components and flows (typically, choreography of services).

Service Identification

This process consists of a combination of top-down, bottom-up, and middle-out techniques of domain decomposition, existing asset analysis, and goal-service modeling. In the top-down view, a blueprint of business use cases provides the specification for business services. This top-down process is often referred to as domain decomposition, which consists of the decomposition of the business domain into its functional areas and subsystems, including its flow or process decomposition into processes, sub-processes, and high-level business use cases. These use cases often are very good candidates for business services exposed at the edge of the enterprise, or for those used within the boundaries of the enterprise across lines of business.

In the bottom-up portion of the process or existing system analysis, existing systems are analyzed and selected as viable candidates for providing lower cost solutions to the implementation of underlying service functionality that supports the business process. In this process, you analyze and leverage API\\x92s, transactions, and modules from legacy and packaged applications. In some cases, componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality.


The middle-out view consists of goal-service modeling to validate and unearth other services not captured by either top-down or bottom-up service identification approaches. It ties services to goals and sub-goals, key performance indicators, and metrics.

Service Classification or Categorization

This activity is started when services have been identified. It is important to start service classification into a service hierarchy, reflecting the composite or fractal nature of services: services can and should be composed of finer-grained components and services. Classification helps determine composition and layering, as well as coordinates building of interdependent services based on the hierarchy. Also, it helps alleviate the service proliferation syndrome in which an increasing number of small-grained services get defined, designed, and deployed with very little governance, resulting in major performance, scalability, and management issues. More importantly, service proliferation fails to provide services, which are useful to the business, that allow for the economies of scale to be achieved.

Sub-system Analysis

This activity takes the subsystems found above during domain decomposition and specifies the interdependencies and flow between the subsystems. It also puts the use cases identified during domain decomposition as exposed services on the subsystem interface. The analysis of the subsystem consists of creating object models to represent the internal workings and designs of the containing subsystems that will expose the services and realize them. The design construct of "subsystem" will then be realized as an implementation construct of a large-grained component realizing the services in the following activity.

Component Specification

In the next major activity, the details of the component that implement the services are specified:

• Data
• Rules
• Services
• Configurable profile
• Variations

Messaging and events specifications and management definition occur at this step.

Service Allocation

Service allocation consists of assigning services to the subsystems that have been identified so far. These subsystems have enterprise components that realize their published functionality. Often you make the simplifying assumption that the subsystem has a one-to-one correspondence with the enterprise components. Structuring components occurs when you use patterns to construct enterprise components with a combination of:

• Mediators
• Facade
• Rule objects
• Configurable profiles
• Factories

Service allocation also consists of assigning the services and the components that realize them to the layers in your SOA. Allocation of components and services to layers in the SOA is a key task that require the documentation and resolution of key architectural decisions that relate not only to the application architecture but to the technical operational architecture designed and used to support the SOA realization at runtime.

Service Realization

This step recognizes that the software that realizes a given service must be selected or custom built. Other options that are available include integration, transformation, subscription and outsourcing of parts of the functionality using Web services. In this step you make the decision as to which legacy system module will be used to realize a given service and which services will be built from the bottom-up." Other realization decisions for services other than business functionality include: security, management and monitoring of services.

The service oriented modelling paragraph is based on an article of Ali Arsanjani, Ph.D., Chief Architect, SOA and Web Services Center of Excellence, IBM.

Service Oriented Maturity Model

This SOA Maturity Model provides a framework for discussion between IT and business users about the applicability and benefits of SOA in an organization across five levels of adoption maturity.

Granularity of Services

Stating that Services are the central part of both SOA and SOE will probably not offend anybody. But methods to identify Services are only slowly emerging. When talking about SOA the Services are often seen as a task that will require only a small effort – so small that we almost don’t bother talking about it. The level of detail, in which this task is described, is usually focused on whether to approach this Top-Down or Bottom-up. In practise you will probably use a mix of both, but should have a strong emphasis on the Top-Down – this is necessary in order to control the coherence between the Services.