Customer 2.0 Strikes

By |2011-12-28T01:52:56+00:00December 28th, 2011|Enterprise Architecture|

For those folks who don’t normally track the events of the Gamer community, I’d like to share a lesson that every consumer facing business should heed.  Social Media has changed the consumer landscape in an irrevocable way.  This incident demonstrates what happens to companies that don’t understand the new power of the customer.

In short, a small manufacturer hired a marketing company to promote it’s novel product.  Unfortunately, the marketing company failed to correctly handle the import paperwork, and the product was stuck in customs.  Customers who ordered the product for Christmas were not going to get their product in time. 

As you’d expect, some customers complained.  One in particular known only as “Dave.”  The marketing company made a couple of rather typical mistakes in handling the complaint.  The customer threatened to get the press and social media involved.  At that point, the company blew it.  Instead of taking a contrite and apologetic tone, offering to reduce the stress of the customer or even offering a discount on the order, the company representative sent a profane and inflammatory e-mail directly to the customer telling him, basically, to “get over it.”

That customer shared his e-mail with social media, and the storm started.  Within hours, the manufacturer has fired the marketing company.  The marketing company has been banned from at least one influential show (and my guess, the fallout won’t stop there).  The company’s image is in the toilet.  If they are still in business in a year, I will be amazed.

The business world has changed.  Customers have the power of community, and can act in groups in a way that they could never act before, at a speed that will make your head spin.  Companies who do not understand this fact will be left behind. 

Wikipedia and the definition of Enterprise Architecture

By |2011-12-13T14:27:15+00:00December 13th, 2011|Enterprise Architecture|

I was asked, this week, about a page that I had put into Wikipedia nearly three years ago.  Far from being able to take credit for it, I discovered that many of the edits made since I put the page up corrupted it to the point of uselessness.  Alas, after changing that page back, I checked out my favorite page: Enterprise Architecture. 

And it was unrecognizable.

The entire page had been rewritten by a single person (Matthew Kern) who, apparently, believes that “Enterprise Architecture” == FEAF (The US Government EA Framework).  While I applaud Mr. Kern’s desire to include cited sources for his statements, his decision to ignore all of the prior content and contributions and toss out all of the compromises along the way seems both short-sighted and arrogant, to say the least. 

I endeavor to let the current author settle a bit, and then change most of the article back, but for the sake of documentation, I wanted to share the direction that Mr. Kern wants to take the Wikipedia article on EA.  Gentle readers, do you agree with Mr. Kern’s decision, or do you support my intent to revert to the original material?

Previous Opening Section (compromise text) New Opening section
An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them.

EA describes the terminology, the composition of enterprise components, and their relationships with the external environment, and the guiding principles for the requirement (analysis), design, and evolution of an enterprise.

This description is comprehensive, including enterprise goals, business process, roles, organizational structures, organizational behaviors, business information, software applications and computer systems.

Enterprise architecture (EA) is a term first used in print in NIST SP 500-167 a US Federal Government Document from the National Institute of Standards and Technology) in 1989. It is currently a mandatory practice in the US Federal Government: OMB Circular A-130 describes enterprise architecture and subordinate activities in some detail, in response to the Clinger Cohen Act (IT Management Reform Act) of 1996 mandatory requirement for government organizations (enterprises) to have an "IT architecture". The term has subsequently (after first use in 1989 by the US Federal Government) been used in foreign governments and in commercial practice.

According to the U.S. Federal Government: "An EA is the explicit description and documentation of the current and desired relationships among business and management processes and information technology. It describes the "current architecture" and "target architecture" to include the rules and standards and systems life cycle information to optimize and maintain the environment which the agency wishes to create and maintain by managing its IT portfolio. The EA must also provide a strategy that will enable the agency to support its current state and also act as the roadmap for transition to its target environment. These transition processes will include an agency’s capital planning and investment control processes, agency EA planning processes, and agency systems life cycle methodologies. The EA will define principles and goals and set direction on such issues as the promotion of interoperability, open systems, public access, compliance with GPEA, end user satisfaction, and IT security. The agency must support the EA with a complete inventory of agency information resources, including personnel, equipment, and funds devoted to information resources management and information technology, at an appropriate level of detail."


