Chapter 10. Model-Based Management

In the past, enterprise organizations remained relatively stable for decades. Changes, for the most part, shifted some responsibilities among managers, brought new products to market. or introduced a new technology, but the basic business model remained fundamentally the same. Occasionally, various forces caused a significant change to the organization structure to streamline or consolidate. These changes, if significant, had ripple effects for several years as unanticipated consequences emerged. But even with significant changes, executives could often focus on certain aspects of the enterprise and assume the rest of the enterprise would be relatively unaffected.

That time is gone. The world is a dynamic place, and enterprises must be able to make significant changes on a regular basis, doing it right the first time. Enterprises are finely tuned to remain competitive, requiring special skills and resulting in greater complexity. There is less margin for error and less tolerance for inefficiency. SOA supports specialization through consolidation of capabilities, but the granularity of service units and the interconnections resulting from sharing services increases complexity. Managers need computer-based business models to manage this complexity and make optimal plans and decisions. Toward that end, model-based management (MBM) positions business models as a critical means for management understanding and control of the enterprise.

Business is undergoing a paradigm shift similar to that experienced by the U.S. automobile industry in the 1970s. Prior to that time, automobiles were designed by development and refinements of physical prototypes. Design of a new model could take five years. In the 1970s the U.S. automobile industry moved to the use of computer-based models to develop and validate the automobile design. Today, a virtual automobile is developed as a set of computer-based models. The automobile is crash-tested by computer. Various other forms of testing such as stress testing, vibration testing, and heat-transfer testing are conducted with computer models. Interactions and potential interference between parts are evaluated by computer. The time to develop a new vehicle model has been drastically reduced, and the quality of today's automobiles could never be achieved with the old prototyping methods.

Business organizations are faced with fundamentally the same problems. Organizations must be able to change to keep up with advances in technology and changes in the marketplace. Those that are not agile will fall behind. The changes cannot be trial and error like the automobile prototypes; they must be well designed and analyzed, considering many dimensions of effects, and they must be highly refined to achieve the necessary efficiency and quality of performance. This can only be done with the support of computer-based models.

SOA and BPM provide the basis of a consistent business architecture to enable more robust models to be developed. Models are abstractions. To be valid abstractions, they must be able to make certain assumptions about the consistency of the problem space. Business models will build on the concepts developed in the preceding chapters to provide increasingly powerful models for managing, optimizing, and transforming the enterprise. Service units are persistent components of the business with consistent mechanisms for their interaction. An agile enterprise based on SOA and BPM preserves most of the operational units and their optimized capabilities as the business changes, even though the management hierarchy may change dramatically and new lines of business may require significantly new value chains.

The development and support of business models falls under the responsibility of the Enterprise Intelligence service unit discussed in the last chapter. Business models support knowledge management, collaboration, insight, and innovation by capturing knowledge about how the enterprise operates, integrating current business data, and enabling managers and specialists to understand interdependencies and explore plans and solutions. A comprehensive solution must support a number of viewpoints based on a consistent metamodel (specification of modeling elements) so that the various viewpoints have a common, underlying representation of the design of the enterprise.

In this chapter we examine requirements for business modeling, particularly those requirements related to business design and the agile enterprise. This is an emerging technology, so some of the capabilities are supported by modeling tools and some needs are just gaining recognition. We look at current modeling technology and examine some enhanced modeling capabilities that should be integrated into modeling tools in the future. Finally, we consider tactical approaches that use currently available tools and technology.

Business-Modeling Viewpoints

Figure 10.1 depicts a number of business-modeling viewpoints that support the management of an agile enterprise, particularly the needs of executive management and the executive staff. Each viewpoint addresses an area of concern regarding the design of the enterprise. Managers also will deal with other models, such as financial models, product models, and distribution models, that are not included here. A human cannot consider all these factors together, and individuals with different areas of expertise need to be able to view different aspects of the business. In addressing a particular business concern, a team might collaborate, developing consensus around a solution while each views the solution from different viewpoints. The solution is consistent because the viewpoints are all related in various ways through a shared enterprise business model (EBM). Some models include data from business operations or records such as cost and performance data.

Figure 10.1. Enterprise Business Model Viewpoints.

