Enterprise Integration Solutions

35

Modeling and Prototyping

for Integration Projects

In Chapter 2, we examined several approaches to implementing EI solutions. In

this chapter, we will describe the general process that most integration projects

follow. As with any project, you use requirements to develop a design or

model, construct the model, and then test, analyze, and deploy it. Each time

you repeat this cycle, you add new functionality and correct or enhance exist-

ing functionality. This chapter focuses on developing the design or model that

you will use for constructing a solution.

We have discovered some significant differences between normal applica-

tion design and EI design. For example, when designing a normal application, we

generally store the data in only one way. When we need to write an entity to

disk, we have a predefined data structure to help accomplish this. In an EI solu-

tion, however, we use many storage locations for a single entity, and that entity

might have completely different sets of attributes in each of those locations.

So how can you wade through the complexity of tying multiple entities,

systems, messages, and endpoints together? This chapter will present a number

of ways to assist with this. The methods presented here are ones that we have

used and found both effective and simple.

Integration Modeling

In Chapter 2, we discussed four categories of assets to integrate:

■ Entities

■ Activities

36 Part I Enterprise Integration Overview

■

Processes

■ Utilities

These four assets are generally stored inside existing systems. One of our

main goals is to expose these assets to outside use. To pinpoint these assets in

an organization, you first need a list or inventory of the systems being inte-

grated. With this list in hand, you can determine which entities are present in

each system. Knowing which entities systems are already passing back and

forth can be helpful. A system that passes a purchase order must contain at least

some of the elements of the purchase order but not necessarily all of them.

Different systems will have different views of a particular entity. At this stage,

we simply want to identify which systems come into play when dealing with

a given entity at a high level. Such identification might look like this: “The

customer relationship management (CRM) system and the contract manage-

ment system both deal with the customer entity.”

Once you know which entities each system contains, you can explore the

activities in which those entities are involved in each system. Logically, when

you string the activities together across the systems, you can define the pro-

cesses. Any required functionality that is not already present can be built into

utility functions. Using these four basic building blocks, you can model an

enterprise quickly and effectively. The first pass usually yields a diagram similar

to the one in Figure 3-1.

F03LS01

Figure 3-1 Example enterprise model.

E-Store Inventory

PurchasingCRM

Ordering

Partner/

Supplier

Order Order

Quote

RFQ

Line

Items