Do I need Enterprise Architecture to do BPM? I’d say yes. If you do BPM – whether it is the business view of process management or the more technical view – you most likely document or design your processes. How do you do that? You create models or diagrams depicting a process that is composed of process steps or activities, roles and organizations, events, information, systems or services, and much more. If you are serious about BPM you are or should be doing this in a structured and managed approach.
Wow, there we have it. You are building an Enterprise Architecture (EA). The EA provides structured information about an organization that is used to support the decision making process on strategic, tactical and operational level. That includes BPM. After all you do this to decide how to better run your organization’s processes.
The EA is defined by a framework. Robust frameworks like TOGAF, DoDAF or ARIS provide the notation and methodology to design the architecture. The notation provides the standards or nomenclature in which you describe or depict the architecture. The methodology describes how to build, manage and analyze the architecture to facilitate the decision making process. Architecture is composed of architecture views or models with are composed of artifacts or objects and their relationships. A model is also called a diagram. Each element of the architecture can further be described in detail using attributes. Furthermore the EA is generally subdivided into specific architectures: business, application, information and technology. Each supports a specific purpose.
Almost any private or public organization of the 21st century has an EA. They may not recognize it as such but it is there. Where ever you find - more or less – structured information of the organization you have essentially established the foundation of the architecture. Of course not all of this is composed in a way that one can make sense of it.
Therefore if you are serious about BPM you also need to be serious about Enterprise Architecture Management (EAM). It is a management discipline that manages the architecture – the governance, creation, maintenance, and analysis of architecture information. EAM in its governance function prescribes the exact notations, formats, tools and procedures by which the architecture is build. The specifications that are used should be driven by the objective of the architecture activities. What am I trying to do? Do I want to do BPM, service oriented architecture (SOA), IT management, or something else? All of those require specific information that must be provided by the EA.
Now you may say ok - but I do BPM and thus I only need business architecture not your mammoth EA. In my next blog I will tell you why that is right and wrong.
Max J. Pucher - Chief Architect ISIS Papyrus said:
Yes, we need an architecture, but you are adding a huge amount of unmanageable layers. What is needed is a production environment that harbors a maintenable business architecture that users can directly interact with. Everything else is too expensive and does not work. You mention that 60% of EA initiatives are not satsifactory. The others just don’t admit it.
EAM, BPM or SOA is all moving away from the bsuiness user and the customer. IT finally has to move closer …
Max, I want to apologize that it took me so long to answer your comment.
I agree with you that what is needed is a manageable architecture. But in order to get this it is key to manage the architecture in a way that it is providing value to all stakeholders, easy to maintain, robust, standardized and up to date. All this is done via EAM. Again, just because one organization concentrates on BPM it does not mean they don’t need a well defined architecture.
A lot of those projects have challenges because information is scrambled up in PPT, Excel, Visio etc and hard to access and manage. Also BPM is not just about processes and organization. A successful BPM initiative with the goal to optimize and/or automate the processes better needs a lot of information from other views such as capabilities, system, services, data, KPIs, and others.