Each of these viewpoints could exist, independent of an EBM. The enterprise itself defines the current attributes and relationships of the concepts being modeled. These viewpoints could be supported by deriving supporting data from current enterprise systems. However, these viewpoints would only reflect the current state of the enterprise. The value of the EBM is to explore future states of the enterprise and ensure that the various viewpoints are consistent with a particular future state. This is how we rapidly design quality automobiles, and it is the way we must learn to design enterprises.

We briefly discuss each of the viewpoints, clockwise from the top of Figure 10.1, in the following subsections.

Management Dashboards

Management dashboards typically provide monitoring of key process variables derived from business activity monitoring (BAM) and may raise alerts for specific events of interest. These should be presented in the context of the enterprise organization, value chains, and service units so that the manager can go deeper, select events or variables to monitor, examine the relationships, and consider related information and implications.

Existing management dashboards require extensions to reflect the broader aspects of the EBM and to open the door to exercise of management control through the dashboard.

Service Unit Performance

Service unit performance is supported by BAM but should also include cost data as well as timeliness, quality, and user satisfaction. These should be considered in the context of the organization structure responsible for the service unit(s).

Though service unit performance can leverage BAM capabilities, extensions are required to appropriately track and present costs and performance of services against level of service specifications.

Service Unit Specifications

Service unit specification focus primarily on the business capability and interface specifications. Service units responsible for master data management should be identified and the scope of their responsibility defined. The specifications should provide access to other aspects such as business processes, costs, organization structure, and use of supporting services.

Elements of this viewpoint exist for tracing value chains and development of software to implement services, but integrated models are needed. Additional content is needed to depict the use of the services.

Organization Structure

The organization structure represents the people and their positions and relationships in the organization. This includes both the management hierarchy and other working relationships that may be more temporary, such as participation on committees, task forces, and project teams. The organization structure should identify service unit organizations and chains of command, for purposes of different types of approval. It should also provide a linkage to role assignments for role-based access control (RBAC).

Existing organization modeling tools require modification and extensions to address the needs of the agile enterprise. An Organization Structure Metamodel (OSM) specification to address this need is under development at OMG.

Role-Based Access Control

RBAC defines the access authorization associated with various roles and the assignment of roles to people. People are associated with the organization structure, and authorizations may be associated with positions in the organization and with the context of particular business activities that require references to business documents or services. RBAC is discussed in greater detail in Chapter 6.

Development of a standard metamodel (modeling language) for business modeling of RBAC has been initiated at OMG.

Enterprise Logical Data Model

The enterprise logical data model (ELDM) includes specifications for all concepts, attributes, and relationships of the EBM modeling elements as well as for all data exchanged between service units. Existing data modeling tools provide the basic capability, but the logical data model should be extended to support alternative vocabularies and semantics—representation of the meaning of concepts, attributes, and relationships.

Business Rules and Regulations

Business rules and regulations that define constraints on business operations must be captured in a formal syntax using terminology and semantics that are consistent with the ELDM. The rules and regulations are linked to the service units affected and should be linked to specific activities of business processes for traceability.

Tools that implement Semantics of Business Vocabulary and Rules (SBVR), the OMG standard, provide capture and presentation of enterprise rules in a business-friendly form.

Strategic Planning

The strategic planning model captures strategic plans and draws on a number of other models that define service units, the organization structure, value chains, and enterprise directives as well as other supporting information sources established by enterprise intelligence.

Tools are available that support the OMG Business Motivation Model (BMM) that is the basis of the strategic planning model presented in Chapter 9. The extensions discussed in Chapter 9 are needed for integration with the other viewpoints and full support of continuous strategic planning.

Electronic Documents

Electronic documents are specified with XML schemas. Electronic documents are exchanged between service units as well as with external entities such as customers and suppliers. Some of the same documents may be used by different services, so each document is associated with the service units, choreographies, and operations in which it is employed.

The ELDM modeling tool should be able to represent the content of electronic documents as views of the ELDM but not the actual structure of the XML documents. The Information Management Metamodel (IMM) specification under development at OMG will support specification of the XML structures as well as the transformation between the ELDM and the XML representations.

Business Processes

Business processes define how the capabilities of a service unit are applied to respond to service requests and deliver value. These business processes also define the use of other service units to fulfill the requests. Thus business processes are an essential link in the integration of services and analysis of value chains. The business processes should also identify the choreographies they support and the electronic documents they use in exchanges.

