/Tag: Collaboration

Explaining Capability Modeling to Business Process Professionals

By |2011-08-19T11:53:05+00:00August 19th, 2011|Enterprise Architecture|

As I’ve noted in prior posts, many hard working business process management professionals find the concept of “Business Capabilities” to be confusing at best, and counterproductive at worst.  In a recent article in BPTrends, Paul Harmon made the following statement:

the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.

This confusion is well known to me.  Within Microsoft, we have a very strong group of senior professionals who base their efforts and practices on BPM concepts.  This includes Kaplan and Norton’s Balanced Scorecards, as well as methods like Six Sigma, Lean manufacturing, and Total Quality Management. 

BPM is my world too.  As readers of my blog know, I am fortunate enough to consider myself to be a follower of these same ideas, having been exposed to TQM while I was working at IBM almost 20 years ago.  I’ve worked at many levels of process improvement. 

  • At the business level: I’ve worked to convey the need for process improvement and help the stakeholders feel comfortable with methods,
  • At the modeler level: I’ve worked to collect the ideas of stakeholders and map out both current state and future state,
  • At the analysis level: I’ve worked to take models and analyze them for opportunities, target waste, and develop innovative alternatives, and
  • At the technical level: I’ve implemented a number of BPM systems and even wrote one of my own. 


That experience lets me have a good relationship with both my EA peers and my BPM peers.  I’m aware of both approaches, having done both.  As my readers may also know, I use business capability models in my daily work.  I create models of capabilities that are useful, valuable, and understandable.   I know the value of capability modeling.

When I talk about business capabilities with my peers, I have to be careful.  Business capabilities are poorly explained and poorly socialized.  It can be tough to convince a BPM professional to listen to these “radical” ideas when we, the community of architects and analysts who also use business capabilities, have communicated so inconsistently about them.

First off, let’s look at the environment we work in.

Business process management practices and techniques are widely used.  In many cases, they have produces very valuable results.  However, the field is still quite young.  As in any young field, there are failures as well as successes.  I’ve seen projects succeed, and been quite proud of them.  I’ve also seen projects attempt to use BPM practices, waste time and money, and produce no real result.  The team would usually deliver something, but often that delivery occurred in spite of the process efforts, and not because of them.  Like any tool, using it well produces good results, and using it poorly… doesn’t. 

Let’s start with a problem

We all have to solve business problems.  Sometimes, you need to approach a problem one way… and sometimes a different approach is called for.  Business process modeling is a powerful tool.  Business capabilities provide an additional tool.  Sometimes you need to use them. 

Let’s look at one of those times.

Joe Freeflier is a business manager in the finance group of his large company.  The company has five divisions, each with completely different business models.  The divisions operate quite independently of one another.  They don’t share the same sales force, and they don’t really speak with the same customers.  Each division has its own plants, and its own workforce.  Joe, unfortunately, works for corporate.

You see, Joe is responsible for maintaining a set of business controls, as well as insuring that each division’s revenue recognition systems and processes are compliant and auditable.  He can see how the transactions appear on the general ledger, but he also has to make sure that some basic rules are followed in order to insure that the company is behaving in a legal and responsible manner. 

Joe has a couple of teams.  One team is focused on a large merger that the company went through in January.  His team is working with this new business to merge their financial systems with one of the existing divisions.  Another team produces important reports for the senior staff, some of which feed the quarterly corporate reporting required of publically traded companies.  A third team performs spot audits and works with the divisional finance leads to insure smooth reporting all up.  Joe’s customers are really the divisions themselves… and each of those divisions have their own business processes.

Joe needs some help.  The new merger has caused some churn.  His team is having a hard time working with the new business unit, and his manager has told him not to “govern them out of business.”  Now, Joe meets every month with Jürgen, his contact from IT, and at one of those meetings, Joe vents about his current problem.  Jürgen suggests that Joe speak with his business architect Sally, and a meeting is arranged.

Sally spends some time working with Joe to understand his concerns, and now has two choices. She can suggest either a process-centric approach or a capability centric approach.  Sally does not know if the problem can be fixed with a business process change.  She doesn’t know if the tools need to change, or the policies need to change, or the information collected needs to change, or if it is a training problem.  She just knows that Joe needs help.  Let’s walk through her thinking:

