Evolutionary Systems Architectures in The Enterprise
Technical Architecture
Technical architecture defines the foundation and design principles of the framework relative to
technology. Here we consider two conceptual views of the technical architecture. One is the
messaging architecture to deal with domain-specific information exchange. The other is the
infrastructure to manage the integration between systems and domains. Figure 2 shows the
conceptual model of such an architecture.
The messaging architecture usually consists of a common information model, corporate standard
message types, and proprietary message definitions. An example in the utility space is the CIM,
now available as an IEC TC57 standard. Such a model could serve as the foundation for
integration message type definitions. With the flexibility of XML technology, utilities could
extend the model to fit their needs without breaking the compliance to the standard if desired.
Reference [1] discusses in detail how such standards can be used to develop corporate standard
message types in the electric utility industry.
The intersystem and interdomain integration infrastructure usually consists of four conceptual
layers: 1) Adapters that provide interfaces into disparate systems and applications — they work
with different network protocols and operating systems and insulate the infrastructure from their
platforms; 2) Transport layers to deliver messages with scalability and guaranteed delivery being
some of the central features; 3) Integration broker layers to route, transform and manipulate
messages before they are delivered to their destinations; and 4) Workflow engines and
definitions to reflect business processes that the integrated systems need to support. There are
vendors who supply technologies for all the layers, which is good for organizations looking for
technology standardization and economy of scale. Others may want to look for the best-of-breed
technologies, such as application servers, MOM, and even Web services, to gradually build the
infrastructure when needs for certain layer(s) arise. As long as the design and implementation
adhere to the overall framework, there should be less pain of growing the infrastructure in the
future.
In an ideal situation, messages should be translated into a common format before they are
dropped on to the transport layer to maximize the value of a common information model. There
are cases, however, in which the complex transformation is better accomplished in the
integration broker layer to fully utilize the features of the integration brokers, rather than
developing custom transformation programs in the adapters.
Figure 2: Technical architecture for integration
