Abstract
This chapter identifies the issues that might create orthogonal complexities for process dynamism, and decouples the components implementing them in a “domain specific” way. Authors believe that traditional process management techniques for modeling and executing the processes still fall short to improve the dynamism of an enterprise. Some of the reasons are: using too “generic” techniques and tools for process management that are not scalable enough for typical business cases, having lack of architectural coverage to manage the tradeoffs between dynamism and other business quality issues, insufficient support for integrating legacy business processes, and unbalanced guidance between “primary” and “supportive” processes. In order to improve the business agility particularly with dynamic processes, effective abstraction and composition techniques are needed for the systematic design of primary and supportive processes in an organization. Authors bring in the “Domain Specific Kit” abstraction as a way to improve the dynamism of complex processes.
TopIntroduction
For many decades, enterprises have been looking for efficient, reliable, flexible and adaptable processes. The increasing agility in business world enforces organizations to be more dynamic in every possible way. But, traditional process management techniques for modeling and automating the core business processes fall short to enhance the dynamism in an enterprise. In traditional business process management, IT mainly abstracts the complexities of business processes with automated methods and tools that unsurprisingly introduce the categorization of processes as “primary” and “supporting” ones.
In order to improve the dynamism of complex business processes, IT departments should no longer be the roots of this process categorization, but rather they should provide the right toolset to business departments for flexible process modeling and execution. However, this is not that much easy to achieve. Proposals abound to segregate the business and IT perspectives for dynamic processes, but these efforts have fallen short so far for many practical cases.
Some of the issues behind this incapability can be detailed as follows: first, existing approaches are too “generic” to be used for every sort of complex [business] process. On the other hand, organizations run the business in different domains and expectedly, they have to comply with different process requirements. One example is integrating different processes of two organizations, one from banking domain and the other from automotive domain, for the processing of consumer loan for automobile sale transaction. The composition of their processes could not be simply orchestrated at run time without having a process choreography model at design time. The generic “process orchestration” models or strategies cannot easily solve service-oriented quality issues such as cross-domain security protocols (Tufekci et al., 2006; Aktas and Cetin, 2006).
The second issue is the lack of architectural coverage. The “dynamism” of a complex process is primarily a “non-functional requirement”, which cannot be achieved by using pure “functional” approaches. Rather, architectural modeling plays an important role here to ensure the process quality. Hence, modeling the business processes with declarative approaches and implementing them using only Web Services will not be enough for process dynamism. This minimalist “functional” thinking cannot help design the architectural aspects (i.e. security, performance, flexibility, modifiability, extensibility and adaptability) of dynamic complex processes. Instead, a reference architecture model (in a meta-level) is needed to conceptually design the domain specific components of process management. That is why Service Level Agreements (SLA) is still a debate in the Service-Oriented Architecture (SOA) community to compose services of different processes (Keller and Ludwig, 2002).
The third drawback is the lack of support for integrating the legacy processes. We know that enterprises still have to run the business with legacy processes worth of billions of dollars, which cannot be simply reshaped in a night. Thus, any strategy to improve the dynamism of complex processes should consider the existing process assets accordingly. The domain specific abstractions could help in that sense to abstract the complexities of existing services and processes so that they can be migrated in a reasonable period of time (Sneed, 2000; SEI, 2005; Ziemann et al., 2006; Cetin et al. at ICPS, 2007; Cetin et al. at ICSEA, 2007).
Additionally, existing approaches focus on the dynamism of “primary processes” but, on the other hand, they mostly neglect the dynamism of “supporting processes” and “organizational processes” (Havey, 2005; Tufekci et al., 2006). This degrades the overall process dynamism since supporting and organizational processes used by IT departments may easily put a barrier against the agile processes of business departments. This is almost the case when IT departments should comply with software process improvement standards (Yeh, 1991; Cetin et al. at EuroSPI2, 2006).
Key Terms in this Chapter
Software Factory Automation: is the vision to set up software factories as the way other industries have been establishing the industrial factories for manufacturing. It requires different know-how, expertise, infrastructures and processes to put forward the integrated software construction environments. Software Factory Automation analyzes the functional and non-functional requirements of a product domain, establishes the product line, provides core assets, and preliminary processes. It leverages the actual software construction in many ways including dynamic process management and time-to-market issues.
Primary Process: represents the activities constituting the major purpose of existence of an enterprise, which figure out services the organization is established for. They are also known as “business domain processes”, which carries the utmost value for an organization. Credit Card Management, Loan Management, Account Management are all “primary processes” in the banking domain.
Supporting Process: is performed to maintain integrity of the product or service developed by “primary processes” as well as it ensures that products and processes comply with predefined provisions and plans. Supporting processes accompany the “primary processes”, which do not typically result in final products of the organization, but rather indirectly contributes to the value added. Documentation, configuration management, verification, training and audit process are all supporting processes.
Domain Specific Process: is the set of activities dedicated to construct the software artifacts in a particular domain. Domain Specific Processes are mainly discrete and isolated from each other in software construction. The best way to integrate them is through well-defined and unified process choreographies. In relational database management domain; database management system installation process, database schema creation and maintenance processes, and database backup-restore processes are all known as Domain Specific Processes.
Organizational Process: includes activities that establish the business goals of the organization and develop process, product and resource assets which, when used will help to achieve business goals. Managerial processes, resource and infrastructure processes are all in organizational process category.
Software Product Line Engineering: is the combination of life cycle management as well as architectural setup of a software product line. A Software Product Line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Software Product Line Engineering can enable rapid market entry and flexible response, and provide a capability for mass customization of a software product.
Domain Specific Kit: is the composite of a “Domain Specific Language” to specify software artifacts pertaining to that domain; a “Domain Specific Engine” to interpret and execute a Domain Specific Language; and a “Domain Specific Toolset” to design, develop, and manage software artifacts of a dedicated Domain Specific Language. An example to a Domain Specific Kit is the “Relational Database Management System” that includes SQL as the Domain Specific Language, Database Engine as the Domain Specific Engine, and iSQL Tools as the Domain Specific Toolset.