Process centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She proceeds to spend time with each of Joe’s divisional customers to map out their business processes, making sure that she is fairly accurate yet high level.  Three of the divisional teams have never mapped out their processes, but one has.  She starts there, and the process looks like a standard she is familiar with.  Unfortunately after interviewing some of the staff in that division, it is clear that they don’t actually follow that particular process.  So she falls back to a standard definition from an industry group, and spends a couple of meetings getting everyone to the same very-high-level process model.   Ten weeks have gone by, but she’s made some progress in understanding the landscape. 

Now, Sally visits the newly merged team and spends some serious time understanding what their existing process is, and how it may be different.  She finds that their business is based on a kind of “consignment” financing mechanism, and the revenue recognition processes that Joe uses have to be able to handle a number of new business events that he never dealt with before.  So she returns to speak with Joe about tracking these new events, and trying to fit the new financing mechanism into his controls.  Joe puts two of his team onto a small
project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system.  As it turns out, Joe doesn’t need to change his processes… what he needs is to change the way information is collected to adapt to new processes.  Joe creates his controls, and creates a set of IT requirements for the IT team to fulfill.  Sally is done.

Sally was successful, and her effort took about four months to do.  Along the way, she learned a great deal about the financial processes, and four divisional leaders now have a process model for their work.  Remember that three didn’t feel the need to create one before, and the fourth didn’t use their model.  Six months later, none of them refer to the process model at all, and it has become “shelfware.”

Capability centric:

Sally knows Joe’s business goals and the controls he needs to insure.  She spends a few days working intensively with Joe.  She has a capability taxonomy that she brought with her from another project.  Her first goal is to get a small list of capabilities that Joe sees as valuable.  After about three or four days, she has a list of capabilities that his team needs to perform in their duties.  These capabilities are “bits of process” that his team owns and needs to do consistently, regardless of the higher-level processes that his customers use.  They are the “standard parts” of processes that his customers have taken a dependency on him to perform well. 

Now, Sally visits the newly merged team and spends some time understanding what their overall process is.  Note: Sally is looking at their process!  She looks to see whether the new unit would benefit from Joe’s finance team and looks for ways to plug Joe in.  It becomes immediately apparent that Joe has some expectations that won’t fit their business.  The new business is based on a kind of “consignment” financing mechanism, and Joe is assuming a more traditional supplier-retailer business relationship.  So Sally comes back to Joe and asks him for details about his assumed business processes.  She works with Joe for another week, charting out a narrow slice of business processes from Joe’s point of view.  She then goes back to the new unit and maps out the same narrow space on a process model.

She presents these two process maps to Joe, who now understands the problem.  Joe puts two of his team onto a small project to craft an alternative set of controls, while the IT team begins to look at new data pathways needed in their financial system. 

Both methods got to the same result.

The capability effort got us there much faster.  Using business capabilities to identify the problem, and narrow the focus of the team, Joe was able to get his team to solve the problem within about four weeks of Sally’s arrival.  She didn’t have to meet with the divisional leaders even once, and she didn’t produce an all-up process model.  Had she stuck with the process-based approach, it would have take three times that long.  Along the way, the process approach produced an interesting model, but it was not later used by anyone. 

Note that, according to Lean manufacturing, the intentional creation of an output that is not actually used by anyone, is waste.  The use of capabilities allowed Sally to remove the wasteful act of creating a high-level process model. 

What I did not do

I did not answer the question: “what is a capability?”  It was not my goal, in this post, to answer that question.  My goal is to show my friends that a tool produced a good result.  If my friends want to use the tool, defining it is unnecessary.  If my friends don’t want to use the tool, defining it won’t matter.

Did you learn what a hammer was by having someone define it to you, or by swinging at a couple of nails? 

Was this a contrived example?

It was an example derived from experience.  That said, there are equally compelling examples where using the word “business capability” generates confusion.  If Sally had gone to the new business unit and had said “I know you look at things as end-to-end processes, but I want to introduce you to the concept of business capabilities,” then she would have failed in her job as a business architect.  Sally could no more use capabilities with the new business unit than she could have taught a teenager to drive by teaching him how to overhaul the transmission. 

Capabilities are a complexity.  Some business stakeholders live at that level of complexity already, and they WANT to work at that level.  For them, capabilities make sense.  Other business stakeholders live at the highest levels of end-to-end experiences.  For them, capabilities make no sense at all.

Finding Common Ground: in response to a BPTrends article on Process and Capability

