Case Study (Cloud computing)

Chapter5SOA.pdf

Home >Computer Science homework help >Case Study (Cloud computing)

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

CHAPTER 5 Service-Oriented Architecture

Enterprise Architecture Framework and Methodology

Developing under a service-oriented architecture (SOA) approach requires thatthe artifacts within the enterprise architecture documentation library be struc- tured to support the business evaluation and understanding of:

� What exists in terms of services and composite business processes. � How those services are currently consumed in terms of both the channels and

the constituents. � What it would take to extend existing services to other channels and/or other

constituents. � What are the core, or foundational, capabilities that must be in place to support

a service and its deployment.

Developing under an SOA approach also requires a methodology that defines and enforces a top-down approach to SOA providing direct identifiable linkages from the top-level corporate strategy down to the physical implementation of each SOA component. The methodology also needs to drive the process to ensure that leveraged and reused SOA components are maximized in the context of:

� Being designed to be leveraged and reused. � Continuous evaluation throughout the process to assess their leveragability and

reuse.

The first part of this chapter defines the SOA enterprise architecture framework (SOA∼EAFTM) columns (subframeworks) and the layers common across the sub- frameworks. The second part provides an overview of the methodology that utilizes and maximizes the SOA∼EAF. The content of this book from this chapter forward defines the specifics of the methodology in detail.

SOA Enterprise Architecture Framework

SOA∼EAF is the framework used to capture and manage all the documentation and metadata needed to support, manage, and maximize an SOA enterprise architecture

Sweeney, Rick. Achieving Service-Oriented Architecture : Applying an Enterprise Architecture Approach, John Wiley & Sons, Incorporated, 2010. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/apus/detail.action?docID=530020. Created from apus on 2018-07-05 00:45:21.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

52 Architecture Framework and Methodology

practice. The framework is also the mechanism that provides traceable linkages from the highest corporate strategic level down to the physical SOA implementations.

The framework is comprised of five columns and seven rows (or layers). The five columns represent the individual frameworks applied to each of the focus areas of the SOA practice. These frameworks are the:

1. Corporate strategy SOA assessment framework 2. Business unit operational plan SOA assessment framework 3. SOA Business Architecture framework 4. SOA Reference Architecture framework 5. SOA Platform Architecture framework

While the architecture practice facilitates and manages all five of these frame- works, the first three are owned and driven by the business. Architecture also manages the direct correlation and linkages of the artifacts and metadata across the five columns at each layer.

The seven layers that are the same for each of the individual frameworks are the:

1. Constituent Domain layer 2. Business Channel Domain layer 3. Business Process Domain layer 4. Business Service Domain layer 5. Integration Service Domain layer 6. Legacy Application Domain layer 7. Legacy Platform Domain layer

Note

Everything in this book assumes that you have an existing enterprise architecture practice and are looking to adapt this practice to support the SOA paradigm. If you do not have an EA practice, you need to establish one quickly. The first step will be to hire a chief architect and establish at least one of each of the architecture types defined in Chapter 11. These resources are needed to develop your SOA business strategy and roadmap, defined in Chapter 14. This document is the basis for initiating the implementation of everything defined in this book. Without an enterprise architecture team and this document you will not succeed at implementing the practice defined in this book.

The corporate strategy SOA assessment framework, business unit operational plan SOA assessment framework, SOA Business Architecture framework, enter- prise SOA Reference Architecture framework, and the enterprise SOA Platform Architecture framework make up the SOA enterprise architecture framework. This trademarked framework is referred to as the SOA∼EAF in this book and other publications. Exhibit 5.1 shows this framework.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 53

Constituent Domain

Corporate Goal/Strategy

Cross-Reference

Business Unit Plans

Cross-Reference

SOA Enterprise Architecture FrameworkTM

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Business Channel Domain

(Enterprise)

Business Process Domain

(Composite)

Business Service Domain (Unit)

Service Integration

Domain (Isolation)

Legacy Application

Domain (Encapsulation)

Legacy Platform Domain

(Migration)

EXHIBIT 5.1 SOA∼EAF Framework

Corporate Goal/Strategy Cross-Reference Column

One of the major reasons for adopting an SOA approach to business systems is to have the entire IT process for communicating, designing, and implementing those systems structured in terms that are understood by the business and therefore can be driven by the business. We want the business to drive not only the tactical im- plementations of its projects through its business requirements structured to support the business architecture, but also the strategic evolution of the SOA environment as well. If the goal is to leverage and reuse as many of the SOA components in the SOA infrastructure as possible to maximize the investment we make, the best way to achieve this goal is to have a business strategy for doing so. In other words, there is value in finding time and money savings on each initiative through the leverage and reuse of SOA assets, but there is an even greater value if the business strategically plans for those advantages: a strategic value that not only results in cost and time to market savings, but also in expanding a competitive advantage and finding new market opportunities and business efficiencies.

The purpose of the Corporate Goal/Strategy Cross-Reference column of the SOA∼EAF is twofold. First is to identify all the strategic objectives of the company. These include strategies to enter new markets, expand existing markets, and expand product lines or reduce production costs. Second is to identify how the company envisions what role each constituent plays in helping it achieve those strategies. What capabilities are needed to help achieve the strategy, and what is the best way

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

54 Architecture Framework and Methodology

to deliver those capabilities? Hence, we translate corporate strategies and goals into strategies and goals that relate to:

1. Our constituencies and how we strategically value their experiences and inter- actions with our company.

2. Our channel strategy and how we maximize our investment in each channel for each constituent type.

3. Identification of our highest value services and how they can be leveraged to achieve the company’s strategic goals.

4. Finding efficiencies and improvements in the services we deliver. 5. Maximizing the value of the legacy system investment by supporting a strategy

to augment them with capabilities that remove or minimize their rigidity in terms of adaptability and flexibility.

6. Providing a strategy to replace or modernize those legacy systems that cannot be augmented.

The conduct of this analysis and the incorporation of the results into the frame- work should occur as an extension of the corporate strategic planning process. This should not be a separate process or an IT process. The participants evaluating and approving the corporate strategy are the top executives of the company and should be the same representatives who make up the SOA Business Domain Governance Committee defined in Chapter 8.

While the business may clearly see its role as a driver for layers 1 through 4, it may not see itself as the driver of layers 5 and 6. It may see these as IT responsibilities. The problem with IT driving these layers is that if they are not addressed and promoted at a strategic level, IT will not be able to address them at a tactical level. There just will not be the money and time to do so. If they are packaged and addressed as IT strategies at the strategic planning level, the business will see them as competing strategies when it comes to assessing their priority and approving funding for them. In most cases, the IT initiatives will lose this fight.

These are not IT strategic requirements. They are the business strategic require- ments so that IT can effectively deliver the capabilities and flexibility the business requires. They are not separate competing strategies but intricate components of the business strategies. Keeping these separate as IT responsibilities is equivalent to sales not recognizing that improvements in customer service impact repeat sales or that reduction in unit manufacturing costs has no impact on competitive pricing or margins. Clearly this is not the case. There is a direct impact to the business units and their strategic goals. Therefore, the business, not IT, needs to take ownership for driving the improvements to the flexibility, adaptability, and efficiency of legacy systems as these result in direct improvements needed to achieve its strategies.

Clearly there are two sides to the coin. One side is establishing the strategy and documenting its components as they relate to the layers of the framework. The other side is how to use the information to drive the tactical decisions we will make to achieve the strategies.

Part of the SOA transformation we are effecting is to change the approach so that we are evaluating and justifying each project at a more strategic level using more consistent metrics. Traditionally we would justify a project by referencing the goals and strategies in general terms (i.e., “This new system will reduce the administrative

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 55

costs of the order processing department by 10 percent”) as a justification against a corporate goal to reduce costs. The reality is that any headcount savings in the order department may be completely offset by the (unpredicted) increase in operational and administration costs associated with running the application. Was the cost of the allocation of 50 percent of an order department resource’s time to administer the security and user configuration management of the application factored into the ROI? It probably was not.

The point is there is nothing in the business evaluation and justification process that evaluates whether the solution is the most effective and efficient use of IT assets and investments. There is nothing to evaluate if the solution positively or negatively impacts the work flow or workload of the employees, customers, or vendors that use it. There is nothing to ensure that the solution reuses existing capabilities instead of duplicating them.

In addition to the business need to drive the modernization of the legacy sys- tems, we also need the business to drive the process for ensuring that we are making our IT investments efficiently and wisely. We need the business to address these issues at the enterprise and strategic level, not at a tactical level. As with legacy systems, attempting to incorporate and enforce development of reusable and lever- aged SOA components at the project level is doomed to fail. In most cases, the cost and time to do so were not factored into the project. Even if there is no impact to the cost and delivery time, there will be resistance to the unknown. Even worse, components may be accepted and then later used as a scapegoat for other delays or cost increases in the project.

The process of incorporating these strategies into the IT planning process and governing their enforcement is the responsibility of the enterprise SOA Portfolio Plan Governance Committee. This governance committee is comprised mostly of business leaders. They focus on both the corporate-wide horizontal strategy of the constituency (service consumers) and the vertical strategy for managing and lever- aging capabilities (service providers). Hence this committee has the responsibility to establish these strategies and validate each initiative submitted to it for approval and funding for support of those strategies. The enterprise SOA Portfolio Plan Gov- ernance Committee is defined in Chapter 8.

From a horizontal (service consumer) perspective, some of the strategic issues addressed by this committee include:

� Who are our constituents? How many constituent types are there? Are their different variations of constituents within each type? Do our strategies require establishing new constituencies or new variations of existing constituencies?

� How do those constituents interact with us? How do we want them to interact with us? How do they want to interact with us?

� How effective is the interaction? How satisfied are they with the interaction? How would they improve the interaction? Do our strategies require any of these interactions to change? Expand or contract? Apply different regulations or support different cultures (e.g., a national to global strategy)?

� How effective are the services being provided to these constituents? How much are they using these services, and through what mechanisms? Are there any services not being provided, or not being provided through a particular channel, that would increase their value if they were? Do our strategies require new

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

56 Architecture Framework and Methodology

services currently not provided or changes to existing services to meet new requirements (e.g., multilingual support or foreign regulatory compliance)?

� Do any services being used by one constituency have value to another con- stituency?

The answers to these questions are translated into strategic objectives and added to the Constituency, Channel, Business Process, and Business Service domain cells in the Corporate Goal/Strategy Cross-Reference column of the SOA∼EAF.

