Uniting Process Architecture And Execution by EnterpriseManagement360

BPMS Watch

Industry Trend Reports

Independent Expertise in BPM

March 2010

UNITING PROCESS ARCHITECTURE AND EXECUTION Adopting a Process Perspective In a world of hyper-competition and continuous change, the ability to conduct business faster, at lower cost, and with better quality and customer satisfaction than the competition means the difference between prosperity and failure. Agile, efficient, customer-centric… you hear these words all the time. Every organization seeks these attributes, but how do you achieve them? The key is understanding and managing your business from the perspective of your trading partners and customers. That sounds obvious, but if you’re like most businesses, your organizational structure probably gets in the way. So do your IT systems. The reason is that these aspects of your business are usually organized around discrete business functions, like sales, finance, engineering, logistics, and customer service. Each may be replicated in various divisions or geographic locations. While your business may be organized for efficiency, integration, and standardization within each of those units, at least at a particular location, your customers don’t interact with you in terms of discrete functions. They interact with you in terms of business processes that cut across corporate functions and locations. Becoming more agile, efficient, or customer-centric is very difficult when you tackle it one function at a time. It’s much easier when you begin to understand and manage your business from a cross-functional process perspective. That’s the essence of business process management, or BPM. Managing the business from a process perspective means several things: understanding how the process works, end to end; measuring business performance from that customer-centric end-to-end perspective; and controlling end-to-end operation in a way that continuously optimizes performance and minimizes risk. Over the past decade, business process management has evolved into a rich conceptual framework supported by tools and technologies that let you manage your business from a process perspective. But as you drill down into it, you begin to see that not all “process people” are striving for the same goals. Some start with the business itself, not driven by a single process but hundreds of processes, some mission-critical to the overall value stream, others in a supporting role. This macro, or big picture, view is supported by tools and technologies for categorizing, analyzing, and ultimately optimizing this vast collection of processes, understanding their mutual dependencies, strategic importance, and alignment (or misalignment). We call this business process architecture or business process analysis (BPA). Others focus on specific processes with the goal of improving them, making them run faster, at lower cost, or with higher quality, performance visibility, or adaptability. This micro view leverages technology and tools that actually control and monitor process operations, automating the workflow, integrating the various IT systems involved, enforcing the business rules, and continuously monitoring dashboards of key performance indicators (KPIs). Those tools and technologies are called BPM Suites (BPMS). Unfortunately, BPA tools and technologies supporting the macro, or architectural, aspect of BPM have evolved independently of their micro counterparts, BPMS. You would think that BPA and BPMS would easily interoperate, but it turns out this is not the case. In fact, in most BPA suites a © Bruce Silver Associates 2010 BPMS Watch: www.brsilver.com/wordpress 500 Bear Valley Road, Aptos CA 95003 USA Contact: Bruce Silver, Principal bruce@brsilver.com +1 831 685-8803

Uniting Process Architecture and Execution

process model typically represents an “architect’s conception” of how the process works, or was supposed to work based on business requirements, not how it actually works, as controlled and monitored by a BPMS. To say it another way, you cannot easily synchronize or “roundtrip” between a process model in a BPA suite and its counterpart in BPMS. That problem has now been solved by the integration of the Appian BPM Suite, a leading BPMS, with MEGA’s BPA suite. Unlike some other vendors’ attempts to integrate BPA and BPMS, the Appian-MEGA solution leverages a single process model, using BPMN notation, used in both environments, so there is no roundtripping problem. In other words, the process models used for enterprise-scale analysis and governance are the same ones used for process execution. This white paper describes the benefits of that integration and how the Appian-MEGA solution works.

What is BPM? To understand the problem, we need to start at the very beginning. What is business process management (BPM)? It’s really three distinct but related things: a management discipline, a technology platform (the BPMS), and a new implementation style for building automated process solutions.

BPM as a Management Discipline BPM as a management discipline came out of the “re-engineering” ideas of the 1980s, when Geary Rummler advised businesses to adopt a customer-centric end-to-end process perspective and better manage the “white space” in the organization chart – the handoffs between the functional stovepipes that get in the way of efficiency and customer satisfaction. Today, adoption of such a process perspective continues to gain momentum. A rapidly increasing number of companies are documenting their key business processes in end-to-end process models and analyzing them for potential improvement. Process A Process B Process C Process D

