Issues with Internal Integration


We haven't yet made a distinction between integrating applications within your enterprise and integrating your applications with other enterprises. The five strategies we described work in both scenarios; however, the emphasis is different. Between enterprises, most of the interfaces are manual. In most cases, the producers of the information don't know there is an interface; they publish information (on paper or a Web site) and someone keys it into a spreadsheet or database. The big database and direct connect strategies are not used much between companies, but point to point in the form of EDI is used extensively. Finally, the message-oriented approach is about to gain currency between firms in the form of Web Services, as we'll discuss in Chapter 13. Although the mechanisms are similar, the semantic challenge is quite different.

Within an enterprise the primary semantic integration challenge is to avoid implementing a large number of point-to-point interfaces. With new technology coming on line it is easier to write individual interfaces, but we must discipline ourselves against doing more of the same damage that we have done in the past, only faster and cheaper. As the old adage advises, "When you find yourself in a hole, stop digging."

Once we have built interfaces to a particular system, it becomes harder and harder to change the system, because more things (the interface and the downstream systems that are connected to the interface) will break. In most organizations we've examined, the problem is worse than this: The organization may not know all the processes that depend on a particular system, database, or interface, because those processes or systems may not be under the control of the people who manage the application. Some of the key activities to be performed include the following:

  • Create an intermediate representation of all interfaces such that each system need only know about the intermediary, and not about the other systems. This reduces the geometric explosion of interfaces, but it requires some semantic analysis.

  • Dictate to the applications what their interfaces will be and what the semantic contract for them will be. The reason for doing this is that the default behavior of application developers is to allow applications to define their public interface, or worse, expose their data model, which opens up many more points of access. This will typically be poorly defined and not designed to interoperate with the rest of the systems.

  • Redefine the number and borders of the existing applications. Even if we don't change them immediately, we will want to define the interfaces as if the new systems were in a more rational configuration. If we don't do this now, we'll be stuck with the configuration of applications we have at this point.

  • Maximize the flexibility, resiliency, and stability of the intermediate model, so that changes to one application are buffered through the intermediary and cause little or no change to other systems.




Semantics in Business Systems(c) The Savvy Manager's Guide
Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)
ISBN: 1558609172
EAN: 2147483647
Year: 2005
Pages: 184
Authors: Dave McComb

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net