Relating Components and Enterprise Integration-Part 1 -- ADTmag

Relating Components and Enterprise Integration-Part 1

By Desmond D'Souza
July 13, 2001

Integration is a common theme in today's "hot" enterprise technologies-e-commerce, enterprise application integration, component technology, and Enterprise Java Beans. When re-architecting code, you must integrate it with existing code. Improving a business process means integrating with other business processes. To integrate with an e-commerce partner or assimilate an acquisition, you must integrate with the relevant parts of another company's systems, processes, and culture. When building a new software application, you must integrate with other applications, databases, and business processes.

UML patterns and the Catalysis method¹ can be used to handle some of the challenges of enterprise integration. I co-developed the Catalysis method, a UML-based approach to component-based development, with Alan Wills between 1992 and 1998. We based it on real project experience, emphasizing precision, traceability, model and framework reuse, and crisp architectures, all aimed at "minimizing the magic" of development. In this two-part series, I will describe how component-modeling, based on Catalysis, can address some aspects of enterprise integration.

THE INTEGRATED ENTERPRISE
An integrated enterprise is one whose multiple business areas, strategies, architectures, organizational units, operations and processes, automated systems, and data and information-combined with the organization's understanding of these components-form a consistent, cohesive, and adaptive whole. This definition covers a broad range of issues, but you can reduce it to the two main dimensions of variations shown in Figure 1.

Horizontal variation comes from different business areas, such as marketing, engineering, and sales. Marketing teams hold events and track customer and product trends, while engineering teams design and develop new products. Each area has its own narrow view of the enterprise.

But marketing and engineering teams also both deal with overlapping views of Product Specifications and Release Dates. This overlap raises an integration issue: Do the different areas, their terminology, business understanding, business processes, and corresponding supporting software systems and databases, actually work together as they should?

Vertical variation comes from different levels of concrete operational detail. In any business area, such as sales, there is the executive view, focused on strategies and key operations; operations staff, working at the daily business process level; and supporting applications and databases. These "vertical" points must be consistent so that application development supports business processes and the information they use and support and inform higher level strategies and objectives.

Any two distinct points in Figure 1 represent an integration problem, across different business areas and different levels of abstraction. This is a complex picture, and models should help people comprehend, manage, and evolve it more effectively.

MODELING THE ENTERPRISE
A model describes key aspects of your software or business. For example, an architectural model of a complex software system might focus on its concurrency aspects, while a financial model of a business would be concerned with its projected revenue. Models should be explicitly represented and managed, precise enough to aid unambiguous understanding and analysis, and abstract enough to focus attention and provide insight. A model is simpler to comprehend than the thing it represents; well-structured models can make complex systems comprehensible. Modeling helps users achieve consensus and understanding about what exists or can be built, since it provides a concrete focus to agree and disagree about. A good model can be validated readily against concrete examples, and perhaps against the real-world operational data it is supposed to represent.

Your team can use models at all levels, from business strategy and process through software applications, databases, and networks. Models take on many forms-graphical, textual, and more or less automated. At the less-familiar business level, aspects of business strategy may be modeled in spreadsheets (for numeric metrics), QFD matrices (for stakeholder objectives through software requirements and design alternatives), and Balanced ScoreCards (for establishing strategic intent and motivating measurable performance goals). More familiar models to us software developer types cover application specifications, software architecture, and network and database designs, as shown in Figure 2.

Of course these models are not independent of each other: The performance of a deployed application depends on the database design, the network design, and the load on the server; the database design must be adequate to support all applications that use it. This leads us to some of the primary challenges of enterprise modeling.

ENTERPRISE MODELING CHALLENGES
Figure 3 outlines some serious challenges of modeling at the enterprise scale. These challenges include separation, integration, architecture standards via shared models, seamlessness, and synchronization.

Separation
Don't try to build a single integrated model of everything in your enterprise.* Even if you did not run out of wall space, the grand unified model couldn't provide a focused and simple way of describing a single concept to several horizontal or vertical groups. A single model cannot do a good job of describing Product for both sales and engineering (horizontal separation); or include both the logical information model and the detail optimized physical database model (vertical separation). Enterprise scale models must be federated, separating both horizontal areas and vertical layers.