These models should include representations of both automated and manual processes as well as those processes embedded in legacy applications.

At the enterprise level, these process models may be expressed as abstract business processes that specify the linkage between service requests and the participation of people or other service units. An abstract business process does not include details of flow control and internal, service unit activity but includes uses of people and other service units in a particular situation—a use case. Typically this will appear as a network of services using other services and people to achieve the top-level objective.

There are many tools that support business process modeling; some support both the BPMN standard with the integration of choreography provided by BPDM (both from OMG). A BPMN 2.0 standard, currently under development. will combine BPMN and BPDM into a single language with a metamodel and graphics.

Choreographies

Choreographies specify the sequence, content, and constraints of exchanges between business processes of participating service units. A choreography becomes a requirements specification for new participants who want to participate in similar exchanges. Choreographies may be modeled with related business processes, but they are distinct components because the same choreography may be used in exchanges between different participating service units and business partners. So a choreography used between service units (or companies) A and B may also be used between A and C or between D and C. Different participants can design their processes to be compliant with the choreography and, consequently, will be able to interact with any participant that is compliant with the complementary role(s).

Standards for XML specification of choreography have been developed—ebBP by Organization for Advancement of Structured Information Standards (OASIS) and WS-CDL by World Wide Web Consortium (W3C), but these are not integrated with business process models. The BPDM specification provides this integration along with a modeling capability appropriate for businesspeople.

Service Unit Cost Models

The cost elements of operating a service unit must be defined and allocated to the services provided, to define billing rates for services. This includes the costs of services used, both direct (value chain) services and supporting services. Consequently costs are linked into service unit specifications and value chains.

Generally, costs depend on the parameters of the requests. For example, the cost of a particular automobile engine will depend on the configuration of the engine, such as different carburetion and support for air conditioning, power steering, or cruise control. Consequently, the cost of contribution to a value chain will depend on the product mix that is described for that value chain (in other words, the particular use cases). The cost model should support these cost computations.

Other than spreadsheet applications, there are no standard tools appropriate for modeling service unit costs as part of the EBM. Spreadsheets are an appropriate interim solution, but rule-based computations may be the most flexible and accurate solution.

Value Chains

Value chains define the services directly engaged to produce business value for an internal user or external customer. A production value chain begins with a customer order and involves each service that contributes to fulfillment of the customer order. Internal value chains begin with a requirement for support of a capability of another service unit. These indirectly impact value chains that produce value for customers. Value chains are derived from service and business process relationships, and analysis should include links to costs, quality, timeliness, and capacity data that impact the value chain.

In general, value chain models deal with an abstraction of business activities. The analysis of service unit relationships—and their value chain contributions of cost, quality, and timeliness—requires new modeling and analysis tools. Much of the supporting information for a value chain model is built on the service unit specifications and business process models.

Development of a modeling standard for value chains is currently under discussion at OMG.

Disruptive Event Notices

Disruptive events must be identified and associated with sources, filters, or complex event processing for recognition. Each event notice of interest must be directed to the attention of a responsible person in the organization or to a process that causes appropriate action to be taken.

There has been considerable industry discussion of event-driven architectures, but this discipline is still emerging. OMG is considering specification of event modeling as an extension to UML to include complex event processing. This does not address the business aspects of establishing event sources and responsibilities for resolution. Enhanced complex event processing should include capture of precursor events to support analysis of the context in which a disruptive event has occurred.

Applications Portfolio

The applications portfolio must be managed as a record of existing and future business applications, the responsible organizations, the associated service units, the costs, and the technologies involved. Business applications are components of service unit capabilities. The application information and association of applications to service units is important, both for management of the application portfolio and for planning business transformations or technology upgrades. Some applications have embedded business processes that should be represented as abstract business processes to identify the links between service requests and services used for value chain analysis.

Some tools exist for management of an applications portfolio from an IT perspective, but they are not designed to address the relationship of applications to service units and business processes.

Business Dynamics

Business dynamics modeling is a technique for modeling systems behavior and trends using the abstract concepts of stocks,flows, and feedback. It has been used for analysis of performance of major construction projects, automobile marketing strategy, effectiveness of strategies in the war on drugs, and production capacity planning.