Trading Partners

Financials

Compliance

Fulfillment

Order Handling

Figure 1. Cross-functional “process perspective”

Many aspects of Rummler’s swimlane flowcharts of the 1980s have been carried forward in today’s process modeling standard, the Business Process Modeling Notation (BPMN) from the Object Management Group (OMG). The goal today is essentially the same: describing the flow of work from beginning to end, with special attention to the interactions or touchpoints with the customer or trading partner. The process diagram, which cuts across organizational units and IT systems, provides valuable context for measuring and managing business performance from a customer-centric perspective. In addition, these models play a central role in business process

Uniting Process Architecture and Execution

improvement projects, which feature comparative analysis of current-state (as-is) and proposed (to-be) process models. Of course, the process model is just one of many models needed to improve organizational performance. You also need models of strategies and goals, functional capabilities, organizational structure and roles, business vocabulary and rules, IT systems and facilities. Tools to manage all of these related models today are called Business Process Analysis (BPA) suites.

BPM as a Technology Platform

Business

Executable Design

Process Engine Human Task Framework

IT User

User

Rule Framework

Modeling

Integration Framework

Performance Data

BAM

SOA Middleware

Many aspects of process improvement – the elimination of non-value-adding tasks, for example – can improve business performance without automation. However, for many business processes, the benefits of business process management are far greater and easier to achieve with technology that actually executes the to-be process model. This technology, called a BPM Suite (BPMS), features an integrated set of tools and runtime components that enables a continuous cycle of business process improvement. ERP Legacy External Services

Rules

User

Figure 2. BPMS provides an integrated platform for model-driven process automation, monitoring, and continuous improvement

That cycle starts with process modeling, describing in business-friendly diagrams the sequence of activities end to end. Then executable detail is added to the model – ideally without changing its outward visual appearance – a step I call process design. Process design rarely involves programming; it is mostly point-click configuration of things like forms and user screens, business rules, integration with external systems using web services, and performance monitoring dashboards. Model-driven development is a central feature of BPMS architecture. The process design is deployed to the BPMS process engine, which executes instances of the model. As each triggering event occurs – an order arrives, for example – the engine creates a new process instance and automatically routes it from step to step as described by the model. The process automation coordinates human and automated tasks. Human tasks are routed to the assigned performer’s workflow inbox. Business rules are automatically executed at the proper time. The process interacts with backend business systems through integration middleware and SOA. And as each process step is executed, the BPMS captures timestamps and snapshots of business data that are converted into real-time performance metrics that can be compared with defined KPI targets, a capability called business activity monitoring, or BAM. Analyzing performance data leads to suggestions for process changes to further optimize business performance, and the cycle of improvement begins anew.

Uniting Process Architecture and Execution

BPM as an Implementation Style BPM Suites have been around for five or six years, and over that time they have continuously evolved toward blurring the boundary between process modeling, a business function, and executable design, an IT function. The reason is that increasing business agility requires empowering business to play a more direct role in process improvement projects. Rather than toss requirements over the wall to IT, business should be able to work collaboratively with IT using a common tool for both modeling and executable design, or at least a common process model. Thus another important aspect of BPM today is its enablement of a new agile iterative style of process implementation, in which business and IT work together in rapid cycles of design, test, and deployment. BPM Suite architecture expects process designs to continually change, and represents a dramatic improvement over traditional waterfall project methodologies. Moreover, a BPMS provides a unified collaboration and execution platform shared by business and IT.

