Uplifting transformation capabilities – reconciling Enterprise Architecture and Business Process Management
Many enterprises are embarking on or are in the middle of a major transformation. Most transformations come with business goals and IT goals. How well business and IT are connecting in planning and execution of the transformation is a key determinator on transformation success.
Business Process Management (BPM) and Enterprise Architecture (EA) are methodologies of choice that many SAP customers are turning to in order to drive their transformation. Within the last 15 years I have been working with customers on architecture and more recently on how BPM plays into their transformation. In this series of blog posts, I want to share perspectives on how BPM relates to EA and how enterprises can create synergies to train the transformation muscle. The blog is intended for anybody playing in either EA or BPM and trying to look out to the other side.
With the partnership of SAP Signavio and LeanIX in view, how does BPM actually relate to EA? What are their objectives? How do they reach them? And after all, are they conflicting or synergistic?
Where are BPM and EA coming from and how they compare?
The field of EA initially aimed to address the problem of managing the increasing complexity of technology and later has evolved into aligning technology with business. Both had become very challenging and resulted in a low perceived value of technology. BPM has its origins in the 2000s and aims at improving process efficiency and performance in a structured way. By many it is seen as succeeding the Business Process Reengineering (BPR) era in which enterprises had radically changed their business processes with the help of emerging information technology. BPM wants to continuously improve processes that have been more radically reengineered.
By now, both BPM and EA have matured standards on various levels practitioners can turn to for orientation, i.e. TOGAF for EA and BPMN 2.0 for BPM.
What are the goals of both methodologies?
What BPM and EA have in common is that they are both set to enable strategy, i.e. to break down strategic business objectives into transformation priorities. Practitioners of both disciplines are interested in bridging the gap between lines of business (LoBs) and IT to deliver business transformation.
How are the goals achieved?
BPM and EA have different perspectives on transformation and reach their goals in different ways. BPM sees business processes in the center of transformation activities and establishes them as the common language between different stakeholders. EA aims to connect the dots between different architecture layers from business architecture to applications and interfaces down to the technical architecture and infrastructure. EA creates transparency throughout these layers while BPM rather wants to establish transparency over business processes that span across business units and divisions of an enterprise.
BPM wants to enable an organization to operationalize continuous process improvement. An EA practitioner is looking for creating target architectures for capabilities, applications, systems and chopping up reaching these target states into smaller pieces that are digestible for the enterprise.
There is the notion of continuity in both disciplines. Business processes and architectures are continuously under pressure for improvement – sometimes incremental, sometimes more radical. How well an enterprise is capable of continuously transforming itself has become a factor of differentiation in the marketplace. To anchor the notion of continuous transformation, enterprises are establishing transformation offices in their organizational structure with a mandate of orchestrating transformation activities across LoBs, business divisions and geographies.
How does BPM relate to EA?
The grand ambition of EA is to capture the big picture and all aspects of this complex mix of business and IT that matter to drive transformation. Considerations for the various layers of EA are outlined below and they are used to look at transformation decisions from all angles.
Any EA work done well looks at elements of business architecture as it is fundamental for any transformation decision to understand business. What are business scenarios critical to the mission of the enterprise? What are the business processes behind? Which require improvement? How are they supported by IT today? What are opportunities for improvement? How can improvement be measured? And this is at the core of the BPM discipline.
Welcome to the intersection of BPM and EA.
BPM then takes this layer much deeper and wants to model, analyze, measure and ultimately improve business processes. Real Business Process Transformation with an architecture view.
Have you made experiences in fields where BPM and EA intersect?
In next blog post, I will look more closely on this spot and propose some linking elements for the transformation practice. How can die-hard EA practitioners talk to BPM aficionados and find common sense?
I'd say that starting with BPM could make it easier to plan the design of a future-proof EA (and the transition to it). If you use capabilities, you need to match the business and IT objectives to capabilities via value drivers that are provided by capabilities. That's often quite hard because business users "live in" their processes; they don't usually think in capabilities.
If you start with business processes - and use BPM to design improved target processes - you can describe what is needed much better. Then, you link process steps to capabilities via business activities.
Spot on Bjoern Weidner! Business processes are the de facto lingua franca of lines-of-business but there is definitely a place for capabilities to bring transformation forward. Stay tuned for my next blog post on this!
I feel identifying BC is the first step and then you can enhance BC with processes supporting those capabilities.
Further once BC's identified , we need to identify technical capabilities supporting those BC's .