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.
In Chapter 2, we discussed four categories of assets to integrate:
36 Part I Enterprise Integration Overview
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.
Figure 3-1 Example enterprise model.