Benefits of BPMS The benefits of a BPMS can be described in five general categories. 1. Operational efficiency. BPMSs routinely demonstrate dramatic improvement in end-toend cycle time, process cost, and labor utilization. Much of this benefit comes from automating the workflow, providing the needed information to the right person at the right time, tracking deadlines and handling exceptions automatically. It is not uncommon that a process that once took two weeks is reduced to less than a day. Companies can greatly increase the volume of orders, loans, claims, or customer service requests handled per day with no increase in staff. This hard-dollar ROI is a key driver of BPMS adoption. 2. Compliance and control. In a BPMS, the process logic is explicit, written down in the model, and enforced in operation by the process engine. The same goes for the business rules. They are not simply the best intentions of individual task performers, but enforced by the BPMS. Moreover, process fragments (or entire processes) can be reused across the organization, enhancing standardization and compliance. Many organizations today have grown by mergers and acquisitions, and may have units spread around the globe. BPMS allows standard policies, procedures, and best practices to be deployed uniformly across the enterprise. In addition, by maintaining an audit trail of what actually happened (and when) in each process instance, a BPMS allows the business to more easily meet regulatory, audit, and transparency requirements. 3. Business agility. A BPMS should be designed for rapid deployment of new process solutions and continual change once deployed. Features such as graphical model-driven design, self-generating integration components, reusable business services, real-time change using business rules, and real-time escalation through BAM allow companies to respond to rapid changes in the competitive business environment. 4. End-to-end performance visibility. This goes back to BPM as a management discipline, and the fact that most IT systems, including enterprise applications like ERP, do not actually measure end-to-end business performance. They just measure transactions within their own narrow boundaries. A BPMS makes process performance visible end-to-end â&#x20AC;&#x201C; in real time â&#x20AC;&#x201C; through dashboards available to process owners and supervisors. Exceptions can be handled as they happen, with drilldown views supporting root cause analysis. And historical performance data can be sliced and diced in analytical views that suggest innovations leading to future performance improvement.

ÂŠ Bruce Silver Associates 2010

Uniting Process Architecture and Execution

5. Innovation through analysis. This last benefit does not even require automation at all. It really comes down to process modeling, which sets down on paper – perhaps for the first time – how the current process actually works end to end. Why do we do it this way? Why does it take three days to get from here to here? Why are we doing this step here? Didn’t we do it already back here? You hear this all the time from stakeholders assembled around the as-is process diagram. Often the only reason a process works the way it does is because that is how it was done in the past. Modeling the as-is process is almost always the first step to improvement.

What is BPA? While BPMSs tend to focus on one process at a time, Business Process Analysis (BPA) tools take a broader architectural perspective. They provide an aggregated look at all of the business processes throughout the company to understand their inter-relationships and dependencies, their reuse of common resources, and relationships to overall business strategies and goals, leveraging a repository based on an extensible metamodel.

BPA as an Architectural Perspective The pressure of everyday business means processes throughout the organization typically evolve independently, driven by their own short-term needs. Business architecture and its IT equivalent, called enterprise architecture, provide a countervailing force to that ad hoc evolution. They seek to make sense of the tangle of existing systems and processes, bring some rational order to them, and align them with the strategic goals of the enterprise. BPA tools are designed to support that architectural perspective. In addition to understanding the activity flow of a process, that perspective attempts to understand, in a structured way, the interaction between processes, people, information, business rules, resource constraints, and technology (systems, data, services). Effecting strategic change requires this broad perspective when considering issues such as how information is captured from and distributed to customers; how it is stored and managed internally; how policies and rules are shared effectively across all the processes that use them; or how disparate systems and services can be consolidated to facilitate a more agile organization. By coordinating the required changes in each of these dimensions, process improvement can achieve truly strategic objectives, such as business agility or reduced business risk. BPA provides this through models and abstractions that create a unified picture of these various dimensions and organize them into well-understood patterns. For that reason, BPA tools are of necessity more complex than simple process modeling tools. They require more training, and are typically used by a smaller group of users. The key feature of BPA is the model repository. This database captures detailed organizational knowledge in each of these dimensions – process, information, people, rules, constraints, and technology – and describes the links between them. In that way changes in any one dimension can be traced to its dependencies and impacts in all the other dimensions as well.

BPA as an Analytical Tool BPA provides more than just a repository of organizational knowledge. It also provides a set of tools that analyze the models in support of strategic change. A critical one is change impact analysis. If this activity or business object or policy or system changes, what processes will be affected? This means cataloguing all of the dependencies and other relationships among model artifacts across the enterprise. These artifacts cannot be © Bruce Silver Associates 2010

Uniting Process Architecture and Execution

modeled within a single tool or editor. By their very nature they require tools specific to each one, while allowing the repository to describe their inter-relationships. BPA makes the full impact of a potential change immediately apparent, allowing the architect to quickly narrow down alternatives and avoid inadvertently creating problems elsewhere. BPA also provides tools to analyze potential performance improvement. Some BPM Suites provide similar tools, but usually within the context of a single automated process. BPA extends that context across multiple processes and considers non-automated processes as well. Through simulation analysis, BPA tools can perform sophisticated what-if analysis of various to-be process scenarios, projecting expected improvement in cycle time, cost, and resource requirements, identifying resource bottlenecks, and providing activity based costing.

