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!
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.
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.
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?"
In my case – the business process and business architecture have always been of primary importance – as once one has worked in technology for 20 plus years exploring its width – the technology answers become easier. However – the integration with the BMP and business leadership is frequently impeded and in most cases – I have found IT senior leadership to blame along with the EA's themselves.
Sometimes – CIO's and other leadership types try to 'play' Enterprise Architect and since they frequently (if not always) do not have the necessary skills – the results or lack of them are a foregone conclusion. In addition – if the CIO does not have a strong business alignment and poilitical clout – this makes the job of the EA – in terms of gaining a strong foothold with the business – challenging to say the least.
In these situations – VP's and CIO's try to play the EA role. Some quite like it – because it gives them a feeling of creating something – but it hinders the Enterprise Architect no end because in the end they have to do the real work without gaining the exposure and trust to do their job properly.
EA's are to blame sometimes as many professionals like the title without having the necessary exposure to be true EA's. The industry too has misused this term to mean senior tech with some leadership skills and this has caused a lot of ambiguity in terms of what a true EA does. Most professionals will take the extra money and the title without having the appetite or skills to work hard on the business aspects of the architecture. This causes significant problems and can cause the EA practice to fold within an organization as well.
So to cut a long story short – BPM and EA can work well if there is good executive sponsorship and the EA happens to be a professional who has advanced understanding of BDAT (business , data, applications and technology) with the requisite soft skills