From a vertical (service provider) perspective some of the strategic issues ad- dressed include:

� Are the services provided flexible and adaptable? Are they designed to support the widest audience of potential users? Are the services capable of supporting the needs of the corporate strategy, or will enhancements to existing services or acquisition of new capabilities for new services be required?

� Are the services controlled and accurate? Are they secured with proper autho- rization policies? Are they compliant with all legal and regulatory requirements? Are they traceable? Auditable? Are all retention and archive requirements sup- ported? Do strategies implicate any of these requirements in terms of new con- trols, regulations, translations, certifications required by those strategies (e.g., requirements to meet new regulations when entering a new foreign market)?

� Are any services duplicate or redundant in any way? How do we eliminate any duplication or redundancy?

� Are there different versions of the service? If yes, how many and how long are they supported? How do we ensure that compliance with these policies is enforced and funded? Will anything in our strategic plan impact our ability to enforce this, and how do we handle these exceptions?

� What organization or group is the custodian of the service and manages its use and life cycle? (I use the term custodian rather than owner consciously.) Are any new custodians required to support new capabilities?

� How do the legacy business applications support our services? How effective is that support? Will this effectiveness impact the ability of these services to meet the requirements of our strategies (e.g., going global requiring 24/7 availability)?

� Are any of these legacy systems being strained from a business capability, performance, or capacity perspective? Will the strategy increase this strain?

� Are any of the technologies or platforms used in these applications unsupported or significantly behind in their version currency? What risk does this pose to the business, and how do we mitigate that risk?

� Are their major enhancements or upgrades scheduled or requested for these legacy applications, and do they have strategic value or make sense from a SOA business model perspective? Are their alternatives that have higher value to the business going forward (alternatives such as implementing a rules engine to build an insurance rating system rather than spending as much or more money to implement a major upgrade of a vendor’s rating application that still will not interoperate with channel and process layers or the security framework)?

� What are the plans to modernize, replace, or sunset these systems? How are these plans funded and incorporated into the portfolio plan?

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 57

The answers to these questions are translated into strategic objectives and placed in the Business Service, Service Integration, Legacy Application, and Legacy Plat- form Domain cells in the Corporate Goal/Strategy Cross-Reference column of the SOA∼EAF.

This process provides the strategic measures and metrics that can be applied to each SOA initiative. How they are applied is discussed in the next section.

Business Unit Plans Cross-Reference Column

The Business Domain Governance Committee establishes the strategic direction for each layer of the SOA architecture, and the SOA Portfolio Plan Governance Committee translates these into identifiable and measurable metrics that can be applied against each SOA initiative. They do so at an enterprise level. Each business unit also needs to evaluate the corporate strategies, what the strategic statements mean to their specific business units, and what they need to do to support the strategy. For example, the impact of going global on constituents, channels, and services is assessed and captured in the strategic column from an overall corporate perspective. But what does going global mean specifically to sales, support, or distribution? Sales may have to expand its sales force into each country by acquiring space, hiring sales associates, and so forth. Distribution’s strategy may be to partner with carriers in each country to extend the channel. Support may be building its own staff in some countries and partnering with an outsource vendor for support in other countries. Each business unit’s plan for how it would support the strategy would be documented in each of the cells in the Business Unit Plans Cross-Reference column of the SOA∼EAF.

Hence, the Business Unit Plans column defines the capabilities needed by each business unit to support the strategy and when those capabilities need to be there. This information is as critical as the strategy itself to structure, evaluate, and pri- oritize SOA initiatives. The corporate strategy may have identified expansion into seven countries where seven different languages are spoken. Knowing that distri- bution is going to partner with carriers that will handle the language issues means that the service integration with these carriers will not require language translation capabilities. However, all the sales services and the channel adapters used to de- liver those services will require language translation capabilities. The business unit plans may also determine that only three languages need to be supported for the support services with the other four languages supported through the outsource vendor.

Not all strategies will affect all constituents. Not all channels will support each strategy. Not all business units support all constituents. Not all business units support all channels. The information documented in the Corporate Strategy and Business Unit Plans columns of the framework will explicitly identify the presence or lack of these relationships. This provides a mechanism to ensure that tactical implementa- tions are consistent with the corporate strategy and business plans. The information also helps to identify inconsistencies or required changes to the business plans and corporate strategy at the implementation level. Perhaps a capability that was not identified in the business unit plans is determined to be necessary when implement- ing the solution, or partnering with oversees outsource support partner is determined to be cost prohibitive when negotiations occur. The framework allows these issues

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

58 Architecture Framework and Methodology

to be pushed back up into the business plan and corporate strategic levels where they can be addressed by the right leaders.

An example of a nonapplicable business unit to constituent strategy is a business unit that has no relationship with a particular constituent (e.g., the human resources department may not have any direct relationship with the customers). In this case, human resources would not have any business plan entries under the external cus- tomer constituent. An example of a nonapplicable channel strategy is a business unit that has no transactions for a particular constituent supported by a particular chan- nel. For example, electronic data interchange (EDI) may be a strategic channel of value to the company, and providing this channel option to customers and vendors is a stated strategic direction. The sales and finance business units may specify a strategy to provide support for purchase orders (POs) through this channel (Sales = POs in from customers: Finance = POs out to vendors). Finance may also specify support for invoices and “payment remittance” transactions between customers and vendors through this channel as well. The customer training business unit, however, has no defined EDI transactions for the services it provides. Therefore, it would have no plans to support this channel. Each business unit should map its plans on how its unit would or could support each of the applicable corporate strategies.

The corporate strategy may also define specific strategic goals aimed at directing the increased use of specific technologies that have economic and/or competitive value to the corporation in general. These will include strategies to expand the self- service capabilities of customers and vendors through the Web, EDI, and intelligent voice recognition (IVR) channels to reduce service costs. Each business unit would identify the customer and vendor services it provides (it may not provide any) and how it would support customers’ and vendors’ use of those services through these three channels.

Business units will almost always be comprised of both service consumers and service providers. A business unit will have services that are used by internal and/or external constituents outside the business unit. The business unit will also use ser- vices that are provided by other internal (business unit) entities or external (vendor and partner) entities. Therefore, most business units should have mappings to every layer within the Business Plan Cross-Reference column in the architectural frame- work. However, the business unit needs to be very clear and diligent about making and enforcing this distinction between consumers and providers when building its plans.

Service providers within the unit should map their support plans only as they relate to the Business Service Domain layer or lower. Service consumers within the unit should map only their support plans as they relate to the Business Service Do- main layer or higher. The common ground between service consumers and service providers is the Business Service Domain layer.

These are very subtle statements but they represent a significant cultural and political shift in the traditional process. We are no longer asking the owners of the business applications to define how they are used. We are asking them to define each service provided by the legacy systems of record that they own and the requirements for authorization, accuracy, and control. We are not asking the users of the legacy systems to define how they are used either. Instead, we are asking the people for whom the service is being rendered to define how the service is used. This is the new dynamic of SOA. This is a top-down, consumer-centric approach to

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 59

business systems versus the bottom-up development approach to systems. This is the outside-looking-in approach versus the inside-looking-out approach.

CHANNEL INTERMEDIARIES REVISITED Employees who consume services to support interactions with other constituents should be treated as channel intermediaries, and their requirements should be no different from those expressed by the constituent they interact with. See Chapter 4 for a full description of intermediaries. If a customer calls a service representative to process a transaction rather than using a self-service mechanism, the transaction itself should be exactly the same. The business process may be streamlined in one instance (the service rep) and more detailed in the other (self-service) instance, but, if done correctly, these are just dynamic modifications to the same business process.

JUSTIFICATION CRITERIA The business justification of the value of a specific business service or process within an initiative is still evaluated through the traditional busi- ness metrics. These business metrics include evaluating the service or process in the context of:

� Its ability to improve operational efficiency, reduce costs, or increase revenue. � Automating a manual business process. � Meeting a legal, audit, or regulatory requirement. � Supporting a new market, line of business, or business offering.

The delivery and use of those services, however, is now evaluated on:

� Their support of the documented constituent, channel and Business Process Domain strategies in the Corporate Goal/Strategy Cross-Reference column of the SOA∼EAF.

� Their alignment with the business unit plans in the Business Unit Plans Cross- Reference column of the SOA∼EAF.

Their technical value assessment is based on their compliance with all the domains of the Reference Architecture framework and the rationalization of that architecture against both the corporate and business unit columns of the framework.

As this approach implies, the decision on what an SOA initiative does and how it does it is no longer a single department or traditional “application owner” decision. This makes sense because the solution is no longer a self-contained stovepipe application. The solution will involve the reuse of SOA components that already exist. The solution will share and leverage existing common SOA components, such as security, and the channel adapter framework established for each constituent. The days of each business unit replicating and duplicating these capabilities are gone. The cost and time savings realized by eliminating these redundancies results in getting new stuff done faster, doing it cheaper, and making more money available to do more.

More information on the corporate strategy and business plan columns of this framework is provided in the “Business Domain Governance Committee” and “Portfolio Governance Committee” sections of Chapter 8.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

60 Architecture Framework and Methodology

SOA Business Architecture Framework

The business architecture depicted in Chapter 3 reflects some of the same basic components of traditional enterprise architecture frameworks. In other words:

� Who is doing something? � Where are they doing it? � What are they doing? � And how are they doing it?

The business architecture picture from Chapter 3 is revisited in Exhibit 5.2 to highlight these characteristics.

The reflection of these concepts in the business architecture is 100 percent conceptual. There are no physical or logical representations in the exhibit. The exhibit does not depict any servers or other hardware components. There are no database models or defined system interfaces present. This business architecture is simply a conceptual framework that both the business and IT can understand and agree to. The existence of this document is critically important as it represents the baseline of common understanding and agreement between the business and IT. It represents the diagram that is the new communication language between the

Paper/Fax Image

Web Interface Intelligent Voice

Recognition Interface

Channels

Validate Customer

Customer Service

Call

Partner Presentation

Services

Business Processes

Business Services

Generate Quote Book Order

Pay Invoice

Schedule Installation

Validate Shipment

Employees, Customers, Partners, and Vendors

How are they doing it?

What are they doing?

Where are they doing it?

Who is doing it?

Check Credit

Check Product Availability

Sales Processes

Manufacturing Processes

Inventory Processes

