A major automobile manufacturer with a lean production system needs to quickly connect its information systems with one of its backup suppliers, as its major supplier has been hit by a natural disaster. Two major telecommunication companies merge. A major computer manufacturer wants to form a strategic alliance with a television manufacturer. In each case, the participants must leverage mutual core competencies and establish mutually profitable marketing, cost-sharing, and pricing policies. Global competition and ever-shorter product/service life cycles increase the need for collaboration among enterprises. In this context, agility and flexibility are typically cited as keys to success [11], as they enable identification of and response to new market opportunities ahead of competitors.
Agility and flexibility both require timely access to relevant data and knowledge often distributed throughout the extended enterprise. Inter- and intraorganizational cooperation implies configuring requisite human and physical resources into business competence. Such resource configuration and its quick deployment require dynamic decision-support capabilities focused through a holistic lens to assist decision makers. A dynamic decision-support system adapts to changes inside and outside the organization. A holistic decision-support system encompasses all the various perspectives of an organizational decision, including process, function, resource, and financial. As products and services sold by organizations increasingly combine best-of-breed capabilities, a configurable, integrated decision-support infrastructure must be in place to support quick response to changing market conditions.
Enterprise modeling (EM) increasingly involves the modeling and analysis of processes, objects, and information flow within organizations (see Table 1). However, in spite of the presence of a number of methodologies and toolsets, EM richness has not been harnessed in the decision-support activities of organizations. One main reason for this limitation is a lack of interoperability and mechanisms to cross-reference the various perspectives by which an organizational decision model might be realized [2, 3, 9].
Agility and flexibility can be achieved via enterprise modeling management (EMM), extending the notions of traditional EM to facilitate a federated approach to specifying, sharing, operating on, and “driving” infrastructure mechanisms to create virtual decision-support environments in much the same way model-driven architecture is employed [7]. The two main EMM objectives are: define and establish the orientations of meta-modeling; and perform model-mapping between various organizational EMs and the operators needed to integrate, manipulate, and store these representations. EMM represents a significant new direction toward achieving an organization’s goal of providing quick response to the changing business environment [4].
Over the past decade, the Unified Enterprise Modeling Language, or UEML, has evolved to address issues of interoperability from a basis similar to the ideas behind EMM, but the effort to date has not concerned itself with middleware infrastructure for decision support, focusing instead on representational efficacy and standardization.
Building on the foundations of UEML, we’ve now developed a vision for “dynamic decision support” based on the concept of a decision support environment (DSE) (see Table 2) that facilitates decision tasks by creating—on demand—a configurable system that inherits from various organizational representations. These representations are associated with various EM toolsets, including those resulting from enterprise model management operations on UEML representations.
Although the limitations of the EM approaches have been recognized for some time, the first steps toward an integrative solution were only recently taken by the European Union (EU). Since 2002, the Information Society Technologies, or IST, EU research program has funded the UEML project [5] (www.ueml.org), aiming to create mechanisms for common representations for EM tools. The project includes both industry and academic institutions building on existing EM capabilities and tools (see Table 3).
A DSE can be considered a “virtual war room” for a specific task, where all participants monitor information relevant to their own context.
Due to its being initiated by the EU, UEML is likely to become the de facto standard for EM, at least in the EU and in organizations interacting with the EU. As the EU continues to be an economic leader with considerable market size and political clout, such standardization implies that EM toolset vendors will increasingly make their products UEML-compatible. Though the introduction and subsequent diffusion of UEML or its derivatives over the next five years should yield new opportunities for dynamic decision support, it hasn’t received much attention due to the variety and complexity of EM methodologies and artifacts.
The meta-modeling constructs of UEML promise to help facilitate and execute decision tasks in collaborative environments. UEML’s ability to function as an inter-lingua among different model representations can be the basis for creating dynamically configurable DSEs to facilitate the integration of business models among different units and/or organizations. This integration can be achieved through a layered approach, where application- and/or vendor-specific organizational models reside on the lower layers, and information exchange takes place at the upper layers, which are loosely coupled with lower-layer models via UEML representations of the lower layers.
Dynamic DSE Architecture
Here, we explore the concept of dynamic DSEs with an example scenario of a complex business decision involving several organizational entities, along with multiple functional dimensions, including process and financial. The decision to be made requires careful analysis of possible combinations of decision variables (some may be time-sensitive) leading to multiple possible outcomes.
Consider a strategic alliance between an airline and a travel agency specializing in vacation packages. The goal is to offer targeted vacation deals to mutual customers, especially at the last minute to fill empty airline seats, along with unsold vacation capacity. Such collaboration requires integration of customer information, including past flights/vacations taken, most frequented destinations, preferences, and schedule information, as well as the price-structure of the combination. The time-sensitive nature of such deals means speed is an important factor. Moreover, the participants are better off loosely coupling their systems than they are building expensive dedicated ones. This way, any change in their internal business processes would have no affect on the collaboration infrastructure. The architecture to facilitate such collaboration (see Figure 1) consists of four layers:
Layer 1. Business applications, data, and EM models. The foundation of the IT infrastructure of any organization is a set of core business applications (such as order processing, invoicing, purchasing, logistics, and human resources management). They are represented in a variety of EM models (such as A_EM-Price, A_EM-Schedule, for Airline A, and T_EM-HR, T _EM-VPack, for Travel Agency T, in the bottommost layer of Figure 1). In current architectures, the models are isolated and standalone. They might have a subset of common entities but are not dynamically connected. For example, changes in traffic patterns in certain segments may be captured in reservation records; however, any corresponding change in schedule and/or price for that segment is captured in two other separate information models: A_EM-Schedule and A_EM-Price. This renders decision making difficult, as the effect of the change in one organizational element (such as price) on others (such as traffic) cannot be evaluated instantly. Moreover, as dynamic information (such as natural disaster and local events in specific geographic locations) comes through, isolated systems do not provide an automated way to respond to the information (such as price/schedule change).
Layer 2. UEML representation of models. The lack of interoperability is resolved in the next higher layer through EU-proposed UEML capabilities. UEML aims to enable rules, constructs, and syntax for facilitating interoperation among disparate models, thus providing a standard way to integrate EMs. Each EM (such as reservation database, price models, and external information) used by the partnering airline and travel agency can have corresponding UEML representations, thus providing an upper layer with cross-referencing capability among the various EMs. Consequently, UEML helps give top management a more holistic view of the organization than a single EM alone could generate.
Layer 3. DSE middleware. Systems architects utilize this fundamental capability of UEML—cross-referencing and integrating organizational models—to conceptualize dynamic DSEs; it is outlined in the next two higher layers of Figure 1 in the form of DSE middleware and DSE. UEML representations can be utilized to derive UEML “views,” or a new UEML representation abstracted from underlying UEML representations. These views should be customized for a particular decision context, possibly by manipulating the underlying UEML models through specially designed EMM operators (such as query, composition, difference, and subset). We refer to them as “materialized UEML views.”
The various UEML instances, combined with the EMM operators and associated materialized representations that can be created, constitute the new “DSE middleware” layer in Figure 1. A1-A2 and T1-T2 are examples of such views corresponding to particular decision contexts. A1_CustomerPriceSensitivity represents a way to integrate customers and their past purchase prices (a subset of the customer and reservation data warehouse) with a new pricing model to evaluate the effectiveness of past purchase prices. A1_CustEmptySeat integrates the current reservation schedule and past customer destinations (another subset of the same warehouse) to identify the customers most likely to respond to a targeted last-minute offer from the travel agency.
T1_CustPackage is functionally similar to A1_CustEmptySeat. Similarly, T2_FuturePrice employs dynamic information about various travel location and vacation categories (such as cruise, theme park, and resort), as well as past prices to project future prices for each category and location. These views may all be constituted by querying the UEML representations in the lower layer. The extent to which a particular model may be queried and/or operated on depends on the decision context and what information must be protected as private and what can be exposed and shared as public.
Layer 4. DSE. Each of the derived UEML representations (such as A1-A2 and T1-T2) can be used in separate DSEs presented at the topmost layer—DSE. Each DSE inherits the necessary toolsets and capabilities from the corresponding EMs via the component UEMLs. That is, DSE A1 in airline A, incorporating economic models and the customer profile information model extracted from UEML representations, inherits the capabilities of each constituent EM tool. In addition, changes to EMs at lower layers can be abstracted to higher middleware layers through relevant EMM operators. The intermediate UEML layer, by providing cross-referencing capabilities, enables the creation of dynamic connections among the many model elements. Each such DSE can be generated on-the-fly, as a particular decision task becomes relevant and urgent. Meanwhile, DSEs are not limited to a particular artifact; rather they constitute a context in which activities relevant to a particular decision task take place and in which actions can change the states of the objects (such as people, process, and information) in order to execute the strategic business decisions made by top management.
As the ability to respond quickly becomes a major driver of success in business, facilitating integrative and dynamic decision making becomes imperative.
Similarly, the notion of dynamic decision support can be extended throughout the organization. Based on a particular decision context, each collaborating organization can create a materialized UEML view (or use an existing one) appropriate for the context. These views (such as A2 and T1) are used to compose the integrated derived UEML view. Like their intraorganizational counterparts, the integrated views are generated through specialized EMM operations. The only difference between them and their counterparts is that the operations are done on interorganizational UEML views.
By doing so, the materialized UEML views underlying an interorganizational DSE contain only sharable public models and information. Participating organizations need not expose their entire organizational models. Instead, they can choose only those subsets from respective intraorganizational views necessary for the task at hand. In Figure 1, the view A2T1 consists of the views A2 and T1 and is the basis of the interorganizational DSE that enables the airline and the travel agency to target customers most likely to respond to the combined airline/vacation package. Similarly, a DSE for evaluating price sensitivity can be created where each organization keeps the internal details of its pricing mechanism hidden, exposing only the values.
A DSE can be considered a “virtual war room” for a specific task, where all participants monitor information relevant to their own context, take necessary action, and configure the system per their business needs, subject to the privacy and “sharability” policies relevant to the environment. Such action is facilitated by querying organizational objects captured in the UEML models inherited by the DSE. Apart from facilitating a collaborative endeavor, a DSE should also enable “what-if” scenario analysis by utilizing the knowledge and information captured in composite organizational (or interorganizational) models.
UEML Views for DSE Middleware
Here, we discuss the “materialized views” underlying DSEs, using ontological representations of UEML models to demonstrate the dynamic architecture concepts discussed earlier. We demonstrate these concepts through ontology for several reasons. A UEML model, capturing information about processes and objects in a business enterprise, has an inherent ontology. Creating a new model, based on models from different contextual domains would be ineffective without knowing the domain-specific assumptions and knowledge structures associated with each constituent model.
The developers and designers of UEML emphasize the significance of having enterprise ontologies [10]; they identify “semantics and syntax to support integration” as the topmost methodological requirement [6]. We use an existing toolset—Protégé (protege.stanford.edu/)—to create the views, demonstrating how to use it to realize DSEs, and suggest future enhancements. We explore two cases of merging ontologies to create materialized views. In one, there are no syntactic conflicts; the other is more complex, where information structure and syntactic differences play a significant role in producing DSEs.
Two ontologies—the customer and the reservation information for the airline (AR)—are merged in Figure 2. The customer ontology is derived based on the customer database of the airline, shown with the “individual”-type customer highlighted in the bottom left-hand corner of the figure. The reservations ontology is based on the data-warehouse schema of past reservation records. The merge operation is shown in the EMM model operator section in the next-higher box. Merging these two ontologies generates a view of the customers, along with their past records. This derived view (the topmost box in the figure) is linked with the database (for customer) and data warehouse (for reservation records). It underlies the DSE (not shown in the figure) targeted to match customers with likely destinations.
A yet more complex operation is needed when the airline and the travel agency combine and apply their individual business ontologies (possibly the result of merging other ontologies) to support the interorganizational DSE. In this case, structure and semantics are an important factor, and separate operations are needed for integration while keeping the structure of the underlying information the same. Structure and semantics are reflected in the EMM operation section in Figure 3 whereby a set of commands is required to map related concepts in each business domain; for example, the tools suggest merging the “customer” concept from the two domains, as each has the same name. However, although “payment” in the airline’s ontology and “payment_information” in the travel agency’s ontology store similar kinds of information and have the same structure, the operators are unable to recognize this similarity due to syntactic differences. The merge operator needs an explicit command to treat them the same (noted by the superscripted “m” for mapping in Figure 3).
Similar operations are needed for the properties of each domain concept; for example, contact_information in airline ontology and “contactinfo” in vacation package refer to the same property of the “customer” concept, though they are not shown in the figure. Such operations, performed manually here, can be (partially) automated through business rules and syntactic similarities. The final merged version of the two ontologies inherits from the constituent ontologies. Scenario evaluation and decision tasks can then be performed by exploiting the link between this high-level model and the low-level organizational system artifacts in the airline and in the travel agency.
Conclusion
As the ability to respond quickly becomes a major driver of success in business, facilitating integrative and dynamic decision making becomes imperative. DSE and DSE middleware (based on the UEML project) are geared toward achieving this goal by incorporating dynamic interoperability via enterprise model management. The UEML initiative takes a significant step in linking organizational representations heretofore associated with standalone EM toolsets. While UEML targets interorganizational application integration, our contribution is in developing a set of middleware concepts that utilize UEML’s meta-modeling constructs toward the creation of environments supporting complex, time-sensitive business decision making.
Research is needed in how to develop EMM operators that provide the UEML representation manipulation capabilities necessary for “operationalizing” DSEs. To create a dynamic DSE from multiple UEMLs, the materialized views must be the result of business-rule-based mathematical and/or logical operations (such as composition, difference, and subset) applied by a DSE architect on the constituent models. While the UEML project has not formally addressed this issue, some involved in the effort have likened the composition operator to heterogeneous database schema integration [8]. Significant work on meta-modeling (such as meta-model operators, particularly composition) is germane in this context [1].
We expect meta-modeling research to be transferable to EMM and DSE middleware. The related synergies are likely to create significant new opportunities for global organizations competing in an increasingly complex environment. DSEs for collaborative alliances must be rapidly configured on the fly with dynamic decision-support capabilities, tapping organizational assets and facilitating the seamless execution of decisions.
Figures
Figure 1. Dynamic decision support environment.
Figure 2. Example architecture for an intraorganizational DSE created by a merge operation on two ontologies: airline and travel agency.
Figure 3. Creating an integrated view for interorganizational DSE involves complex operations.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment