Taking an Enterprise Architecture approach to BPM
By Peter Schooff, Contributing Editor, ebizQ , 12/17/2010
In this Q & A, Peter Schooff speaks with ebizQ contributor Dr. Alexander Samarin about corporate BPM strategies. Samarin, chief enterprise architect of the African Development Bank, is author of “Improving Enterprise Business Process Management Systems” (Trafford Publishing, October 2009).
PS: Why should a company consider BPM?
AS: For me, BPM is three complementary things. First, there’s the BPM discipline, how to use processes to better manage an enterprise. Second, [there’s] BPM software [and] technology from many, many vendors. And third, [there’s the] architecture of a BPM enterprise system that is built to manage, to govern, execution of the processes within enterprises.
Together, they’re very powerful tools and [a] primary force to make an understandable, explicit and executable coordination between systems, employees, customers and partners. With such coordination, it becomes possible to monitor the dynamic of various indicators, values and risks, and it helps people for better decision-making. In addition, it helps with the evaluation of feasibility and impact of future changes.
PS: What are some problems that companies face when they go to BPM?
AS: Typical problems at first [involve questions about] “What is it?” A lot of efforts are spent to explain BPM. Usually within a company, there is a mixture of opinions from the Internet. So [building] a commonly agreed-upon understanding about BPM is a must.
Second : “What does it do for me?” [It’s necessary to explain] to everyone how BPM will address his or her concerns and how his or her current working practices will be changed for the better. Of course, it’s not necessary to talk to each of the thousand people within a company; instead, be prepared for talks with about 20 groups of people.
[A third question involves project size.] BPM projects usually start small, without a bigger view or understanding of how to grow. [I] recommend considering BPM as an enterprise-wide initiative from the very beginning.
The last typical is: “How do we change it?” By definition, any BPM solution will be changed…So [my recommended] approach is to architect flexibility because many, many changes will be carried out.
PS: Is an enterprise architecture approach important for companies that are considering BPM?
AS: Yes, both enterprise architecture and BPM are enterprise-wide activities or programs, and you don’t want them to collide. At first look, they’re very different. Enterprise architecture is about [going from] this state to this state as a transition, and the typical lifespan is [measured in] years. BPM, on the contrary, is talking about continual improvements and a typical time span is weeks or months.
But the two may be very complementary and enrich each another. For example, enterprise architecture does a great job in describing the enterprise genotype, or full nomenclature, of enterprise artifacts. And there are many techniques to evaluate enterprise phenotype, a set of observable characteristics such as performance. But enterprise architecture cannot answer how enterprise genotype defines enterprise phenotype. From the BPM side, it’s very strong with executable models of relationships between artifacts. And in this way, it can form some kind of a bridge between enterprise genotype and enterprise phenotype.
Actually, your enterprise architecture team should be the best friend of your BPM initiative and vice-versa.
PS: Essentially we’re talking about processes that are human processes. So what is exactly the social aspect of BPM?
AS: English is not my mother language, so I [looked] at the different meanings of this word “social” and took some of those meanings.
First, [it is] affordable to everyone. BPM and new tools are now more affordable for small and medium enterprises and governments. Second, [it involves] public or common ownership. Right now, this is mainly organization of work and provisioning of convenient access to different artifacts, which is a common practice in modern BPM tool.
And the third meaning, which is the simplest, [involves] human-initiated interdependent relationships with others…Of course, that last meaning is the most interesting for clients of BPM.
PS: You touched on this in the first question, but to drill down a little bit more, exactly how does BPM help companies solve their problems?
AS: BPM mainly helps companies through managing the common understanding of work. One aspect [is] coordination. Coordination is externalized from people’s heads, applications, quality documents and habits in an understandable and explicit form. One of the forms is the well-known BPMN [Business Process Modeling Notation] diagrams.
Then this explicit coordination is used through the whole improvement lifecycle: plan or model, implement, do or execute, check or control, and act or optimize. In many enterprises, those phases are carried out by different roles and often different languages are used…And each time information is moved from one role to another, there are some translation errors, explicit coordination in BPM removes the source of those errors.
Then BPM helps people to express coordination the same way, so that different people within an enterprise are solving the same problems in very similar ways, thus improving reusability.
And finally, BPM makes your enterprise information more flexible because executable coordination serves as a way to assemble bigger services from smaller ones. So BPM helps companies to make some kind of breach, glue or guidance between strategy and execution.
PS: What do you see ahead for BPM?
AS: I can see that it should [include] better understanding among BPM experts, more practical standards, easy comparable business cases, more commonly agreed-upon knowledge, better interchange been tools from different vendors. We know that BPM is a vendor-driven market right now; I see it [becoming] more customer-driven in the year ahead.
This Q & A was excerpted from a recent ebizQ podcast. It has been edited for editorial style, clarity and length.