Case Study (Cloud computing)

Chapter6SOA.pdf

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

P1: OTA/XYZ P2: ABC c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

CHAPTER 6 Incorporating Existing Enterprise

Architecture Documents and Artifacts into the SOA∼EAF

This chapter focuses on how to modify and incorporate the enterprise architectureframeworks used within your current EA practice to support the SOA enterprise architecture framework (SOA∼EAFTM). How this is done will depend on what frame- work your EA practice currently uses. This chapter presents a specific example of how to transform and integrate documents within a Zachman FrameworkTM into the SOA∼EAF.

For those of you using other frameworks, such as The Open Group Architecture Framework or Scott Bernard’s Enterprise Architecture Cube (EA3)TM, this chapter provides a general approach and analytical technique for assessing these artifacts and adapting them to the SOA∼EAF. This chapter provides a direct mapping of the Zachman Framework cells to the SOA∼EAF cells. The discussion of each layer of the Zachman Framework, however, includes general concepts and analysis that can be used when evaluating the artifacts of other frameworks.

If you use these frameworks, or variations of them, this section explains how to leverage them to support SOA∼EAF. If your EA practice does not have a tool for capturing and maintaining EA metadata and artifacts, you need to think about getting one or building a homegrown solution. If you have a document management system with a work flow management capability or a team management capability, you may be able to put something together relatively quickly. Even tools like MS Access can be used and can add value if no other alternatives exist. A tool that lets you create dimensions of the data into different views or facilitates a process to do this will have the greatest value.

Relationship of the SOA Enterprise Architecture Framework to Other EA Frameworks

Many EA frameworks manage the artifacts from an organization or functional per- spective. Frameworks like the EA3 track and manage the assets across the corporate domain but slice and categorize those assets by line of business domains as well. This approach tends to put a silo perspective on the assets even if, in fact, that may not

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:46:36.

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

90 Architecture Framework and Methodology

be the case. For example, a corporate system (e.g., general ledger) may be shared by all the lines of business, or a single data center may house all the systems for all the business units. These shared assets need to be recognizable and distinguishable from assets dedicated to the line of business when taking the SOA view.

Other traditional EA frameworks like Zachman focus on compiling the IT as- sets and capabilities horizontally from an IT system development perspective (i.e., planner, owner, designer, etc.) and vertically from a traditional IT implementation perspective (i.e., what data, logic, connectivity, user, availability, etc.)

These frameworks, however, were not designed to facilitate an evolutionary and migratory transformation from traditional legacy systems to an enterprise SOA system. As stated earlier, you need to think of SOA as one system, not many systems. Every component has the potential to be shared. Every component has the poten- tial to be leveraged for different business purposes. Even capabilities like security, personalization, logging, auditing, and archiving may be shared. Nothing is built in a (stovepipe) vacuum anymore.

The metadata compiled through traditional EA models is valuable for finding opportunities for efficiencies, especially while we are in a mixed architectural mode of traditional and SOA-driven solutions. However, the format of the frameworks and the artifacts within are not structured to support the representation of opportunities and efficiencies of the defined SOA∼EAF.

It is important to note that I am not advocating that any investment previously made in compiling EA artifacts and metadata be thrown away. In fact, the more you have, the better off you are. I am suggesting, however, that we are going to restructure and reorganize this information in a different way and leverage this new format to communicate and assess our portfolio from a very different perspective. We are embarking on a journey to evolve architecture to a model where the business readily understands and adopts the ability to make better decisions about IT and present new ways and opportunities to think about IT.

To accomplish this, we need to evaluate the artifacts of our existing enterprise architecture framework and determine how we can cross-reference their content from within the SOA∼EAF and vice versa. The two frameworks initially can be pop- ulated and maintained separately, but they need to be linked so that changes in one model can be reflected in the other model. When you first start out, the existing architectural framework will still be the dominant one since most documentation will exist under this framework and most development will still be under the tradi- tional model. As more SOA initiatives are completed and more SOA initiatives are funded, there will be a tipping point where the SOA∼EAF will become the domi- nant one. This tipping point will come from the business that, as it becomes more comfortable with the SOA business architecture approach, will understand more and more of its value and ask, or even demand, that all initiatives and discussions around the IT capabilities are structured this way. This demand will be natural be- cause the framework communicates the information from the business’s conceptual perspective.