Product Development Processes

Vendor Processes

Partner Processes

Order Processes

Shipping Processes

Billing Processes

Post-Sale Support

Service Processes

Corporate Processes

EXHIBIT 5.2 Business Architecture Revisited

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 61

business and IT. Everything specified by the business and everything delivered by IT should be able to be mapped to the business architecture. If you cannot map the business specification or an implementation to the diagram, one of two conditions has occurred. Either you are missing something in your business architecture (an undefined constituent or a missing channel), or what you cannot map is not a business process or service (i.e., it is not a business application).

The business architecture diagrams are the conceptual representations of the required capabilities defined in the business unit plans in the Business Unit Plans Cross-Reference column of the framework. In the strategic example given earlier, where support in certain countries was provided by an outsource partner, we would expect to see a business architecture diagram for those countries where a customer accesses a partner’s channel to use services that have been integrated into that partner’s channel.

So far the business architecture diagram only relates to service consumers. The complete business architecture diagram extends through the remaining layers of the framework to reflect the conceptual views of the service providers as well. A complete business architecture diagram is presented in Exhibit 5.3.

Like the top layers, the three lower layers show no logical design or physical im- plementation characteristics. They are just conceptual representations. Even though the Legacy Platforms layer contains specific technical terminology, the terminology is conceptual as well. It does not tell us how many COBOL programs, virtual stor- age access method (VSAM) files, and Customer Information Control System (CICS) regions there are, how they relate to each other, and where they physically reside. They are represented to show that the service providers are, for example, supporting the “Book Order” business services with order system integration services like the “Create Customer Order” integration service, which creates a new order record in the order system running on the mainframe.

Every SOA initiative should have an associated business architecture diagram that reflects all the conceptual SOA business components needed to meet the spec- ified requirements of the initiative. The metadata and artifacts associated with the enterprise SOA Business Architecture framework are managed and maintained by the business architects. They have the custodial responsibility for maintaining the currency and accuracy of the artifacts. Any changes to them must be made by the business architects. The business architects are also responsible for maintaining the horizontal integrity of these artifacts with the SOA reference architecture and the SOA platform architecture, ensuring that any business definitions or concepts im- pacted by a change to the reference or platform architectures are identified and reflected in the business architecture.

Enterprise SOA Reference Architecture Framework

The enterprise SOA reference architecture is the framework that translates the busi- ness architecture conceptual components into components within a logical SOA reference architecture. It represents the next layer of specificity about the SOA Enterprise Architecture Domain. It represents the logical view of the SOA architec- ture. It is the bridge between how the business sees SOA (the business architec- ture) and how those business needs are logically implemented (the enterprise SOA

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

62 Architecture Framework and Methodology

Paper/Fax Image

Web Interface Intelligent Voice

Recognition Interface

Channels

Validate Customer

Customer Service

Call

Partner Presentaion

Services

Business Processes

Business Services

Integration Services

Legacy Applications

Legacy Platforms

Generate Quote Check Credit Book Order

Pay Invoice

Schedule Installation

Check Product Availability Validate Shipment

Employees, Customers, Partners, and Vendors

Get Customer

Order

Create Customer

Order

Update Customer

Order

Get Product

Description

Get Customer

Credit Limit

Update Customer

Credit Limit

Product Master

File

Order System

Customer Contract System

Mainframe Virtual storage access method (VSAM)

COBOL Customer Information Control System (CICS)

Mainframe DB 2 SQL SAS

Mainframe DB 2

COBOL CICS

Sales Processes

Manufacturing Processes

Inventory Processes

Product Development Processes

Vendor Processes

Partner Processes

Order Processes

Shipping Processes

Billing Processes

Post-Sale Support

Service Processes

Corporate Processes

EXHIBIT 5.3 Business Architecture Diagram: All Layers

reference architecture). Exhibit 5.4 represents the enterprise SOA Reference Archi- tecture framework.

Each domain layer in the Enterprise SOA Reference Architecture framework (with the exception of the Legacy Application Domain) is split into sublayers. These sublayers isolate the functionality provided by the component from its integration specifications with the layer below and its invocation specifications with the layer above. The only exception to this is in the Channel layer, where certain layer- specific functionality is embedded in the channel adapter (i.e., a browser contains the functionality to interpret and display hypertext markup language [HTML]; a portal contains the functionality to interpret and display portlets).

The added descriptor of Domain is included in the description of each row. This is done to reflect that specific resources may be dedicated to a specific horizontal

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 63

S e r v i c e C o n s u m e r C h a n n e l D o m a i n

C h a n n e l A d a p t e r L a y e r

C h a n n e l I n t e r f a c e L a y e r B u s i n e s s P ro c e s s D o m a i n

B u s i n e s s S e r v i c e D o m a i n

S e r v i c e D e l i v e r y C o n t r a c t L a y e r

P r o c e s s D e l i v e r y C o n t r a c t L a y e r P r o c e s s D e f i n i t i o n L a y e r

S e r v i c e D e f i n i t i o n L a y e r

S e r v i c e I n t e g r a t i o n L a y e r

I n t e g r a t i o n A d a p t e r L a y e r

F u n c t i o n a l D e f i n i t i o n L a y e r

L e g a c y A d a p t e r L a y e r L e g a c y A p p l i c a t i o n D o m a i n

L e g a c y A p p l i c a t i o n

C o r p o r a t e D a t a b a s e Wa r e h o u s e / M a r t s

D o c u m e n t M a n a g e m e n t

S y s t e m s

I n t e g r a t i o n D o m a i n

P r o c e s s I n t e g r a t i o n L a y e r

D e v e lo

p m

e n

t F

ra m

e w

o rk

s :

S e c u

ri ty

, P e rs

o n

a li

za ti

o n

, P ro

fi li

n g

, L o

g g

in g

, E x

c e

p ti

o n

H a

n d

li n

g , A

rc h

iv in

g , e

tc .

EXHIBIT 5.4 Enterprise SOA Reference Architecture Framework

plane. It is also added to further enforce the demarcation of accountability and responsibility of the layers. As stated at the beginning of this book, SOA will force a paradigm shift in everything IT does. Part of this shift will result in certain groups relinquishing some accountability and ownership while others will add to their domain of accountability.

The establishment of these domains and the isolation of responsibilities within them will help to break the traditional mind-set of application ownership associated with a non-SOA approach. The vertical mind-set belief that a particular department or organization owns the entire application, from the user interface to the data, needs to disappear. It will be difficult to convince departments to let go. They will resist. However, if you can show that the process and practice provides them with these benefits, you have a good chance of winning them over:

� A tightly controlled and transparent mechanism to ensure that they still have visibility and input into the vertical view.

� A new, added responsibility that is more strategic than tactical. � Measurable improvements in the flexibility and adaptability of the systems sup-

porting their business.

An SOA business architecture diagram may show a customer using a customer portal through the Web channel to consume the listed processes and services. The

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

64 Architecture Framework and Methodology

SOA Reference Architecture diagram would show the role of customer logging on to the Web using a portal adapter, authenticating and exposing privileges to access the listed services being delivered as JSR 168 portlets.

DEVELOPMENT FRAMEWORKS, DESIGN PATTERNS, AND DESIGN STANDARDS In addition to the logical representation of all the implemented SOA components in the port- folio, the enterprise SOA reference architecture also includes all the development frameworks, design patterns, and design standards that are applied when develop- ing under SOA. These are the architectural components of an SOA development. Development frameworks, design patterns, and design standards are the A in SOA.

Development Frameworks A development framework has a larger scope than a de- sign pattern and is less specific and rigid in its implementation (i.e., one or more options on how to apply a specific component of the framework may be allowed). An example of a development framework is the framework for the enterprise se- curity module. This development framework transcends from the Channel layer of the architecture all the way into the Legacy Application layer. The framework de- fines how each business component within each layer interfaces and interoperates with the framework and how the framework’s modules in one layer interface and interoperate with the frameworks modules in the layers above and below.

A development framework encompasses many components and interfaces. An SOA enterprise architecture development framework can transcend multiple layers of the architecture, like the three just mentioned, or be specific to a single layer of the architecture. An example of a single-layer framework is one for transforming and orchestrating different message formats at the integration layer.

Components of one development framework may interact with components of another. For example, frameworks for performing personalization or user profil- ing may also be defined. Components implemented under these frameworks may be required to interact with each other or components of the enterprise security framework. In those instances, the documentation of each framework includes the framework-to-framework integration and operation specifications.

You should have all your development frameworks defined and documented before you start to develop your first SOA-based architecture solution. These frame- works are critical to the consistency, leveragability, and reusability of your SOA components. Failure to do so will result in:

� Components that will not be reusable or leveraged. � Rewrite and replacement of these SOA components after these frameworks

are defined.

How many frameworks you will need to support your SOA environment will depend on your unique environment. The architects need to perform a comprehen- sive assessment of their environment (e.g., tools, platforms, channels, etc.) to deter- mine the frameworks needed. At a minimum, most companies will need the four just mentioned (security, personalization, profiling, orchestration) as well as frame- works for nonfunctional capabilities (e.g., logging, auditing, exception handling, archiving, etc.).

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 65

Design Patterns Design patterns apply to the specific design of individual compo- nents. More than one design pattern may exist for a single component. For example, multiple design patterns will exist for each of the service stubs needed by each of the channels and channel formats that invoke the services. The design pattern for invoking a service through a Windows client will be different from the pattern for invoking the service through a browser client. Within the Web channel, the design for invoking the service as a JSR 168 portlet by a portal will be different from the design for invoking the service through an MVC or Spring-based Web application. However, the design pattern for invoking all JSR 168 portlets from all portals should be exactly the same. Multiple design patterns for the same purpose should not be allowed.

A design pattern tells the developer exactly how to technically code the com- ponent. The architect should use examples of previously coded SOA components compliant with those patterns when explaining the requirement to the developer. Design patterns ensure that each installation of a component is consistent (i.e., coded exactly the same way). This ensures that subsequent users of the component will understand exactly how to use the component. The design patterns also en- sure that solutions architects will be consistent and more accurate in their initiative estimations.

There will be many design patterns documented within your SOA reference architecture—perhaps as many as 100 or more components, types of components, and variations of components exist. Unlike development frameworks, you can de- velop your design patterns as you need them. As more SOA components are built, more design patterns will exist.

