Written by Helene Abrams Thursday, September 18 2008
Integration of diverse applications means building bridges that connect one application to another in order to pass data between them. There are several ways of integrating data, from writing code to insert data that is generated in one system into another system to using a hub-type technology with several adaptors that also includes a messaging system and a broker for routing and transformation of the data. In the following diagram, the blue lines represent data movement and messages that are passed through adaptors to other systems. The blue circles represent adaptors that are connected to a common interface table in a system. The red lines represent interfaces directly between any two systems.
These interfaces are generally SQL code used to extract the data from one system and load it into another system. As is obvious, both methods of integration can be very complex and difficult to maintain. The data may be in different formats in each of the systems, the interface code or the adaptors may need to change as each system is upgraded, the loads have to be done in a particular sequence to obtain the correct results, and the data itself may be inconsistent. Decisions have to be made regarding which application contains the correct data, how to deal with conflicts, and the frequencies of loads. There are some basic principles that will help streamline the process of integrating data among disparate systems.
- Try to keep the same type of data within a single application, or at best, identify a single place where data is created and updated. This is the underlying concept of master data management efforts. All applications that reference that data should be “read only”.
- Set up data standards. Create naming standards and formatting standards for all systems across the enterprise. For example, all descriptions should be the same field length, telephone numbers should all be in the same format (for example, countrycode.areacode.number.extension), punctuation should be eliminated, and abbreviations should be standardized.
- Create a Data Map. This can be done in a spreadsheet, in a database, or by using database design software. The purpose of the Data Map is to show what each data element is mapped to in other systems and the “load instructions” for that data element. The data map is cross referenced for two-way interfaces. If using a spreadsheet, you would have a worksheet for each table with the attributes or columns of the table on the left of the spreadsheet (column A) with each interfaced system/table going across the top (Row 1). The first Application should be the current system. In the first intersection cell (B2), put the format of the data of the current system (i.e. varchar 10). After the current system is documented, allow 3 columns for each application to be integrated with the current system. In the second intersection cell (C2), put the table/column name that is the destination for the first data element in the first application to be integrated. In the third column (D2), put the format required for the first system to be integrated (i.e. varchar 25). In the fourth column (E2), you will document the transformation code required to get the data from the format in column B into the format required for Application B, Column D (i.e. rpad 15). Continue on until you have all the interfaces mapped and the transformations documented for each application to be integrated. Keep the data map current as systems are updated.
- Limit the interface to a “need to know” interface. In other words, if an application does not need to use the information as a trigger for a procedure or an action within that system, do not bring it into the new system.
- Define the processes that create, read, or update each type of data and put security and access controls in place so that the governance and ownership of the data is unambiguous.
| < Prev | Next > |
|---|
Related Articles
Related Pages
Enter your email address to sign up for our Newsletter
January Puzzle
A traveler gets lost on a deserted island and finds himself surrounded by a group of n cannibals.
Each cannibal wants to eat the traveler but, as each knows, there is a risk. A cannibal that attacks and eats the traveler would become tired and defenseless. After he eats, he would become an easy target for another cannibal (who would also become tired and defenseless after eating).
The cannibals are all hungry, but they cannot trust each other to cooperate. The cannibals happen to be well versed in game theory, so they will think before making a move.
Does the nearest cannibal, or any cannibal in the group, devour the lost traveler?
Solution
The short answer is the traveler’s fate depends on the parity of the group. If there is an odd number of canibals, the traveler will be eaten, but if there is an even number, the traveler will survive.
To prove this, we will consider small groups and use mathematical induction to explain the solution for larger groups.
Case n = 1: this is an obvious case. If there is one cannibal, the traveler will be eaten. It doesn’t matter that the cannibal will get tired because there are no other cannibals around as a threat.
Case n = 2: this is a more interesting case. Each cannibal wishes to each the traveler, but each knows he cannot. If either cannibal eats the traveler, then he will become defenseless and the other one will eat him. So each cannibal uses backwards induction to realize that the only strategy is to not eat the traveler. The hapless traveler finds a bit of luck, therefore, and actually survives.
Case n = 3: this is where the problem gets interesting. The best strategy is for the closest cannibal to make a move and eat the traveler. The cannibal will be defenseless after eating, but ultimately he will be safe. Why is that? The reasoning is due to induction: once the cannibal eats the traveler, the resulting situation has 2 unfed cannibals and the 1 defenseless cannibal. But as we just showed above, when there are 2 unfed cannibals, neither will make a move for fear of being eaten by the other! Thus the first cannibal to make a move will be safe as the remaining 2 cannibals block each other.
We can prove the higher cases using mathematical induction. If the number n is odd, then the closest cannibal can safely eat the traveler because the remaining number of unfed cannibals is even (and by induction, with an even number of unfed cannibals no one makes a move). If the number n is even, then no cannibal will eat the traveler, for if he did, the remaining number of cannibals would be odd, meaning he will get eaten by the induction hypothesis.
Success Tips for Oracle Project Management
- Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
- Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
- If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
- Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
- Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
- Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
- Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
- Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
- Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
- Include governance, risk, and compliance management as part of the project plan.
- Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.
The Analyst Corner
John Van Decker, Research VP of Gartner, states:
"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."