Certain aspects of the traditional frameworks, especially as they relate to the legacy applications, can and probably should continue to exist in those frameworks until those legacy systems are decommissioned, replaced, or modernized. (See Chapter 12 for more information on decommissioning, replacing, and modernizing legacy applications.) The management of the legacy application code, the platforms those applications run on, and the physical data models of their data stores

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

Incorporating Existing Enterprise Architecture Documents and Artifacts into the SOA∼EAF 91

all can be maintained and managed within the traditional framework. Links to this information would be provided within the SOA∼EAF. The integration layer documentation associated with those applications, however, should be tracked and managed by the SOA∼EAF.

As we build more SOA capabilities, we will be consciously weaning users off the proprietary user interfaces of the legacy applications. (The capability they need is now being delivered as services through a channel interface.) The goal is to eliminate the use of these proprietary interfaces completely. Any remaining users of these interfaces should be managed through the old framework as well. The en- terprise SOA Technology Governance Committee should be seeking opportunities to eliminate the use of these interfaces as part of its strategic governance agenda. The user interaction defined in these traditional stovepipe interfaces may be helpful in defining the presentation logic for some exposed services. The logic may not be valuable, however, if the new interface adopts a standard semantic model and the old interface uses a proprietary format. These interfaces may not have value at the process level either. Many of the new processes will transcend the functionality of multiple systems and provide a work flow very different from the old interfaces. Tracking these interfaces in the EA framework will enable you to identify opportu- nities to transform these interfaces to SOA solutions. As this occurs, these interfaces should be decommissioned and flagged as such in the EA documentation.

Value of Mapped EA Artifacts

When mapping information from existing EA artifacts into the SOA∼EAF, you need to classify the information into one of two categories:

1. Information about applications that can be readily leveraged by an SOA initiative 2. Information that cannot be leveraged but can assist in assessing the functionality

of the application and identify opportunities and approaches for modernization of the application

Within an existing legacy stovepipe application, information about the data stores and any established mechanisms used to access those stores directly is valu- able and can be leveraged. Information about any application programming inter- faces (APIs) or embedded messaging capabilities is also valuable and potentially can be leveraged.

Information that explains the functional capabilities of the application and how the application authenticates users and controls their access to the functionality can- not be leveraged in an SOA development. The information is, however, valuable when defining constituent authentication and authorization requirements in an enter- prise SOA security system. This information is also helpful for identifying high-value functional capabilities that become high targets for service developments.

These distinctions should be clearly identified within the newly structured arti- facts. Thus the framework will include six categories of artifacts:

1. SOA component artifacts for all SOA components created to date 2. Various stages of artifacts for SOA components under development on active

SOA initiatives

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

92 Architecture Framework and Methodology

3. Legacy artifacts that can be leveraged and used in their current state 4. Future SOA strategic documents 5. Legacy artifacts that cannot be leveraged but document characteristics and capa-

bilities of those applications that can be assessed for modernization/migration opportunities

6. Strategic legacy modernization, migration, and decommission documentation

Having this information available and classified this way is valuable to every aspect of the SOA enterprise practice. The first four categories contain artifacts that are heavily used by business and solutions architects when describing and analyzing business needs. They are also used by project architects during the SOA development process. The documents in categories 5 and 6 are used by enterprise architects to support and drive the legacy modernization/migration process. Documents in any or all of the categories can be used by the governance committees and governance bodies to assist them in the governance process.

Incorporating Zachman Framework Artifacts into the SOA∼EAF The Zachman Framework consists of six columns and five rows. The columns represent:

1. Data (What) 2. Function (How) 3. Network (Where) 4. People (Who) 5. Time (When) 6. Motivation (Why)

The rows have these labels:

1. Scope (Contextual) 2. Enterprise Model (Conceptual) 3. System Model (Logical) 4. Technology Model (Physical) 5. Detailed Representations (Out of Context)

The SOA∼EAF with the description of each cell is repeated in Exhibit 6.1. It can serve as a reference in understanding the Zachman cell mappings to the SOA∼EAF depicted in Exhibit 6.2 as well as the comparison paragraphs that follow.

