System Integration and Architecture, Papers of Systems Design

Download System Integration and Architecture and more Papers Systems Design in PDF only on Docsity!

The Implementation Methodology Overview

LESSON 3:

This chapter describes the EA implementation methodology (EA methodology), which is a detailed procedure for establishing, maintaining and using an EA framework and documentation approach. The EA methodology is the first step in coordinating the EA documentation approach. The value of adopting an EA methodology is that it reduces the risk of creating an ineffective EA program and/or inaccurate EA documentation. Learning Objectives

• Understand the purpose of an EA methodology within the EA program.
• Understand the steps of an example EA methodology.
• Understand the relationship between an EA framework and EA methodology.

Business Systems Hierarchy

• (^) The systems of an enterprise can be viewed at a number of different levels of detail. As we move up the hierarchy, the scope of business functionality increases, and the level of detail exposed decreases.

Application Components

• (^) At the bottom of the hierarchy are application components. Components are units of application software that can be combined to produce larger units of functionality. Basic components are application objects that are implemented with programming languages. These will be grouped into object structures that provide functionality representing a service or business entity.

Business Processes

• (^) As noted earlier, most automated business processes currently are embedded in application code. These processes may determine the order in which activities occur, the participation of users, and the actions to be taken to resolve exceptions

Business System Domains

• (^) Business processes, applications, and their components must be managed to meet the needs of a particular organization. The organization will coordinate and control changes to the systems it uses. It will have primary responsibility for the integrity and security of the information, including the ability to recover the system from failures.

Virtual Enterprise

• (^) Up to this point in our discussion, the systems and their users are contained within the single managing entity of a corporation. The virtual enterprise level integrates customers and business partners. The difference from intra- enterprise level integration is the level of isolation between the corporation and its customers and partners and the use of the Internet to provide communications connectivity.

Integration Infrastructure Model

• (^) The integration infrastructure is the collection of shared facilities that allow the various business systems to work together. The enterprise will incorporate many systems. These systems will come in various shapes and sizes

Work flow Process Model

• (^) Business processes drive the operation of the business. Some business processes perform enterprise-level actions, such as filling a customer order, and some processes automate relatively trivial operations, such as obtaining approval of a package pass.
• (^) These systems have a common model. In the following subsections we will describe each of the components of this model, their relationships, and, in general terms, their implementation.
• Process
• Process instance
• Activity
• Requester
• Personal work list
• Resource assignment facility
• Process manager
• Process interoperability

Business System Domain (BSD)

Model

• (^) Although the enterprise architecture will accommodate a number of application models, the component-based application model will be preferred for new applications.

Knowledge Access Model

• (^) Knowledge is information about the business and its technologies. Typically, i t is not stored in operational databases or data warehouses, but often it is stored in less structured ways or retained in the memories of knowledge workers.

An Enterprise Integration Scenario

• (^) Up to this point, the discussion of enterprise integration has been abstract.