Evolutionary Systems Architectures in the Enterprise
5. Define a framework for common information exchange
Interface and data requirements must be studied for the processes, systems and
applications to be integrated. From an enterprise perspective, much of the reusability
and efficiency of integration come from having a common information exchange model.
Many standards, some of which are horizontal, such as XML and OAG, and some of
which are utility-specific, such as CIM and WG14, have made a great deal of progress
toward providing solutions vendors and, ultimately, utilities with useful frameworks.
Much of the work these standards groups have done to date is readily accessible and
available to leverage, and the underlying implementation technologies provide the ability
to adapt as these standards undergo further evolution and ratification. Also, defining a
common information exchange model is different from defining a corporate data model,
as many utilities have done. The organization must focus on the information exchange
between systems and applications with traceability to business process, not simply
intra-application information requirements.
6. Select technologies that enable good architectural principles
Various enterprise application integration technologies have been maturing for several
years. Many vendors supply specific components or the entire family of integration
tools needed for the enterprise-level integration needs, including A2A, B2C, B2B and
other scenarios. Conversely, newer technologies and standards are currently evolving,
and maturity curves are no longer just based on time. Organizations can commit to a
specific vendor to provide everything needed for integration, or they can select
best-of-breed technologies to get the best fit for their integration needs. Both strategies
are viable, but the challenge is to ensure that the technologies have the right balance of
achieving “architectural goodness” with principles such as scalability, security and
extensibility with enabling the organizational goals.
7. Walk, then run
Developing an enterprise integration architecture framework requires a rigorous
engineering effort. It also involves risks in both business and technology. To mitigate
such risks, organizations should take an iterative approach using prototypes and pilots
to surface specific issues and problems with the framework before it can become the
corporate IT standard.
8. Test for functionality and performance
The organization must allocate enough time and resources to test the functionality and
performance of the integration framework in the production environment. A flexible and
reusable framework at the technical level often comes with an unacceptable tradeoff
relative to performance. The framework must balance performance and flexibility, which
means that the required level of performance should also be documented at the time of
process and messaging definition.
9. Define success clearly, then show results early and often
The success of an enterprise-level integration framework relies on its ability to enable
the business value of IT projects using such a framework. Results must be shown early
and often to maintain the interest and support from both management and other
stakeholders. Sometimes direct short-term benefits from the framework can be difficult
to quantify and must prove out at the enterprise level over a longer timeframe, which is
acceptable as long as the organization is an “informed consumer.” In this case, the
more projects that use the framework, the better overall effect on TCO, time to market
and other indicators of success.
10. Keep the momentum going
One of the pitfalls of any such integration framework is its inherent obsolescence.
There has to be a team and a process in place to maintain and evolve the framework.
Given today’s business and technology environments, any good framework will lose its
value to an enterprise rather quickly without such processes and commitment.
Enterprise Integration Architecture Framework
The enterprise integration architecture framework for utilities facing deregulation has its
basis in the principles discussed previously. The framework is divided into three
architectural categories: business, technical and organizational architecture. Each
category has its own unique design. Consideration is also given to the touch points
between each category.
Business Architecture
Business architecture defines the foundation and design principles of the framework
relative to business considerations. Here we consider three conceptual layers of
architecture. The first layer deals with understanding the business domains and drivers
as well as the corporate business vision and goals. The second layer deals with
developing integrated business processes to enable the organization to achieve those
goals. The third layer deals with understanding the touch points between systems and
business events inside or outside the organization that are significant to process
integration. Figure 1 shows the conceptual model of this architecture. The centerpiece
of this architecture is the integrated business process model. It is extremely important
for an organization to invest the right resources and time to develop such models in a
flexible, maintainable and expandable format. Tools and consulting services are often
available to assist in such an endeavor. Organizations should look for consulting
companies with specific utility knowledge and systems integration experience.
Figure 1: Business architecture for integration