What say you?

Using Enterprise Architecture To Get The CIO To The Strategy Table

By |2011-11-21T12:33:10+00:00November 21st, 2011|Enterprise Architecture|

Recently, Patrick Gray blogged on TechRepublic that IT has a Chicken and Egg problem.  In his post, he describes two mechanisms that CIOs take to become recognized as strategic leaders: a) work in anonymity to demonstrate that the work that they are doing is aligned, hoping someone will notice, and b) wait for the business to take on the responsibility for ensuring that IT’s efforts are aligned.  He charts out a course that involves a) get the utility aspect perfect, quietly, b) speaking the language of business value, and c) pitch the strategic expertise of IT. 

Reasonable advice in some ways but, as always, the devil is in the details.

  1. Getting the utility aspect perfect is NOT a prerequisite.  Having IT to the point where it works reasonably well is sufficient.  Executive peers should not be distracted by bad service, but perfect service is an unattainable goal.  All services have tradeoffs, especially with respect to “time to market” and “cost.”  There is no one else at the executive table that has a perfect operational aspect.  Marketing sometimes runs an ineffective campaign.  Sales sometimes misses their targets.  Operations is not perfectly efficient and effective.  Customer support sometimes angers a customer or two (or ten).  Perfection is not necessary.
  2. Speaking the language of the business can be tough when “the business” does not speak the language of business.  Read that twice.  The “Language of business” is not just dollars and cents.  It is often influence, power, and politics.  This requires an understanding of not only the language of “value” but also the language of “power.”

    How many times has a “business client” of IT asked for a project without any rational reason for believing that the project is actually a good expenditure of money?  How many times has a good, valuable project been cancelled or poorly funded while a pet project moved ahead.  The language of “value” is necessary, but not sufficient, to get business peers to include you in critical conversations.  They have to believe that they need your resources, your input, and your power to deliver.  For the CIO to exercise power, he or she must first have it, and then must demonstrate it.  I’ve seen many who either did not, or could not, do that. 

  3. The strategic expertise of IT is interesting, but where exactly is IT exercising that muscle?  Why would IT have any strategic expertise at all, unless it is carefully developed and encouraged.  And what exactly would a strategic capability within IT look like?


Enterprise Architecture is a business function that allows the business to do a very important thing.  EA is based on the simple rule: “Do what you say you will do.”  Many a business executive will declare that they can’t actually get the business to do what they want it to do.  EA is part of the solution to that problem.  It is a necessary business function.  The leader who owns this function has an “ace” to play.  And if that leader is the CIO, then the CIO has a useful capability. 

Patrick Gray is right… you must not “live” with the hand you are dealt.  You must build a better hand.  Enterprise Architecture is one card that the CIO can build into his or her hand, and then play to great effect.

The End of Flash

By |2011-11-09T12:37:58+00:00November 9th, 2011|Enterprise Architecture|

The writing is on the wall.  Adobe has abandoned Mobile Flash in favor of HTML5.  It is just a matter of time before the Adobe Flash developers switch over to producing HTML5 instead of Flash as a matter of course.  With the move to mobile devices, the dominance of Flash on the desktop will simply not matter anymore. 

I’ve been in this profession for 31 years.  I’ve seen a long list of technologies rise up to be one of the “top technologies” in a space, only to be relegated within a few years to the dust heap.  There is always a tipping point.  Apple pushed, and now, Adobe tipped. 

It is time to add Flash to the list.

To create a roadmap, we need to know what it is supposed to accomplish

By |2011-11-04T15:16:22+00:00November 4th, 2011|Enterprise Architecture|

I’ve been involved in a number of meetings recently as our IT teams try to come to consensus on answering this question: What is a Roadmap?  It’s been a fascinating series of discussions.  One thing that strikes me is that most of the internal discussions, and many of the discussions I’ve seen online, are only seeing part of the business process where a roadmap is used. 

If we don’t see all the process interactions, we can’t get the requirements right.  And if we don’t get the requirements right, the solution (the design of the roadmap) will not be as useful as it could be.