BPA as a Governance Platform Even in the most process-centric enterprises, end-to-end business processes are rarely governed and maintained by a single â&#x20AC;&#x153;process owner.â&#x20AC;? By their nature, end-to-end processes tend to have distributed ownership and governance. Different groups throughout the organization are responsible for various parts. Without BPA, this makes managing the business from a process perspective extremely difficult. BPA tools allow for this distributed governance authority within the context of a shared enterprise repository. While authorization to change a particular policy, service, or subprocess may be restricted to a particular group, others in the enterprise can see the latest version and incorporate those artifacts within a common change impact analytical framework. Some BPA tools include built-in governance procedures for review, revision, and approval of artifacts within the repository, facilitating consistent governance at the enterprise level.

Benefits of BPA BPA places process improvement and management within a strategic enterprise context. BPA recognizes the interconnectedness of processes with other processes, organizational structures, policies and rules, systems, information, and other factors across the enterprise. It applies a common abstraction layer in the form of models that capture detailed organizational knowledge and describes their mutual dependencies. By taking an enterprise view, BPA helps align the particulars of any process improvement project with strategic goals, and assists strategic decision-making by exposing the impact of a proposed change on other parts of the business. By linking IT and business investment with value chain analysis and prioritized strategies and goals, BPA helps ensure efficient deployment of assets, both human and technological. BPA supports a disciplined approach to creating a process-centric organization through quantitative analysis. It considers the enterprise context of potential improvements, and allows quantitative projection of the expected performance benefit, comparing as-is process metrics with a range of potential to-be scenarios. Change impact analysis streamlines business and IT planning by identifying downstream impacts early. Quantitative performance analysis, including simulation and activity based costing, enables the resource planning and system sizing needed to meet existing and new service level agreements. Most important, BPA provides a central hub for process-related information across the enterprise, allowing business to be more agile at the strategic level, able to more quickly create products and services that bring true competitive advantage. Moreover, BPA encourages standardization and reuse of best practice procedures, policies, and business rules across the company, and provides the information needed to plan organizational ÂŠ Bruce Silver Associates 2010

Uniting Process Architecture and Execution

change or system consolidation. It provides centralized process governance infrastructure while allowing for distributed ownership of end-to-end processes. Finally, BPA links BPM to IT architecture. Many organizations provide enterprise-level architectural planning and management for IT assets but leave BPM up to individual projects and departments. BPA applies a similar enterprise structure to business processes, and links those processes to the IT architecture. Again, the key benefit is more effective investment and more efficient deployment of assets.

A Gap in the Marketplace BPA and BPMS would appear to be two faces of the same coin. Nevertheless, these technologies have evolved independently, almost in isolation. Tool vendors play in one space or the other, rarely both. They barely acknowledge each other’s existence. Even vendors that provide both BPA and BPMS typically do not allow true integration between the tools. Moreover, on the end user side, within the same company, BPA and BPMS are typically employed by separate “BPM” groups, who may have little interaction or even awareness of each other.

The BPA Challenge BPA provides tools to do effective risk and architecture analysis, but populating the system with actual process models and keeping the repository up to date represent huge costs. Moreover, how does BPA ensure that the process is executed as modeled, when modeling and execution are disjointed? Even after the process is modeled, companies spend vast sums on auditors and consultants to understand how those processes are actually executed and enforced. Connecting an idealized process world with reality is at the heart of the BPA challenge. Meeting this challenge requires BPA to offer compatibility with the process models used by a BPMS, either in their native process modeling tool or by roundtripping with a BPMS modeling tool. Historically, BPA vendors have defined their own process modeling notations and formats, whereas BPMS vendors have largely standardized on BPMN, a vendor-neutral modeling standard. BPA by definition deals with multiple models, and defines a web of inter-relationships between those models through a complex metamodel. Changing the native process modeling tool in the BPA environment would mean changing the BPA metamodel, so vendors are reluctant to do it. Most BPA tools attempting to integrate with a BPMS do so by mapping their native process model to BPMN on export. But it is a one-way street, as it is impossible to roundtrip BPMN model changes back into the native BPA process model. For processes that are implemented in a BPMS, that means that the process model in the BPA Suite is merely a modeler’s initial conception of the implementation, not a model of the actual implementation, which could change substantially throughout the cycle of continuous improvement. So roundtripping BPA process models with BPMN, the process modeling standard, is the first challenge. The second challenge, which is related, arises from the fact that executable details in a BPMS process design are tool-specific, layered on top of the BPMN. These include the data objects, the forms, and the business rules employed – all artifacts that rightfully belong under the BPA umbrella. Because those details are BPMS-specific, mapping them from native BPA models requires a separate development effort for each target BPMS. Roundtripping there is almost nonexistent.