This cross-referencing of the Zachman Framework cells to the SOA∼EAF cells should be used as a guide when reviewing and assessing your Zachman docu- mentation. Many documents will contain information that relates to several of the SOA∼EAF cells. This is because the traditional documents represent traditional ap- plications that were designed using traditional stovepipe and tightly coupled, mono- lithic methods.

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

Incorporating Existing Enterprise Architecture Documents and Artifacts into the SOA∼EAF 93

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 6.1 SOA∼EAF Cell Descriptions

Key Considerations When Conducting the Cross-Reference Assessment

ZACHMAN “WHERE” COLUMN The Where column of the Zachman Framework is concerned with the Network as it relates to the location of the application and the location of the application users. Under the SOA∼EAF, the Where is really a con- cern for what channels exist, what services are provided over those channels, and what is the overall performance and reliability of the SOA components required to deliver those services to the consumer through those channels. Channels, as defined in Chapter 4, now play a more dominant role in the architectural framework. This is to reflect the fact that there is no longer a single access node for services. Knowing which channels exist by constituency indicates the level of effort required to deploy new or other services to those constituents. Hence, the conceptual concerns around the network, from a business architecture perspective, focus around the constituents and the channels they use. The logical concerns around the network, from a refer- ence architecture perspective, focus on the relationship between the user and 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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

94 Architecture Framework and Methodology

Legacy Platform Domain

(Migration)

Legacy Application

Domain (Encapsulation)

Constituent Domain

Corporate Goal/Strategy

Cross-Reference

People and Motivation Scope

Network and Motivation Scope

Function and Motivation Scope

People and Time Scope and Enterprise

Network and Time Scope and Enterprise

Function and Time Scope and Enterprise

People and Enterprise

Network Enterprise

Function Enterprise

People System

Network System

Function System

People Technology

Network Technology

Function Technology

Function and Motivation Scope

Data and Motivation Scope

Function and Time Scope and Enterprise

Data and Time Scope and Enterprise

Function Enterprise

Data Enterprise

Function System

Data System

Function Technology

Data Technology

Detailed Representations

Business Unit Plans

Cross-Reference

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 6.2 Zachman to SOA∼EAF Cross-Reference

channel and the standardized invocation of the underlying business processes and business services to the channel itself. The physical concerns around the network, from a physical architecture perspective, focus on the node-to node interconnectiv- ity within the infrastructure and the bandwidth and performance across the nodes of the network.

ZACHMAN (LOGICAL) SYSTEMS MODEL ROW The artifacts within the (logical) system model row of the Zachman Framework are more than likely structured around a single business application. Even though they may be logical representations with no physical reference to the system itself, they will contain logical representations of a traditional self-contained application. The logical application architecture will more than likely reflect a grouped set of business capabilities controlled by a central application controller, not a set of discrete and isolated services independently callable and consumable outside a central controller mechanism. The logical human interface architecture will probably reflect a self-contained, self-secured structure directly tied to and controlled by the underlying application rather than a logical description of how each service exposes its capabilities and interacts back and forth with the consumer, and the role the channel plays in delivering the service.

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

Incorporating Existing Enterprise Architecture Documents and Artifacts into the SOA∼EAF 95

Therefore, the documentation around the core application itself is less valuable than the documentation around any APIs exposed by the application and/or any custom built integration capabilities associated with the application. The legacy framework artifacts and metadata around the core application have two values:

1. Necessary for maintaining the application until it is replaced 2. Necessary when developing new integration capabilities on top of the applica-

tion to support new SOA initiatives

This documentation should remain within the legacy framework to be main- tained by maintenance and enhancement developers as necessary. The information on the APIs and integration assets, however, should be maintained by the new SOA framework in order to reflect that the portfolio of existing applications must be con- sidered as legacy assets. The applications represent investments that will continue to exist, but their legacy status sets an expectation that they represent the old way, and how we deal with them going forward will change. The key transformation at this layer is to capture information about the legacy applications, not in the context of the traditional modus operandi but rather their capability to support the Integration Service Domain layer of the SOA∼EAF.

While all the traditional information about the application needs to be retained and managed, additional metadata around the integration capabilities of the applica- tion needs to be captured or, if already captured, restructured to a consistent format across all applications. Depending on the age of the application and the underlying technologies, integration capabilities may have been added at any or all of the ap- plication layers. Integration may have occurred at the data layer by allowing other applications or data access tools to go directly against the application’s data store. Alternatively, all or part of the data may have been replicated to a secondary store utilized by other reporting and analytical tools or applications. This replication may involve bidirectional synchronization. The key is to understand the data, where it has been integrated, and what the system of record is for the data.

