Abstract - Several enterprises around the world consider Information Technology (IT) as an entity separate from its core business functions. This is the result of a mindset that considers IT as automated systems that support business functions as opposed to considering it as an enabler for achieving business goals and thus being integral to the business. This very mindset has given rise to the concept of “Business-IT alignment” — a concept that intends to align two separate entities. Unfortunately, for most enterprises this alignment is difficult to manage, hugely expensive, and often fails to deliver the intended business goals. This article attempts to change this mindset and provide a guideline based on real-world experiences in creating a service-oriented enterprise, using a model-driven approach, where IT is considered an integral part of business.
Enterprises do not, or should not, act randomly. When an enterprise executes a business process (action) or applies a business rule (directive), it should be able to say why (i.e., the motivation for the action or directive). In other words, the key motivation for business to plan for a course of action and execute is to attain its business goals. Business goals help an enterprise to attain its vision. A Service-Oriented Enterprise (SOE) enables the attainment of business goals by offering services both externally and internally and thereby creates a flexible model for realizing business capabilities. However, such flexibility cannot be achieved unless Information Technology (IT) is considered an integral part of business. Such a fusion not only helps enterprises to attain its business goals but also helps them respond to market changes quickly.
Unfortunately, several enterprises around the world consider IT as an entity separate from its core business functions. This is the result of a mindset that considers IT as automated systems that support business functions as opposed to considering it as an enabler for achieving business goals and thus being integral to the business. This very mindset has given rise to the concept of “Business-IT alignment”—a concept that intends to align two separate entities. Alignment necessitates some kind of an adjustment—adjusting business due to IT constraints or adjusting (customizing) IT due to changes in business. Unfortunately, for most enterprises this alignment is difficult to manage, hugely expensive, and often fails to deliver the intended business goals. Solving this problem requires a change in this mindset—it requires a paradigm shift where IT is not considered separate from business (requiring alignment) but an integral part of it. This integration is made possible by establishing the methods, tools, and assets to create a SOE that should ideally be able to realize the desired capabilities of the enterprise by offering business relevant services both externally and internally. It is important to note that the meaning of the term “service” is contextual and is qualified by the model used to represent it. The models that a SOE must produce, manage, and maintain to ensure the attainment of the overall enterprise vision are:
- Motivation Model;
- Strategy Model;
- Process Model;
- IT Model;
- Operating Model; and
- Governance Model.
A close inspection of the Motivation, Strategy, Process, and IT Models will reveal that each model successively builds additional levels of elaboration over its preceding model thereby ensuring the realization of the business motivation, defined by the Motivation Model, through the IT Model. The Operating Model and the Governance Model helps to monitor and manage the attainment of this realization as a continuous process ensuring that the IT Model is always derived from the business motivation and hence not requiring a forced alignment. This ensures that IT is considered as an integral part of business, i.e., each and every IT investment is made for achieving business goal(s) as opposed to being “aligned” to meet business goal(s). However, this does not discount the need to align existing IT solutions that existed before an enterprise started practicing SOE but suggests a paradigm shift that is necessary to adopt the new world order.
Figure 1 – Service-Oriented Enterprise Models
A Motivation Model for an enterprise should be able to articulate what an enterprise wants to be (end) and what it has decided to do in order to become what it wants to be (means). OMG’s Business Motivation Model provides a scheme or structure for developing, communicating, and managing a motivation model (business plan) in an organized manner. It categorizes Ends as Vision (overall image of what the enterprise wants to become) and Desired Results (derived from Vision), and Desired Results as Goals (qualitative) and Objectives (quantitative) and Means as Mission (overall image of ongoing operational activity), Courses of Action (strategy and tactic), and Directives (Business Policy and Business Rule). The Motivation Model should be the basis for identifying business services that are derived from business goals and to identify business units that need to be optimized for delivering business value and thus provide the foundation for creating the Strategy Model.
A Strategy Model analyzes and elaborates the courses of action indicated and/or identified in the motivation model. A strategy model should be effective in analyzing what is needed, what’s not, and what can be outsourced in terms of people, process, and technology. It should be able to clearly articulate what a company needs to be able to do to execute its business strategy (for achieving the business goals) in terms of capabilities. It should be able to identify what externally facing business services the enterprise should offer and to whom in addition to the internally exposed services for realizing the aforementioned capabilities. It should also be able to identify the areas of improvement and transformation for organization, processes, services, and IT systems in order to attain business goals and to be able to offer desired capabilities.
Enterprises should be able to group cohesive business functions into manageable business units (also known as business components) that are responsible for managing their own capabilities, processes, IT systems, and resources. Such business units should be able to interconnect using business services for executing enterprise level business processes. A Strategy Model not only provides the foundation for the Process and IT Models but also lays a foundation for the Governance Model. It ties together people, process, and technology elements into manageable business units (components) that have the potential to operate autonomously. The Strategy Model can then be used to identify “hot spots” (as in a heat map) to identify areas of transformation. A possible outcome could be to outsource a “hot” business component that has high operating costs once a provider is available that can offer the required services allocated to the business component at a much lower cost and can provide a comparable or higher quality of service. It is much easier to effect such a transition if the organization was componentized in the first place in creating autonomous units that can manage themselves with clear separation of concerns in terms of business services offered and required.
Effectively, such a model helps evaluate business components against strategic goals, answers what’s needed, what’s not, and what can be outsourced. Moreover, it can also identify different entry points to introduce services (e.g., customer and supplier facing business components and components that have many “internal” customers that need to expose services for their customers). Such a model also helps highlight Business and IT gaps, misalignment of IT capabilities to meet business needs, duplication of IT functionality across the enterprise, and overextension (as opposed to separation of concerns) of IT systems that support multiple business components.
A Process Model elaborates how the organization intends to execute its capabilities. It derives the processes identified for transformation from the strategy model and analyzes the variations in terms of process execution, information needs, and enforcement of business rules. Identifying key business entities, their lifecycle states, and access policies as a part of developing the process models not only helps accelerate process discovery and identify business relevant services but also helps in creating the groundwork for an Operating Model where the performance of the business processes can be measured by measuring the business entity lifecycle transitions. Identifying services during this phase and/or elaborating the services identified during the strategy modeling phase provides the foundation for creating a service-oriented IT Model where the services can easily be re-orchestrated to accommodate process variations and/or for process transformations triggered by market and/or organizational changes.
It is important to note at this stage that the Motivation, Strategy, and Process Models primarily deal with the semantic aspect of services with the Motivation Model defining the vision and the Strategy and Process Models elaborating such a definition in terms of services that will help in realizing that vision. The Strategy Model looks at it as a set of interconnecting business components where such interconnections are made possible using required and offered services and the Process Model looks at it as a set of activities inducing state transitions of business entities where such activities can be exposed as services for both business component inter-connection and intra-connections for creating end-to-end enterprise process flows that are flexible and can be dynamically choreographed based on process variations and even be re-choreographed driven by changes in the market or in the enterprise.
An important takeaway from this discussion is that though each business component is responsible for managing its own processes they need to offer services that enable end-to-end enterprise processes to be realized through interconnections of such business components.
An IT Model defines the structural aspects of IT systems which comprise software, hardware, and connection components and enables automation of specific business processes defined in the Process Model. It is important to note that not all processes in the enterprise need to be or can be automated. However, automated business processes, sub-processes, and tasks can be exposed as services with varying level of exposure scope to enable process choreography. In other words, the IT Model effectively creates a structural model of the IT system that implements business services using IT infrastructure. The IT Model not only needs to support the semantic aspect of the services discovered using the Strategy and Process Models but also needs to provide a standard and consistent representation of the service realization along with satisfying the operational expectations (Quality of Service). The representation (syntactic aspect) refers to the mechanisms needed to interact with a service realization, e.g., message formats, communication protocols, security etc. Quality of Service (QoS) refers to the operational aspect such as response time, throughput, availability, and reliability for the service realization. In other words, the service realization implements both the semantic and non-semantic aspects (representation and QoS) of a service. However, separation of concerns mandates that we separate the semantic and non-semantic aspects of a service into architecturally distinct layers; one that implements the semantic aspects of the service and the other that implements the non-semantic aspects.
The semantic aspects of a service can be implemented using process execution engines and other container technologies. The non-semantic aspects can be implemented using hardware and/or software components that implement the Enterprise Service Bus (ESB) pattern. It is important to note that the QoS aspect needs to be handled by both the ESB and the execution container, with the execution container exceeding some of the QoS requirements like performance (since the mediation performed by the ESB can only degrade the performance) and in some cases the ESB improving the provider’s availability by routing to an alternative execution container. However, from a governance perspective QoS is primarily the responsibility of the non-semantic layer (realized by an ESB) since it is this layer that is responsible for service exposure and thereby it’s specification of non-semantic aspects. Moreover, it has complete control of routing to the appropriate provider that can provide the expected quality of service. It is also important to note that several products support both the capabilities of an ESB and a process execution engine. Such products can be used to implement both the semantic and non-semantic aspects of the service but it is important to implement separate components for handling the semantic (orchestration) and non-semantic (mediation) aspects to retain separation of concerns. Realization decisions taken at this juncture should consider the trade offs carefully. Architects should evaluate whether using a certain capability of a product is prudent considering both semantic and non-semantic aspects of the IT Model. Consider a scenario where a software product may provide both the capabilities of an ESB and process execution engine, but an architect may choose not to use the ESB capabilities of the product and use an ESB hardware device instead. The motivation of the architect may be driven by the performance expected (response time and throughput) from an ESB which the software product may not be able to fulfill. However, the software product may easily satisfy the performance requirements and especially the semantic requirements expected from a process execution engine. This is often a typical scenario for most enterprises since though usage of an ESB is enterprise wide (may be a federated model) and hence widespread, usage of process execution engine is relatively low and is needed were the existing providers cannot satisfy the semantic requirements of a governed service by themselves. Hence services from existing providers may need to be orchestrated to create a new composite service and such orchestration can use the business process execution runtime capabilities of the software product.
An Operating Model enables the management of the business processes and the measurement of Key Performance Indicators (KPI), agility indicators, metrics, and Service Level Agreements (SLA). To maintain a competitive or differentiated advantage an enterprise must ensure that the operating model improves faster than its competition’s. An enterprise should be able to identify optimization opportunities for its business process by measuring its KPI and agility indicators and should also be able to react and respond in a timely manner to events generated by internal and external influencers. It provides definitive indication of whether the objectives stated in the Motivation Model is being achieved by the Strategy, Process, and IT Models.
A Governance Model enables the governance of business services and ensures that the governed services help achieve business goals. It ensures that the business functions are made reusable and duplication and redundancy is avoided to reduce total cost of ownership and improve returns on investment. In other words, governance must ensure that all services specified and realized using the IT Model are derived from the Motivation, Strategy, and Process Models that define the semantics of the service and are measured using the Operating Model to ensure that business objectives are being achieved. Hence, the Governance Model should define the end-to-end process flow for identification, funding, specification, realization, implementation, and versioning of services and should ensure continuous management and optimization of services for realizing the business objectives. Corporate Governance, Process Governance, SOA Governance, and IT Governance need to work together encompassing managing, versioning, and sharing of all the various models discussed above i.e. from Vision and Mission in Motivation Model to executable code in an IT Model to be able to realize the enterprise vision. Enabling this capability in an organization requires deploying sophisticated technology that can not only be used to create these models but also be able to manage and version them by using a centralized repository and provide end-to-end traceability of all artifacts produced by the models.
This article attempts to emphasize the need to consider IT as a core part of business in order to create a service-oriented enterprise that can not only attain business goals but can also respond to market changes quickly. It proposes a model-driven approach to affect the fusion of business and IT and depicts how “service” can be used as a key binding element for each of those models and that the term “service” is contextual in nature and should be appropriately qualified by the model in which it is defined.
It also states why the model-driven approach is an effective way to model and govern how an enterprise goes about its way of doing business and provides traceability across all its models from motivation to IT. This makes IT a core part of business that realizes the business motivation identified using the Business Motivation Model and specified using the Strategy and Process Model. This effectively helps reduce representational gaps in an enterprise and makes it more agile (ability to respond to market changes quickly).
It also emphasizes the importance of an Operating Model which can help measure the attainment of business intent using Metrics and an end-to-end Governance Model that defines and manages processes for identification, funding, specification, realization, and implementation of business motivation.