EA & Services Oriented Enterprise (SOE) / Service Oriented Architecture (SOA)

Services Orientation, Hype or Hope?

Structuring the Enterprise around Services

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.

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.

Services Oriented Enterprise (SOE)

A service-oriented enterprise is really connecting business processes in a much more horizontal fashion. It's having an Enterprise infrastructure that provides an enterprise architecture and security foundation to be able to run these services consistently across your enterprise.

While the concept of a service-oriented architecture has been considered a best practice by system architects for the past three decades, it is now being embraced by organizations everywhere as the key to business agility. But SOE and SOA doesn’t come in a box, it’s not a single technology and it doesn't render all problems solved. While SOE enables and even drives organizational change, it also requires executives, enterprise architects and program managers to think and act differently or simply find themselves in possession of new problems with few or no new benefits.

The Service Oriented Architecture (SOA) Vision

Service-orientation presents an ideal vision of a world in which resources are cleanly partitioned and consistently represented. When applied to IT architecture, service-orientation establishes a universal model in which automation logic and even business logic conform to this vision. This model applies equally to a task, a solution, an enterprise, a community, and beyond.

By adhering to this vision, past technical and philosophical disparities are blanketed by layers of abstraction that introduce a globally accepted standard for representing logic and information. This level of standardization offers an enormous benefit potential for organizations, as many of the traditional challenges faced by ever-changing IT environments can be directly addressed through the application of these standardized layers.

For example, by shaping automation logic through service-orientation, existing investments can be leveraged, business intelligence can be accurately expressed, and inherent automation agility can be achieved. When coupled with the Web services technology platform, SOA offers a significant and real potential for manifesting these benefits.

The service-orientation ideal has sparked a movement that has positioned SOA as the next phase in the evolution of business automation. In the same manner in which mainframe systems were succeeded by client-server applications, and client-server environments then evolved into distributed solutions based on Web technologies, the contemporary, Web services-driven SOA is succeeding traditional distributed architecture on a global scale.

All major software manufacturers and vendors are promoting support for SOA—some even through direct involvement in the development of open standards. As a result, every major development platform now officially supports the creation of service-oriented solutions.

Be forewarned, though, that SOA makes impositions. A change in mind set is required, as business logic now needs to be viewed within a service-oriented context. Applying this context also requires a change in automation logic, as solutions now need to be built in support of service-orientation. Finally, a technical architecture capable of hosting service-oriented automation logic further introduces new technology and infrastructure requirements.

_________________________________________________________________________________________________

The Top 5 SOA Adoption Pitfalls of 2005

By: Thomas Erl, author of “Service-Oriented Architecture: Concepts, Technology, and Design"

It’s been a tumultuous year in the world of SOA and we’re just at the beginning of rollercoaster ride. As organizations continue to re-examine the ever-shifting landscape of service design, service buses, service governance, and even just services, there are often mixed emotions. Many are confused as to the maturity and overall status of SOA in the IT industry, but there is definite sense of excitement around its touted potential to unite business and technology.
Many SOA initiatives were launched this year, each with its own set of goals and expectations. Some failed miserably, while others failed just a little. For many, the determining factor in fulfilling their original objectives was drawing upon the experience of those who had already survived projects with less fortunate results. These individuals lived to tell their stories and warn others of what lies ahead along the path toward SOA.
In our line of work we get pulled into various projects at different stages of completion. We’ve seen good SOA go bad and bad SOA get even worse. Problems can be fixed and mistakes can be undone, but of course there is always an impact to getting things back on the right track. The best course of action is, obviously, avoiding problems and mistakes in the first place.
Understanding the pitfalls others have fallen victim to puts you in a position from which you can form the extent of foresight required to chart a safer route down your own SOA roadmap. To help you get a head start, we have collected the five most common SOA adoption pitfalls of 2005.

#5 NOT UNDERSTANDING SOA PERFORMANCE REQUIREMENTS
Loose coupling comes at a price. When implemented with Web services, SOA introduces layers of data processing as well as the associated performance overhead imposed by these layers. When starting out small, it is easy to build service-oriented solutions that function and respond as expected. As the scope increases and more functionality is added, the volume of message-based communication predictably grows. This is when unprepared environments can begin experiencing significant processing latency.
Critical to building a successful service-oriented solution is understanding the performance requirements of your solution and the performance limitations of your infrastructure ahead of time. This means testing (and, if necessary, strengthening) the message processing capabilities of your environments, and paying close attention to service design so as to achieve an acceptable balance between transmission rates, transmission sizes, and other service characteristics that can negatively affect solution performance.