For example, in his book Business Dynamics, John Sterman describes the application of business dynamics modeling by General Motors to analyze the impact of used-car superstores on the automobile marketplace. The concern was that the availability of relatively new used vehicles was increasing price competition in the new vehicle market. The analysis revealed that the short-term leases offered by automakers were the source of a large volume of relatively new used cars. The superstores were a symptom, not the underlying problem. Leasing brings relatively new vehicles back into the marketplace, drawing customers away from new vehicles. Further analysis established that longer lease terms, such as four years, reduce competition with new vehicles and also improve the resale value of returned lease vehicles, thus reducing losses at lease end.

The automobile market model represents stocks of new vehicle inventory, late model vehicles in service, late model used car inventory, and older cars on the road. Stocks are increased and depleted by flows of new vehicle production, trade-ins, sales, and aging or scrapping of cars. Various feedback factors affect the flow rates.

Business dynamics models should be used to better understand the dynamics of the business ecosystem. In this context, applications of business dynamics may draw on service unit performance and capacity data, data warehouse data on product trends and relationships, and other, external sources of economic and market data. Historical data will be important for validating a model. If these data can predict past trends, they are more likely to be able to predict future trends.

Modeling Technology Standards

The OMG is the leading organization for development of modeling standards. OMG adopted the Unified Modeling Language (UML) for design of object-oriented programming applications in the late 1990s. Shortly thereafter OMG adopted Meta Object Facility (MOF) as the data model for storing and exchanging models. MOF with UML notation (graphics) has become the specification of a language for specification of modeling languages—in other words, a meta-language. MOF is essentially a subset of UML. It can model itself as well as UML.

Now all modeling languages developed by OMG are either UML profiles, i.e., extensions to UML or languages specified with MOF. A UML profile uses standard extension mechanisms of UML called stereotypes and tagged values to redefine standard elements of UML. This allows a user of a UML tool to apply a profile using an existing tool. A MOF model, on the other hand, represents the modeling concepts without the baggage of the existing UML specification. There are some things that a UML profile simply can't do because of UML restrictions—it's designed to model applications. In addition, a tool vendor that just wants to implement a specific OMG modeling language does not want to be required to implement UML first.

XML for Metadata Interchange (XMI) was developed for exchange of models between tools and repositories. XMI defines the way a MOF-based model is expressed in XML. Thus any modeling language that is MOF compatible automatically has a model exchange specification using XMI.

Around the turn of the 21^stcentury, OMG recognized that the standards it had developed based on the Common Object Request Broker Architecture (CORBA) middleware standards were limited to that particular middleware technology. At the same time, UML was gaining momentum. Some earlier work had introduced the concept of generating application code from UML models to improve application development productivity and quality. Driven by these factors, the model-driven architecture (MDA) was developed.

Under MDA, OMG develops specifications in the form of models that are independent of specific implementation technologies. This enables standards for services and applications to be implemented in different technologies and survive market shifts in technology preferences. At the same time, with code generation, it enables users of computer technology to develop applications independent of current technology so that their investment can be preserved. When the technology changes, the application code can be regenerated. There were technical challenges to MDA, so it took some time before UML tools were able to demonstrate MDA capabilities, but this technology is well established today.

The foundation established by UML, MOF, and XMI was extended with Query, View, Transformation (QVT). QVT is a language for operating on MOF-based models. The primary importance of QVT is for transformation of models from one modeling language to another. In early MDA efforts, the focus of QVT was on transformation of platform-independent models (PIM) to platform-specific models (PSM), as depicted in Figure 10.2.

Figure 10.2. OMG Model-Driven Architecture.

The PSM is more technology specific, and the associated language is expected to support the addition of features and tuning factors to tailor an application design to a particular technology. In some cases a PIM may be executed interpretively or translated directly to a computer programming language, but the transformation to a PSM provides the opportunity to optimize the executable design for the target technology.

MOF Model to Text specifies the transformation of a model to program code or other textual form. This can be used to produce text for documenting a model.

QVT can also be used for transformations of other models that can be expressed as MOF models and exchanged as XMI. It could be applied, for example, to transformation of a business process model in a proprietary language to a business process definition metamodel (BPDM) process model, as described in Chapter 3. In that case the transformation would be from a platform-specific language to a platform-independent language (BPDM).

OMG, particularly the Business Modeling and Integration (BMI) task force, has developed modeling languages for business. Though some models ultimately may be used to generate programming language code, the emphasis of the BMI effort is on development of models to help managers and consultants manage complexity and adapt the enterprise.