This puts a significant weight and pressure on your team of architects, especially during the first few initiatives in the early stages of SOA adoption. For these first early initiatives, the team of architects should be addressing and resolving as many of these design pattern requirements as early as possible. They should start addressing them even before the initiative begins if possible.

One way to accomplish this is for the architecture team to review and assess all the approved SOA initiatives that have not started yet. Through this process they can determine what patterns will need to be developed to support the initiatives, how many individual patterns are needed for multiple initiatives, and which design patterns will be needed first based on projected project start dates.

It is absolutely essential that the architects have a center of excellence (COE) at their disposal to conduct proofs of concepts to test out their pattern designs and prove their viability in terms of accuracy and abilities (reliability, scalability, interoperability, adaptability, flexibility, etc.). The COE should include versions of all the technology platforms used in production and development tools used by the developers. It can also be used to recertify existing deployed components on newer versions of the technology platforms before they are upgraded. Components for development frameworks should be developed, tested, and certified in the COE as well.

Architects will often find flaws in how a technology actually works versus how it was documented. Or architects find that features that would make the technology more effective or easier to use are missing. This may initiate many discussions with the vendors’ engineers and product development teams. New patches may be delivered by vendors to fix these problems or accommodate the capability identified.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

66 Architecture Framework and Methodology

The last place you want to discover these flaws is during the development phase of a real project. Flaws discovered at this stage will more than likely jeopardize deliv- ery of the project. It is critical to find and resolve flaws in a certification environment as early as possible.

Design Standards Unlike development frameworks and design patterns, your archi- tects do not write design standards. They already exist. There are many standards and many standards bodies that govern them. In many cases, there are choices or alternatives for standards to use for the same purpose. In most cases, multi- ple versions of the standards are available and supported. You need to determine which standards you will adopt in your architecture and which versions you will support.

The decisions on which design standards to support, however, may not be 100 percent at the discretion of the architects. Support for these standards may or may not be embedded in the technologies you use. If you have a lot of business partners and a lot of system interaction with those business partners, you need to understand what standards they support or will be willing to support. (This is especially important for standards like security assertion markup language [SAML].)

Like design patterns, you will not need to have all your design standards defined before you start your first initiative. Very much like patterns, however, you need to have them defined and documented before they are needed by an SOA initiative. It is hoped that many of these standards have already been adopted. Documentation for support of the SOA reference architecture for adopted standards should be easy to determine.

The same process used when assessing design patterns should be used to iden- tify what standards will be needed. The COE should also be used to test out these standards and their versions for the same evaluation and certification reasons that were applied to design patterns.

CONDUCTING CODE REVIEWS AND IDENTIFYING VARIANCES Code reviews are conducted by project architects during development to validate that artifacts were applied correctly to the code produced. One of three conditions can come out of a code review:

1. The code was written accurately and compliant with the architecture require- ments.

2. For some reason (either technical or nontechnical), the architecture standard, pattern, or framework needs to be altered or violated.

3. A unique or first-time condition arises where no previously established standard, pattern, or framework exists.

All other instances of noncompliant code should be rewritten to make them compliant. As more coding experience is gained, the percentage of compliant code should increase.

Approval for a variance to an architectural framework, pattern, or standard must be obtained from the SOA Technology Governance Committee. This may occur, for example, when a partner’s technology or the technology used for a purchased business application cannot support an enterprise framework, design pattern, or standard.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 67

MAINTAINING THE REFERENCE ARCHITECTURE DOCUMENTATION The metadata and ar- tifacts associated with the development frameworks, design patterns, and design standards in the enterprise SOA Reference Architecture framework are managed and maintained by the enterprise architects. These architects have the custodial respon- sibility for maintaining framework and design pattern and standard currency and accuracy, and any changes to them must be made by the enterprise architects. The enterprise architects are also responsible for maintaining the horizontal integrity of these artifacts with the SOA business architecture and the SOA platform architecture, ensuring that changes to the logical reference model are reflected in the conceptual (business) and physical (platform) architectures as well. The reference architecture metadata and artifacts associated with the logical views of implemented SOA com- ponents are produced by the solutions and project architects, who also maintain their currency and accuracy. In other words, the enterprise architects maintain the overall SOA Reference Architecture framework and all the development frameworks, design patterns, and design standards associated with it. The solutions and project architects maintain all the logical views of the specific implemented instances of the SOA components in the environment.

Enterprise SOA Platform Architecture Framework

We discussed that the Business Architecture framework was the conceptual view of SOA and the enterprise SOA Reference Architecture framework was the logical view. The enterprise SOA Platform Architecture framework represents the physical view of SOA.

The enterprise SOA platform architecture identifies the specific products and technologies that exist at each layer of the architecture. It maintains all the physical aspects of the deployed SOA components, including the source and compiled code associated with the SOA components and the physical platforms where the deployed code operates. It also contains the artifacts associated with the monitoring and management of the SOA components in production as well as the service-level agreements (SLAs) for the SOA components in the production environment.

The artifacts also include the physical representations of the physical connec- tions and platforms between interoperating components. While the enterprise SOA reference architecture tells developers exactly how to code for each platform and how to design and code the integration with the specific technology platforms above it and below it, the enterprise SOA platform architecture describes the physically im- plemented instances of those developments in production.

The enterprise SOA platform architecture is focused on the physical attributes of the IT infrastructure that are important to SOA. The intent is not to clutter the physical architecture framework with the entire portfolio of IT physical assets such that it merely duplicates the documentation maintained in the existing enterprise architecture framework. It is recommended that physical artifacts around the com- pany’s networks, server farms, storage area networks, and so on be maintained and managed through the traditional framework. The physical platforms captured and managed through the SOA Platform Architecture framework are the technologies used to support the production SOA applications. These platforms include the:

� Channel platforms (e.g., the Web server product, the IVR technology, the Windows and browser clients supported, etc.).

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

68 Architecture Framework and Methodology

� Business process/composite application platforms (business process manage- ment system [BPMS] technology, orchestration technology, work flow technol- ogy, application server technology, etc.).

� Business services platforms (enterprise service bus technology, service registry technology, service repository technology, etc.).

� Legacy integration platforms (enterprise application integration [EAI] messaging technology, including message transport and message broker, and data manage- ment technologies, including extract-translate-load [ETL] tools and data “hub” tools).

In addition, the platforms for the enterprise development framework compo- nents should be captures here as well. These include:

� Security authentication and authorization technologies including supporting technologies, such as directory services and the lightweight directory access protocol (LDAP).

� Provisioning technologies. � Logging, audit, and tracking technologies, including analytical and reporting

tools. � Archive, retention, and retrieval technologies. � Document management and database management technologies. � Business analytical, business intelligence, and business reporting technologies.

To continue our previous example, a customer using a customer portal as de- scribed on business architecture diagram translates to a constituent with the role customer using a portal framework invoking JSR 168 portlets and enterprise SOA se- curity components in the enterprise SOA reference architecture. This in turn, would be reflected in the SOA platform architecture as a user accessing, for example, a SunOne portal server where the customer portal application code has been de- ployed and, after being authenticated by the SOA security services on top of a SunOne access manager application, invokes deployed orchestrated services on a BEA AquaLogic service bus through a portlet service stub.

STRUCTURING YOUR ENTERPRISE SOA PLATFORM ARCHITECTURE The graphical repre- sentation of the enterprise SOA platform architecture for your company will be unique to your company. All the layers within the SOA∼EAF should be represented in the platform architecture, but the technology components that you have deployed to perform those capabilities will be unique. For this reason, showing you an im- plementation example may be more confusing then valuable. Some companies may use multiple products with capabilities focused on a single layer of the architecture framework. Other companies may use a single product or a single vendor’s product suite to support multiple layers of the architecture.

The Application Integration layer and the Business Service layer together may be referred to as the enterprise service bus and supported by one product or suite of products from a single vendor. In some cases, the Integration layer may include a legacy investment in a traditional middleware infrastructure like IBM WebSphere MQ series, a collection of integration capabilities built on open messaging technolo- gies like JMS, or off-the-shelf integration drivers such as Java database connectivity ( JDBC) and open database connectivity (ODBC).

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 69

There are positives and negatives to whatever options you choose. Presenting an example of one approach may put an inappropriate (positive or negative) perception of that implementation in your mind. What is more important is that you are able to map support for each layer and sublayer of the enterprise SOA reference architecture to the capabilities of the technologies in the enterprise SOA platform architecture and the design patterns and design standards have been vetted and certified on those technologies.

PURPOSE OF THE ENTERPRISE SOA PLATFORM ARCHITECTURE FRAMEWORK In addition to the enterprise SOA reference architecture, the enterprise SOA platform architecture is the other tool used by the architects and developers to design and develop the detail physical specifications of the solution. For each SOA component design specification, the architect describes to the development team the specific platform used to code, test, deploy, and manage the component. This information, along with the specific development frameworks, design patterns, and design standards specified within the enterprise SOA reference architecture, provides project architects and project developers with everything they need to technically develop architectural compliant solutions.

The enterprise SOA Platform Architecture framework is also used by the so- lutions architect to validate the capabilities and quality of service for existing SOA components that may be targeted for reuse or leverage in their new initiative. Project architects can extract the code and configurations of deployed SOA components as examples to provide to developers coding similar SOA components using the same design patterns and standards. These provide the developer with a real-life example of how a similar component was developed and physically deployed in the past. The artifacts in the SOA reference architecture can provide examples of how previ- ously developed SOA components were designed. The artifacts of the SOA platform architecture can provide examples of how previously developed SOA components were deployed into production and how they are maintained and supported in production.

The enterprise SOA platform architecture is also the primary tool used by the enterprise SOA infrastructure and capacity architect to manage the SOA infrastruc- ture and capacity. The enterprise SOA infrastructure and capacity architect uses these artifacts; the network, server, and direct access storage device (DASD) artifacts from the EA framework; and the IT management and monitoring tools used in the company to analyze, simulate, and project capacity issues and needs. At a global level, this analysis is conducted on an ongoing iterative basis to proactively manage the capacity requirements of the production environment. At a portfolio level, this analysis is also conducted for each SOA initiative to ensure that any added capacity to support the initiative will be there when needed and that funding for that capacity is covered. Finally, at a development level, this analysis is conducted to validate that the component as designed and the capacity as planned will support the capacities and SLAs specified in the requirements.