Uniting Process Architecture and Execution

The BPMS Challenge A BPMS provides fine-grained control over process execution and enforcement of policies and rules, but cannot see the relationships and dependencies of those processes across the entire organization, or their alignment with corporate strategies and goals. For BPMS vendors, meeting that challenge requires reproducing the repository, metamodel, governance features, and countless other tools and editors required by BPA. However, most BPMS vendors are not really in the “tools” business. Their tools exist primarily to support the BPMS runtime components. Some BPMS vendors even give their tools away. Thus investing in anything remotely approaching real BPA is rarely something the vendor can afford. A few BPMS vendors offer something like BPA “lite,” but nothing that comes close to fulfilling the mission of strategic planning and analysis at the enterprise level.

The Need and the Opportunity Not every process improvement or performance monitoring project requires process automation in a BPMS, but a BPMS makes it a lot easier to maximize operational efficiency, standardization and compliance, business agility, performance visibility, and innovation. Increasingly, the most strategic new processes in the enterprise will be based on a BPMS. So there is an obvious need to unite BPMS tools, where those processes are designed and updated over time, with BPA, the strategic enterprise repository of process artifacts and focal point of process governance. Unless BPA can capture executable designs as they are actually implemented, including changes over time, BPA’s “strategic” view will only represent the modeler’s initial conception of the process, not what is actually deployed. In theory, you can keep the two environments synchronized manually, but in practice this is extremely difficult to achieve. The growing acceptance, among BPMS and BPA vendors alike, that BPMN is the universal standard for process modeling, creates an opportunity to bridge the gap. Despite the challenges mentioned above, Appian, a leading BPMS vendor, and MEGA, a leading BPA vendor, have now teamed up to do it.

The Appian-MEGA Solution Before describing the integrated solution, here is a capsule summary of the two vendor offerings.

Figure 3. The Appian BPM Suite (Source: Appian)

Appian in a Nutshell Appian, founded in 1999 and headquartered in Reston, VA, is a leading BPMS vendor with over 2.5 million seats deployed. Its Appian BPM Suite (Figure 3) is ranked a Leader by Gartner,

Uniting Process Architecture and Execution

Forrester, IDC and others, and its cloud-based Appian Anywhere offers the same capabilities on demand through a SaaS subscription model. Appian provides the industry’s only 100 percent web-based BPMS. Appian’s comprehensive set of natively-integrated components extends the standard set of BPMS capabilities with unique real-time performance analytics, built-in content management, and a collaboration portal providing a user-configurable runtime environment. These functional capabilities are exposed to process designers through a palette of Smart Services, essentially prebuilt executable design components that perform specific tasks. BPMN modeling lets you assemble these tasks into process flows, but IT does not have to develop the underlying executable functionality. It comes out of the box. Through a combination of functional power and extreme ease of use, Appian strives to accelerate the design, execution, management and optimization of process applications. Government agencies and a broad range of commercial organizations use Appian to automate, streamline and better-manage critical functions across areas such as financial operations, compliance and risk management, service delivery and support, program and project management, sourcing and procurement and IT services. The US Marine Corps, for example, saved $9 million in one year from an Appian procurement solution. The US Army saved $28 million in hardware costs alone after deploying Appian as the underlying technology for Army Knowledge Online (AKO), the world’s largest intranet serving more than 2 million members of the US Armed Forces and their families. Telecom solution provider Nokia Siemens Networks has benchmarked $15 million in annual productivity savings from its use of the Appian platform for Consulting Services and Integration planning and delivery. Concur, a leader in On Demand Employee Spend Management services, saves $700,000 per year using Appian for a host of IT services related to customer on-boarding, deployment and maintenance.