Currently, OMG business-modeling languages tend to be focused on separate aspects of the enterprise. As they evolve and as new modeling capabilities are developed, they should complete an array of viewpoints as proposed earlier. The standard OMG modeling technology supports the consistent representation of concepts shared among the viewpoints and provides the foundation for development of integrated specifications for a shared EBM.

Enhanced Modeling Capabilities

Current modeling tools tend to focus on the use of diagrams to depict concepts and relationships. However, diagrams, with some supporting notes and attributes, are not enough to address some complex problems. Modeling tools that implement these standards should incorporate simulation, multiple vocabularies, and semantics.

Simulation

Most of our current modeling capabilities are static representations of a situation. For complex systems such as an enterprise, it can be very difficult to comprehend all the consequences and dynamic interactions of a change. It must be possible to explore the implications of change with models before betting the business on a new strategy.

Simulation requires the ability to perform some form of execution of a model. There are tools that provide “executable UML” that might be considered a form of simulation. However, simulation requires an environment in which the effects of changes in inputs, outputs, and variables can be explored. This is more than testing a solution; it requires functions to simulate business activity and additional displays or reports for analysis.

There are narrowly focused business simulation models today. Simulation of product distribution and production scheduling are well established. These tend to be mathematical models for optimization. There is a multitude of modeling technologies in product design. No manufacturer of airplanes or automobiles would consider going into production without first doing extensive modeling and simulation on all aspects of its products.

There are some products that provide support for simulation of business processes. This can be characterized as discrete event simulation, where simulated business transactions flow through the processes. This can be particularly valuable for recognition of potential bottlenecks. Business dynamics modeling tools (discussed earlier) provide another form of simulation.

In SOA, the relationships between business processes become more complex, so simulation is needed on a larger scale and the effects of exceptions and failures become more important because one process can adversely affect many other business functions. It should also be possible to simulate the effects of changes in business rules. This enterprise scope simulation requires that business processes be analyzed and the associated operating data be captured or imported into a single process simulation tool, thus reinforcing the importance of standards for the exchange of models as well as standards for exchange of performance data.

Multiple Vocabularies

The use of multiple vocabularies has been discussed briefly in earlier chapters and has been addressed in the OMG Semantics of Business Vocabulary and Rules (SBVR) specification. Alternative vocabularies can be defined for a model so that its concepts can be expressed in a particular vocabulary for one community and in another vocabulary for another community.

The fundamental idea is quite simple. The words (that is, the vocabulary) used to express concepts are represented separately from the representation of the concepts, so there can be words for different vocabularies associated with the same concept. Presentation of the model is associated with a particular vocabulary, so when the concepts are presented, the associated words come from the designated vocabulary.

This is a powerful concept, particularly for global enterprises and systems integrators. Much of the effort involved in development of a common logical data model is devoted to developing consensus on terminology. If different communities were allowed to use their own vocabularies for semantically identical concepts, some of this effort might be reduced. Furthermore, this could promote acceptance of an industrywide common data model. The concepts and the form of the data associated with those concepts could be common, whereas the terms used to reference and display the data elements might be in vocabularies tailored to each community of users.

OMG is exploring the application of this concept to other specifications. However, there is a risk that including this capability in a standard could deter acceptance of the standard because it places an additional burden on the modeling tool vendor that must implement the standard. The absence of a standard does not need to prevent vendors from implementing this capability, but, of course, a standards-based exchange of models would not include the alternative vocabularies.

Semantics

The meanings of modeling elements are generally defined in natural language text and implied in the names given to the elements. This is often not very precise, and it does not provide characteristics in a form that a computer can use for computations or validation.

For example, semantics has become a hot topic for Internet search because the user would like to be able to express search criteria in familiar terms and have the search engine look for items that incorporate the ideas of interest without being limited to the specific terms in the user's search request.

SBVR also provides support for capture of semantics. The semantics are expressed in terms of attributes, relationships, and rules that define concepts in terms of other concepts. Like multiple vocabularies, this is a desirable feature for other models, but it adds to the complexity of the modeling tools.

Tactical Solutions

