Jaa

Our own worst enemy: BPM pros tell horror stories about working with EA

  • Artikkeli

I recently asked two questions on LinkedIn.  I asked BPM professionals what they thought about working with Enterprise Architects, and I asked EA folks what they thought of working with Business Process Managers.  The results: BPM professionals want to work with you, but you have to meet them half way.

The number one complaint against Enterprise Architects?  Focusing on technology instead of business. 

Kenneth Beard of South Africa tells of Enterprise Architects who “think that EA = ITEA and BPM = name of a software … tend to live in silos, fight turf wars amongst the technical population, and are often at odds with the business they should serve, making it difficult to work with them.”

John Segal of New Zealand says

“in my experience the majority of so called EA's are IT focused and hired to be so. Consequently they are typically interested in the automated solution aspects of BPM rather than what is to my mind its primary importance as a process design and improvement meta process.”  He goes on, “So, with IT oriented EAs emphasizing a technology solution led concept of BPM, they can effectively become an impediment to deploying BPM as a core business meta process.”

If John feels that the majority of EAs are an “impediment,” then we may have only ourselves to blame.  After all, many of the responders were Enterprise Architects, and surprisingly, they agreed.  Adrian Gregoriu of the UK shares this bit of insight:

“BPM and other process improvement efforts like Six/Lean Sigma, business process and organization alignment to strategy are left out of the definition of EA and business architecture development. In my work, I have collaborated with BPM people and efforts but could not ever engage EA people to work with them. After all, contrary to what many claim, EA seems to be mostly about IT, unfortunately.”

Alas, all is not lost.  There were also stories of success, when conditions were right. 

Kenneth Beard shared a positive opinion as well.  He prefers to work with Enterprise Architects who “understand that real EA is a set of layers for process, information, application and technology that are inseparable and work in concert & must be managed as such.”  In this environment, Mr. Beard finds that Enterprise Architects view BPM in its proper role, “BPM is seen as a customer focused initiative to improve the performance of the real enterprise architecture” and he finds these architects to be “strategic level thinkers who share an integrated view and are a pleasure to work with, and they get results.”

Alexander Samarin of Switzerland tells the story of carefully, over time, educating a team of Enterprise Architects so that they can understand how best to use BPM in their work.

“At first, I explained to the team how BPM can solve many of typical IT problems (rescuing a couple rotten projects helped me a lot). Then, in each opportunity -- a difficult problem, new enterprise-wide project, developing principles, writing procedures, etc. -- we applied the power of BPM (discipline, tools and practice). We gave seminars, built demos, shared our knowledge, etc.  After about 2,5 years, the first BPM-centric solution has been selected (via a tender) for the new information system of a governmental service. “

There is a great deal of insight here.  Clearly, the combination of Enterprise Architecture and Business Process Management is valuable, when it is applied right.  Clearly, Enterprise Architects are, as a group, missing out on that value.  Some folks are taking the time to educate, while others wait patiently for an EA who actually has a clue. 

There are surprising synergies.  Here is Kenneth Beard again, sharing his opinion about how important an EA repository is. 

“we need to appreciate that business leaders with different experience find it hard to grasp. Most believe it is simply too complex to document and maintain the information assets. But the diversity of each layer of the EA plus the know-how of how they work in concert is vast, and is exactly the reason why this knowledge needs to be managed in an integrated repository, with strict configuration management and change control procedures. Otherwise it remains in the heads of various SME's and at best partly documented in numerous unrelated formats that decay with time or are lost when people move. The benefits of having it in one home are vast, enabling enterprise performance management, despite having a massive knowledge asset.”

Lastly, our friends in the BPM community have some advice on how to work well with them… focus on the customer!

Kenneth Beard tells us that “the emphasis should be on the customer experience so successful outcomes translate into meaningful results along with value for the business.”  John Macdonald of the Netherlands provides similar advice, “the intended customer experience should be the start point, then assemble the parties and methodologies required to bring about the transformation. EA, BPM, L6SS, Project Mgmt etc all have vital contributions to make.  The change leader should be the party responsible for customer satisfaction, employee well being and profitability, the team should be made up of a cross section of process (business), IT and employee competence experts.”

What is your experience when working between EA and BPM roles? Please share your story!

Comments

  • Anonymous
    July 07, 2010
    For me Enterprise Architecture has always been 'real' Enterprise Architecture and has always included Business Architecture, Business Processes and BPM.  There should not be any artificial conflict between EA and BPM practitioners! It's only those clients who misunderstand the Enterprise Architecture discipline in the first place and treat it as just another name for  IT Architecture, somehow completely separate from the Business Architecture, who cause this problem in the first place. Enterprise Architects must be Business focused and not IT focused and be doing 'Real' Enterprise Architecture.

  • Anonymous
    July 07, 2010
    When I look at EA job description, out of 10 only 1 stands out to be a real EA job, others are only Information Technology, integration or data architect jobs. I do come from a Information Technology Architecture background, but when started my EA practice with very little guidance at hand,I realised that I must be business focused than IT focused. Very Informative Blog, Thanks.

  • Anonymous
    July 07, 2010
    Fantastic piece Nick, thanks for the insight! Certainly it chimes with my own experience. In the BPM case study work I've been doing over the last 18 months or so I've always tried to dig into how the BPM implementation has interacted with EA... and invariably the answer has been (to paraphrase) "why would I?"

  • Anonymous
    July 15, 2010
    The comment has been removed