Why the Implementation Level Makes Things So Much Harder


Occasionally applications are built from a sound semantic or conceptual model of the domain. Usually before the implementation project is completed, and certainly before the application is retired, the conceptual model gets shelved. The implementation is there, and all bugs must be fixed in the implementation. The implementation has its own data structure (often because of real or suspected performance problems) and its own naming conventions. The conceptual model is no longer relevant to the maintenance programmers, because the implementation model is more germane to their task.

What happens is that the conceptual model gets violated at every turn. If it is possible to overload some field that isn't being used all the time, with a value that essentially subtypes the object, that is what will be done. For example, an analyst might note that no one is using the "inventory source" field and might decide to put substitute part numbers there. If another field needs to be tacked on somewhere it will, and generally at the most concrete level possible. If someone requests a "price per ounce" field, that is what will get added, and there will be little or no consideration to whether there is a need for price per unit; it will be price per ounce. A few maintenance programmers would actually go through the analysis, but most wouldn't (largely because it wasn't requested, isn't appreciated, and is outside their sphere of training). Often the original models and analysis can't be found or are out of date. However, I don't mean to single out maintenance programmers; the issue is the general state of applications systems as we typically encounter them after years of in-the-field adaptation.

Why You Probably Don't Have the Right Applications Anyway

One other aspect of the implemented systems is even more profound for the business of integrating efficiently: The applications themselves have arbitrary boundaries. Typically what is in one application is a product of what was needed at the time to fill some other gap, or it reflects the scope that was offered by an application software vendor. Based on our observations, it is highly likely that some applications share too much data, and they should be combined instead of integrated; many nearly duplicated systems should be rationalized; and a few applications are too big to be economically maintained and should be partitioned.

If you accept these boundaries, you will build an integration infrastructure that will ensure that these boundaries stay in place. In effect, you will have calcified the existing configuration at a time when you need to be moving toward more flexibility. An approach that enables the repartitioning of application boundaries and redefinition of application interfaces, if needed, is the enterprise message model.




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