Standards and tools for business modeling are still emerging in the marketplace. In spite of the limited tooling support, enterprise leadership should not wait for generally available solutions to pursue the benefits of an agile enterprise. An enterprise with appropriately skilled personnel could implement the essential models as database applications in lieu of commercially available tools. These models might later be transformed for input to commercial tools.

The full EBM capability discussed in this chapter is certainly not required to start development of the agile enterprise. The SOA Maturity Model provides insight on the capabilities that are needed as the enterprise advances. The following are fundamental viewpoints for beginning the transformation:

• Enterprise logical data model (ELDM)
• Business process models
• Business rules
• Service unit specifications
• Application portfolio

The ELDM can be captured and managed with existing data modeling tools. Business processes can be modeled with existing modeling tools. Tools are also available for business rules modeling. Integration of the ELDM, business process models, and business rules models with the EBM can come later; dependencies with other models can be managed manually in the short term. Management of service unit specifications and the application portfolio can be addressed as conventional database applications, or they can be implemented with generalized modeling tools that support the specification of custom modeling languages. Such tools are currently being used for modeling aspects of enterprise architectures.

The business modeling marketplace will develop over time, most likely with development of tools focused on particular viewpoints. If these tools implement MDA modeling technology, there will be technical compatibility. However, this alone will not achieve unification into an EBM. The viewpoints share concepts that must be represented in a consistent way for all the viewpoints in which they appear, even when the specifications for these models expand and change over time. As the scope of adoption of SOA and the level of maturity increase, reconciliation of the viewpoints will become more complex. Modeling tool customers should express their requirements for standards compliance and additional product features to their tool vendors.

At level 3 maturity, the enterprise should develop an initial EBM in a shared database to integrate the viewpoint models of interest at that point. This should add the following viewpoints:

• Organization structure model
• Strategic planning model
• Service unit costs model
• Role-based access control model

The EBM database may be a conventional database or it may be a MOF repository product that is designed for management of MOF-based models. A MOF repository would not require transformation of the models to a database schema (e.g., a relational structure).

The modeling applications may update the database directly, or views of the consolidated model can be exported for modeling a particular viewpoint and then imported to apply updates. The latter approach enables the modeler to explore alternatives without affecting other viewpoints until a final approach is defined. This also supports the acquisition and integration of modeling tool products that provide more robust modeling and analysis capabilities.

To maintain consistency in the EBM, there must be agreement on the segments of the model that each viewpoint can change as opposed to those elements that it can view (read only). As an analogy with enterprise master data records, only the human resources organization can create an employee record or change an employee's status, only the finance and accounting organization can create and update account records, and only the engineering organization can define and revise part specifications. Eventually the EBM must become a database of master data records that are coordinated with the business activity master data records to maintain a consistent representation of the state of the enterprise. Management of the EBM and support for the viewpoint models should be the responsibility of the Enterprise Intelligence service unit.

As the scope of modeling expands, development and maintenance of an integrated EBM become similar to the development and revisions of a complex product design involving multiple engineering disciplines. The agile enterprise has an EBM that represents the current design of the enterprise and one or more future versions that represent planned transformations.

Eventually, the EBM is a primary source of enterprise information, a context for planning, and a basis for performance evaluation, accountability, and control. Associated modeling tools enable top management to explore changes and simulate effects before committing to transformation initiatives. The models then support tracking of progress of the transformation, compliance with directives, and achievement of enterprise goals. That is the ultimate objective of MBM.

The agile enterprise is an enterprise in which managers are enterprise designers. They do not design, produce, sell, or deliver products themselves; they are responsible for creating and maintaining the enterprise system in which products are designed, produced, sold, and delivered. They must ensure that everyone knows their responsibilities and is accountable for results, and they must ensure that activities are coordinated and people have the tools they need to do their jobs.

In the past, managers could design the enterprise with paper and pencil, trial and error, based on experience and intuition. These tools are no longer good enough. Just as the automobile industry could not meet today's market demands without computer models, so managers cannot meet the competitive demands of today's emerging markets without computer-based models to design and adapt the enterprise.

Not all the needed tools are available today, but a general approach to design of an agile enterprise, as described in this book, provides a basis for development of more robust modeling capabilities. The tools are coming. At the same time, the limitations of current tools are no reason to delay the journey up the maturity model. The greatest challenge is not the current lack of tools, but the need to change the way people think about the design of the enterprise and the role of information technology. The time to start the transformation is now.