MEGA in a Nutshell MEGA, founded in 1991 and based in Paris, France with North American operations in Boston, MA and Washington, DC, is a leading BPA and enterprise architecture suite vendor. The MEGA Modeling Suite (Figure 4) provides a repository-based platform and assorted tools for process modeling, business architecture, IT planning, and Governance, Risk, and Compliance. It provides built-in frameworks and libraries for vertical architecture standards like eTOM, ITSM, TOGAF, and DODAF, and tools for publishing its artifacts to a broad community across the enterprise. They are one of only three vendors that are ranked by leading analysts in BPA, EA, and risk management. MEGA has extensive experience in BPA, with implementations at more than 3,000 companies worldwide, including Procter & Gamble, Aetna Insurance, GeoEye, Axa, DIRECTV, Alstom Power, Cardinal Health, Michelin, Nissan, Unicredit, Hydro-Quebec, Morgan Stanley, as well as state and federal governments such as US Department of Agriculture, Department of Homeland Security, New York State, and NASA. For example, GeoEye, the largest commercial satellite remote sensing company in the world, used MEGA to develop an infrastructure that lets managers use company resources (people, money, time, equipment) more efficiently, and at the same time meet new Sarbanes-Oxley compliance requirements.

Uniting Process Architecture and Execution

Figure 4. The MEGA Modeling Suite (Source: MEGA)

In addition to individuals who use the MEGA software to do modeling, there are about 300 business users across GeoEye who use the output of the data repository in HTML or Word. For example, the project team that led the Sarbanes-Oxley and ISO compliance efforts were frequent users as they shaped those programs. The MEGA software allowed them to select the integration points between business processes, applications, and business structure that supported the applications, giving them a better idea of how the business was aligned to meet their specific goals. Another customer, UniCredit, selected MEGA to help them meet the requirements of 262 compliance, define a governance model, and implement a unified enterprise control system. Due to the complex and international aspect of the project, involving over 40 Group companies in 20 different countries, UniCredit actively involved business process owners to go beyond compliance and improve both operational processes and sharing of information and analysis methods. This involved developing and promoting a coherent business model, using a common enterprise repository that integrates standard and shared methodologies. This allowed comparison of work practices across the company and definition of best practices for risk management, operational excellence, and process optimization. The final by-product of the 262 Compliance Project was the optimization of business processes, particularly in the finance department, which is the most directly concerned by the regulation.

Unifying the Tools MEGA starts out ahead of most of its BPA competitors by accepting that many to-be process models are going to be executed in a BPMS. Thus MEGA supports, for example, mapping of process models to BPEL and XPDL for interchange with a variety of BPM Suites. But, as

ÂŠ Bruce Silver Associates 2010

Uniting Process Architecture and Execution

pointed out earlier, this kind of mapping is mostly one-way, since changes in the BPMS cannot be automatically synchronized with the process model in BPA. The Appian-MEGA solution goes further than this to offer the strategic benefits of full roundtripping. It essentially brings the Appian executable design metamodel – both standard BPMN and Appian-specific features like Smart Services, forms, and business rules – inside the MEGA suite. The tools and overall environment are still MEGA, but the underlying data is Appian-native. That means there is no roundtripping problem between the MEGA environment and the Appian native environment. It seems obvious, but this is a fundamental change in the way BPA and BPMS work together. To my knowledge, it is unique. Figure 5 illustrates what this looks like. The background shows the Appian Process Architect by MEGA modeling editor as it appears within the MEGA BPA environment; it can also be used independent of the other MEGA modules. The tree view in the left panel lists Appian modeling artifacts. For example, Add Customer Response, Alert Case Worker, Approve Resolution... These are Appian Smart Services, either prebuilt or user-defined. Once imported into Appian Process Architect by MEGA, they can be managed as enterprise assets, linked to strategies and goals, used in simulation analysis, mapped to specific systems and organizational units and geographic locations, all managed within the MEGA repository.

Figure 5. BPMN model in MEGA (background) and Appian-native (foreground) tools. Source: Appian