By |2011-07-26T21:03:13+00:00July 26th, 2011|Enterprise Architecture|

Recently, Paul Harmon published an article in BPTrends that discusses his views on the notion of Business Capability, and whether it is a useful concept.  He was not particularly kind to the field of Business Architecture in his article.  While I encourage my readers to take a few minutes to read the original, I have included a few excerpts to give perspective to those with a little less time on their hands:

    • To date, I have to admit that I have no clear idea of what the term "capability" means.
    • In other words, as far as I can see, according to this definition, a "capability" is just a way of talking about being able to produce what processes produce.
    • I don’t see a real difference between WHAT an organization can do and HOW the organization will do it.
    • I might prefer to call it a Business Process Architecture, but I can certainly live with the term Business Architecture, if that’s what most people come to prefer.
    • the idea of "capabilities" is introducing confusion into the marketplace. It is hard enough to work with an organization to create a business process architecture that can be used to effectively organize the management and measurement of how well the organization is achieving its goals. To introduce the idea that an organization should first or simultaneously create a map or hierarchy of "capabilities" and then create another hierarchy of processes is to add confusion to an already very difficult and complex task.
    • If former IT architects want to become business architects, I’m all for it, but they are going to find that there are BPM practitioners who are already functioning in that role, and I believe they will be well advised to work with us rather than trying to create a new body of knowledge with a new vocabulary.
    • I believe that we ought to resist any urge to quickly redefine terms and practices that we have been using for many years.


My attention was called to this article by a reader of my blog who was interested in my response.  This is particularly apropos because, as a member of the OMG Business Architecture Working Group (or BAWG), I am one of the folks that Mr. Harmon is talking about. 

First let me say that his criticisms are fair.  As any new methodology appears, it runs the risk of creating confusion in the minds of business stakeholders.  We are not immune to that criticism.  In fact, within my own organization, BPM practitioners have been dismayed by the discussion of business capabilities and have asked many of the same questions that Mr. Harmon asks.  In our organization, we have worked to address those concerns and I believe we have been successful.  I will be sharing some of those discussions with readers in upcoming posts.  In addition, I welcome Mr. Harmon’s questions and would love to work with him, and any other member of the BPM community, to amicably answer these concerns as best I can.  I hope that the efforts of the BAWG will produce fruit by providing the consistent basis that Mr. Harmon so clearly calls for.

I don’t agree with Mr. Harmon’s conclusion: business architecture is a ‘redefinition’ of Business Process Management terms and practices.  That said, my belief is based on my own practice.  I recognize that Mr. Harmon may have been speaking with practitioners who have been using Business Architecture concepts in confusing and inconsistent ways. 

Just as business process management did not coalesce as a profession until some key voices published books that entered general business practice, I ask only that Mr. Harmon consider the possibility that Business Architects have not found a small set of clear voices just yet.  Our field is younger.  Just as the folks who believe that “functional groupings” were a reasonable way to organize a company may have found confusion in the introduction of BPM concepts 20 years ago, I believe that business and BPM professionals are finding confusion in the introduction of BA concepts today.  We are not less legitimate as the result of our youth… but we are less coherent.

His confusion is healthy, and through his expression, he provides further demand for the outputs of the BAWG and other BA thinkers who want to resolve his dilemmas and create clarity. 

I ask for patience. 

I will attempt to answer specific questions in later blog posts.  I wanted to start with this message to make it clear that I do not view Mr. Harmon, or any other business professional, as opposed to the ideas that I profess.  Rather I view his views as the necessary result of our own poor consistency, in words and practices.  I am confident that, as our profession matures and we find our voice, we will demonstrate clearly the ways in which BPM professionals and EA professionals can support each other’s efforts and build a shared model of success.

We can, we should, we must, be united in our shared goal: to improve the ability of our organizations to fulfill their missions. 

We want the same things.  We are using different tools, at different points in different processes, to achieve them.  By working together, and not apart, we will both succeed in a better way.  I seek to find that common ground.  I beg all who want the same things to help me to find it.

Business Strategy and Kindergarten Soccer

By |2011-07-13T08:38:19+00:00July 13th, 2011|Enterprise Architecture|

Back when my kids were small, they all played soccer on local youth teams. 

