GISdevelopment.net ---> GITA 2002 ---> Systems Architectures

Evolutionary Systems Architectures in The Enterprise

Mark Cioni, M. Joe Zhou,
Massimo Rolle SchlumbergerSema
6399 South Fiddler’s Green Circle,
Suite 600, Englewood CO 80111


Abstract

Twenty-first century organizations face myriad factors influencing their business and technical environments. Mergers, divestitures, new opportunities and globalization, as well as emerging technologies and solutions, contribute to unprecedented levels of change. Organizations must be ready to quickly capitalize on change. The key to adaptability is an evolutionary systems architecture that can enable the organization to rapidly respond to business and technical influences in a manner that parallels strategic goals.

This presentation focuses on several important evolutionary systems architecture areas. Initially, we explore the most important holistic factors to balance when making architectural decisions. Next, we examine in detail several evolutionary models and their implementation. Finally, we delve into the future state of an evolutionary architecture within the implementing organization.

Introduction

Electrical utilities today are experiencing a very interesting time of change. Deregulation of the industry in the United States, although varying from state to state, has forced utilities to become much more competitive and adaptable to change. Some of the more aggressive organizations are taking advantage of deregulation and are thriving through innovative business process reengineering and enabling technologies. Others are treading water with caution and skepticism. Regardless of the stage of deregulation for a given utility, a great many are looking to their IT infrastructure as one of their main competitive tools in this new landscape. However, not all utilities are approaching their IT initiatives with a holistic mindset and implementing them with consistent and systematic methods. Some initiatives are driven by business and technical values and constraints, some are required under their deregulation environment, and still others may be implemented to leverage cutting-edge technology. Consequently, utilities have seen their business process models, IT infrastructure, systems and applications become increasingly more heterogeneous. This, in turn, has tended to make the integration of systems and applications in such an environment much more complex, expensive and difficult to maintain. Standards such as XML, Common Information Model (CIM) and the work done by the IEC TC57 Working Group 14 have made progress toward enabling a more systematic integration approach based on a common information exchange model.

An enterprise integration framework must also embrace a hybrid approach relative to technology, where solution components such as application servers Message Oriented Middleware (MOM), integration brokers and other building blocks are utilized to support a multitude of integration scenarios. In this model, the organization’s business processes, integration scenarios, message definitions and integration components are not only reusable but also extensible, with the goal of enabling a more agile and responsive enterprise that can capitalize on business opportunities while optimizing Total Cost of Ownership (TCO) and time to market. Such a framework requires a rigorous architectural and engineering effort, a strongly focused integration team, and as always, support from executive management and key stakeholders throughout the organization.

Deregulation Requires Integration

The recent problems that have surfaced from the California deregulation environment have dampened the pace and extent of deregulation across the United States. However, the fundamental business strategies of preparing and positioning for deregulation, however and whenever it arrives, have remained and even grown in importance. Strategies such as mergers and acquisitions, disaggregation of vertically integrated utilities, preparing for customer choice, outsourcing and e-Business all require some level of IT investment to realize their business benefits. In most cases, these strategies require a large degree of systems integration or even disintegration. Deregulation represents a major change to operations and leads to changes in the existing IT infrastructure. Therefore, it is likely that utilities preparing for deregulation will face more integration requirements and challenges. How can utilities better position themselves using their IT infrastructures to face the challenges of systems integration needs driven by deregulation?

Ten Principles of an Enterprise Integration Architecture Framework
  1. Understand organizational business drivers

      An integration framework must be developed within the context of business strategies and goals. Business domains within the organization must be understood and leveraged both in their own context and within the larger consideration of the organization’s business strategy. This understanding is the guiding light of any systems integration effort.

  2. Know the integrated business processes

      Understanding business strategies and domains drives the need to understand the business processes used to achieve these goals. Business processes must be understood from the standpoint of integration, both at the process and systems levels. Business events that either trigger a business process or arise as a result of a process must be understood. Integrated business process models will serve as both the blueprint and the scope for the subsequent integration work. These models should ideally be modularized so that they can be flexible enough to adapt to future changes driven by deregulation. Understanding the business drivers (the “What” and the “Why”) as well as the processes that tactically enable them (the “How”) provides the crucial foundation for evolving the integration architecture framework.

  3. Start with an architectural blueprint

      An enterprise integration architecture must balance best practices and strong principles with organizational values and constraints. Just like building a city, there will be tradeoffs along the way to reconcile principles with pragmatics and still achieve business goals in a way that optimizes cost and time to market. Equally as important, the concept of architecture is broadened to apply to the organizational domains of business, technology and organization because of their myriad interdependencies. Harmonizing these domains improves the chances for architectural success.

  4. Have a centralized integration management and project team

      A key component of the framework is organizing the development and ongoing support initiatives for enterprise integration. Since integration touches many business domains, processes and systems within a utility, a centralized organization that can coordinate and lead these efforts increases the chances for success. Obviously, the amount of authority and support that this organization has from the rest of the business is key to its chances for success.

  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 done to date by these standards groups 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 needs to focus on the information exchange between systems and applications with traceability to business process, and 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. There are many vendors who 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 evolving at this moment, 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 as well as the 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 have to 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 in place.
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 will have 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 corporate business vision and goals. The second layer deals with developing integrated business processes that will enable the organization to achieve those goals. The third layer deals with understanding the touch points between systems and business events inside or outside of 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. Look for consulting companies with specific utility knowledge and systems integration experience.