Integration may also occur at the business logic layer. This could include sub- routines and remote procedures that were added to the code to allow access to the business logic outside the core application. The integration may be through APIs that were provided by the software vendor or custom built in house to expose the logic. All business logic integration capabilities need to be documented and evalu- ated in the context of their ability to be leveraged by the SOA enabling technologies employed at the higher layers. Those that can be leveraged should be left alone for now. Those that cannot be leveraged should be targeted for replacement as part of the legacy application migration/modernization strategy.

Finally, integration can occur at the presentation layer. This was traditionally done with screen-scrapping technologies, a common approach in the 1980s and 1990s used for mainframe applications based on 3270 and CICS. The shortcomings of this approach are well documented, and screen scrapping is hardly ever used today. Screen-scrapping approaches exist for Windows and browser-based applications as well. These are equally bad and should not be used. All existing screen-scrapping capabilities should be replaced when their underlying functionality is needed to support an SOA initiative.

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

96 Architecture Framework and Methodology

There is a fundamental tenet to application layers that will forever hold true. Data is the most static and least volatile in terms of its structure and use. How often do companies redefine the “order” data element in their databases, or any data element for that matter? Data element changes do not happen often, if ever. Usually it is a catastrophic event (e.g., expand the size of the field) that forces changes to data.

Business logic is the next least volatile, although it is much more volatile than data. The need to change business logic occurs frequently. (Changes in tax rules or volume discounts are two common examples.) When these changes are required, you must assess the impact across the entire continuum, including other applications using replicated copies of the data and duplicate instances of the business logic. This can be a costly and time-consuming exercise when the business logic has been duplicated in multiple applications.

Finally, presentation layer logic is the most volatile. Presentation logic can change often and drastically. Any integration approach that scrapped the presenta- tion layer of legacy applications is either:

� Constantly being changed as well � Constantly being versioned � No longer used � Very expensive � Any combination of the above

Some applications may be completely isolated in that they have never been integrated at any layer. Very few of these types of applications should exist. If your company is like most, most of the integration will consist of direct access to the applications data store or replicated copies of the data store. This type of integration is usually a point-to-point solution where very little leveragability exists for reuse. The key is to identify which of those point-to-point solutions have leveragability across other applications. The assessment may identify that several solutions have a significant amount of common data among them. These solutions should be assessed for an SOA opportunity. The strategy should be to migrate these point-to-point solutions to a common data service based on a semantic data model tied to a single source representing the system of record for the data. This will allow each existing application to migrate its interface to the semantic service and structure over time and eventually eliminate the multiple point-to-point code sets.

MANAGING INTEGRATION GOING FORWARD Since integration started out as point-to- point data interfaces or data replication mechanisms, these were traditionally docu- mented as embedded components of the application architecture of the respective systems. They were not perceived, designed, and deployed as reusable integration assets; therefore, there was no need to separately identify them. Companies that adopted a middleware technology and approach in the 1980s and 1990s began to develop leveraged and reusable integration components within their portfolios. The presence of these technologies allowed architects to add this layer to their EA frame- work or at least maintain its metadata separately. Some of these architects infused this documentation below the System Model (logical) layer and above the Technology Model (physical) layer of the framework, making it subservient to the application

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

Incorporating Existing Enterprise Architecture Documents and Artifacts into the SOA∼EAF 97

architecture. While this approach was correct under a traditional stovepipe applica- tion development paradigm, it is not appropriate under an SOA paradigm.

Under SOA, the integration points of the application are promoted to a higher level of importance than the applications themselves. The monolithic user interface and application-specific security components of the application are not important to SOA. The embedded business logic and data are important. Hence, any integration assets associated with the application are the assets we want to identify, analyze, and modernize. We also want to explicitly establish development frameworks, stan- dards, and design patterns for the construction of any integration capabilities going forward. By inserting an architectural framework layer specifically for integration, we can promote the level of importance and infuse domain-specific criteria for all integrations across the enterprise.