[Terminology Note: I don’t have any great love of the word “roadmap” to refer to the EA artifact.  I like “action plan” as a term, but I have no strong preference.  In keeping with prior posts on the subject, I’ll keep using the word “roadmap” unless and until we can get some consensus on an alternative word.]

Picking the correct approach

There are two different business processes where a roadmap is useful: deciding on the order of efforts, and tracking the efforts against that decided order.  IT folks tend to focus on the second.  I will focus on the first.


When we look at the notion of strategic planning from an EA perspective, we are trying to reduce unnecessary effort.  Just as a downhill skier in the Olympic games will surely lose if they are off course by a few degrees, adding a few extra meters to the length of their run, commercial enterprises are not asking for “any path down the hill” to win the race.  They are asking for “the best possible path down the hill.”  (If your company is run by a salesman, they may shout the words “win the race.” 🙂

The business has created their strategy and we have assisted with creating the measurable scorecard to track our progress towards achieving it.  That is step one (most Enterprise Architects have NO idea that this is part of their job).

The first process that uses Roadmaps starts here (colored in brown above).  Enterprise Architecture collect information to produce a series of alternative approaches (“candidate roadmaps” in the diagram above).  The input information includes other roadmaps, as well as business rules, political needs, dependencies, parallel initiatives, resource constraints, technology standards, fiscal constraints, regulatory constraints, and business drivers.  Each approach allows the business to deliver on that strategy in a way that is feasible, fiscal, and forward looking.  We allow ideas that may require us to change big things (merge, split, and repurpose teams, systems, processes, assets, etc.). 

Why have many candidates?  Because there is nearly always more than one path.  Each path will have tradeoffs.  One may be quicker to see results, another less expensive, and another less disruptive to existing product plans.  We need the business to pick the path that they want to follow.  Moreover, we want them to debate the tradeoffs in front of their peers, and come to a resolution about which path they will collectively select.  Because the only thing worse than having no roadmaps is having many competing roadmaps.  It is tempting to come to the business with only one roadmap. “Here’s your solution, sir.” On occasion, that works. Depends on the organizational politics. Personally, I think that is not a good recipe for buy-in. Your mileage may vary.

At the end of this two-step process, we walk out of the room with something powerful: buy-in.  We come away with a clear decision: beyond “get this done,” we now have “go do these projects, in this order, to get it done.” 

The candidate roadmaps fuel the debate.  It is the tinder to which we strike a match.  Each one explains all of the information that a stakeholder needs to debate the pros and cons, and the collection of information is sufficient to allow business leaders to pick one with their eyes open to the tradeoffs. 

Delivering on the approach selected

In the second part of the process (in purple above), we bring up the roadmap on a regular basis as we review, with our business stakeholders, the status of our projects and whether there are dependencies that may be driving our decisions.  In other words, if two projects are on time and a third project is late, but the fourth project cannot kick off….  You get the picture.

This is a kind of decision-rich governance activity.  The “roadmap” in this context is used for expectation management.  While this is a very valuable activity, you do NOT need all the same data for this activity as you do for the previous one.   Whether you need one diagram or two will depend on your business and how it handles project governance.


I went to such trouble to explain the distinction between these two parts of the process because the first part (using a roadmap as a high-level decision making tool) is often misunderstood by EA stakeholders who only view EA from an IT context.  As such, much of the debate on “what belongs in a roadmap” is centered around delivery needs and not enough on the decision needs described above. 

To build a better roadmap, it helps to know where it will be used.

Governance in an Organic Enterprise

By |2011-09-28T04:32:12+00:00September 28th, 2011|Enterprise Architecture|

I spent a few minutes this evening reading through Tom Graves’ fascinating post Management as ‘just another service’ and it got me thinking of Governance in the organic enterprise.

As Tom describes, there are two paradigms of management at play: organization as machine, and organization as living organism.  Tom is of the opinion that most organizations think that they are of the first type, while they actually behave like the second type.  While I cannot quantify his assertion, I have noticed that my own organization behaves more like an “organization as living organism.”

So, this evening, as I contemplate the notion of enterprise governance, I consider the reality of improving governance in an organization that behaves more as an organism than as a structured automaton.  In order to share my thoughts, I want to establish some basic terms to make sure we are all on the same page.

First off: Governance is a system of distributing decision rights to specific individuals or groups so that (a) desirable behavior is encouraged, (b) undesirable behavior is discouraged, and (c) business rules are aligned with enterprise principles and legislative constraints.  Governance can be a simple as having the project sponsor review the project plan, and as complicated as having the United States Supreme Court review the specific clauses of President Obama’s healthcare reform law, before the administration compels the various states to implement it.

There are many things that can be governed:  the scope of projects, the expected architectural outcomes, the assignment and activity of individuals, the assignment of responsibilities to teams and systems, the correct handling and security of information, and the measurable performance of processes, to name a few. 

In addition, there are many different levels at which governance occurs.  Governance can occur at the personal level (I choose to do the right thing).  It can also occur at any “level” where a group of people with specific decision rights have a stake in the governable elements of an activity.  To whit:

  • A team may want to govern the efforts of its members. 
  • A business sponsor may want to govern the activities of a project team that is spending his or her money. 
  • A cross-business virtual team (v-team) may want to insure that dependencies between teams are carefully managed in order to insure the delivery of value. 
  • A senior business executive may want to govern the level of acceptable risk in a portfolio of projects to insure that there is a good balance between innovation and incremental improvement. 
  • A senior leadership team may want to insure that leaders have clear ownership and accountability (no gaps or overlaps) so that strategic changes can be implemented in cross-functional processes.

This may lead you to conclude that governance can be performed as part of a hierarchical escalation process, but that is not a foregone conclusion, as you will see below.

When designing a system of governance in an organic enterprise, we need to make sure that the “solution” matches both the “problem” and the organizational “network of influence” (instead of hierarchy) that the enterprise uses to make decisions and resolve disputes. 

So let’s break down the problem a little.  What is the array of problems that organizational governance (of which IT governance is a subset) is supposed to solve?  Here are some elements of that array:

  • Senior leaders are consulted when the cost of day to day operations overwhelms the organization’s ability to behave strategically
  • Business Managers are consulted when investments by one business manager can interfere with the efforts of another
  • Process owners are consulted as a process is being changed, leveraging organizational knowledge and experience
  • Information facet owners are consulted as requirements emerge that impact master data management and data quality
  • Platform owners are consulted for the improvement of business capabilities supported by enterprise platforms
  • Architectural owners are consulted as system designs are considered for inclusion in the enterprise IT ecosystem
  • Organizational standards are followed in order to minimize the cost of ownership of process, system, information, and infrastructure investments


The key thing to note from this list is that different “governors” are interested in governing different things.  There is no simple “chain” of escalation.  Rather, it is a network.  This is one effect of organic governance.  Another is that the number of levels of governance, for any one issue, should be fairly short.  You deal with things at an individual level, at a project level, and then, fairly quickly, at the level of a “governance body” designed specifically to resolve that particular type of issue for a business and then the enterprise.  Lastly, there is a senior management body that can settle all remaining disputes. 

Unfortunately, when considering this kind of problem, the metaphor of “enterprise as organism” begins to fail.  Actors in an enterprise do not behave like cells in an organism, nor do business units within an enterprise behave like organs.  Cells are regulated by internal instructions, hard-coded in chemical DNA sequences, and respond to fairly simple stimuli with pre-programmed responses.  Actors and business units do not. 

Organizations do not have consistent and uniform instructions (like DNA) that guide each person and business unit.  Governance is needed because of the variation of human beings and their desire to continuously look after their own interests.  Quickly we can see that the “organism” metaphor is shaky at best.  In small units, the metaphor of a sports team is a better metaphor, and at the larger end, the metaphor of a city is more appropriate.

I work in a fairly large company, so the metaphor of a city is better for me to consider.  After all, I’ve lived in cities all my life.  So in a city, how many times have I behaved in a beneficial way?  I’d like to believe that I do that every single day, in a hundred small ways.  How many times have I interacted with the police?  Less than the fingers on one hand.  Well… that’s interesting.  That simple observation alone makes one thing starkly clear: the police do not govern my city life.

I believe that the most important governance element of city life is the system of property laws, commercial practices, licensing laws, and simple rules of civil behavior that allow the city to be a productive and useful environment for individual people.  Governance itself is a tiny fraction of the overall efforts of the population of a city, and it is normal to live your life for years without involving a police officer, filing a law suit, or walking into a court.  That said, courts and lawyers and legislative bodies are essential overhead.  From an economic standpoint, governance is overhead and waste.  People who govern contribute nothing.  But from a social standpoint, the system of governance is critical to the success of the “organically” managed city. 

Which leads me to a rather startling conclusion: In order for a large organization (of say 100,000 employees) to successfully becoming a mega organization (of say 1,000,000 employees), they must develop a simple and fair system of property laws, commercial practices, licensing laws, and rules of civil behavior, and a simple adjudication system to address conflicts.  Hierarchy do
es not work as a model of governance in an organic enterprise.

When IT Architects Describe EA to other IT Architects

By |2011-09-02T09:53:24+00:00September 2nd, 2011|Enterprise Architecture|

Sometimes, I have a hard time being upbeat about the emergence of EA as a profession.  This felling is especially acute when I come across a slick, well-prepared guide to Enterprise Architecture, written by an IT Architect, that is incomplete, inaccurate and/or misleading.  That happened to me today.

The guide is written by Wolfgang Keller and was published in its final form in November of 2009.  His guide is titled “TOGAF 9 Quick Start Guide for Enterprise Architects.”  The document can be found here

Most Enterprise Architects have their roots in IT organizations, and there is a great deal of interest in both the role of EA and the TOGAF framework’s stated goal of becoming a framework useful for Enterprise Architecture.  That said, most practicing Enterprise Architects have some level of difficulty applying the TOGAF to their work, largely because it is a guide to producing Enterprise IT Architecture (EITA) artifacts, and not EA artifacts.  One such architect, Adrian Grigoriu, writes about his experience applying TOGAF to EA in his blog (link). 

EITA is to EA what a Biologist is to a Physician… a respected colleague with a similar area of concern, but totally different role.  Since TOGAF is a framework for EITA, it can be tough to expect an EA to use it.  Now, I know that the Open Group is making progress, and I have acknowledged that progress in past posts.  But let’s face it: TOGAF is about 20% there.  It is not wrong… just wildly incomplete.  Learning TOGAF to do EA is like learning to fly a business jet in order to take on combat missions in an F16.  The skills you’d gain are somewhat useful, but not even close to being sufficient.

So when I opened up Keller’s guide, I expected to see some tables showing typical scenarios for an Enterprise Architect, the ways in which a framework can support EA, and an indication of the gaps that TOGAF still has in providing that support.   That is not what I found, and I’m not happy with what I saw.

  1. First: it was not written by an EA or even listing EAs as contributors. There is no indication whatsoever that the author actually has ever worked as an EA. It would be like a nurse writing a guide to the Physicians Desk Reference.  Worse, “experienced” Enterprise Architects are supposed to use this.  What does it say about the student if he chooses a fool as his teacher? 
  2. Second: The author describes Enterprise IT Architecture, not Enterprise Architecture. He doesn’t know, nor has he taken the time to find out, what an Enterprise Architect actually does. It is one thing to be speaking outside one’s area. It is another to describe the role in completely inaccurate terms.
  3. Third: The author, while attempting to describe the much more limited role of EITA, gets that wrong as well. The author has placed the role of EITA in an untenable and ineffective position with no authority (or even role) in program portfolio prioritization and funding. If that were my job as an EITA, I’d quit.  I have seen EITA’s struggle and fail, time and time again, in this role.  This makes the guide not only a bad way to access TOGAF, but also provides some elements of seriously bad advice for any IT architect.
  4. Fourth: His document misrepresents itself.  Only about one third of it is a guide to using TOGAF.  There are two other parts.  One is a description of software architecture (including a history lesson), and the final third is a supplement that attempts to fill in some perceived gaps in TOGAF. He attempts to address two specific gaps: Formulation of IT Strategy, and IT Portfolio Management. He makes an attempt in both cases, and I will credit him for the effort.  The output is average.  Were TOGAF to include his supplement sections, it would be helpful to a small number of EITA’s, but not any EA’s that I know.   

There are two use cases for reading the document, outlined by the author: (a) An Experience EA wanting to understand TOGAF, and (b) A Student wanting to learn EA and TOGAF.  For both cases, the guide fails to be practical and, in many ways, is actually harmful.  I cannot recommend this document for either case.

Of course, that means that there is still an opportunity for an actual Enterprise Architect to do what Adrian tries to do, and provide insight into how TOGAF can be used to in the practice of Enterprise Architecture. 

If you know of one… please let me know.  If you develop one, I’ll be happy to review it.  (If you’d like my feedback to be private, let me know before you publish it and I will do what I can to provide feedback in a timely fashion.  Once it is published, my feedback on the published version will be public as well.) 

Technorati Tags:

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.

Enterprise Business Motivation Model version 3.5

By |2011-07-27T00:26:07+00:00July 27th, 2011|Enterprise Architecture|

For those of you who have been waiting for me to announce the release of the newest version of the Enterprise Business Motivation Model, I’m happy to announce that version 3.5 is available now. 

To visit a WordPress site set up to explain the model, visit http://motivationmodel.com

To visit a web site produced by the Sparx modeling tool, allowing direct navigation of the model itself, visit http://motivationmodel.com/ebmm

To download a PDF document exported by the modeling tool (for those folks who love PDF files), visit this link here

Special Thanks

The Enterprise Business Motivation Model has gone through a long list of changes since the original article was published over two years ago.  I’ve spent considerable time working through the model and getting feedback from colleagues from around the world. 

I’d like to give special thanks to Michael Davison, JD Beckingham, Neil McWhorter, Bruce McNaughton, Henk Harms, Bill Ulrich, Jim Rhyne, Kirk Rheinlander, Leo de Sousa, Yelena Edelstein, Al Newman, Amy Nguyen, David Vugteveen, and many others who have commented, criticized, and asked for clarifications.  Without your concerns and your insight, the EBMM would not move forward.  Thank you!

Changes to look for

There are many changes since the last public version (v1). 

  • The business model description was updated to reflect connections between customer types and partner types, and to more completely cover the model elements of Alexander Osterwalder’s Business Model Generation. (model, description)
  • Porter’s Five Forces was added as a separate area clarifying the linkage between a Five-Forces analysis and business models themselves.
  • The dual notion of Business Capability and Business Unit Capability proved too confusing and arbitrary for a core conceptual model.  The single concept of Business capability remains.
  • The concept of Data object is now elevated to a top-level element in the model with necessary changes to the high level view. 
  • Business role was added with relationships to business processes and data objects.
  • The concepts of Regulations, Legislative Edicts and Charter Legislation were added to clarify the role of these key concepts to Government and Semi-private organizations.
  • The concept of “capability maturity” was expanded to “assessment metric” to allow a broader understanding of how measures can be applied to business capabilities in order to motivate and measure the success of initiatives.
  • Clear distinctions are made between an enterprise, a company, and a business. 
  • An additional relation has been added to business unit: relates to.  This allows models of the enterprise to include interrelationships between business units other than the normal hierarchical relationships that the existing “includes” relation allows.  This should enable a wider array of analysis models to be created for those architects who need to model a subset of the enterprise.
  • A page was created on the WordPress site to discuss the difference between a Process and a Capability.  (link)


Of course, we are not done.  I am publishing version 3.5 in order to insure that my conversations with other Business Architects has a current footing.  The following concerns have been shared and are under consideration for future versions:

  1. Add the ability to attach a Value Chain Analysis
  2. Add the ability to represent the accountabilities of a team in relation to the business processes themselves
  3. <<your suggestion here>>


As always, I welcome feedback and input.  I’m proud of where the EBMM has come so far and look forward to working with exceptional people to discuss and describe future changes to the model. 

Note: I didn’t keep a careful list of the folks who offered valuable feedback on the model.  If you offered feedback, and I didn’t mention you above, please accept my apologies and send me a note.  I’ll update this post.

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.