B E S T P R AC T I C E S

The Enterprise Architecture Of SOA

Essential Action Items For The EA Groups Plans
February 21, 2006

Client Choice topic

by Alex Cullen with Randy Hener, Gene Leganza, Sam Higgins, Laurie Orlov, and Samuel Bright

EXECUT I V E S U M MA RY
Whether or not you have a strategy for service-oriented architecture (SOA), SOA is inevitable. Software vendors are re-architecting their solutions around this architecture concept and in-house developers and solution architects are rushing to use it in their work. The enterprise architecture (EA) group must lead the decisions on where and how it will be adopted or risk a chaotic proliferation of redundant or incompatible services. The good news for EA groups? While SOA is new, if you have a robust EA program, you will be able to factor in the new concepts and design decisions into your EA frameworks and processes. But there are steps you should take to ensure you are suciently guiding adoption of this new architectural paradigm. RESEARCH CATALYST Clients selected this topic for Client Choice research. SOA IS AN INEVITABLE PART OF IT AND EA NEEDS TO GUIDE ADOPTION SOA is fundamentally a design philosophy: Expose business functionality and information of an application as encapsulated services, and use these services whenever that functionality or information is needed. But the impact of SOA is in the opportunity for IT to address the constraints that have hindered its support for business: increasing exibility for business change, enabling multichannel access to business functionality, and positioning for closer coupling between a rms business processes and those of its customers and suppliers.1 A recently completed Forrester survey showed that while 25% of large global rms have an enterprise strategy for SOA, the balance of rms report either that they are using SOA without a strategy or that they have no plans for pursuing SOA. What is the risk to these rms that do not have a dened SOA strategy?

Packaged applications will bring services into your IT environment. The software suppliers

to these rms, major application vendors like SAP and Oracle, as well as many smaller ones, are vigorously incorporating SOA into their product plans. This enables them to unify their products under a single architecture and to make it easier for their customers to change their applications and incorporate new oerings.

Headquarters Forrester Research, Inc., 400 Technology Square, Cambridge, MA 02139 USA Tel: +1 617/613-6000 Fax: +1 617/613-5000 www.forrester.com

Best Practices | The Enterprise Architecture Of SOA

Application developers will slip SOA into their software deliverables. Among technologists,

SOA has tremendous mindshare; SOA is one of the top search terms on the Forrester Web site. The platform and tools vendors these individuals work with are building SOA functionality into their products. These technologists see SOA as the leading edge and want to use projects to gain experience and burnish their resumes.

Unmanaged SOA will yield the same morass EA already confronts. Without a plan, there

will likely be a proliferation of incompatible services, duplication, and redundancy rather than sharing common services and one-o technology and infrastructure choices all the issues that EA already recognizes. SOA adoption must be planned if the benets to IT and the business are to be realized.

SOA challenges basic IT assumptions. SOA changes the denition of application. An application
has been a somewhat self-contained combination of business logic, process, and data on its own platform with its own user interface but now an application will be an assembly and orchestration of business services, service composition, process engines, and user interface modules.2 The concept in IT of who owns what changes, funding, change control, operations, portfolio management, etc. is a daunting list. Business solutions will be comprised of services that might be shared across business units or sourced from partners in a business process.

HOW DOES SOA FIT INTO A FIRMS ENTERPRISE ARCHITECTURE? While SOA brings new architecture challenges, it does not require a new approach to enterprise architecture. An SOA strategy and associated architecture can be thought of as a dierent view of the architectures and strategies that EA is already responsible for and can be addressed in a separate set of deliverables or in an update to existing deliverables (see Figure 1). Of particular importance are:

Service portfolio view. The portfolio view answers questions about what services provide

which functionality to which business groups or processes. The portfolio view gives EA groups the capability to compare what services are needed in a to be state with what initiatives are currently underway. Beyond identifying the needed service, this view claries how the service interface denition will mirror the business activity. The service portfolio is organized the same way as the application portfolio view.

Service design view. The design view guides project architects and development teams. It builds
on the service portfolio, especially how service interfaces are dened, and includes architecture patterns, standard solutions to design issues such as security, design principles, and data standards the same elements covered in the application architecture design view.3

February 21, 2006

2006, Forrester Research, Inc. Reproduction Prohibited

Best Practices | The Enterprise Architecture Of SOA

Figure 1 The SOA Perspective Builds On Your EA Documentation

Enterprise architecture domain Business architecture SOA perspective Use business strategy to derive potential leverage and benets of SOA Derive business functions to be service enabled from the business process architecture Develop a services portfolio using the same framework as the application portfolio architecture Identity the existing systems within application portfolio that will be the foundation of services Document design patterns and guidance for individual services using the same formats used by the application design architecture Dene the platform and conguration standards and strategies, including monitoring, management, and security tools, as an expansion of existing technical and operations architecture documentation
Source: Forrester Research, Inc.

Application portfolio architecture

Application design architecture

Technical architecture Operations architecture

Service infrastructure architecture. The infrastructure for SOA is an expansion of the