The foreground at lower right shows the Appian native tool. IT process designers would typically use it for custom development, testing, and deployment of executable process solutions. Note that the process diagram looks mostly the same as in MEGA. There are slight differences in colors and line styles of standard BPMN shapes, but the underlying process model is clearly identical. You can edit the model in either environment and synchronize with the other, without the lost-in-translation problems that afflict every other BPA-BPMS integration.

Applications and Benefits The unique Appian-MEGA solution provides a host of benefits:

Uniting Process Architecture and Execution

1. Continuous alignment of architectural and process documentation with actual execution. Typically, process modeling artifacts in BPA represent just a modeler’s initial conception or “requirements” for the to-be process, not the process as it was actually refined, deployed, and continually modified. Auditors, executives, and other stakeholders count on the BPA repository to represent reality, not an artist’s conception of it. The Appian-MEGA solution provides that. Moreover, in some organizations, enterprise architecture itself can be perceived by lines of business as idealized, disconnected from the way things actually work. Continuous alignment of the enterprise BPA repository with process artifacts as they are actually deployed prevents that. That not only helps BPMS fit more easily within the enterprise BPM strategy, but adds credibility and effectiveness to the enterprise process architecture. 2. Roundtrip engineering from conceptual modeling to execution and back to model analysis. Conceptual process modeling is inherently a business function, performed variously by process owners and participants, analysts, and architects. Executable process design is more often an IT function, although tools like Appian have made much of it accessible to business process analysts. The ability to roundtrip between the business conceptual view and the IT executable view of the process is the key to business-IT collaboration, a prerequisite to true business agility. 3. Advanced performance analysis. BPA and BPMS bring separate strengths to optimizing process performance. BPA tools like MEGA feature richer process analysis capabilities than a typical BPMS. Appian Simulation by MEGA can look across multiple processes and incorporate organizational resource models and other constraints to project expected performance in a range of what-if scenarios. BPM Suites like Appian, on the other hand, capture actual process metrics in operation. Uniting MEGA and Appian means that actual performance and audit trail data can be fed back into BPA’s analytical models, without laborious manual transformation. These benefits of the Appian-MEGA solution are important to a range of stakeholders:  Business process analysts are able to enjoy roundtrip engineering between their own descriptive and analytical models and executable designs as deployed. This is the key to business-IT collaboration.  Enterprise architects are able to model the real world of process artifacts, continuously as they evolve, not just how they were originally conceived.  Auditors are able to rely on BPA as a repository of how the business actually works, to verify segregation of duties, documentation of financial controls, and risk analysis. This can save hundreds of hours and significant cost.  Executives benefit from assurance of actual compliance with policies and best practices across a globally distributed enterprise. Connecting the way processes are supposed to work with the way they actually work, as enforced by a BPMS, dramatically lowers the risk of doing business.

The Bottom Line The synergy between BPA and BPMS is obvious, but we almost never hear about putting these two technologies together. The industry analysts treat them as completely separate “quadrants,” and in many companies there is little or no interaction between them. From the tool vendor’s perspective, one can understand why this is. But from the end user’s perspective, it would be so

Uniting Process Architecture and Execution

much better to unite them. It’s a technical challenge, and thus integration between BPA and BPMS has been mostly clumsy and one-way. The Appian-MEGA solution is unique, and does it right. The complete set of BPMS design artifacts is directly incorporated into the BPA metamodel, including executable Smart Services, forms, and rules. That means these artifacts can be linked to other process models across the enterprise, as well as to enterprise models of organizational structures, policies and rules, strategies and goals, resources, facilities, and other elements of business architecture.

“The integration of [Appian and MEGA] will give us an incredible amount of visibility into process performance and the potential impact of change on our production processes.” Pat Steinmann, Manager, Request Services, Enterprise Rent-A-Car

Process models can be edited in either the Appian or MEGA environment with roundtripping guaranteed, so auditors, executives, architects, and business analysts can understand the business as it really is, even when it is continually changing. This increases compliance, lowers risk, and reduces the time and cost of audit. It also helps align IT investment in process improvement with broader strategies and goals, and identifies downstream impacts of proposed changes that might otherwise be overlooked. Most people understand the need for both BPMS and BPA, but have never seen an example where they could be tightly integrated. The Appian-MEGA solution shows not only that it can be done, but that such integration offers tremendous organizational value. Bruce Silver March 2010