#4 NOT STARTING WITH AN XML FOUNDATION ARCHITECTURE
In the world of today’s SOA, everything begins with Web services. That statement has become a mantra of sorts within some organizations, but it is not entirely true. In the world of today’s SOA, everything, in fact, begins with XML. It is the standard from which multiple supplementary standards have evolved to form a de facto data representation architecture. It is this core set of standards that has fuelled the creation of the many Web services specifications that are now driving SOA.
So much attention is given to how data is transported between services that the manner in which this same data is structured and validated behind service lines is often neglected. This oversight can lead to an improper implementation of a persistent XML data representation layer. This layer is foundational to SOA and its weaknesses will have repercussions across any solutions built upon it.

#3 NOT CREATING A TRANSITION PLAN
The chances of a successful migration will be severely diminished without the use of a comprehensive transition plan. Because the extent to which service endpoints are positioned within an enterprise can lead to a redefinition of an environment’s infrastructure, the affects of a poorly executed migration can be significant.
Transition plans allow you to coordinate a controlled phasing in of service-orientation and SOA characteristics so that the migration can be planned on a technological, architectural, and organizational level.
Typical components of an SOA transition plan include an impact analysis (that predicts the extent of change SOA will impose on existing resources, processes, custom standards, and technology), transition architectures (that map out a series of planned hybrid stages toward a target SOA), and a speculative analysis (that takes into account the future growth of Web services and supporting technologies).

#2 NOT STANDARDIZING SOA
SOA, like any other architecture, requires the creation and enforcement of internal design standards for its benefits to be truly realized. For example, if one project builds a service-oriented solution in isolation from others, key aspects of its solution will not be in alignment with the neighboring applications it may be required to interoperate or share agnostic services with one day.
This can lead to many problems, including incompatible data representation, service contracts with irregular interface characteristics and semantics, and the use of non-complementary Web services extensions (or extensions being implemented in different ways).
SOA promotes a development environment that abstracts back-end processing so that it can execute and evolve independently within each application. However, standardization is still required to ensure consistency in design and interaction of services that encapsulate this back-end logic.

#1 BUILDING SOA LIKE TRADITIONAL DISTRIBUTED ARCHITECTURE
The number one obstacle organizations have been facing when attempting to achieve SOA is building service-oriented solutions in the same manner in which traditional distributed solutions have been built, under the pretence that SOA is actually being achieved.
SOA is not CORBA + XML, nor is it ASP.NET + WSE. Service-orientation is not object-orientation, nor is it “close enough” so that building object-oriented component logic will always “fit right into” service-oriented solution environments. SOA is a distinct architectural model based on service-orientation, a distinct design paradigm. Understanding these distinctions is critical to building automation logic that is truly service-oriented and in alignment with where the SOA industry is moving on a global scale.

This section contains excerpts from “Service-Oriented Architecture: Concepts, Technology, and Design” by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2005). For more information, visit www.soabooks.com.

Services Oriented Computing (SOC)

There has been an increase in interest recently within the service oriented community towards "Service Oriented'' Computing. Services are often seen as a natural progression from component based software development, and as a means to integrate different component development frameworks. A service in this context may be defined as a behaviour that is provided by a component for use by any other component based on a network-addressable interface contract (generally identifying some capability provided by the service). A service stresses interoperability and may be dynamically discovered and used. According to the "Open Grid Services Architecture" (OGSA) framework, the service abstraction may be used to specify access to computational resources, storage resources, and networks in a unified way. How the actual service is implemented is hidden from the user through the service interface. Hence, a compute service may be implemented on a single or multi-processor machine -- however, these details may not be directly exposed in the service contract. The granularity of a service can vary -- and a service can be hosted on a single machine, or it may be distributed.

Web Services provide an important instantiation of the Services paradigm, and comprise infrastructure for specifying service properties (in XML -- via the Web Services Description Language (WSDL) for instance), interaction between services (via SOAP), mechanisms for service invocation through a variety of protocols and messaging systems (via the Web Services Invocation Framework), support for a services registry (via UDDI), tunnelling through firewalls (via a Web Services Gateway), and scheduling (via the Web Services Choreography Language). A variety of languages and support infrastructure for Web Services has appeared in recent months -- although some of these are still specifications at this stage with no supporting implementation. Web Services play an important role in the Semantic Web vision, aiming to add machine-processable information to the largely human-language content currently on the Web. A list of publicly accessible Web Services (defined in WSDL) can be found at www.xmethods.net. By providing metadata to enable machine processing of information, the Semantic Web provides a useful mechanism to enable automatic interaction between software -- thereby also providing a useful environment for agent systems to interact.

