Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 25
Best Practices for Integration 25
· What are the standard workflows through the process?
· What are the alternate workflows through the process? When do the alternates occur?
Only the business rules that pertain to the pieces involved in the integration effort need to be
collected. Also, some of the business rules that need to be collected might pertain to data not cur-
rently collected or systems not yet in existence. After the business rules have been collected,
review them to ensure they are
· Consistent with each other;
· In line with the priorities defined in Step 1, Define Business Objectives and Identify Informa-
tion Needs; and
· Complete.
Case Study Step 5
The Project Manager added a member of the airport's legal staff to the team to
ensure that the requirements of the airlines' use and lease agreements were
understood and incorporated into the business rules for the data. The CFO
reviewed the draft business rules and found that the contractual rate-making
methodology required that the landing fee be calculated using airline self-
reported landing counts. Because this business rule would preclude using airport-
generated flight data, and thus reduce the potential benefits of the integration
project, the CFO flagged this problem for resolution by the CEO. The CEO agreed
to try to negotiate a change in the rate-making methodology in the upcoming
re-negotiation of the airlines' use and lease agreements.
Step 6: Perform a Gap Analysis
Figure 3-8 indicates the level of effort of the stakeholders for this step.
A gap analysis defines the gap between where the systems are today and where the integrated
system should be. The gap analysis defines missing systems, processes, and data needed to achieve
project success as previously defined. The gap analysis starts with the rules and requirements col-
lected in Step 5. Determine for each requirement whether there is a gap between what is avail-
able and what is required for success. Gaps can take the following forms:
· Missing data or business rules,
· Inaccurate data or business rules,
· Incomplete data or business rules, and
· Systems with conflicting business rules.
Figure 3-8. Step 6.