This layer also allows us to more quickly identify and structure these assets at a much more granular level and categorize them with more specificity. For example, a company may have a large monolithic back-end legacy system that is the processing system of record for customers, orders, products, and prices. Over the years, a series of middleware messages were developed to provide this granular information:

� Several customer messages providing customer address, account number, terri- tory, sales volume, and volume discount.

� Several order messages providing orders by territory; orders by week, month, quarter, and year; orders by customer; and orders by product line.

� Product messages providing product prices, product discounts, and product descriptions.

Each of these messages is captured and documented at the Integration Domain layer of the framework along with all the other messages that have been built on top of other applications. While these are physically mapped to the specific applications with which they integrate, they can be logically categorized many different ways. In fact, the documentation (and a tool used to capture and store the metadata) should be designed so that any one of multiple views of available messages can be constructed depending on the business need and/or audience.

I use messaging as an example, but any integration artifact—whether an ODBC driver, a stored procedure and trigger, or whatever—should be documented.

In some instances, the integration layer may contain the documentation of spe- cific custom APIs that were provided as part of the business application itself. These APIs may be 100 percent custom code built in house or supplied by the application vendor or built on top of the foundational class APIs of the underlying platform.

Whatever technology is used, the intent of this layer is to provide the first layer of abstraction of data and business functions from the underlying applications. If the integration is achieved through the construction of a Web service, it is important to separate data access layer objects from the business logic layer objects and business logic layer objects from presentation layer objects. This is necessary to ensure a level of loose coupling that allows other services to utilize existing data access and business logic assets.

Whether any of these documented integration assets are reused to support a future need is an entirely different matter. We have to document that they exist so we can assess their value. That value assessment includes determining if the asset

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

98 Architecture Framework and Methodology

complies with the strategic direction of the architecture and if it is stable and reliable. Some integrations may not have been built by IT. They may not have been fully vetted and tested. Even worse, they may not even be maintained and supported by IT operations. They may be based on old technologies that have a high maintenance cost or a known obsolescence horizon.

Some of these assets will be directly leveraged without modification. Others may be leveraged with some effort to modernize them or make them more compliant with the architectural standards. Finally, some will be explicitly identified as risky, obsolete, or highly noncompliant and be targeted for replacement if a new need to use or enhance them arises.

This documentation, especially for this last type of asset, is critically important to the governance team and process. The governance teams will facilitate and drive the replacement and elimination of these “bad” assets. If, however, they are unaware that they exist, do not understand the risk of continuing their use, and have not been presented with a pragmatic alternative for dealing with them, you have no hope of eliminating these assets.

ZACHMAN ENTERPRISE MODEL LAYER The Enterprise Model layer of the Zachman Framework will relate mostly to the Business Process Domain layer of the SOA∼EAF. While almost all the artifacts at this layer can be utilized within the Business Process Domain, several key distinctions should be understood and a few changes must be incorporated.

First, not all the assets will be considered enterprise. Some assets, which will clearly be recognized as never having an enterprise purpose, may still have value to be captured and managed at this level. For example, even though there may never be more than five people allowed to enter journal entries directly into the general ledger system, there may be a reasonable business justification for building a service to do this. An example might be to allow work-at-home employees to input the entries through a secured service without giving them access to the entire general ledger system. From an architecture audit and control perspective, it is important to know this service exists and how it is used.

Second, many of the artifacts will more readily map to the Business Service Domain rather than the Business Process Domain. Some business services may be very granular; some may be very coarse. Coarse ones may encapsulate significant and complex portions of the higher-layer business process in a single business process. They are in themselves miniprocesses that contain their own semantic data documents and process steps. In these cases, the Business Process layer may add little more than choreographic capabilities to orchestrate one process to another.

Unlike the Integration Domain layer, where the strategic approach is to have all the Integration Domain assets flow through the Service Domain layer, some of the Business Service Domain layer assets will flow directly to the Channel Domain layer, bypassing the Business Process Domain layer. In these instances, the Business Process Domain layer may include a notation referencing a business service that can flow directly to a channel. The artifacts of the lower layer would be referenced, not replicated.

Finally, in the traditional EA model, artifacts at this layer do not represent top- down conceptual representations of a business process but rather fully functional production versions of those business processes as monolithic implementations.

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