The metadata and artifacts associated with the Enterprise SOA Platform Archi- tecture framework are managed and maintained by the enterprise SOA infrastructure and capacity architect in conjunction with the IT operations and data center teams. They have the custodial responsibility for maintaining metadata and artifact currency and accuracy; any changes to them must be approved by the enterprise infrastructure

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

70 Architecture Framework and Methodology

and capacity architect. The enterprise SOA infrastructure and capacity architect is also responsible for maintaining the horizontal integrity of these artifacts with the SOA reference architecture and the SOA platform architecture, ensuring that any business definitions or concepts impacted by a change to the reference or platform architecture are identified and reflected in the business architecture.

Leveraging the Artifacts from All the SOA Frameworks

From an architecture practice perspective, you need to pull together and manage all the SOA frameworks. You need to be able to track and manage all the metadata and artifacts vertically through the layers of each framework and horizontally across the frameworks within each layer. The artifacts also need to be identifiable to the specific domain layer they support and structured so that each sublayer in the domain is isolated and can be identified easily and readily. The architects also need a way to identify the relationships among all the interrelated SOA components supporting the applications in the production SOA environment. For example, they must be able to identify all the SOA components that make up the capabilities provided by the customer portal application, from the channel down to the integrated legacy applications that integrate into the customer business services. They need to be able to show these relationships conceptually to the business, logically to the developers, and physically to IT operations.

In order to facilitate an SOA approach, we need a framework that can quickly show all the leveraged and reusable assets in our portfolio. We need a framework with artifacts that can tell us how those assets have been leveraged and reused in the past and how they can be leveraged and reused to support new requirements. In other words, we need a way to quickly understand all the logical and physical capabilities that exist (or need to exist) in our environment to support their con- ceptual business needs. The business architecture of an initiative is a conceptual representation of what the business wants. The enterprise SOA reference architec- ture is the logical representation of how to deliver those needs, and the enterprise SOA physical architecture is the physical representation of what was built and where they exist in production.

The business architecture for a new SOA initiative may reflect a desire to pro- vide the capability for customer constituents to use the IVR to check order status using the “GetOrderStatus” service that they were told already exists. The enterprise SOA reference and platform architectures will reflect that, yes, the “GetOrderStatus” service exists, but it is currently deployed only through the legacy client channel of the CRMS desktop application. The enterprise SOA reference architecture could also be used to represent the logical capabilities that would be needed to provide this service to the IVR channel. These capabilities would reflect:

� The requirement to build a new service delivery contract stub for the “GetOrder- Status” service using the invocation format and protocol supported by the IVR technology.

� The need to develop the IVR scripting necessary to add the new touch tone and voice recognition logic to handle and process the order status request, including converting the service reply from text to voice.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 71

� The need to script the authentication and authorization security requirements and integrate to the enterprise channel security module if needed (i.e., the first customer service delivered through the IVR that requires an authentication).

The SOA platform architecture would be used to identify:

� Any additional technology platforms needed to support the initiative (e.g., the purchase of a channel technology like an IVR or portal server platform).

� Any increases needed in the physical infrastructure (servers, CPU, memory, disk, hub, blade, etc.).

� Any increases in licensing fees for the platforms (e.g., database management systems licenses, Web application server licenses, etc.).

Hence the business can leverage its business architects to lay out a need or an opportunity using the Business Architecture framework, and the solutions architect can respond back quickly with IT’s ability to meet that need using the information from the enterprise SOA reference and platform architectures.

This can and should be an iterative process. The business should constantly be questioning and looking for new opportunities to leverage the IT assets to im- prove, expand, or enhance their business. Business architects should be constantly working with the solutions architects to understand what exists and what is new in the SOA asset portfolio. They should be evaluating these assets in terms of their knowledge of the business functions, capabilities, and strategies of the business unit they support. They should be drafting straw-man business architecture diagrams of those opportunities and reviewing them regularly with their business unit, coming back with new or modified opportunities based on feedback and input.

When you are able to conduct this iterative process with your business, you are achieving the ultimate benefit of SOA. The architecture practice is leveraging SOA∼EAF as a tool to work hand in hand with the business to help it take advantage of as many opportunities as possible as quick as possible. The IT assets are not seen as a bunch of applications and databases locked in a room somewhere. They are seen as business enablers and business opportunities. This is the transformation from a reactive process of looking at the IT portfolio for potential opportunities and efficiencies to a proactive one that identifies the opportunities and efficiencies already built into the portfolio.

This is yet another example of achieving SOA value through an architectural approach. No technical book on SOA or technical implementation approach to SOA will tell you to set up these frameworks and conduct these activities with your business.

The view we want to take of our IT assets from an SOA perspective is twofold. On one hand, we want to know which assets we have leveraged to take advantage of SOA, how that leveraging was accomplished, and how they can be further leveraged. On the other hand, we want to be able to view our assets from the perspective of those that have not been leveraged to take advantage of SOA. Is there an opportunity to do so, and, if so, is there value in doing so? We want to be able to view these assets from both a top-down and bottom-up perspective, regardless of which layer we start at and which layer we drill up or down to.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

72 Architecture Framework and Methodology

Thus, from a top-down representation, we need the ability to extract and present:

� Which channels have been deployed in support of each constituent, and what deployed adapters they use.

� What business processes and business services are available through those channels.

� What legacy systems are integrated into those services, and how they are integrated.

We also may want to represent:

� What channels have been deployed to other constituents but not to this con- stituent.

� What processes and services are deployed through one channel but not the others available to that constituency.

� What business processes and services have been deployed to other constituents but not this one.

From a bottom-up perspective, we may want to extract and represent:

� What integration services support each business service. � What business services are embedded in a business process. � What channels are a specific business process or business service deployed

through. � Who the constituents are who use a specific business process or business service.

We may also want to represent:

� Which legacy applications have no or partial integration capabilities. � Which integration assets have not been integrated with the Business Service

layer.

Understanding these assets in this format is critical to the business architect and solutions architects when evaluating a business requirement. They are also critical for identifying potential opportunities to leverage these assets with their business units. Being able to communicate these capabilities back to the business in terms users can understand is also critical.

Thus, there is no rigid format or structure for storing, analyzing, and presenting the SOA metadata. Just as SOA applications are loosely coupled, SOA metadata needs to be loosely coupled, allowing for an infinite number of dynamically constructed views of that metadata to address a specific business requirement and solution.

The entire purpose of everything we have discussed so far is to facilitate the representation of the system universe from a top-down, consumer-centric view. It also helps to focus the strategy and planning of systems based on the holistic view and needs of the consuming users rather than the individual systems in the portfolio. This is a critical characteristic that results in a model that is a true reflection of the real world, especially when it comes to external consumers.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 73

The good news is that we have the capabilities to allow our customers, vendors, and partners to interact directly with our systems instead of via phone interaction with our employees. The bad news is that how we deliver that interaction can be perceived as effective and efficient or complex and difficult. If the latter happens, the chances of that external consumer using the capability again are almost nil. There is a real risk that you will lose them as customers if your competition provides a more enjoyable experience.

Pulling It All Together

This capability to manage all the artifacts from all the frameworks is facilitated through the SOA enterprise architecture framework (SOA∼EAF) and the associated SOA∼EAF methodology. This framework integrates the SOA business architecture, the enterprise SOA reference architecture, and the enterprise SOA platform architec- ture into one model. The model also incorporates the business unit business plans and corporate strategy. Exhibit 5.1 depicts this SOA enterprise architecture frame- work. It is the overarching tool used by the enterprise architecture SOA team to manage the SOA practice.

From an SOA enterprise architecture practice perspective, we need to know the entire legacy systems of record. We want to promote the isolation of those legacy systems to the largest degree possible by encapsulating their functionality at the lowest functional level possible. We want to isolate that encapsulated functionality from its physical characteristics by providing logical access at the integration layer. We want to use this logical functionality to build services that perform discrete units of work. We want to be able to provide access to these units of work individually or incorporate them into higher-level business processes that use several of these services to perform more complex business activities. We want these services and processes to be accessible through as many channels as possible to any constituent that needs to use them.

We need to explain all of this to the business in terms understood by the business. We need to explain what is required of the SOA application designers in terms that the designers understand. Finally, we need to explain the requirements to the application developers in terms that they understand. We also have to justify the approach to the business unit leaders and the corporate executives.

A DYNAMIC AND MULTIDIMENSIONAL FRAMEWORK The model should be able to be sliced not only horizontally and vertically, but also dimensionally. You should have the ability to create a view that reflects the specific pieces that make up an initiative that is in production or in development. The Horizontal Constituent Strategy Sub- committee of the SOA Portfolio Plan Governance Committee (defined in Chapter 8) may request a view of all the capabilities in production for a specific constituent and metrics around their utilization of those capabilities. Other examples of dimensional slices of the frameworks metadata include:

� All capabilities delivered through a specific channel. � Services being delivered to multiple constituents. � Services being delivered through multiple channels.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

74 Architecture Framework and Methodology

The more flexibility you build in, the greater the value it returns. As architects with years of systems experience, we readily see the value in our

technical artifacts and metadata. What we often fail to realize is that the business does not have our technical expertise and experience and does not view them the same way. This framework gives us the capability to cross-reference all our technical capabilities to the business need, the corporate strategic value, and, most important, the business description of those capabilities.

Through this framework and methodology, the architecture practice and IT in general will learn a new way to leverage this technical data by repackaging the infor- mation into dynamic, business-friendly models with business-friendly terminology that the business can easily understand and act on.

Layers of the SOA∼EAF Framework The previous section described the columns of the SOA∼EAF. The next sections will define the rows of the SOA∼EAF.

CONSTITUENT DOMAIN Referring back to Exhibit 5.1, the highest layer of the SOA framework is the Constituent Domain. Under SOA, the plan or scope always starts with the service consumer (i.e., the constituent). The best technical solution will fail if it does not give service consumers what they want, how they want it, and when they want it. This is one of the major cultural paradigm shifts we are attempting to achieve to support an SOA enterprise architecture approach. This is the cultural transformation from inside looking out to outside looking in.

If you think about it, most of the legacy business applications were built to be used exclusively by employees. In fact, most were designed to be used by a limited number of employees. If anyone else, internally or externally, needs infor- mation from those systems or processes a transaction against those systems, they did so through the individual authorized to use the system. This is why the dilemma depicted back in Exhibit 3.2 exists.