The modeling concept you need here is the UML's package. This concept lets different packages provide their own views of a Product. The same kinds of separations apply to packages of software designs. Different interfaces of an object may be better defined separately, and modeling should separate the interface definition from the implementation package.

Integration
Separated models often overlap in certain places. When engineering and marketing staff collaborate, they must have a common vocabulary and process to work together-this is horizontal integration. Similarly, when a new data warehouse pulls in information from engineering and marketing databases, the two schema must be integrated-also horizontal integration. Or, when the information gleaned from this data warehouse is used to shape marketing and engineering strategies, the warehouse model must be clearly related to the strategy models-an example of vertical integration.

The UML modeling concept you need for horizontal integration is the ability to compose two packages: you should be able to import the contents of two different packages with overlapping elements, and establish appropriate relationships between them. Mapping between concrete and abstract models, which the UML calls a "refinement," provides vertical integration and is the foundation of traceability from requirements to code.

Architectural coherence and standards
You must build models of this scale to a coherent architecture, with standards for describing similar concepts. For example, if you develop four different applications with an object model mapped to relational tables, you should use a single object-to-relational mapping architecture documented in a shared model.

The same principle holds for business models. When sales and information technology departments enter into different forms of service-level agreements, they should be able to adapt a single, generic service level agreement model. This applies the UML concept of a model template or "framework" in a shared package.

Seamlessness
You want to smooth over the "seams" between different kinds and levels of models, such as process, component, object, and data models, and across different business areas. This means handling more than one kind of meta-model, and relating models that are based on different underlying meta-models. It requires the forthcoming UML ability to handle multiple dialects, consistently relating models to each other within and across dialects.

Synchronization
Besides keeping integrated models in sync, you must also keep models in sync with the real world that you're modeling. For example, changes to code should be reflected as changes to models that are supposed to represent that code (and vice versa).

But this synchronization is not just a code issue. Business processes might change without their models being updated. It's a good idea to detect such divergence and take corrective action. Similarly, changes to business models should be deployed to the actual processes, which might involve upgrades to hardware, software, and personnel.

Of course, because models are generally much smaller and simpler than the things being modeled, you should offset the cost of building, integrating, and managing models with the cost savings from more efficient operations and effective designs within a good enterprise-modeling environment.

INTEGRATING DOMAIN, PROCESS, AND PRODUCT MODELS
To build a model of a business solution, you combine selected tool or product models with particular business process models to solve a generic problem domain model. Figure 4 shows how these models are structured. The models of software products and tools, in turn, have multiple views and levels of abstraction, from their specifications through their architecture, design, and implementation; we will revisit that in the next installment.

In Figure 4, based on Catalysis modeling work done for a client, there are "essential" problem domain models describing the areas of customer service and deployment management; these models would be correct, although abstract, descriptions for almost any business that dealt with customer service or software deployment. To create these models we abstracted from an as-is model of current business processes. Separately, we have models for particular software products that support some parts of the customer service problem (service requests), or the deployment management problem (a software distribution tool). Finally, the to-be business solution is modeled by (re-)defining business processes around these new products, and showing how they relate to the essential model of the problem domain itself.

Note that the problem domain models are clearly independent of any particular vendor's software or detailed process. Product models are based on the domain model that they were designed to address. Your actual business solution will be the result of deploying and integrating selected products in concert with your particular business processes to solve your domain problem.

Businesses solve architectural problems with some combination of business processes that integrate selected software applications. Clearly, you could combine many alternate processes and software applications to solve the same essential business problems. Enterprise modeling with Catalysis is a way to integrate across all levels and views of the enterprise.

CONCLUSION
I have outlined the modeling aspects of enterprise integration and shown how models ranging from business strategy through processes and software applications and databases should be related to each other. Next time, I will show how a component-based approach based on the Catalysis method offers a way to address both component-based development and the modeling aspects of enterprise integration.

Reference