infrastructure architecture. It will consist of tool and platform standards, production, and test environment specications specic to SOA services, as well as SOA-specic elements for service registration, security, monitoring, etc.4

Governance, policies, standards, and consulting. While SOA has its dierences, existing EA

processes for governance and consulting can be adapted to these dierences. EA is the logical leader to champion the need for governance, relating governance and investment in SOA to the strategic objectives of the rm and the rms IT.5

THE EA GROUPS SOA DELIVERABLES EA groups should lead in a continuum of activities toward an SOA strategy, ranging from the conceptual description of this is what SOA is to the deliverables that support implementation and production use of SOA services. EA groups should involve other IT and business areas as needed to (see Figure 2):

Educate IT and business. Business and IT management and key stakeholders must understand

what SOA is (or service orientation), what benets are possible, and what impacts are likely. The

February 21, 2006

2006, Forrester Research, Inc. Reproduction Prohibited

Best Practices | The Enterprise Architecture Of SOA

EA group should plan and execute an education program to prepare the organization for later decisions around SOA adoption.

Dene strategic positioning. The core of an SOA strategy is the answers to the questions: How
and where we will use SOA, and how we will know how successful we are? The EA group should develop and circulate a position paper addressing these questions and get agreement on the answers.

Develop technical strategies. SOA requires rethinking strategies for scalability, monitoring,

change control, and deployment in fact, all aspects of system development and operations. Dene, with appropriate resources, the technical strategies for SOA design, implementation, and operation.

Expand the application portfolio framework. Use your application portfolio framework to

dene the services portfolio, with to be and current state views. By combining or crossreferencing the application and the service portfolio, you will identify opportunities and impacts.

Dene and manage technology standards. Use technology standards and design patterns to
promote consistency across service development and implementation and to provide greater ability to leverage previous experience. For example, a standard approach to service interface conguration helps developers focus less on how to do this and more on the service they are developing.

Establish syntactic and semantic standards. Syntactic (meaning of message elements) and

semantic (structure and rules for transactions) standards are necessary for ecient reuse of services. They should be derived from your information architecture and your information taxonomy. Where possible, external and industry standards, such as ACORD XMLife for life insurance, should be incorporated.

Implement architecture review and governance. Develop and implement review and

governance criteria for the SOA aspects of projects, and incorporate them into existing architecture governance processes such as project design reviews.

Sponsor the pilots. If needed, sponsor or champion pilot service development, and reuse

projects to gain experience, prove benets, and validate standards. But be careful sponsoring SOA pilots should be a transitional activity, with production services owned by the groups that own the applications.6

Sponsor the infrastructure. If needed, sponsor the SOA enablement infrastructure, such as
service registries, which facilitates the realization of the core value proposition: reuse and leverage of services across multiple needs.

February 21, 2006

2006, Forrester Research, Inc. Reproduction Prohibited

Best Practices | The Enterprise Architecture Of SOA

Figure 2 The EA Groups SOA Deliverables

Education and positioning What is it and where does it t?
Dene SOA service portfolio
Sponsor pilot services

Syntactical and semantic model standards

Sponsor SOA enablement infrastructure repositories, registries, and test environments

Concept
Strategic positioning: How and where we will use SOA
Technical standards and design patterns for SOA services Technical strategies for SOA design, implementation, operation
Review and governance of projects SOA components

Implementation

Source: Forrester Research, Inc.

R E C O M M E N D AT I O N S

ASSUME SOA WILL BE PART OF YOUR IT, AND MUST BE PART OF YOUR EA
EA groups must assume that SOA will be part of their rms IT environments and therefore must be a part of the architecture. SOA will be brought in either by individual developers and architects doing what they think is right or by application vendors migrating customers to their next versions. Ultimately, SOA should become simply another attribute of the enterprise architecture. EA groups, at a minimum, should guide a rms SOA adoption by:

Dening the strategic positioning. The EA group should tackle head-on the decisions on
where and how to use SOA assessing their strategic application vendors directions as well as their own legacy systems. The EA group should clearly state what the expected benets are and put in place the metrics that will show if they are on track.

Promoting a basic level of infrastructure commonality and interoperability. When a newsounding technical approach is being adopted there is a temptation by project teams to pick their own technical platforms and tools. EA groups should ght this, explaining that as SOA moves into the mainstream, all services built on out-of-favor platforms will become a legacy that requires conversion or replacement.

February 21, 2006

2006, Forrester Research, Inc. Reproduction Prohibited

Best Practices | The Enterprise Architecture Of SOA

Providing a forum for design decisions that have long-lasting consequences. In the
early stages of SOA adoption, project managers will be making a myriad of decisions that could have lasting implications by dening a transaction interface or adopting an Internet standard that is in ux. The EA group should not try to control decisions where the solution criteria is not clear, but should provide a forum where these decisions and their ramications can be discussed.