Figure 1: Business architecture for integration


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


Organizational Architecture

The organizational architecture of the framework sets up the foundational principles for driving people, capital and other infusion necessary to bring the entire framework into existence and then to evolve it as needed to enable business goals. Figure 3 shows the conceptual model of this architecture. The core elements of this architecture are: 1) the integration program management office that has the overall responsibility of delivering integration results to the organization; 2) the core integration architecture team that is responsible for creating and maintaining the integration framework and serving as the key consultants for multiple integration projects; 3) an independent architectural review board to serve as the internal auditing and quality assurance team; and 4) an enterprise integration knowledge base for all people involved to share and contribute to.



Figure 3: Organizational architecture for integration


Issues and Challenges

An investment in an enterprise integration architecture framework is strategic to the business. One of the first challenges is to engage the leadership of all stakeholder groups to provide support for the initiative. To “sell” stakeholders requires a clearly articulated vision, replete with benefits, consequences of inaction, frankness in dealing with the inherent risks, and most important, a clear definition of success and a clear plan to get there with results shown early and often.

There may be issues with establishing the business architecture. One of the most glaring challenges is the relative immaturity and disparate nature of the standards available today. A potential mitigation strategy is to have a good understanding of the underlying methodology and available standards of various guiding groups, and balance following the architectures with using the standards out-of-the-box.

One of the challenges of establishing the technical architecture is the abundance of integration technologies. Many forms of middleware and other solutions are available on the market. They are all variable in their features, functionality and “fit for the organization” but it is important to remember that no one product includes everything needed for an enterprise-level integration architecture. The key is to select the technologies that fit the systems to be integrated and to drive to a common architecture at the messaging level.

A common issue in establishing a centralized integration organization is the inherent overhead and politics that come with such a visible and far-reaching body. Management support is the key to having an efficient organization to manage and coordinate various enterprise integration efforts, all using the same business and technical frameworks. Also, there are many ways to ensure that everyone gets their opportunity to contribute in a visible fashion to such an important effort.

To be able to achieve the objectives described can be a daunting prospect for organizations. Choosing the best technology based on functionality, even if best-of-breed, can be a pitfall if there is no clearly defined path for getting to the desired end goal. Companies trying to integrate their systems need to employ a multi-step approach, and be able to take the time to do it right. Reference [4] describes an application integration maturity model that goes from pre-integration up to the external integration. Companies should use the model to assess where they are before they embark on the road to the enterprise integration architecture framework. This is essential to achieving a cohesiveness between the business, information technology and program management. Conclusion

We often hear that “The devil is in the details.” As practitioners of using architectural frameworks to help our clients meet their business goals, we face the challenges of making enterprise integration work on a daily basis. Deregulation will force utilities to change and become more competitive in many ways, and consequently organizations will be likely to leverage information technology to achieve these goals. However, technology alone will not justify architectural investment and bring real value to the organization. A balanced framework with the right mixture of business, technology and organizational architecture is the key. Technology principles must harmonize with organizational imperatives. The justification for an enterprise integration architecture framework, therefore, is based not on technology as an end unto itself, but rather as a key component to broader organizational achievement.

References
  1. M. Joe Zhou, Massimo Rolle, “Standards (CIM & XML) Based Integration Approach,” GITA2002, Conference, Miami, February 2002.
  2. IEC 61968 Part 1, “Interface Architecture and General Requirements,” CD, November, 2001.
  3. David S. Linthicum, “12 Steps to Application Integration,” SD2001 West, Conference, San Jose, April 2001. John Schmidt, “Enabling Next Generation Enterprises,” eAI Journal, July/August 2000.
© GISdevelopment.net. All rights reserved.