It is interesting to watch very young kids play soccer, because the instructions are so simple: kick the ball into the goal.  With instructions like that, what do you get?  Bumblebees, of course.  While many of the kids will wander around the field, or stand in one spot wondering when something will happen, about half of each team will be in constant motion, within about ten feet of the ball.   They hover and dive and kick wildly, with the ball hopping in one direction and then another.  From the sidelines, all you can see is a cluster of little bodies moving around, and you see the ball kicked first this way, and then that.  It’s like watching a cluster of bees gradually move up and down the soccer field.

The behavior of the players is simple.  Everyone wants to score.  No one wants to pass.  No one plays a position because that is too difficult to explain to a five year old.  Rules like “offsides” are simply ignored.  The kids get dirty and get their exercise.  That’s all the parents really want.  Most everyone is happy. 

So, why bring this up?  Because the same thing happens in some companies.  There are companies that have honed a senior layer of internally competitive business managers.  Each has tremendous ambition to rise to the next level, where prestige is accompanied by a serious bump in pay.  This happens in some law firms, ad agencies, and even some large businesses. 

Take a company with a highly competitive upper middle management layer, and toss in a business strategy.  It’s like tossing a soccer ball into a group of kindergartners.  Everyone goes for the ball.  No one steps back to take the pass, because no one trusts anyone, and no one is going to be held to their position.  There are no real referees.  Add referees and the players have to start to mature!  The parents (investors) can put in referees, but if they don’t, the game looks like Kindergarten Soccer.  Lots of energy.  Everyone gets dirty.  A few times, someone scores a goal.

It is very difficult to be an Enterprise Architect in a culture like that.  No competitive child wants to listen to someone on the sidelines shouting out instructions.  Most commonly, an Enterprise Architect can be an advisor, providing pointers to one of the players so that he or she can beat the other players.  At best, you can be a coach, but only if the team recognizes that they are a team.  Even then there is no “practice time”… only “game time.”  No easy way to get these players to practice new skills, develop trust, and take the the field as a team.

Now, you could say that a business strategy should be so detailed, and so well described, that it identifies roles that each person should play.  But in Kindergarten Soccer, it won’t work.  The kids can’t follow complex plans without their childlike enthusiasm for “kicking the ball” simply taking over. 

In some businesses, Business Strategy is Kindergarten Soccer.  The only difference: if you are advising a losing player, you can be disposed of fairly quickly.  When your kid is out of the game, you go too.  Politics trumps Performance every time. 

EA Schools of Thought

By |2011-07-01T19:05:00+00:00July 1st, 2011|Enterprise Architecture|

As an Enterprise Architect, I’m first and foremost a problem solver.  I don’t like to ignore problems.  Yet, it appears that EA as a field has a problem and I’m finding it tough to ignore it.  What is the problem?  If you judge by the 1500+messages that have flooded the Enterprise Architecture Network on LinkedIn, Enterprise Architects cannot agree. 

How did I come to that impression?  Let’s look at the measures.  Across a handful of questions over the course of the past few months, there have been literally hundreds of responses.  Judging by the responses, we seem to have, as a group. different opinions about every facet of our profession.  We appear to disagree about mission statements, value propositions, metamodels, methodology, inputs, outputs, and the necessary levels of job experience needed to perform.

Certainly the impression is reasonable, but is it a reality. 

Yes and No.

There are a handful of “schools of thought” that emerge if you read and discuss.  The number of people in each school of thought varies, but there are some clear distinctions between them.  The biggest disagreements come from folks who are using the same words, but come from these different schools of thought.  

The following list is in alphabetical order.  Note that ALL of these folks have presented themselves as Enterprise Architects.

  • Alignment Architects – these folks are focused on interpreting strategy, making it actionable, and using it to scope and define business change initiatives.  Also referred to as Business Architects.
  • Application Architects – these folks are focused on implementing successful “enterprise applications” or “enterprise systems.”  Also referred to as Enterprise IT Architects (EITA)
  • Information Architects – these folks are focused on managing information assets at the enterprise level in a consistent way
  • Process Architects – these folks are focused on improving business processes or reorienting business processes to place the customer first.
  • Strategy Architects – these folks are focused on helping business leaders create new strategies, open new markets, develop new products, etc..


Just to make things interesting, the Zachman framework (ZF) is used by a subset of “alignment” architects as well as a subset of “application” architects.  So when you are discussing ZF, you aren’t even sure which perspective they are coming from.  It is just as easy to get two “alignment architects to disagree about the value of ZF as anything else. 

