Planning for change is a necessity for most modern enterprises, yet plans that are never executed have very little value. Continuous business performance and services optimization is derived from proper coordination between planning and execution. This in turn requires a firm understanding of the lifecycles of the enterprise, as well as the establishment of appropriate collaboration and governance processes.
While Business Process Management (BPM) and Enterprise Architecture (EA) each have value on their own, IBM believes that they are naturally synergistic, and best when done together for better business outcomes and strategic alignment of business and IT. When done together, BPM provides the business context, understanding and metrics, and EA the discipline for translating business vision and strategy into architectural change. Both are, in fact, needed for sustainable continuous optimization.
It is important to realize the value of direct collaboration across BPM and EA boundaries. Only when supported by appropriate collaboration and governance processes can BPM and EA roles work effectively together towards the common goals of the enterprise.
This article describes the principles for aligning and interconnecting BPM and EA from a business perspective. The primary audiences are leaders and architects who need to understand how to effectively combine BPM and EA as a key differentiator for successful enterprises in their drive toward continuous business improvement.
In a globally integrated marketplace, the ability to effectively plan and execute change is quickly becoming a survival skill. Historically, biyearly or yearly business and IT planning was the norm and projects were often driven with a budgeting mindset. However, as our environment becomes ever more dynamic, our world ever more interconnected, instrumented, and intelligent, businesses must now continuously improve business processes and optimize costs.
Too often enterprises find themselves restrained in meeting these imperatives by lack of coordination between planning and execution. The road toward strategic change involves the right vision, the proper understanding of the existing portfolio, the ability to define and execute the right projects with the right scope, and finally a robust platform that ensures the integrity, reliability and scalability of business processes across the enterprise. All of which need to be governed and managed collaboratively between the people planning the future of the enterprise and the people optimizing and managing the portfolio of existing processes and solutions.
The classical value proposition of EA is centered on the translation of business vision and strategy into effective enterprise change by creating and communicating key requirements, principles, and models that describe the future state and the enterprise, and enable its evolution. The ability to architect the future of the enterprise is a hallmark of EA, and is the cornerstone for enterprise-wide planned improvement.
The notion of business process optimization has been around even longer than EA. Yet, around the same time that EA became a mainstream topic in the context of business and IT alignment, the focus in many process optimization communities shifted subtly to business process management (BPM). The key distinction for BPM as a discipline is added focus on flexible and dynamic process design, as well as process orchestration and automation through IT enablement. In addition to reduced cost through continued process optimization and automation, BPM also provides the foundation for converged and agile business and IT responsiveness.
While BPM and EA each have value on their own, IBM believes that they are naturally synergistic, and best when done together for better business outcomes and strategic alignment of business and IT. When combined, BPM provides the business context, understanding, and metrics, and EA the discipline for translating business vision and strategy into architectural change. Both are needed for sustainable continuous optimization, as illustrated in Figure 1.
Figure 1. BPM and EA are best when done together
From an EA perspective:
- In one direction, establishment of the proper business context is a prerequisite for effective planning of architectural change –- a business context that naturally includes BPM artifacts and metrics.
- In the other direction, BPM projects are governed and guided by architectural considerations and targets –- targets that can naturally be provided by EA.
From a BPM perspective:
- In one direction, process change may drive the need for IT architecture change –- architectural change that can naturally be driven by EA.
- In the other direction, EA can reference business processes for architectural analysis and design –- business processes that are naturally provided by BPM.
These synergies are enabled by appropriate collaboration and governance processes -- processes that must coordinate plans and solutions without hampering effectiveness by requiring overly detailed synchronization. We'll discuss that in more detail in Coordinating planning and delivery.
Furthermore, by adding Service Oriented Architecture (SOA) to the mix, you can realize additional synergies (see [SOA, BPM and EA] for details). The value proposition of SOA is centered on agile and aligned business and IT design and delivery. The ability to architect the alignment between business and IT is a hallmark of SOA, and is the cornerstone for derived business agility, reduction of cost and risk, as well as improved portfolio management. Consequently SOA as an architectural style is well suited for modern EA. Furthermore, SOA provides horizontal transactional strength to a BPM initiative, thereby enabling business integrity and operational excellence (see [SOA and BPM – why] and [SOA and BPM – what] for details).
Historically, BPM and EA have evolved independently without explicit recognition of each other and without consideration of the need for collaboration across the two disciplines. Yet in most cases continuous business improvement will not happen without effectively merging the holistic planning aspects of EA with the process and optimization focus of BPM. We need to work smarter across the enterprise, transforming our organizations so that people can make more informed decisions, build deeper relationships and work with more agile and efficient business processes.
According to Gartner, process improvements have been the number one concern of CEOs for the past four years. Studies, such as the recent McKinsey survey CDR: Need URL and analysis of 100 companies in France, Germany, UK and the US show that aligning business and IT efforts results in double the productivity gains of those efforts in isolation. But working smarter requires more than simple alignment of efforts; it requires a deep understanding of the business processes of the enterprise, as well as the ability to execute change on these processes by collaboration between business and IT. This convergence of business and IT concerns is imperative from both a planning and an execution perspective.
Lately, a lot of focus has been put on executing agile change at the project level, yet agility at the cost of consciously planned enterprise improvement is not very useful. In fact, one of the challenges a modern enterprise must meet is how to achieve continuous business improvement through collaborative and integrated planning and delivery processes across the enterprise. This meld of planning and delivery is exactly where BPM and EA are strong when done together, as illustrated in Figure 2.
Figure 2. Integrated planning and delivery with BPM and EA
The immediate BPM and EA synergies are important not only to IT, but to the line of business as well. Without proper integration of planning and delivery processes across the enterprise, business evolution becomes opaque and uncoordinated. Without rigor in managing architectural change across business and IT, BPM solutions may quickly become brittle. Conversely development of a business architecture is a principal activity that needs to be undertaken by EA unless appropriate artifacts can be derived from, for instance, BPM activities (see [Actionable BA] for additional details).
It is important to realize that improvement derived from BPM and EA has lasting value only when supported by appropriate collaboration and governance processes. Done in isolation, either discipline may trigger confusion and distrust among stakeholders throughout the enterprise. From a planning and delivery convergence perspective, we must ensure that enterprise plans are evolved in coordination with the delivery of solutions through change programs and projects. It is tempting to assume that such coordination always happens from the top down, with enterprise plans driving the definition of projects, as well as governing their execution. However, in practice plans and solutions are truly interdependent, and the need for coordination may be triggered in either direction.
Typically in the context of EA, we talk about doing transition planning based on the enterprise architecture, deriving change projects that in turn are governed according to said enterprise architecture. This is in essence a hierarchical view of the world, with EA at the top of the hierarchy. In reality, though, the relationship between EA and BPM is far from hierarchical.
In order to harness change, we need to separate enterprise planning concerns from solution delivery concerns. However, as illustrated in Figure 3, we should not try to continuously synchronize the planning cycle with the delivery cycle, but rather to leverage the powers of iterative planning and iterative development separately and only coordinate as appropriate.
Figure 3. Coordinating the planning and delivery life cycles
Because these two cycles have different scopes and purposes, they are not linked in any linear or hierarchical fashion. The differences between the extended timeline and enterprise perspective of a roadmap and the execution of a specific project with limited scope and deadline simply makes it undesirable to combine the two cycles into one. As an example, consider a five year roadmap for a business merger. Even though the intended end result is known, it would be impractical to analyze all projects in the roadmap in solution-level detail before delivering and acting on a definition of the roadmap itself. Similarly, for an SOA transformation roadmap, it is impractical to analyze the entire legacy portfolio before being able to deliver a single new SOA solution.
Note that this is not a matter of scope, as a BPM initiative can, and often will, have enterprise scope –- rather it is a question of trying to achieve different things. A clear separation of enterprise planning concerns and solution delivery concerns is important simply because the two types of activities are targeted at different purposes and roles. The enterprise planning cycle results in enterprise blueprints that define a desired future state and are used to prioritize, select, guide and govern the execution of projects –- the purpose is the planning of potential changes. Examples of enterprise blueprints are organizational blueprints, enterprise data models, and standard network topologies. The solution delivery cycle results in solution constructs deployed in the business and IT operational environments –- the purpose is the building of solutions. Examples of solution constructs are business processes, software design models, and actual network designs. Planning and delivery activities are typically interleaved, alternating and iterating as objectives and assets evolve over time. Note that within a business and IT alignment context both the enterprise planning cycle and the solution delivery cycle need coverage across business and IT, including all relevant conformance and key performance indicator (KPI) monitoring. The level of detail and the rigor of governance may vary depending on environment and corporate culture, yet some amount of planning and some amount of delivery always occurs in order to ensure that the goals of the business are being met. And as far as the coordination between the two is concerned, at a minimum coordination ought to occur at the beginning and end of each project in the enterprise.
How should an enterprise practically enact the coordination between the enterprise planning and solution delivery life cycles? Don't fall into an engineering mindset by default! While it is tempting to directly connect enterprise blueprint designs to solution constructs, typically this approach fails because enterprise planning and solution delivery concerns have intrinsically incomparable intentions and work products. For instance, there is no direct translation between an organizational blueprint outlining a desired future organizational structure and the business processes that are part of a new accounting solution. Understanding the relationship between the two types of models requires first understanding the building blocks used to construct each of them -- building blocks such as standard roles, activities and services. What we need in order to provide a dynamic bidirectional link between enterprise planning and solution delivery is an explicit awareness of (and distinction between) architectural principles, enterprise patterns and reusable solution building blocks. Separating concerns into building blocks and designs will facilitate effective collaboration and communication between the planning teams and the delivery teams in an organization, keeping the architecture consistent, dynamic and alive. For example, the standardization (as building blocks) of accounting activities and the organizational roles performing them will help bridge the gap between the enterprise design represented by the new organizational blueprint and the solution constructs represented by the business processes of the new accounting solution.
From a lifecycle perspective, in one direction we should synthesize the principles and patterns of the enterprise, using these shared building blocks to govern solution delivery projects. This will give us better span of control in achieving a collective and coordinated impact across the project portfolio. In the other direction, mature solution delivery projects should synthesize and leverage their experiences and solution designs to produce shared building blocks to add to the enterprise inventory. Solution organizations should take ownership of their contributions to the enterprise portfolio, and ensure that their projects remain aligned to the enterprise architecture. For additional details, see [SOA, BPM and EA].
Approaching the coordination between enterprise planning and solution delivery in the fashion described above will result in clear targets being set by the enterprise planning cycle – not as things to build for a single project but as targets to live up to for any project in the enterprise, targets that can be anything from architectural principle to a desired enterprise capability. Similarly from the multitude of solution delivery lifecycles (one for each project or change initiative), we will have clear and relevant feedback to the enterprise planning lifecycle –- not as enterprise blueprints to incorporate directly into the enterprise architecture but as feedback on project experiences, feedback that can range from opinions on applied targets to suggestions for new enterprise standards. In that fashion, targets and solutions are not substitutes for each other, nor are they different levels of detail of the same underlying concept -- on the contrary, targets and solutions are intrinsically different things, but still they must be linked together so that their relationships may be tracked and governed, thereby enabling continuous improvement across the enterprise.
While each has value on its own, the disciplines of BPM and EA are naturally synergistic, and when combined provide better business outcomes and strategic alignment of business and IT. Leveraging these synergies at an enterprise level requires the establishment of appropriate collaboration and governance processes. From an organizational perspective, the enterprise needs to leverage the synergistic powers of robust architectural planning and agile business optimization represented by EA and BPM respectively. From a technological perspective the enterprise needs to establish a platform that will enable the appropriate collaboration by creating visibility, traceability and integrity between targets and solutions across all roles and tools.
Effectively combining BPM and EA will be a key differentiator for successful enterprises in their drive toward continuous business performance and services optimization. To that end, IBM’s integrated methods, tools and infrastructure are a good starting point that provide a solid foundation for the future.
- [BPM and SOA – why]: IBM whitepaper,
Achieving business agility with BPM and SOA together – Smart work in the smart enterprise,
Claus T Jensen, Rob High, Jr., Steve Mills, 2009
- [BPM and SOA – what]: IBM whitepaper,
BPM and SOA require robust and scalable information systems – Smart work in the smart enterprise,
Claus T Jensen, Rob High, Jr., Steve Mills, 2009
- [SOA, BPM and EA]: IBM whitepaper,
Leveraging SOA, BPM and EA for Strategic Business and IT Alignment,
Claus T Jensen et al, 2008
- [SOA Foundation]: IBM whitepaper,
IBM’s SOA Foundation – An Architectural
Introduction and Overview,
Rob High, Jr., Stephen Kinder, Steve Graham, 2005
- [Smart SOA™]: IBM whitepaper,
SOA: Best practices for
agile innovation and optimization
- [Actionable BA]: IBM whitepaper,
Actionable Business Architecture,
Ray Harishankar, Kerrie Holley et al, 2010
developerWorks BPM zone:
Get the latest technical resources on IBM BPM solutions, including
downloads, demos, articles, tutorials, events, webcasts, and more.
Claus Torp Jensen is a Senior Technical Staff Member and Chief Architect for SOA-BPM-EA Technical Strategy at IBM in Somers, NY. He is part of IBM's SOA Foundation team, working on the convergence of different architectural disciplines. Claus is a member of the WebSphere Foundation Architecture Board.
Prior to joining IBM, Claus had ten years of experience as a Chief Architect and SOA Evangelist.