Incorporating Existing Enterprise Architecture Documents and Artifacts into the SOA∼EAF 99

This includes business models developed in languages such as business process execution language (BPEL) and deployed using a BPMS technology platform. There is nothing in these tools or platforms that forces the recognition and isolation of channels and constituents. There is nothing that identifies constituents or channels as enterprise assets. Therefore, most of these artifacts will reflect these very simi- lar to traditional monolithic applications. BPMS solutions built compliant with the development frameworks and design patterns of an SOA reference architecture are very different from traditional monolithic approaches.

ZACHMAN SCOPE LAYER Most of the documents captured at the Scope layer of the Zachman Framework will map to the Constituent, Channel, and Business Process layer cells under the Corporate Goals/Strategy Cross-Reference and Business Unit Plans columns of the SOA∼EAF. Additionally, these artifacts may map to these three layers within the Business Architecture column of the SOA∼EAF. The business archi- tects should be heavily involved in evaluating these artifacts and reconstituting their structure to reflect concepts around constituents, channels, and services. Once they are reconstituted, they should be evaluated horizontally across the three layers to identify common business themes and conditions. One way to achieve this is to lay out all the documentation in a spreadsheet format with each column representing a scope artifact and the artifact contents split among three rows representing con- stituents, channels, and services. Once this is done, the business architect can look horizontally across all the scope documents for constituent commonalties, service- sharing opportunities, and channel expansion opportunities. This analysis will also show the amount of waste and duplicity that exists in the current applications and provide a compelling argument for adopting an SOA approach.

General Approach for Integrating and Leveraging EA Artifacts into the SOA∼EAF Regardless of what framework you currently use to capture EA artifacts, these prin- ciples should apply:

� The artifacts should be decomposed so they can be restructured to reflect a top-down constituent-centric view of the application. The presentation layer user interface should be called a proprietary legacy channel. If multiple con- stituents use the user interface, it should be identified under each constituent using it. If functionality delivered through that user interface is restricted to specific constituents, the functionality should be identified as a service devel- opment opportunity only under those constituents authorized to use it. Du- plicated functionality used by multiple constituents should be listed under all those constituents. This provides architects the ability to identify high-value, multiconstituent service opportunities within each application.

� Assets that can be leveraged immediately should be classified as such so they can be identified by the solutions and project architects who are estimating, designing, and developing the new SOA applications.

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 c06 JWBT251-Sweeney March 22, 2010 10:40 Printer Name: Hamilton

100 Architecture Framework and Methodology

� Integration and API capabilities of the application are the most valuable pieces of documentation, but only if those APIs and integration capabilities are below the presentation layer and built with technologies that can interoperate with the technologies deployed at the SOA Integration Service layer of the Enterprise SOA Platform Architecture.

� Information about the functionality provided by the application and who uses that functionality can be noted at the Business Service, Business Process, and Constituent layers of the Business Architecture column of the SOA∼EAF to facilitate evaluating modernization and migration opportunities.

� Information about authentication and functional authorization mechanisms within the application can be helpful for providing a broader picture of se- curity roles and privileges when setting up the enterprise security profiles of the constituents in the Enterprise SOA Security Framework modules.

� Information about the underlying technologies and platforms that the applica- tion runs on is valuable to determine if those technologies and platforms contain any inherent capabilities that can be used to extend or expand the application’s interoperability characteristics or capabilities.

� Information about any standards or semantic models embedded in or supported by the application is important for assessing the openness of the application.

Summary

This chapter identified approaches and techniques for evaluating existing application artifacts and leveraging their information into the SOA∼EAF. The chapter also pro- vided a specific example using the Zachman enterprise architecture model. It iden- tified the different categories used to classify artifacts stored within the SOA∼EAF and the usage distinctions of these categories.

The key point to remember is that you should incorporate only those existing artifacts that provide one or more of these values:

� Identifies assets that are readily usable by SOA initiatives. � Documents information that allows SOA architects to assess the modernization

and migration opportunities for those applications. � Provides strategic information about the modernization and migration plans for

these applications.

All other artifacts should continue to be maintained in the EA framework al- ready in place until a tipping point is reached where most of the artifacts are now being generated through the SOA∼EAF. The old framework should be shut down after a majority of the legacy applications have been modernized or migrated and decommissioned.

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