Services Transition Path (STP)

Your SOE, SOA and SOC is very much a work in progress, and your transition to Services Orientation will take place over a long period, in many phases. Consequently, transition management is one of the most critical concerns in the long ramp-up to Service Orientation everywhere.

Despite the magnitude of a migration to a services-oriented platform, the continuing uncertainty of critical WS-* standards, and the often thundering impact of large-scale SOA deployments, now is the time to start considering the move. The key to a successful transition is to find a spot of calm amidst the storm of activity surrounding SOA, and develop an intuitive plan that will guide your organization through a path of technical obstacles, organizational resistance, and ever-shifting industry trends.

Invest in an Impact Analysis Before Developing the Transition Plan

In order to assess the feasibility of a transition to Services Orientation, you first need to estimate the real-world impact such a migration will have. Therefore, you should consider holding off any sort of planning until an initial impact analysis is complete. Using the impact analysis results as your primary guide, and factoring in budget constraints, related project requirements, and other external drivers (such as strategic business goals), you should be able to determine the scope of your planned transition. It is not uncommon for an SOA transition plan to apply only to a subset of an organization's technical environment. For instance, there may be several legacy areas of an enterprise that do not warrant any intrusion by service encapsulation. Perhaps your goal is to build a dedicated hosting environment intended only to support new service-oriented applications. More often than not, however, integration requirements drive SOA transitions, in which case the scope of your project could easily see the introduction of SOA affect a majority of your IT enterprise.

Service-oriented principles themselves are not complex, however, the application of these principles can result in relatively complex automation solutions. This is especially the case when services from different solutions are shared and composed to support new or modified business processes. If you're going to live in a service-oriented world, your project team will need to change the way it thinks about fundamental aspects of common architecture, such as componentization, integration, and process automation.

Services Oriented Maturity

Companies are at different levels of maturity in the adoption and incorporation of Services-Orientation (SO). Some are just beginning to explore the world of SO using its technology instantiation: Web services. They are wrapping legacy functionality and exposing it for invocation for third-parties, clients, and business partners. This gets them into the game: they ramp up the development team, start the process of changing the corporate culture to better support SO, and take the first steps in the exploration of new technologies and the business capabilities that may be impacted. This is level one.

Level two of SO adoption is when the initial testing of Web services has been successfully overcome and now the organization is beginning to integrate systems and applications using services. As proprietary protocols, glue code, and point-to-point connections give way to more open, standards-based protocols and interaction based on service descriptions that each system externalizes, we step into the realm of Service-Oriented Integration (SOI). In this world, the enterprise service bus reigns supreme: a mechanism for mediation, routing, and transformation of service invocations irrespective of the target service provider. It helps overcome many of the shortcomings associated with point-to-point connections.

Service Orientation; layers of adoption

Implementing individual Web services Creating services from tasks contained in new or existing applications (SOC/SOA)
Service-oriented integration of business functions Integrating services across multiple applications inside and outside the enterprise for a business objective (SOI/SOA)
Enterprise-wide IT transformation An enterprise architected implementation enabling integration across business functions throughout an enterprise (SOA/SOE)
On Demand Business Transformation Broad transformation of existing business models or the deployment of new business models (SOE)

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.

Choreography of Services

With the growing popularity of Service Oriented Architecture (SOA) and Web Services, these diverse assets can be made available as individual enterprise services. How do we build and expose them as such and how do we leverage them in building new service-based applications or business processes? This is the problem Business Process Choreography tries to solve.

Web Services Choreography Interface (WSCI) is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services. WSCI describes the dynamic interface of the Web Service participating in a given message exchange by means of reusing the operations defined for a static interface. WSCI describes the observable behavior of a Web Service. This is expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions.

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.

But how do we actually identify our Services? This is now doubt a discipline normally mastered on the abstraction level of EA. In SOE we need a method to identify Services in a way that supports the paradigm of SOE and utilizes the experience of EA. The important notion here is that we don’t start from scratch!

If you are experienced working with SOE, SOAA and EA you should however not expect any revolution – it is in fact a very simple method. But this is just where I see the strength of the method. The simple message is: when identifying your Services don’t start developing your solution! Keep on track, and identify the Services one level of abstraction at a time