Ayesha Manzer
Middle East Technical University, Turkey
Ali Dogru
Middle East Technical University, Turkey
aBstract
A mechanism is presented to construct an enterprise process by integrating component processes. This approach supports the formation of value-added chains based on process models. Process represen- tations in logical as well as physical levels are offered in a hierarchy as a graphical tool to support process integration. An enterprise represents a complex process that needs to be constructed within an engineering approach. Such construction is a matter of integration if component processes are made available by smaller enterprises. Process integration is supported by task-system formalism that may especially prove useful in the analysis of the preservation of process attributes during integration. Approaches using the decomposition of the problem definition have matured for various engineering disciplines in an effort to match definition pieces with previously built subsolutions. Among these dis- ciplines, the techniques used in software engineering are exploited as this domain is closer to business process construction than the others.
introDuction
Businesses are complex organizations, therefore their formation requires some scientific guidance. Similar to the construction of any other structure, the construction of an enterprise is expected to benefit from engineering practices. Similar to the role of information technologies in shaping the way we conduct our operations, structuring
the business will also require modern technolo- gies. Developing rapidly, software engineering has become the closest discipline to enterprise engineering for the study of processes, the logical representation of any structure integration, and modeling. Similar leverage has been exploited in other disciplines, but software technologies have used them most recently and effectively. In this chapter, some mechanisms used in compo-
nent-oriented software integration are adapted to enterprise engineering, namely, hierarchical decomposition and component integration.
We will benefit from engineering practices, and such rigorous techniques are crucial in achieving dependable outcomes. However, we also need simplicity and understandability, especially when it is a matter of preserving our intellectual control over the business (Laguna & Marklund, 2004) through a mind not necessarily that of an engineer’s. It is a fact that complex artefacts require interdisciplinary teams. In other words, the big picture should not be neglected while low-level details and formalisms of engineering mathematics are accounted for. There is a rac- ing condition here; we want to understand the enterprise easily, and yet the enterprise needs to be engineered rigorously.
Another complicating factor is the need for agility. Our organizations, like our production infrastructure, need to be flexible and dynamic to meet the rapidly changing market demands
(Madachy & Boehm, 2006). Rather than designing the process from scratch, it is always faster and more reliable to reuse what was invented and tested before. Our goal is to utilize a number of existing component processes in a smart integration for constructing the next enterprise-level process. Agility can be achieved through component-pro- cess replacement. Wherever a modification need arises in the system, one corresponding process can be replaced with another that might satisfy the need. This replaceable part may correspond to a single process or to a set of neighboring processes in the hierarchy model.
We treat enterprise engineering as a design problem. Being applicable to any design area, hierarchical decomposition has been proposed as the fundamental algorithm (Simon, 1969). Applied to business processes, this means an enterprise engineer can think of the organization as a huge process that can be decomposed into component processes. Assuming a top-down approach to designing a new process, as an initial step the
System abstraction Abstract component Abstract component
component component component
Abstract component Abstract
component component Abstract component A bs tra ct ion l eve l
whole operation (system) can be modeled as an abstract process. Likewise, the immediate parts of the whole, the smaller processes, can be repre- sented as logical entities in the decomposition. At the outset, we want to visualize the relative posi- tions and perhaps interactions of the component processes in the system. Eventually, when suf- ficient decomposition is done, the decomposition model will come closer to real processes: Process models that represent real business processes will take place at the bottom of the hierarchy. Figure 1 depicts the decomposition model.
Component processes are represented as boxes that connect to others (integration) through links that carry information about material flow, re- source allocation, and synchronization. A box can be modeled by any existing modeling technique that helps in ordering the activities, assigning resources to activities, and organizing material and product flows. In other words, a process in the system will be presented as an activity inside a process. This view not only allows for process abstraction, that is, hiding the information inter- nal to a process and viewing it as a black box so that the big picture is easier to understand, but also, in cases of too many processes, it becomes possible to understand the system by looking at it one region at a time. The region of focus could correspond to the whole enterprise when it is at the top of the hierarchy, or to any other local con- text. In the following sections, information about the related mechanisms in software engineering and their adaptation to enterprise engineering will be presented with a process integration example. Also, a task-systems-based formal representation is included so that some process attributes can be analyzed for their preservation after integration.