If you sort out the responses into groups on the basis of these different schools of thought, there is remarkable consistency among the answers.  That’s right: consistency.  People are saying similar things… sometimes even the same things… about the value, methods, and concepts of Enterprise Architecture.

Perhaps we need to split up the field into specialties, just as physicians have specialties, with some base training and a focus on a particular branch of medicine.  After all, an oncologist makes a reasonable diagnosis when you have a cold, as would an Emergency Room doctor, but in the event of a car accident, I’d take the ER doc any day, and in the event of cancer, I’m making a beeline to the oncologist. 

If we understand enough about an enterprise, and the problems that they want to solve, we can focus on a single specialty (and/or bring in the right specialist). 

Solve these problems

With these architects

We need new products.  We need to open up to new markets.  New opportunities have arisen.  New threats are recognized.  New competitive pressures are being felt. 

Strategy Architect

We need to be more agile.  We need to organize our business to deliver to our stated mission.  We need to get our strategies to be realized more quickly.  We need to cut waste.  We need to focus on what matters.  We need to implement new regulations.  We need to respond quickly to corporate mandates.

Alignment Architect

We need to implement more scalable technical solutions.  We need to integrate and/or replace complex areas of our line-of-business applications with packaged solutions.  We need to add process flexibility into our systems.  We need to consolidate business rules.

Solution or Application Architect

We need to make our processes more efficient and effective.  We need to reduce friction between business groups.  We need to minimize the cost of a business process, and remove waste. We need to refocus our processes on customer requirements and customer experience. 

Process Architect

We need to create a single version of the truth.  We need to reduce the amount of processing needed at each step of an information-based process.  We need to reduce the difficulty in producing consistent reporting.  We need to manage large amounts of information.  We need to improve the ability of business units to communicate through consistent information.

Information Architect


Perhaps if we begin to see that these folks are EACH needed, at different times, to solve different problems, we can spend much more time agreeing with one another.

Perhaps the most valuable conversation you can have… starts with a question

By |2011-03-15T17:48:26+00:00March 15th, 2011|Enterprise Architecture|

A co-worker and I spent an hour doing something innovative… and no, it was not part of a “Google 20% strategy.”  We spent an hour discussing PKI, personal identity, and trust of both “passive content” (like documents) and “active content” (like applications) as that content originates from one actor, passes through another actor, and finds its way to a device that I own.  We spent a lot of time thinking through, and discussing, some fascinating ideas and thinking about how we use notions of “trust” and how those notions have to change as our world becomes increasingly digital, interconnected, and fragile.

The point of this post is this: that was perhaps the most fun, interesting, and thought provoking conversation I will have this week.  In many ways, it may end up being the most valuable (assuming I decide to draw value from it).  And the entire conversation started with a question, or a series of questions, that my co-worker had on information security and content assurance.

The power of a question…

I’m working on a book with a friend of mine.  He’s excellent at thinking through ideas, and bringing them to the fore.  He’s an amazing speaker and an effective strategist and leader.  A writer… not so much.  One tactic that we are pursuing right now is the notion of a conversation.  If I can send him a series of questions, can he make a recording of his answers and send them back to me, and allow me to author a chapter for him.  We are looking at that idea right now.  It may not work.  If it does work at all, it will be because of the “power of a question” led to thinking along the lines of a specific topic… thinking that can be distilled into a simple, logical, consumable form. 

How many questions do you answer every day?  If you are in the EA or IT architecture fields, as I suspect many readers of my blog are, you probably answer a sizeable number.  Architects are often employed to “find the answers.”  But let’s not be too sure of ourselves.  Perhaps the real power of the work we do is not in the answers we give, but in the questions we ask.

For each question we ask has the potential to stimulate thought, to trigger ideas, and perhaps to develop an innovative idea.  If someone asks me a question, and I ask ten people various questions as a result, and they each ask ten people, then 111 people were impacted by a single question.  As long as there is a way for innovation to work its way through that community, then we have the opportunity for one question to trigger thinking in over 100 people, potentially leading to a useful and practical innovation. 

All because of the power of a question.

The difference between selling EA and performing EA

By |2011-02-24T09:05:46+00:00February 24th, 2011|Enterprise Architecture|

Through a discussion on LinkedIn, I ran across a rather goofy blog post titled (“EA does not matter”), an obvious riff on Nick Carr’s famous HBR article.  Unfortunately, while Nick Carr is a well established business and IT contributor, the author of the blog post, Martin Palmgren, seems to have been writing articles for an astounding two weeks before levying a false attack on Enterprise Architecture. 

