EAI Process
• 1: Understanding the Enterprise and Problem Domain
• 2. Making Sense of the Data
• 3: Making Sense of the Processes
• 4: Identifying Application Interfaces
• 5: Identifying the Business Events
• 6: Identifying the Schema and Content Transformation Scenarios
• 7: Mapping Information Movement
• 8: Applying Technology
• 9: Testing, Testing, Testing
• 10: Considering Performance
• 11: Defining the Value
• 12: Creating Maintenance Procedures
• Step 1: Understanding the Enterprise and Problem Domain
• Understanding the problem domain requires working with many organization heads in order to get a handle on the structure and content of the various information systems, as well as the business requirements of each organization—
how they do business, what's important, and, perhaps more importantly, what's not.
• This process is a basic requirements-gathering problem. It requires interfacing with paper, people, and systems to determine the information that will allow the EAI problem to be defined correctly so that it can be analyzed, modeled, and refined. Only then can the appropriate solution set be employed.
• Step 2: Making Sense of the Data
• We begin with the data for a couple of reasons.
» First, most EAI projects exist only at the data level.
» Second, even if the EAI project works at the method, application interface, and user interface levels, it is still necessary to understand the databases
• the implementation of data-level EAI comes down to understanding where the data exists, gathering
information about the data and applying business principles to determine which data flows where, and why.
• There are three basic steps that must be followed to prepare for implementing data-level EAI
• 1. Identifying the data
• 2. Cataloging the data
• 3. Building the enterprise metadata model
» Defines all the data structures existing in the enterprise and how those data structures will interact within the EAI solution domain.
• Step 3: Making Sense of the Processes
• understanding and documenting all business processes and how they relate to each other, as well as to the
enterprise metadata model
• it is preferable to document existing business
processes and methods, to better understand what they do and, therefore, how to integrate them at the method level through a composite application
• Use traditional process-modeling techniques, such as object modeling (e.g., the Unified Modeling Language [UML]) to create business processes
• Process Integration
• Process Cataloging
» In the same way that data-level EAI requires a data-level catalog, method-level EAI requires a "process catalog"—a list of all business processes that exist within an
enterprise
» the architect will not only enter the business processes into the catalog but will also determine the purpose of the process, who owns it, what exactly it does, and the technology it employs
• Step 4: Identifying Application Interfaces
• integration with application interfaces and other EAI levels.
• The best place to begin with interfaces is with the creation of an application interface directory
• this is a repository for gathered information about
available interfaces, along with the documentation for each interface.
• Step 5: Identifying the Business Events
• The next step is the identification of all relevant business events that occur within an enterprise.
• This means when something happens—an event — then there is a resulting reaction.
• It is important to understand what invoked a business event, what takes place during the event, and any other events that may be invoked as a consequence of the
initial event.
• Step 6: Identifying the Schema and Transformation Scenarios Content
• With an existing understanding of the data and
application semantics that exist within an EAI problem domain, it is good to get an idea about how schema and content of the data moving between systems will be transformed
• First, data existing in one system won't make sense to another until the data schema and content is
reformatted to make sense to the target system.
Second, it will assure the maintenance of consistent application semantics from system to system.
• Step 6: Identifying the Schema and Transformation Scenarios Content
• With an existing understanding of the data and
application semantics that exist within an EAI problem domain, it is good to get an idea about how schema and content of the data moving between systems will be transformed
• First, data existing in one system won't make sense to another until the data schema and content is
reformatted to make sense to the target system.
Second, it will assure the maintenance of consistent application semantics from system to system.
• Step 7: Mapping Information Movement
• Once the preceding steps have revealed all the
information available, it is time to map the information movement from system to system—what data element or interface the information is moving from, and to
where that information will ultimately move.
• For example, the customer number from the sales databases needs to move to the credit-reporting system, ultimately residing in the customer table maintained by the credit system. This knowledge enables us to map the movement from the source
systems, the sales system, to the credit system, or the target system.
• Step 8: Applying Technology
• selecting the proper enabling technology to solve the EAI problem.
• Many technologies are available, including application servers, distributed objects, and message brokers. The choice of technology will likely be a mix of products and vendors that, together, meet the needs of the EAI
solution
• Step 9: Testing, Testing, Testing
• if an EAI solution is not tested properly, then disaster looms large. For example, important data can be
overwritten (and thus lost).
• Step 10: Considering Performance
• EAI systems that don't perform well are destined to fail.
For example, if processing a credit report for a
telephone customer takes 20 minutes during peak hours, then the EAI solution does not have business value.
• While most EAI solutions won't provide zero latency with today's technology, the movement of information from system to system, or the invocation of common business processes, should provide response times under a second.
• Step 11: Defining the Value
• it's time to define the value of the EAI solution, to determine the business value of integrating systems. In this scenario, the method of determining value is generally evaluating the dollars that will be saved by a successful EAI solution.
• Two things should be considered here: the soft and hard dollar savings.
• Hard dollars represent the value of the EAI solution easily defined by the ability for the solution to eliminate costly processes, such as automating manual processes, reducing error rates, or processing customer orders more quickly
• soft dollar savings include increased productivity over time, retention rate increase due to the ability to make systems work together for the users, and customer satisfaction
• Step 12: Creating Maintenance Procedures
• Who will administer the message broker server?
• Who will manage security?
• Who will monitor system performance and solve problems?
• a good idea is to document all of the maintenance activities that need to occur—and assign people to carry them out.