The whole intent of SOA is to create an environment where anyone potentially has the authority and ability to get the information or process the transaction directly, eliminating the “facilitating employee” as quickly as possible at the lowest cost possible. As explained in Chapter 4, once the investment is made to build a channel for a constituency, the ability to quickly deploy new services over that channel has tremendous value from a competitive and financial perspective.

To go back to the Starbucks example, once it established the shipping, billing, and collections capabilities to ship the coffee to retail outlets, it can sell any of its other products (e.g., coffee cups and travel mugs) through that channel. Similarly, once you have built the framework to deliver secured services to your customers over the Web channel, the ability to give them access to a new service can be as simple as adding the service to their defined role privileges and exposing the URL for the service on their authenticated landing page. Because you have adopted an architectural approach to SOA, this process can be as simple as a configuration file change to the role and policy files of the authentication and authorization service and a redeployment of the landing page.

The corporate strategy identifies all the constituents and their relationships. Each business unit defines its business model, specifying the relationships it has with those

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 75

Constituent Domain

Corporate Business Exposure Strategy

Corporate Goal/ Strategy

Cross-Reference

Business Unit Plans

Cross-Reference

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Business Model

Constituents Roles Users

EXHIBIT 5.5 SOA∼EAF Constituent Domain Layer

constituents. The business models drive the definition of the constituents in terms of what they are allowed to do when interacting with the company.

These business rules for access authorization to the services of the company translate into roles and privileges logically applied within a security authentication and authorization framework. These are implemented as user security profiles on the security platforms. The cells of the Constituent Domain layer are depicted in Exhibit 5.5.

BUSINESS CHANNEL DOMAIN The Business Channel Domain layer is included in the SOA∼EAF to reflect the importance of managing channels as a distinct set of SOA assets. Referring back to the Starbucks example, when the company decided to sell its coffee to retail outlets, the coffee did not magically appear on the shelves the next day. Starbucks did not sign a contract with a shipping company to ship it to one specific retail outlet in one specific location. When it decided to use these outlets, Starbucks planned and built out the entire delivery channel to do so.

Yet when companies decided to use the Web as a channel, they treated each application as its own delivery channel and kept throwing “stuff” out there until frustration and rejection reached such a level that they were forced to rethink their strategy. Users internally and externally did not want to log on to multiple systems and remember multiple user IDs and passwords. To users, it seemed that the systems were dictating their work flow rather than their work flow dictating the systems.

This spawned a new set of products designed to provide single sign-on across multiple applications. In reality, this was treating the symptom rather than the prob- lem. Single sign-on eliminated the need to remember multiple passwords but did nothing to solve the complexities and inefficiencies placed on the user’s work flow.

Another set of technologies that tried to get at solving these problems was portal technologies. Unlike single sign-on, portal technologies required a complete rewrite of the Web applications. Portal technologies were a way to bring all the functionality provided by the separate applications under one umbrella, allowing the entire user experience to be managed and maintained through a single user session.

Portals are an excellent solution to the problem because they incorporate some of the very capabilities we have identified as channel capabilities. They provide a way to authenticate the user, set up and manage the session while the user employs the channel, and restrict and authenticate access to individual services within the portal. Hence a portal can be thought of as a Web channel adapter technology that works well with authentication, authorization, and personalization frameworks for delivering services to a constituent through the Web.

The strategies for channels and their use should be established at the highest strategic level of the corporation. Channels designed to support SOA are expensive

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

76 Architecture Framework and Methodology

Business Channel Domain

(Enterprise)

Horizontal Constituent Experience

Corporate Goal/ Strategy

Cross-Reference

Business Unit Plans Cross-Reference

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Business Distribution

Mechanisms and Partnerships

Contract/ Interaction

Mechanisms

Channel Models

Production Channel

Connections

EXHIBIT 5.6 SOA∼EAF Business Channel Domain Layer

to implement, but the value they provide by allowing you to flood them with all existing services results in a high ROI. They have to have this strategic value to warrant the investment. Developing an EDI channel to support one EDI transaction is not a wise investment. In the early stages of SOA adoption, strategic decisions for focusing limited spending on less services and more channels versus more services and less channels will need to be made. Line managers at a tactical project level should not make these decisions.

These decisions drive the business unit’s plans for supporting the channels with high strategic value to the corporation. Specific requirements for use of these channels are documented and used to develop the logical models and frameworks for implementing them. The cells of the Business Channel Domain layer are depicted in Exhibit 5.6.

BUSINESS PROCESS DOMAIN The Business Process Domain layer is the layer that aggregates business services and business flows into complex business processes. These are represented by composite applications within a specific business domain. Hence the Sales Domain can have quoting services, ordering services, payment services, and shipping services all part of its composite application service. While this layer, on the surface, looks very much like the old Legacy Application layer, it is distinct in many ways.

Within the Legacy Application layer of our architecture, we identify that quoting and ordering are part of one legacy application. Payment is a second legacy applica- tion, and shipping is a third. Under the old legacy model, an employee, trained and authorized in all three of these applications, navigated the customer order process from quote to shipment using these three applications and their three separate user interfaces. The complexities of understanding and navigating all of these systems were hidden from view of the customer on the phone.

Under the new model, the composite application hides the existence of these three systems and manages the “quote to ship” process utilizing a set of discrete logical services in a work flow. Under the old model, the payment application was owned by finance and the shipping application was owned by distribution. They had to approve the access privileges of every sales employee who used these systems and often required that they had training on how to use the entire application even though they used only one small function.

Under the new model, the “CheckPaymentStaus” service has been defined with the roles that are allowed to use the service as specified by Finance. One of those roles is “Sales Order Administrator.” Similarly, the “CheckShippingStatus” service has been defined with the roles that are allowed to use this service as specified by dis- tribution. One of those roles is “Sales Order Administrator.” Under the new model,

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 77

a Sales Order Administrator automatically gets access to the payment and shipping services he or she needs, but only the services needed, not the entire payment or shipping application. Nobody in finance or shipping has to train a new user and set up security.

Under the old model, three different logons and user interfaces were required to do the job. Under the new model, a single logon and user interface is used. Under the old model, the only way to access each of the user interfaces was through the proprietary presentation layer of each application. Under the new model, the user can use a telephone voice recognition interface, a Web portal, or a customer services Windows client to access and use the same business process.

This is a different approach from the model that builds a new monolithic stovepipe application that duplicates the business logic. Even new Web applica- tions that use the integration layer assets to get the underlying business functionality but do not follow an SOA architectural approach will have their own mechanism for controlling the presentation and flow of the business process. The application will have its own mechanism for structuring, presenting, and managing the display of the process. The application will probably duplicate some of the field validation logic associated with those displays. Under the SOA approach, these functions are handled once by the business process within the composite application.

The corporate strategy for the business practice and business operational model that represents how the company operates in the future is documented in the cor- porate strategy cell. The “Service Consumer” horizontal strategy leaders within the business units document their responsibilities for delivering the processes within the business practice that delivers the new operational model capabilities. The detailed requirements of specific business processes, many of which will transcend multiple business units, will be defined. These will be translated into logical process models to be developed and deployed into production. The cells of the Business Process Domain layer are depicted in Exhibit 5.7.

BUSINESS SERVICE DOMAIN The Business Service Domain is the next layer in the framework. This layer will ultimately become the most critical layer of the frame- work. It represents the lowest layer of assets designed to be fully compliant and supportive of the SOA. This layer represents the base portfolio of assets with the highest level of reusability. It also is the common shared demarcation point between the service providers and the service consumers.

The ultimate goal is to get those in the business who were traditionally seen as the owners and maintainers of the legacy business applications to focus on every- thing from this layer down. In other words, their accountability is to manage the plan for enabling the legacy application assets to support a full set of granular services

Business Process Domain

(Composite)

Corporate Business Practices

Corporate Goal/ Strategy

Cross-Reference

Business Unit Plans Cross-Reference

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Business Unit

Responsibilities

Business Processes

Process Models

Process Implementations

EXHIBIT 5.7 SOA∼EAF Business Process Domain Layer

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

78 Architecture Framework and Methodology

that can be leveraged across the enterprise. They are no longer focused on the user interface or defining one specific, rigid, and hard-coded way to process those ser- vices. Instead, they recognize that lower-level, more granular capabilities embedded in their hard-coded application have value to other business entities and business processes. After all, it usually can be proven that these other business entities have acquired this capability through back-door data extraction and duplicated business logic embedded in applications that they now own.

The architects can show these individuals that this new model will actually increase their control over the data in their domain, not decrease it. If they look at all the places the data from the system they think they own, which they believe to be the system of record, has been replicated and all the duplicate business logic that has been written to process that data, do they really think they are in control? They have no visibility or control over the accuracy of the replicated data and duplicated business logic.

They may have authorized the extraction of data from their system from a particular business area for a specific purpose at some point in time, but do they know who is accessing that data? Are they sure that the other business unit did not give the extraction ability to someone else or allow the data to be pulled from its data store with a new extract? In most companies, the path of data from its system of record is almost untraceable.

If you change the business rules within your application (the system of record) to, for example, require the capture of a nine-digit zip code for all customers, are you then guaranteed that all other applications that extracted that customer data will follow suit? Most likely they will not. Even if they were made aware of the change, they might not have the funding needed to make the change in their copy of the data. So when a major customer complains that it continues to get mail with a five- digit zip code when you contractually agreed to send all mail with a nine-digit zip code, it will be traced to some obscure individual in some other department who, with all good intentions, generated mailing labels from a department application that stores only a five-digit zip.

Under the SOA paradigm, the goal is to have everybody use the same service regardless of where and how they use it. Thus if an “Extract Customer Addresses” service existed and those addresses were extracted directly from the system of record, everyone would have a nine-digit zip extract. The older version that produced a five- digit zip could be shut down for applications consuming the service’s presentation layer or allowed to exist for a limited period of time until the applications consuming the service at the business logic layer could adapt to the field change. For those applications and services that were built correctly, if the XML structure and the presentation layer handling of that structure is dynamic, there may not be any modification needed.

While the service providers are not concerned with the delivery and presentation of the service, that does not mean they do not own or control the service. They are accountable to ensure that the service functions, properly and accurately, including all validation and audit requirements associated with the back-end system. They also set the policies for who can use the service and how. Thus while they may not know any specific person using the service, they will know that every person will be authenticated and have a valid role that authorizes the use of the service. The role may also limit how or when people use the service. The role may result in

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 79