Masked below his obvious contempt for “things he does not understand” is a fatal flaw: he is asking for a result that EA can provide!  Mr. Palmgren is clearly of the ITIL mindset: that well defined and delivered IT services can provide a solid mechanism for both governance and alignment.  As an Enterprise Architect, I agree.  Perhaps Mr. Palmgren thinks that EA is opposed to that idea?  I don’t know.

Regardless, he shows a remarkable lack of understanding of what Enterprise Architecture is and does.  With EA fully engaged, the business would be able to see the linkage between their business goals and the IT services that Mr. Palmgren obviously desires, and therefore would be free of the need to demonstrate the ROI of infrastructure.  (ever tried to prove the ROI of good plumbing systems in a restaurant?  IT service providers have the same problem.  EA can help).

To Mr. Palmgren and the others who radically misunderstand EA, I encourage you to reach out to actual practitioners to find out what this profession is about before you launch ill-informed attacks.  It’s a good way to avoid shooting at your allies.

How (not) to convince an architect

By |2010-12-09T11:12:10+00:00December 9th, 2010|Enterprise Architecture|

I’ve been watching, with a mixture of dismay and mirth, a LinkedIn discussion between Adrian Grigoriu and a group of Enterprise Architects as he attempts to promote his new business architecture approach.  Now, to be fair, Adrian has already written and published his book, so it is a little late to take constructive criticism from his peers.  Poorly timed discussions are a dangerous thing.

One thing that is clear: the architects on LinkedIn are not convinced that his diagram is actually an architectural model.  To be fair, Adrian has dug a hole for himself by (a) insisting that his diagram is actually an architectural model, and (b) stating that it compliant with emerging standards.  The folks on the forum have rather convincingly demonstrated that both these statements are untrue.  The odd thing is: those statements don’t need to be true.  The diagram doesn’t have to be an architectural model to be a useful diagram.

Not everything that an architect produces must be an architectural model.  I think it is good when we use models because we can defend the view with data, but the imperative of an EA is to be useful first and foremost.  It is entirely possible that, in some situations, Adrian’s diagram would be “useful” without being a model.  Unfortunately, he never describes those cases, so we are left to marvel at his diagram and say “good job” without being sure that we can use it.  Personally, I don’t find it useful.  Alas.

So, what does it take to get other architects to see value in the work you do?  What mistakes did Adrian make when he started the conversation?

  • First and foremost, we all have a certain amount of self confidence in the “goodness of our stuff.”  That can lead to a little bit of self delusion, and every author is susceptible to it.  The key, in a semi-scientific community like EA, is to counterbalance that natural tendency with opinions from peers in a private and trusted conversation, before you go live to the marketplace with your final product.  Scientists discovered a long time ago: peer review matters.  Get your peers to review your work before you publish it, so that you can make statements that are credible, accurate, and compelling without getting involved in pedantic discussions.
  • Secondly, Use some of that business savvy that makes a business architect successful and consider your “idea” to be a product.  How would you market that product?  What name would you call it that would be appealing to the people who need to “buy” it?  What would they find credible, surprising, useful, compelling, and easy to share?  Perhaps if Adrian had taken a “marketing” approach to his ideas, he would not have named his framework “GODS,” presented it only from the business process perspective, or ignored the fact that he has represented two (out of dozens) of high level business models as though it were an archetype for all commercial businesses.
  • Third, when you want others to believe you, tell a compelling story about how the product came to be, what inputs you used, what experts you relied on, how it has already proven useful in three or more places, how others can use it, and why it is important for your readers to adopt it NOW.  If you cannot weave together all of the elements of a good story, your customers won’t care and you will spend all your time talking to critics who really have no motivation to support you, but plenty of reasons to oppose you.  Not a good place to be.
  • Lastly, know when you are selling and when you are collaborating.  His question to LinkedIn was phrased to invite collaboration, but that is not what he wanted to occur.  As a result, his purpose (advertising the book) is defeated, but more importantly, he is unable to collaborate with people who would love to help him, but cannot because he did not ask for help at the time when it would have been useful: before the book was out the door.

I wish Adrian good luck with his efforts, but more importantly, I hope to learn from his mistakes.

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

By |2010-07-06T21:15:25+00:00July 6th, 2010|Enterprise Architecture|

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!