BUSINESS-IT ALIGNMENT IN COMPLEX PROCESS APPLICATION DEVELOPMENT TABLE OF CONTENTS 1 Introduction 2 Model-driven development in BPMS: myth and reality 3 From disparate to aligned models 4 Model traceability for business-it alignment 4 Creating process-centric solutions 5 The need for model governance and traceability 6 The benefits of linking models to execution 7 Summary 8 About the author How we create process-based applications is changing. In the early days of BPM, business-level process models were created as a part of the business requirements, and re-created by IT in a separate process implementation tool. As process models gained importance and replaced written requirements, a business-friendly view within the process automation tool allowed business analysts to create process models directly within that tool. However, the shortcomings of this shared model approach for complex, core business processes is causing a trend towards two classes of tools used in concert: a Business Process Analysis (BPA) or Enterprise Architecture (EA) modeling tool used by business analysts to create and optimize business models, and a Business Process Management System (BPMS) used by developers to implement process-centric applications. As the need for separate tools in some situations is recognized, so is the need for traceability between the two environments. Although business and IT will continue to have different perspectives on process models, governance of the process-modeling life cycle can coordinate modeling efforts between the different participants. This helps to create a seamless integration from the highest-level business models to executing processes, thereby aligning the goals and efforts of business and IT. WHITE PAPER
Model-driven development in BPMS: myth and reality Business process management systems have evolved as they moved into the mainstream of enterprise application development. Originally, a BPMS was a specialized systems for designing and executing business process flows, including both human activities and system orchestration, that could be executed as stand-alone processes or invoked by other applications. Eventually, these systems expanded to provide many other functions that allowed them to create complete process applications: initially, the ability to create user interfaces and call external system services from within a BPMS design environment; then, design and development of business rules, service interfaces, organizational models, analytics dashboards and more. In other words, a BPMS covers much more than just process: These systems have become full modeldriven application development environments for process-centric applications. For pure business modeling, BPA and EA tools provided capabilities to model all aspects of a business data, processes, people, systems but typically did not provide the ability to generate executable business applications. Maturity ranged from simple free-form flow charting, to process model templates, to dedicated process and EA modeling tools that provided advanced analysis and optimization capabilities. When the BPMS concept first gained popularity, and had only rudimentary businessfriendly modeling capabilities, a BPA/EA tool would be used by a business analyst to create process models, which were then re-modeled and implemented by a developer using a BPMS, sometimes with the addition of custom code or within the context of another application development environment. Because this was a manual reinterpretation of the requirements, translation errors were common between what was modeled in the BPA/EA tool and what was implemented in the BPMS. Recognizing that a shared model could reduce translation errors, many BPMS vendors added business-friendly modeling capabilities. The business analyst now used this view within the BPMS as the BPA tool to create a shared process model that was then augmented and implemented by the developer. Changes by the business analyst in the business view of the model would be reflected in the technical view, and vice versa. Although this resolved the issue of out-of-sync process models between business and IT, a model-driven environment where business and IT share the same models introduced two key problems: Insufficient functionality for the business analyst BPA/EA tools are used for much more than just creating models for implementation in a BPMS: They are generalized business modeling and optimization tools, and the business modeling tools within a BPMS typically cannot provide the level of business analysis that is present in a dedicated BPA/EA tool. Purely manual activities, such as movement of physical items, cannot be modeled because those activities are not automated or monitored by the BPMS, and advanced business and process improvement analytical functions are absent. True business analysts and process improvement specialists as opposed to IT staff who are tasked with gathering requirements but performing little actual business analysis require specialized tools for their work, and a BPMS typically does not provide most of those capabilities; failure to recognize this and provide for separate BPA/EA and BPMS tools reduces the opportunity for business optimization and innovation. Implementation models may not match business models Variations can occur between the business view of a complex process and the optimal technical implementation of that process, typically for reasons of performance and re-usability. For example, a decision that a business analyst models as a process gateway may be externalized by a developer as a business rule in a decision management system, a frequently used series of process activities may be collected into a subprocess that is called from multiple processes, or event handlers may be added to sense and respond to external events that impact the process. In a model-driven BPMS, the developer must change the model in order to optimize it for implementation. Because the model is the code, however, if that model is shared with the business, it may no longer match the business view of the process. 2
For complex, end-to-end business processes, the ideal environment is to create business models in a BPA/EA tool for planning, analysis and optimization, then translate the business models into technical models for augmentation and implementation. In practice, this is what most organizations are doing, even if they have a shared-model BPMS that provides a business view: Some amount of modeling occurs in a BPA/EA tool first, then those models are translated or transcribed, either by business or IT, into the BPMS. Can a non-technical business analyst create executable models for complex process applications directly in a BPMS? Maybe. Should they? Maybe not. There are counter examples to this application modeling and development paradigm: building simple process applications for administrative flows, or configuring parameterdriven vertical process applications for a specific installation. However, once complex business architecture and analysis are required, or the application complexity increases to such an extent that the implementation model no longer matches the business view, a two-tool approach provides better functionality for both business and IT. The choice of whether to use one or multiple notations and model types (e.g., BPMN for process models) must be based on a sound modeling methodology within an organization, so that different model perspectives are created and linked together consistently; this decision may be dependent on the modeling tools as well as the preference and skills of the modeling participants. From disparate to aligned models Early efforts at model-driven development in BPM resulted in business participants being confronted with complex technical tools that the average business person was neither capable of nor interested in using. Furthermore, the level of detail required in an executable process model was far beyond that required for business people to be able to understand their processes. Instead, business analysts continued to create their process models using familiar business-oriented tools, such as Microsoft Visio or ARIS, then passing these onto IT for manual translation by the developers into the technical process modeler. Although using a BPMS created an easier environment for the developers, who could now model much of an executing process using a graphical environment rather than with code, it did not address the challenges associated with inadequate alignment due to a lack of shared process models. As process modeling tools became more integrated with the process execution environments, it became obvious that different roles process owners, business analysts, process engineers and developers required different views of a process model. Whereas a process owner is most concerned with the high-level value chain and Key Performance Indicators (KPIs), a business analyst needs to document activities and the process flow in complete detail. Process engineers require more detailed logical views and optimization tools, such as simulation, and developers need to be able to attach and configure automated services to the process in order to make it executable. Clearly, one size does not fit all when it comes to process modeling tools. The multiple views required on business processes are similar to that of an enterprise architecture framework, where moving to lower levels of models isn t simply a matter of creating a similar but more detailed model, but rather translating to a completely different perspective appropriate to the key stakeholders at that level. For example, the higher-level process models may contain activities that are purely manual, such as the movement of physical paper documents, which will not be translated into system functionality at the lower levels. Similarly, technical services attached at the lower levels may be rolled up into less-granular business services in the higher-level perspectives, or may not be represented at all if they don t add value at that level and may confuse the audience. It is equally valid to make changes to the models at any level, since those changes may be made for different reasons, and the effects of those changes must propagate through all perspectives. 3
Model traceability for business-it alignment The primary challenge of using multiple levels of modeling is that lack of alignment and traceability between the business and executing process models can cause a corresponding lack of alignment between business and IT. In order to support business-it communication when using two separate tools for modeling and implementation, two capabilities are required: The tools should provide some degree of automated translation from the BPA environment to the BPMS, in order to decrease the number of translation errors There must be mechanisms for traceability from a change in the business requirements and models to the implementation models, to ensure that changing business needs are communicated to the implementation team This loosely coupled environment does not strictly enforce model consistency between the two environments, since that may be inappropriate for either business or technical reasons, but provides an initial set of translated models to speed implementation. By providing different stakeholders with process tools appropriate to their needs, yet establishing traceability between the resultant models and tools, it is possible to create a shared vision of process excellence while allowing creativity across all modeling efforts. Separation of the BPA/EA and BPMS tools also allows either tool to be changed out independently as business and technology needs change; standards such as BPMN allow models to be translated between any tools that support the standards, regardless of the tool vendors. Creating process-centric solutions Every business application is more than just its underlying business processes, and model-driven BPA and BPMS tools have expanded to meet that need through additional model types: data models for business objects, organizational models for roles and relationships, decision models for business rules, user interface models, and enhanced process models with KPIs and other metrics identified for run-time analytics. Whereas a business analyst may have previously written text-based requirements annotated with a few process models and UI sketches, he can now create an entire model-driven blueprint of a business operation in the context of the overall enterprise and business architecture. The operational-level process and KPIs can be linked to the corporate value chain and goals, and changes to those high-level models can be directly reflected in the business blueprint. Even if portions of that blueprint are not targeted for BPMS implementation, they may be used to develop training and procedures to guide users in manual operations. Once a business analyst has defined the functional requirements of the solution, the business-level models can be aligned with the implementation tools and translated to implementation-level models and artifacts by a more technical team. The businesslevel models become documentation that guides the developer as well as an implementation starting point, and also provide test cases for the solution when implemented. Alignment between these environments is critical and must allow future change to a business-level model to be mapped onto the corresponding technical implementation artifacts, regardless of whether the technical implementation uses executable models or more traditional code. Irrespective the different perspectives are implemented as a shared model or by translating between multiple models, the key issue is establishing linkages between information at different levels: Process model flow diagram, typically modeled at all levels of business, logical and implementation perspectives Organization model, including roles and hierarchy Data model, modeled at the logical level and implementation level Service definitions, including access to a service repository, modeled at the implementation level User interface, possibly modeled at the business and logical levels as use cases or storyboards, and in a more representational form at lower levels KPIs, modeled at the business level, and translated to events and metrics at lower levels 4
The linkages between levels of models cannot be ad hoc if they are to be applied consistently. It is necessary to have not only a methodology for model translation, but also governance to ensure not only x but y as well as traceability between layers. The need for model governance and traceability In an enterprise architecture view of a business process, business strategy maps to business goals, which map to business operations, and in turn to business-level and technical implementation models. There are multiple conceptual models of various types involved in the design and implementation of any process application. Furthermore, there are interactions between the model types: Process models must be closely linked to data models and organizational models in order to allow process, data and roles to be modeled coherently between business and IT. The business view of a process can be quite different from the IT view, and they aren t necessarily directly representative of each other. Given that there are two or more different models, how do business and IT coordinate their modeling efforts? A key challenge is the linkage between business requirements and technical implementation. As business-created models become a common part of or a replacement for business requirements, it is even more critical that the life cycle of process models from requirements to implementation is properly managed. With multiple artifacts, whether they represent different aspects of the enterprise architecture or different perspectives of the same aspect, the concerns become traceability, consistency and impact analysis between models when a change is made to any of the models. Adding a governance framework to the process-modeling life cycle reduces model transformation errors and greatly speeds modeling and implementation efforts. Process governance provides an answer to managing the life cycle of process models and other artifacts. It guides the design and implementation of process applications, and enforces alignment between business and IT by coordinating the collaboration efforts. Governance provides consistency management, not just between versions of the same model, but also between models of different types that represent the same process, where there may be an overlap of information representation. Without process life-cycle governance, there are significant challenges in model transformation and synchronization when BPA and BPM are performed in different tools, as well as in coordinating the efforts between business and IT process modelers, regardless of whether one or multiple modeling tools are used. Process-model life-cycle governance is based on a deceptively simple procedure: When the business creates or changes a process model, the business hands it over to IT for implementation. IT is then notified of the handover and proceeds with the tasks required to turn the business-level model into an executable process. Conversely, if IT changes the model in order to optimize it for automation, IT hands it back to the business for approval, who are notified of their approval task. Although this may involve model transformation or manual updates to models, this is primarily about synchronization and collaboration of efforts between business and IT. Any of the modeling participants can view the status at any time in order to determine what process that it has already undergone, and what steps are required to complete it. 5
The benefits of linking models to execution Establishing traceability between models even in different tools allows all stakeholders to speak a common language and share a vision of the process improvement. This also shortens the time required to move from the business vision to executing processes, and to make updates to the processes in the future, providing significant cost savings. Creating a link from business-level process models to executable processes through life-cycle governance is critical to achieving business-it alignment, since the models become the method of communicating business goals and strategy directly into action. Modeling tools that allow for traceability between business and implementation models ensure that business requirements are communicated accurately and completely to the implementation team, and that technical limitations that impact the business-level view of the process are communicated back to the business. Many higher-level business models do not link directly to executable processes, but require a proper architectural framework and methodology to guide both business and technical modelers through the connections between these radically different perspectives. Such frameworks and methodologies can turn a disconnected set of models into a unified view of a business process, as seen from different perspectives, and require proper governance in place to translate consistently between the perspectives. In addition to promoting business-it collaboration and reducing translation errors in requirements, model traceability can create efficiencies in the process implementation cycle, allowing changes to processes to flow between different stakeholders seamlessly. Rather than requiring a complete redevelopment effort when a business process changes, this allows modifications to a process in the business model to be clearly communicated to the developers for the technical implementation.this reduces the time and effort required for a change to a business-level model to be reflected in the operational process, allowing for continuous process improvement. 6
Summary Sharing a vision of process excellence between business and IT is no longer a dream, but there are two things are required to make it a reality. First of all, process models must be easily transformed between business and IT perspectives, since business-level process models now form a significant portion of the requirements for implementation. Secondly, there must be governance over the life cycle of process modeling to guide and support the collaboration that must occur between business and IT in order to create, modify and maintain process models across multiple perspectives. Working in concert, these will have the effect of reducing translation errors between different process model perspectives, decreasing the time required to model and implement business processes, and improving business-it collaboration. 7
About the author Sandy Kemsley is an independent analyst, process architect and blogger specializing in business process management. She performs engagements for both enduser organizations and BPM vendors across North America, writes the popular Column 2 blog at www.column2.com and is a featured conference speaker on BPM. ABOUT SOFTWARE AG Software AG offers the world s first Digital Business Platform. Recognized as a leader by the industry s top analyst firms, Software AG helps you combine existing systems on premises and in the cloud into a single platform to optimize your business and delight your customers. With Software AG, you can rapidly build and deploy digital business applications to exploit real-time market opportunities. Get maximum value from big data, make better decisions with streaming analytics, achieve more with the Internet of Things, and respond faster to shifting regulations and threats with intelligent governance, risk and compliance. The world s top brands trust Software AG to help them rapidly innovate, differentiate and win in the digital world. Learn more at www.softwareag.com. 2015 Software AG. All rights reserved. Software AG and all Software AG products are either trademarks or registered trademarks of Software AG. Other product and company names mentioned herein may be the trademarks of their respective owners. SAG_Business-IT_Alignment_8PG_WP_Nov15