only some of the options for using the service being exposed. These are all controls that can be specified by the service provider and coded within the Business Service layer and enterprise SOA security framework.

The businesspeople responsible for providing the service actually have a lot to gain by adopting and supporting this approach. They can be much more confident about the use, accuracy, and exposure of the data and functions within their domain. The business as a whole benefits by:

� Improving overall accuracy as more people use the same service with a single set of business rules and a single data source.

� Reduction in physical and human resources as more and more of the old re- dundant solutions are decommissioned.

The Integration Domain and the Business Service Domain layers combined can be referred to as the enterprise service bus (ESB). Ideally architects would like a single ESB platform to maximize efficiency and cost. This is not always a reality. What is important is that a preferred platform is identified and that all in-house development leverages that platform. Whatever platforms exist or are preferred, a good SOA architecture will specify a platform architecture and framework that adds layers of abstraction and isolation from the physical attributes of the underlying technology. A good architecture will ensure that any changes to technologies above, below, or inside the ESB will have little or no impact on the deployed set of services, the applications that use them, or the applications that feed them. Enforcing the same development frameworks, design patterns, and design standards to services built on other ESB technologies (e.g., services embedded in a purchased or leased application) ensures their interoperability with your services and frameworks. It also allows these services to be ported to your ESB if the need arises. Replacing the customer credit system should have no impact on any application consuming the “Get Customer Credit” service. Replacing the ESB used to build and deploy the “Get Customer Credit” service should not impact the service for consumers who use the “Get Customer Credit” service.

The amount of success you have in achieving the promoted values of SOA will be directly impacted by how effectively you manage these two layers. That is why they are pulled out and so prominently represented in the framework. Their management from an architecture practice perspective is as important as any other aspect of the architecture portfolio when it comes to SOA.

The corporate strategy identifies the key service capabilities needed to achieve the strategy. The business units define their requirements for participating in or supporting those services. This drives the definition of each of the business services, which in turn drives the architectural model for developing those services that are then deployed into production. The cells of the Business Service Domain layer are depicted in Exhibit 5.8.

INTEGRATION SERVICE DOMAIN Like most companies, yours probably has millions of dollars invested in legacy applications. Also like most companies, the belief is that these applications do a (relatively) good job at supporting the core business capabilities they were purposed for. The less favorable perception of these systems lies in their flexibility and adaptability. They lack flexibility to participate and add

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

80 Architecture Framework and Methodology

Business Service Domain (Unit)

Corporate Business

Capabilities

Corporate Goal/ Strategy

Cross-Reference

Business Unit Plans Cross-Reference

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Business Unit Activities

Business Services

Service Models

Service Implementations

EXHIBIT 5.8 SOA∼EAF Business Service Domain Layer

value to larger, more complex business activities without the intervention of a highly trained human to manually bridge their capabilities to those of other systems. They are also not very adaptable to changes in business rules or processes; major funding for IT resource involvement is required to effect the changes. Once again, these are the very constraints highlighted in the introduction of this book that are driving us to a new and better way of doing what we do.

The architecture approach to SOA involves a conscious and concerted effort to relegate the legacy applications to a level where their rigid and restrictive capabilities around adaptability and flexibility are mitigated but their competency to perform the core business functions they support is leveraged. Any SOA strategy that expects to succeed has to leverage the legacy applications. The cost and time it would take to holistically replace the total functionality of these applications is so large that we do not even go there in our discussions. How effective an approach you take architecturally to this integration is also key to how successful you will be. Attempting SOA without an architectural approach to legacy integration may have some short- term early successes, but this approach will eventually fall under the unmanageable and unsustainable weight of traditional approaches.

What we do not want to leverage in a legacy application is the proprietary custom user interface. What we do want to leverage in the legacy application is the data it contains and manages and the business rules and conditions that are applied when creating, reading, updating, or deleting the data. This includes what data must change together, in what order the data changes must occur, and what changes are required based on other changes. So, we need an approach to expose the data and business logic outside of the proprietary user interface framework. We cannot, however, violate any of the authorization, validation, logging, and auditing requirements maintained and enforced by the legacy application. We also want to make sure that the approach we take for exposing these capabilities and maintaining the integrity is consistent, not only within a specific legacy application but across all legacy applications. We want to make sure that while each legacy application and the payload in each integration may be different, the format of that integration mechanism and the naming conventions and standards used are consistent for every integration. What we are specifying here is an architectural approach to integration, one where development frameworks, design patterns, and design standards exist to govern and enforce these characteristics. This helps to make future reuse of these integration assets easier and the development of new integration assets faster.

Thus, under SOA, the legacy application integration strategy and architecture is critical to effective SOA development. As you move up the architectural framework (from integration to channel), the physical number of assets, especially reusable ones, will decrease. You may have hundreds of integration assets but only four

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 81

channel alternatives. Therefore, the less architectural focus you have on developing the lower layer assets, the less reuse and leveragability you will have on the biggest population of assets. Under SOA, integration must have its own domain and be a prominent, recognizable layer within the framework with heavy focus on its strat- egy and management. This is true for all horizontal views of the integration layer (conceptual, logical, physical, and strategic).

As a final point, it is vital to recognize that, while this layer will have high visibility and have critical importance as you embark on the SOA path, its visibility (especially to the business) will diminish over time. That is because these assets, while leveraged, were not constructed as business service assets. They were con- structed as application integration (AI) assets. Eventually one of two things will happen to these assets:

� They will be wrapped in a higher-layer business service technology with this layer taking over the visibility and focus.

� They will be decommissioned by new replacement components built with the higher-layer business service technology integrated directly to the underlying legacy applications.

When this happens, most of the business and reference architecture focus will shift up to the Business Service Domain layer. Ultimately this is the lowest layer that you want the business to focus on. This is the layer where all the discussions are around a conceptual and logical service rather than a physical representation of a legacy connection point. This is the layer where semantic data models and structures based on industry standards, when available, have replaced the proprietary and application bounded data sets of the integration layer.

The business-represented community that is set up under the governance model defined in Chapter 8 to help the architecture practice strategically govern this layer is the vertical provider-centric subcommittee within the SOA Portfolio Plan Governance Committee. The horizontal consumer-centric subcommittee assists the architects with the strategic governance of the channel, process, and service layers of the architec- ture. The vertical provider-centric subcommittee helps the architects strategically manage the integration service layer of the architecture. Governance at this level will be more likely to support the development of sharable and reusable integration assets using an integration technology and framework rather than a quicker and cheaper custom-built one-off interface.

Integration Layer Development Frameworks Another key component of the integration layer architecture is the presence of development frameworks to define the integra- tion approaches. These frameworks can include definitions around:

� Using a common shared set of code translation tables to augment the request and reply data sets with user-understandable translations of data codes stored in the legacy applications.

� How to handle aggregation when the population of a specific set of data is split across multiple systems of record.

� Mechanisms to support synchronous and asynchronous communications.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

82 Architecture Framework and Methodology

� Queuing and latency support for integration with legacy applications that do not support 24/7 availability.

� Security framework for pass-through of authentication and authorization cre- dentials required by the embedded security system of legacy systems.

These are a few of the architectural considerations that should be defined and applied to all the integration components developed.

Integration Service Domain Cells The corporate strategy should provide direction on how legacy applications need to support the SOA approach and which of these systems have the highest strategic value to the company. The corporate strategy also establishes the policy for adoption of industry standard transaction and data formats at this layer. This includes the semantic models published by standards bodies (e.g., EDI), industry regulatory bodies (e.g., HIPAA),1 or industry-specific consortiums (e.g., ACORD).2

The business units augment this strategy by defining the data and transactional capabilities embedded in these systems and their weight in terms of their busi- ness value. They also define the specific business requirements for the integration layer, including the rules for mapping and managing their proprietary formats to the standard models and the priority for exposing and isolating these capabilities.

Architects develop the logical approach for developing integration assets to meet these business requirements, including the development frameworks, design patterns, and design standards applied when building these capabilities. Ultimately these integration assets are deployed into production utilizing the integration tech- nologies and platforms. The individual cells of the Integration layer of the framework are depicted in Exhibit 5.9.

LEGACY APPLICATION DOMAIN The Legacy Application Domain layer is where all the artifacts associated with the legacy applications that are integrated with or need to be integrated with the SOA applications. From a corporate strategy view, the framework needs to identify the strategic direction for modernization of these applications. For those on platforms identified as at risk by the corporation and documented at the Legacy Platform Domain layer, the strategy for replacement of these applications should be defined at this layer. For those on platforms that are not at risk, the strategy for how those applications need to support the business going forward needs to be documented. This is not a technical strategy; it is a business strategy. Strategic statements, such as “The application needs to be more flexible and adaptable to business changes” or “Reduce the amount of money and time it takes to change the application,” are examples of the contents of this cell.

Service Integration

Domain (Isolation)

Legacy Application Leveraging

Strategy

Corporate Goal/ Strategy

Cross-Reference

Business Unit Plans Cross-Reference

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Data and Transaction

Source Plans

Integration/ Isolation

Requirements

Integration/ Isolation Approach

Integration/ Isolation

Implementations

EXHIBIT 5.9 SOA∼EAF Service Integration Domain Layer

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 83

Legacy Application

Domain (Encapsulation)

Legacy Application Modernization

Strategy

Corporate Goal/ Strategy

Cross-Reference

Business Unit Plans Cross-Reference

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Utilization Plans

Conceptual Legacy Application

Usage

Logical Legacy Application

Usage

Physical Legacy Application

Usage

EXHIBIT 5.10 SOA∼EAF Legacy Application Domain Layer

Based on the stated strategies, the business units should develop their plans for how they will utilize (or not utilize) these applications in the future and how they will prioritize the efforts to modernize them. The business architects should assist in this process by extracting conceptual models of the legacy applications’ monolithic capabilities into a business architecture diagram.

Logical approaches to these modernization views can be developed and ul- timately implemented as enhancements to the application or displacement of the functionality through the use of a newer technology.

The cells of the Legacy Application Domain layer are depicted in Exhibit 5.10.

LEGACY PLATFORM DOMAIN The Legacy Platform Domain is the layer where all the artifacts associated with the infrastructure supporting the legacy non-SOA appli- cations are captured and maintained. The documentation maintained in this layer should be for only those legacy applications that have been or will be integrated into the SOA architecture. If there is no plan or need for the application to be ex- tended or leveraged by SOA, keep any architectural documentation you have on the application in your EA framework where they already exist. This will eliminate clutter and confusion by both the business and IT as these assets are addressed and modernized or migrated.

