Designing A Business Process Architecture: An Overview Of .
Designing a Business Process Architecture:An Overview of Approaches and their UseRemco Dijkman, Irene Vanderfeesten, Hajo A. ReijersEindhoven University of Technology, The Netherlands{r.m.dijkman, i.t.p.vanderfeesten, h.a.reijers}@tue.nlAbstract. With the uptake of business process modeling in practice,the demand grows for guidelines that lead organizations to consistent andintegrated collections of process models. The notion of a business processarchitecture has been explicitly proposed to address this issue. This paperprovides an overview and comparison of the prevailing approaches todesign such a business process architecture. Furthermore, it includes anevaluation of the usability and actual use of the identified approachesthrough our interaction with a large group of practitioners. Our findingssuggest that practitioners heavily rely on a mix of guidelines instead ofembracing any single approach wholeheartedly.1IntroductionWhen an organization engages in modeling its business processes, inevitablyquestions arise. Which processes exist in my organization? Where does one process end and the other begin? At what level of detail should I model my processes? To deal with such concerns, several authors have proposed the notion ofa business process architecture [1–5]: An organized overview of the processes thatexist within an organizational context. While a business process architecture ispositioned to help individual modelers to arrive at a consistent and integratedcollection of process models, it remains an open issue how in any given situationsuch an architecture should be established.Given the availability of many views on how to design a business processarchitecture, we identify a lack of understanding of the differences between theseviews and uncertainty among business users to make the right choices here. Yet,it has been recognized that not all business process architectures are equallyeffective. In a recent blog post, for example, Derek Miers notes how some processarchitectures may actually impede on the process-centered line of thinking thatwas behind the initiative to model process in the first place1 .This paper aims to fill the identified knowledge gap by investigating whichapproaches and guidelines to business process architecture design exist and whichof these are considered most useful in practice. More precisely, the paper offersthe following contributions:1See http://bit.ly/fBnfzI, accessed on November 17, 2011
1. An overview of the approaches that can be used to design a business processarchitecture; and2. A comparison of both the use and usefulness of these design approaches.The overview of the design approaches is based on a structured review ofthe existing literature. The practical use and usefulness of the different designapproaches has been investigated in a workshop session with 39 practitionerswho are active in the area of Business Process Management (BPM). During thissession we presented the approaches, conducted a survey, and engaged with thepractitioners to determine their experiences with the various approaches.The remainder of this paper is structured as follows. Section 2 presents aprecise description of what a business process architecture is. Section 3 presentsand compares the approaches to designing a business process architecture, asidentified through our literature study. Section 4 presents the evaluation of theuse and usefulness of the approaches. Section 5 presents the related work andSection 6 concludes this paper.2Business Process ArchitectureWe define a business process architecture as the overview of a set of business processes that reveals their inter-relations, which may be extended with guidelinesto determine the various relations between business processes. Having a businessprocess architecture in place provides guidance for the actual modeling of theinvolved business processes. Figure 1 shows an example of a business processarchitecture in the ArchiMate notation [6]. The figure shows a small portion ofthe actual process architecture that is in use by the Rotterdam Harbor [7]. Inthe figure, processes are represented by rounded rectangles with an arrow icon.The figure also shows different relations between these business processes.There is no consensus about all the possible relations that can exist betweenbusiness processes. However, the following types of relations are frequently referred to in the literature. The decomposition relation expresses the decomposition of a process into subprocesses. Figure 1 represents this relation by thegraphical containment of subprocesses within their parent process. The specialization relation expresses that one process is a specialized version of another.Figure 1 represents this relation as an arrow with an open arrowhead. The trigger relation expresses that the execution of one process can trigger the executionof another. Figure 1 represents this relation as an arrow with a filled arrowhead.A business process architecture can be enriched by ‘containers’, such as layersor columns, along with guidelines for which processes can be contained in aparticular container. For example, a distinction can be made between containersfor primary and support processes [8]; the container for primary processes thencontains processes that directly add value for the client and the container forsupport processes contains processes that are necessary for the effective operationof the primary processes. As another example, Joosten [3] defines three levelsof abstraction at which processes can be defined: at the level of links in a value
chain, at the level of business functions, and at the level of executable partureResourceReservationSea arrivalSea departureInland arrivalInland departureStakeholderNotificationFig. 1. Example Business Process Architecture3Business Process Architecture Design ApproachesThis section presents a classification of the different approaches for business process architecture design that we identified through a literature study. The literature study was performed using the keywords ‘business process architecture’and combinations of the words ‘business process’ and ‘identification’, ‘delimitation’ or ‘demarcation’. ‘Google Scholar’ was used as the initial source. For eachapproach that was found, references and citations were used to further identifyapproaches. As a result, 45 approaches were identified. Of these approaches 30originated from a survey [9] specifically aimed at the topic of using referencemodels to design a business process architecture. We validated the completeness of our results by using additional sources, in particular: ‘Scopus’, ‘Web ofScience’, ‘Inspec’, ‘ABI/Inform’, ‘IEEE Electronic Library’, ‘ACM Digital Library’ and ‘Springer’ (in that order). ‘Scopus’ and ‘Inspec’ both returned oneadditional approach. After that, no additional approaches were found. Referenceand citation analysis of the additional approaches returned one more approach,leading to a total of 48 approaches to design a business process architecture.The approaches that were identified in this manner were subsequently classified by answering the question: ‘On what basis are processes and their relationsidentified according to this approach?’ This led to five classes of approaches: goalbased, action-based, object-based, reference model based, and function-based.Table 1 shows this classification. In each class of approaches, a business process architecture is designed by first designing another structure, e.g. a goalstructure. Such a structure should be designed in terms of the concepts and therelations prescribed by the respective approach. A business process architectureis subsequently designed based on that structure.In the remainder of this section we discuss each of the five classes of approaches in more detail. Note that the classes are not mutually exclusive.3.1Goal-basedIn goal-based approaches [10–15] a goal structure, which consists of businessgoals and relations between those goals, is designed first. Subsequently, a businessprocess architecture is derived from it, based on the definition of a business
Table 1. Classification of Business Process Architecture Design Approachesapproachstructureorganizing conceptconcept relationsgoal-basedgoal structuregoal(various subtypes)action-basedaction structureaction loop(various subtypes)object-basedobject modelfunction-basedreference modelbasedfunction hierarchyclassificationbusiness object(various subtypes,including:- permanent object- case object)functionclass(various subtypes,including:- business function- industry segment)various associations,including:realization(inclusive, exclusive)influencevarious inggeneralizationvarious associations,including:decompositionstate generalizationprocess as a collection of related activities to achieve a certain goal. Figure 2shows an example of a goal structure and a business process architecture that isderived from it. The benefit of using a goal-based approach is that associatinggoals with processes also helps to determine why certain processes are importantor at all needed.The main organizing concept in goal-based approaches is the ‘goal’, but different approaches distinguish different types of goals. Antón, McCracken andPotts [10] provide an extensive discussion of different types of goals that canbe identified. Subsequently, they show that focusing on different types of goalsleads to a different goal structure and, therefore, potentially to a different business process architecture. In addition, different types of goals may be translateddifferently into processes when a business process architecture is constructed [14].Different goal-based approaches also distinguish different types of relationsbetween goals. Four of the approaches within this class consider a realizationrelation between goals, which expresses that a (higher level) goal can be achievedby achieving the (lower level) realization goals being related to it [10–13]. Kavakliand Loucopoulos [13] also distinguish the influence relation between goals, whichexpresses that one goal influences another goal. Lee [12] allows the modeler tofreely define the types of relations that can be considered within a goal structure.Goal-based approaches differ significantly in the way in which a process architecture relates to the goal structure. Lee [12] defines a relatively strict relationbetween goals and sub-goals on the one hand and processes and subprocesses on
the other, stating that if goals are related, the processes that help realize thosegoals must also be related. Koubarakis and Plexousakis [11] and Kavakli andLoucopoulos [13] state that goals can be used to identify processes, but do notmake statements about how relations between goals influence relations betweenprocesses. Antón, McCracken and Potts [10] and Yu and Mylopoulos [14] relateprocesses only indirectly to goals (i.e. via other concepts).(achievement)create annualreportrealizationcreate annual reportcreate social reportrealization(achievement)create financialreport(achievement)create social reportrealization(achievement)create financialstatementi. goal structurecreate financial intain financial administrationii. process architectureFig. 2. Example of Goal-based Design of Process Architecture3.2Action-basedIn action-based approaches [16–21] an action structure is designed first. An action structure consists of business actions and their relations. A business actionis an activity loop in which a provider completes some work for an internal orexternal customer. Thus, by definition, it is very similar to a business process.The main difference between a business process and a business action lies thereinthat business action theory assumes that each human action, and therefore alsoeach business action, follows certain standard patterns and phases. This makesbusiness action theory particularly suitable for identifying processes, delimitingthose processes (i.e.: determining where one process stops and the other starts)and dividing a process into subprocesses and/or variants [17, 18]. The patternsand phases help determine which (sub-)processes should exist according to apattern and where a (sub-)process ends and another begins, because of a transition from one phase to another. Once an action structure is designed, a businessprocess architecture can be derived from it, using the strong similarity betweenbusiness processes and business actions. Figure 3 shows an example of an actionstructure and a business process architecture that is derived from it.The main organizing concept in action-based approaches is the ‘action’ anddifferent approaches distinguish different types of actions. Nonetheless, all actionbased approaches use the idea that each action goes through a number of phases.However, the exact number and definition of these phases differ per approach.Different action-based approaches distinguish different types of relations between actions. All of the action-based approaches that we studied have a decomposition, a triggering and a phasing relation. A decomposition relation betweenactions represents that an action can be decomposed into multiple, more detailed actions. A triggering relation represents that the completion of one action
triggers the start of another. A phasing relation represents that one phase ofan action is completed and that the next phase starts. Lind and Goldkuhl [17,18] also discuss a generalization relation, in which actions such as ‘apply for carinsurance’ and ‘apply for home insurance’ can be generalized into a more generalaction ‘apply for insurance’.Action-based approaches differ strongly in the way in which a process architecture relates to the action structure. First, approaches differ with respectto how the role of the business process concept is perceived. Most approachesuse the action-based approach instead of business processes [16, 19–21]. Onlyone of the approaches discusses the relation between business processes and actions [17, 18]. Roughly speaking, this approach equates actions to processes suchthat actions can be used to identify processes. Second, the approaches differ withrespect to the scope of the action structure that is designed. Where a businessprocess architecture focuses on structuring all business processes within a certain scope, the scope of an action structure can vary. Case studies are performedfor high-level business functions, such as purchasing [19], or workflow processes,such as hiring new personnel [16].makeprojectplanperform projectdecompositiontriggerperformprojectmake project planapprove projectplanapproveprojectplani. action structureii. process architectureFig. 3. Example of Action-based Design of Process Architecture3.3Object-basedIn object-based approaches [1, 22] a business object model is designed first, forexample in the form of a UML class diagram. Subsequently, a business processarchitecture is designed by studying the business objects that exist in the organization, as well as their inter-relations. Figure 4 shows an example of an objectmodel and a business process architecture that is derived from it.The main organizing concept in object-based approaches is the ‘business object’. Within both of the identified approaches three types of business objectsare considered: ‘permanent objects’, ‘case objects’ and ‘other objects’. Permanent objects are business objects that have a relatively long life cycle in theorganization, such as the ‘client’ in most organizations. Processes can be identified from permanent objects by determining what can happen to these objectsand defining processes to support these actions. For example, a new client canarrive or buy something, thus leading to the need for a process to register newclients and a sales process. Case objects are objects that guide the execution of
a business process and thus directly identify a business process. An example ofa case object is an ‘order’ or an ‘application’.Object modeling is a discipline in itself. The many object modeling techniquesthat exist distinguish many different types of relations between business objects.Some of these relations are of particular interest in the context of designing aprocess architecture. The relation between permanent objects and case objectscan be used to identify a logical group of processes. A relation between states ofone or more business objects can be used to delimit or relate business processes.For example, a state-change of an object from ‘ordered’ to ‘shipped’ can be usedto delimit and relate the ‘order’ and ‘shipping’ processes. A decomposition relation between objects can be used to identify a decomposition relation betweenbusiness processes. For example, the decomposition of a ‘mortgage application’into ‘client details’, ‘mortgage details’, and ‘securities’ can lead to different subprocesses in the mortgage application process. Finally, a generalization relationcan be used to identify a logical group of processes. For example, a generalizationrelation between ‘apply for car insurance’, ‘apply for home insurance’ and ‘applyfor insurance’ can be used to identify a logical group of insurance applicationprocesses.insurance applicationClientInsurancenameaddresshome insurance applicationnumberamountcar insurance applicationComplaintdescriptionCar insuranceHome insurancevehicleageaddressvaluei. object modelcomplaint handlingii. process architectureFig. 4. Example of Object-based Design of Process Architecture3.4Function-basedIn a function-based approach a function hierarchy is designed, which representsthe decomposition of business functions into more detailed business functions.Thus, the main organizing concept in the function-based approach is the ‘business function’, which is defined as a capability of an organization, such as ‘production’ or ‘procurement’. This relation that is considered is always a decomposition relation. A business process architecture can be subsequently structuredaccording to the function hierarchy. Figure 5 shows an example of a function hierarchy and a business process architecture that is derived from it. The benefitof using business functions to identify processes is that, compared to businessprocesses, business functions are relatively simple to identify and stable, becausethey focus on what an organization does rather than how the organization accomplishes that. Consequently, business functions arguably form a good startingpoint for designing a business process architecture.
The duality of business processes and functions is well known and frequentlyused in business process modeling frameworks [5, 23–25]. There are roughly twoways in which a function hierarchy can be related to a business process architecture. Firstly, the function hierarchy can be the primary way of organizingthe business processes. In that case, functions are decomposed into more detailed functions until a chosen level of decomposition is reached from which thefunctions are further decomposed into processes [23, 25]. In this case, businessprocesses are organized according to the functions to which they belong. Secondly, functions and processes can both be organized into hierarchical structuresthrough decomposition relations, which should be closely aligned [5, 24].Grant subsidySupply informationgrantingsubsidyProcess ne admissabilityJudge applicationi. reference modelprovidingsubsidyProvide subsidyii. process architectureFig. 5. Example of Function-based Design of Process Architecture3.5Reference Model BasedIn reference model based approaches, an existing business process architecture– the reference model – is re-used and adapted to design a new busines
a business process architecture [1{5]: An organized overview of the processes that exist within an organizational context. While a business process architecture is positioned to help individual modelers to arrive at a consistent and integrated collection of process models, it remains an open issue how in any given situation such an architecture should be established. Given the availability of .
What is Computer Architecture? “Computer Architecture is the science and art of selecting and interconnecting hardware components to create computers that meet functional, performance and cost goals.” - WWW Computer Architecture Page An analogy to architecture of File Size: 1MBPage Count: 12Explore further(PDF) Lecture Notes on Computer Architecturewww.researchgate.netComputer Architecture - an overview ScienceDirect Topicswww.sciencedirect.comWhat is Computer Architecture? - Definition from Techopediawww.techopedia.com1. An Introduction to Computer Architecture - Designing .www.oreilly.comWhat is Computer Architecture? - University of Washingtoncourses.cs.washington.eduRecommended to you b
CARESOURCE'S BUSINESS ARCHITECTURE PRACTICE ¡CareSource's Business Architecture practice is part of the Enterprise Architecture team ¡EA team uses Orbus iServer as our primary architecture tool ¡In 2020, launched a reset / maturing focus on the business architecture practices: ¡ Existing capability model rebuilt leveraging Business Architecture Guild's industry reference models
Designing your Tesla Coil September 2003 Rev 2 www.spacecatlighting.com Designing your Tesla Coil Introduction When I was in the process of designing my first tesla coil in May of 2002, I was hardpressed to find one source that comprehensibly described the process of designing a tesla coil from scratch.
Business Architecture According to Gartner, business architecture is defined as “the (enterprise architecture) activities that create deliverables to guide people, process and organizational change in response to disruptive forces and toward desired business outcomes.” This about business architecture, from the Open Group: “A description of the structure and interaction between the .
Business Architecture. o Descriptions of an Organization (Business model, MSGs, operating model). o Business processes & workflows. o Stakeholders and their roles and relationships. o Business rules (what the actors must do in a BP) o A lot about Process Change o Process Reengineering & Process Change, o Quality Movement o BPMN, UML Use Case Models . Lecture 4: Business Process Redesign .
This book will help you learn the importance of designing a sound architecture for successful implementation of any business solution, different types of C/S architecture, and various tenets of SOA, explaining the fundamentals and explaining the advantage of using the Service Oriented Architecture in designing of the business solution. From a
In Architecture Methodology, we discuss our choice for an architecture methodol-ogy, the Domain Specific Software Architecture (DSSA), and the DSSA approach to developing a system architecture. The next section, ASAC EA Domain Model (Architecture), includes the devel-opment process and the ASAC EA system architecture description. This section
The Alex Rider series is a fast-paced and action-packed set of books, ideal for lovers of spies and action. Teen readers will adore this unforgettable and enthralling series. Tomasz Hawryszczuk, age 9 This series of books is a must read for anyone over the age of 9 who likes spy stories, gadgets and danger. Best books ever! The Alex Rider series is an amazing set of books based on a 14 year .