Expanding business, application, and information architectures to address SOA. Welldened business, application, and information architectures are the foundation of managed adoption of SOA. With them, EA groups will be well positioned to provide direction to the services portfolio and service interface denition. But if these architectures are not well dened, then their development must become a priority.

Championing SOA portfolio framework and processes. Rather than give application
teams free rein to develop whatever services they think useful, the EA group must provide the framework that provides a larger contextual view and the processes by which project teams can use and contribute to the portfolio denition and maintenance.

Championing SOA repositories, registries, and testing standards. A good infrastructure

of repositories of SOA service documentation, service registries, and testing standards builds the condence of the project team that must use these services a must to achieve the reuse and leverage implicit in an SOA strategy.
W H AT I T M E A N S

ARCHITECTING THE FOUNDATION FOR YOUR DIGITAL BUSINESS

Digital Business Architecture is Forresters concept of the conuence of business services, Organic IT, unied communications, and pervasive interactions to provide an IT platform that more closely matches a rms business processes and enables change at the pace of business change.7 But the migration toward Digital Business Architecture requires more than technology it depends on a robust portfolio of services and the embodying of a rms processes and business rules in metadata that supports orchestration and enables code-less change. An EA group that has a disciplined model for their SOA migration will be well positioned to seize opportunities to build out their rms Digital Business Architecture.

ENDNOTES
1

By pursuing service orientation and moving your shop toward service-oriented IT, you can aim to achieve responsive, adaptive business optimization underpinned and accelerated by incremental IT delivery and a transformed, realigned business-IT relationship. See the June 18, 2004, Trends The Big Strategic Impact Of Organic Business And Service-Oriented Architecture.

February 21, 2006

2006, Forrester Research, Inc. Reproduction Prohibited

Best Practices | The Enterprise Architecture Of SOA

Frequently, in SOA discussions, someone will say that because SOA so heavily blurs the lines between applications, the concept of an application goes away. But managing a plethora of individual SOA piece parts is too complex, so IT still needs some way to manage groups of SOA assets. Thus, a better way to think about it is that SOA changes the denition of application. In fact, SOA creates multiple denitions of application as dierent combinations of interaction layer and business services layer modules. Composite applications bring the pieces together, leveraging business process denitions to increase the exibility and agility of enterprise applications. See the August 1, 2005, Best Practices Does SOA Make Applications Obsolete? Forrester outlines four key design principles for services. See the August 8, 2003, Planning Assumption Service Orientation: Key Application Design Principles. Your SOA platform the software infrastructure and tools you use to build, congure, deploy, monitor, and manage services heavily inuences your ability to attain the strategic business exibility and benets that service orientation promises. See the March 29, 2005, Trends Your Strategic SOA Platform Vision. In the world of traditional IT, the ownership of business applications is shared between the IT organization and the business unit that uses the application. This shared ownership drives a division of responsibility for business cases, project sponsorship and oversight, implementation, and benets assessment. SOA introduces a new dynamic: business services that are shared across business units and applications. These services in SOA become a new class of IT asset, requiring new governance models and a larger, more central IT role to avoid contention between business units or worse orphan services. See the June 30, 2005, Trends Who Owns Business Services In An SOA World? The concepts and philosophy of SOA are becoming mainstream in IT. EA has been largely successful at championing this change. The eorts by IT to incorporate SOA concepts can be characterized as rstgeneration SOA; early releases of services largely focused on the infrastructure level. IT needs to examine the structures that will sustain SOA: maintaining and evolving services, better matching services to business needs, and enhancing the capability of the service infrastructure to support widespread use. This is where second-generation SOA begins where SOA is a given and the focus is on how IT supports the business. EA will continue to drive the way that enterprises utilize SOA, but this leadership will be dierent from how EA has championed SOA thus far. See the September 30, 2005, Trends What Must EA Do To Sustain SOA? Forresters Digital Business Architecture lets diverse IT domains work together as one, enabling IT to deliver unied solutions to business problems that cross IT domains. This either: 1) drives down a rms total spending on IT, or 2) lets IT deliver more business value at the same spending level. See the November 7, 2005, Big Idea Digital Business Architecture: IT Foundation For Business Flexibility.

Forrester Research (Nasdaq: FORR) is an independent technology and market research company that provides pragmatic and forward-thinking advice about technologys impact on business and consumers. For 22 years, Forrester has been a thought leader and trusted advisor, helping global clients lead in their markets through its research, consulting, events, and peer-to-peer executive programs. For more information, visit www.forrester.com. 2006, Forrester Research, Inc. All rights reserved. Forrester, Forrester Wave, Forresters Ultimate Consumer Panel, WholeView 2, Technographics, and Total Economic Impact are trademarks of Forrester Research, Inc. All other trademarks are the property of their respective companies. Forrester clients may make one attributed copy or slide of each gure contained herein. Additional reproduction is strictly prohibited. For additional reproduction rights and usage information, go to www.forrester.com. Information is based on best available resources. Opinions reect judgment at the time and are subject to change. To purchase reprints 38979 of this document, please email resourcecenter@forrester.com.