From the corporate strategic perspective, the business focus should be on pro- viding direction for an obsolescence mitigation strategy. Many legacy systems, espe- cially core mission-critical applications, are extremely large and took many years and lots of money to get to where they are today. Every business application, however, will eventually need to be replaced. Most often this will be driven by obsolescence or by ever-increasing maintenance and support costs of the platforms underlying those applications. Eventually all platforms will reach an obsolete status, and the cost of maintaining these applications on these platforms coupled with the cost of keeping these applications current with the business needs will force a change. The corporation needs to set forth a strategy that explicitly addresses the modernization of these platforms, no matter how expensive their replacements will be or how long it will take to replace them.

The business units must then develop support plans to replace these legacy platforms over time as the applications that run on them are modernized or replaced. The business units will also need to provide conceptual migration plans on how each system under their control will be replaced.

The architects will need to develop logical approaches for migrating these plat- forms so that minimal impact to the business occurs. They will need to determine if the replacement strategy can be evolutionary, like the examples given in Chapter 12, or require an all-at-once, big-bang approach.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

84 Architecture Framework and Methodology

Legacy Platform Domain

(Migration)

Obsolescence Mitigation Strategy

Corporate Goal/ Strategy

Cross-Reference

Business Unit Plans Cross-Reference

Business Architecture (Conceptual)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

Support Plans

Conceptual Migration

Plan

Logical Replacement

Strategy

Infrastructure Modernization

EXHIBIT 5.11 SOA∼EAF Legacy Platform Domain Layer

Ultimately these migration activities will result in the old physical infrastructure being replaced with new, modern technologies and platforms. The cells of the Legacy Platform Domain layer are depicted in Exhibit 5.11.

SOA∼EAF LAYER SUMMARY The exhibit at the end of each section provides a sum- mary description of the focus of each cell in the framework for that layer. Exhibit 5.12 provides the complete table of all the entries in each cell. These entries help to highlight that the framework is used, not only to reflect current state of the environ- ment but to reflect future states as well. The framework facilitates extracting views to represent any desired state that is, past, present, or future.

Overview of the SOA∼EAF Methodology A framework like the one just described is used to capture data in a structured consistent format so it can be managed and leveraged. It represents the what in terms of our SOA management practice. The methodology tells us the how in terms of our practice. Exhibit I.1, presented in the introduction of this book, is a high-level overview of the SOA∼EAF methodology.

The flow of the methodology is represented in the center of the diagram. It starts with the corporate strategy. From there the process moves to the business units’ strategic plans to support the corporate strategy. This information is used to drive the definition of SOA initiatives that provide the system capabilities needed to achieve those business plans. The initiatives in turn define the SOA projects that develop those capabilities culminating with their production implementation.

Some key points about the methodology are:

� While the corporate strategy drives the business unit plans that in turn drive the SOA initiatives, SOA projects are driven by SOA initiatives but can also influence them.

� Similarly, SOA implementations are driven by SOA projects but can also influ- ence SOA projects and even SOA initiatives.

Both of these conditions are due to the fact that the entire SOA value proposition is based on leveragability and reuse. Therefore, work being performed in an SOA project may not only benefit the initiative that funded the work but may present opportunities for additional capabilities for other initiatives as well. Existing SOA components already implemented and in production will not only influence the cost and effort of projects that are leveraging and reusing them but can drastically reduce

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 85

Legacy Platform Domain

(Migration)

Legacy Application

Domain (Encapsulation)

Legacy Application Modernization Strategy

Legacy Application Leveraging Strategy

Obsolescence Mitigation Strategy

Conceptual Legacy Application Usage

Conceptual Migration Plan

Logical Legacy Application Usage

Logical Replacement Strategy

Infrastructure Modernization

Physical Legacy Application Usage

Utilization Plans

Support Plans

Constituent Domain

Corporate Goal/Strategy

Cross-Reference

Corporate Business Exposure Strategy

Corporate Business Practices

Corporate Business Capabilities

Business Unit Activities

Business Services

Service Models

Service Implementations

Integration Isolation Implementations

Integration/ Isolation Requirements

Integration/ Isolation Approach

Data and Transaction Source Plans

Business Model

Constituents Roles Users

Business Unit Plans

Cross-Reference

Business Unit Responsibilities

Business Processes

Process Models

Process Implementations

Production Channel Connections

Channel Models

Contact/Interaction Mechanisms

Business Distribution Mechanisms and Partnerships

Horizontal Constituent Experience

Business Architecture (Conceptual)

Business Channel Domain

(Enterprise)

Business Process Domain

(Composite)

Business Service Domain (Unit)

Service Integration

Domain (Isolation)

Enterprise SOA Reference

Architecture (Logical)

Enterprise SOA Platform

Architecture (Physical)

EXHIBIT 5.12 All Layers of the SOA∼EAF

the cost and time of delivering entire initiatives. These will potentially influence future submitted and approved initiatives. An initiative that provides significant value to the business by leveraging and reusing a significant amount of existing SOA components will be much cheaper and faster to implement than a similar-valued initiative where fewer SOA components are reused and more new SOA components are required.

Managing and controlling this process flow is the SOA enterprise architec- ture practice. The architects manage and control this process through the publi- cation and enforcement of the policies, procedures, and standards defined within this book.

The policies that need to be developed to transform the company to the SOA paradigm will be created by and enforced through the governance bodies de- fined in Chapter 8. The top two committees (SOA business domain and enterprise SOA portfolio plan) are focused on business strategic policies, and the remaining

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

86 Architecture Framework and Methodology

bodies are focused on technical and operational (tactical) policies. These policies will provide the criteria that will be the basis for governing how:

� SOA initiatives are structured and evaluated. � SOA initiatives are approved and funded. � SOA initiatives are implemented. � Those implementations are monitored and supported.

The policies will also provide the basis for enforcing reuse and leveraging of SOA components.

The procedures represent the detail activities that make up the high-level methodology pictured in Exhibit I.1. These procedures are defined throughout the other chapters of this book. These procedures include the:

� Governance process � Development life cycle � Vendor application evaluation process � Capacity planning and monitoring process � Legacy application modernization and sunset process

In addition to the policies and procedures, specific standards need to be identi- fied to support the SOA architecture. The governance bodies are also responsible for the identification, adoption, and enforcement of these standards. These include not just technology standards but also industry business standards, regulatory standards, legal standards, and so forth.

As you adopt the SOA enterprise architecture model defined in this book, you will be transforming all the processes associated with business application devel- opment. All the standards that apply to business application development will be transformed as well. The basis for these transformed procedures will be the new policies and standards developed to support SOA. These policies and standards will be developed and enforced by the governance committees and governance bodies.

If we look at the model from a side view perspective (Exhibit 5.13), we can see that the SOA EA Practice is the foundation that encapsulates all the other layers of the methodology. This practice is responsible for making everything in the layers above happen. The SOA EA Practice facilitates the development, publication, and enforcement of the policies and standards that drive the SOA enterprise architecture processes. They facilitate setting up all the new processes, educating participants in their roles and responsibilities regarding the processes, and manage their smooth

S O A E A P r a c t i c e

S O A P o l i c i e s

S O A P r o c e d u r e s

S O A S t a n d a r d s

S O A E A F P r o c e s s

EXHIBIT 5.13 SOA∼EAF Methodology: Side View

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

Service-Oriented Architecture Enterprise Architecture Framework and Methodology 87

ongoing operation. Finally, they capture all the documentation and artifacts pro- duced out of these processes; structure and categorize them within the SOA∼EAF; and produce dynamic, adaptable views of the framework information to support processes going forward.

Summary

This chapter defined the SOA∼EAF and all its individual components. It defined the purpose of each of the individual SOA architectural frameworks and their relationship to the other architecture frameworks. It showed how all these are pulled together and managed from an SOA enterprise architecture practice perspective. It also showed how the framework supports and facilitates the business involvement in the strategic direction and value of the IT investments to support their needs and how this strategic involvement plays a critical role in maximizing the return on those investments across the enterprise.

This chapter also provided a high-level overview of the methodology that man- ages and leverages the framework. The remaining chapters provide the information necessary to implement both.

The framework and the methodology are living, evolving entities. This should be obvious, but I will state it to make sure it is consciously understood and enforced. The contents of the framework will change constantly. The use of the content hap- pens continuously. The methodology is constantly operating. The processes defined by the methodology occur over and over. This means that both the framework and the methodology are operational assets that must be managed and maintained daily by operational people; likewise, the outputs and deliverables must be reissued continuously to maintain currency throughout the company. Failure to keep the framework current and the methodology operational will quickly make the process useless and bring a slow death to the SOA enterprise architecture practice. Do not invest all the time and money to get this process up and running if you are not going to invest in keeping it going.

Finally, I hope this chapter begins to show that this new approach and this transformation of how the business and IT communicate and operate with each other results in a more effective, more efficient, and more dynamic company,

In the next chapter, we define how this framework relates to traditional enter- prise architecture frameworks and what is necessary to translate artifacts from these other frameworks into the SOA∼EAF.

Notes

1. From the cdc.gov web site: The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was adopted to ensure health insurance coverage after leaving an employer and also to provide stan- dards for facilitating health-care–related electronic transactions. To improve the efficiency and effectiveness of the health-care system, HIPAA included administrative simplification provisions that required DHHS to adopt national standards for electronic health-care trans- actions. At the same time, Congress recognized that advances in electronic technology

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

P1: OTA/XYZ P2: ABC c05 JWBT251-Sweeney March 26, 2010 18:23 Printer Name: Hamilton

88 Architecture Framework and Methodology

could erode the privacy of health information. Consequently, Congress incorporated into HIPAA provisions that mandated adoption of federal privacy protections for certain indi- vidually identifiable health information.

2. From the official ACORD web site (www.acord.org): ACORD (Association for Cooperative Operations Research and Development) is a global, nonprofit standards development organization serving the insurance industry and related financial services industries. ACORD’s mission is to facilitate the development of open con- sensus data standards and standard forms. ACORD members include hundreds of insurance and reinsurance companies, agents and brokers, software providers, and industry associa- tions worldwide. ACORD works with these organizations towards a goal of improved data communication across diverse platforms through implementation of standards.

C op

yr ig

ht ©

2 01

0. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed