/Enterprise Architecture

Inside Architecture blog

How to screw up a visual metaphor

By |2019-11-02T21:05:27+00:00November 2nd, 2019|Enterprise Architecture|

Maybe I’m a little sensitive to bad visual story metaphors.  I’ve certainly seen more than a few… but this one was professionally published and promoted.  We can learn from what the storyteller did wrong.

As many of you know, I worked with Martin Sykes and Mark West to co-author a book on visual storytelling.  It’s beautifully constructed, thanks to Mark, and provides a framework that Martin and I created called CAST that helps individual folks create their own compelling and interesting stories. It’s also given me a somewhat visceral reaction to visual stories done well, and stories done poorly.


Beware of Digital Officers who only know Marketing

By |2019-07-29T17:55:51+00:00July 29th, 2019|Enterprise Architecture|

This is a dangerous blog post. I’m a consultant and sometimes I come across a potential client who may recognize themselves here.

However, I hope this message guides good outcomes. It is a necessary yet sometimes painful message.

Digital Transformation is not just a marketing initiative

Dangerous words.

In many companies, the digital transformation project is led by a Digital Officer whose prior life was solely marketing. In those situations, it is often the case that the measures of transformation success are all about “customer loyalty” or a similar one-sided perspective.

I understand alignment. I understand it well. I’m a certified Balanced Scorecard Practitioner. I’ve created capability maps and Benefit Dependency Networks and Scorecards and Ishikawa diagrams for a dozen companies.

The places where digital transformation is LEAST successful are places where the measures of success boil down to a single customer measure.

That’s because digital transformation is about the customer, the product, and the company. Not just one. All three.

Data can be used to create new products and improve existing ones.

Process improvements can reduce the cost of goods as well as overhead in many ways, including technical automation and agile practices.

User Experience can change the relationship between the customer, the company, the (existing) product, and even upstream suppliers.

But your scorecard measure should reflect the balance of every aspect, not just customer attach (or loyalty, or satisfaction).

It’s not just marketing that is being transformed. It’s not just experience. It’s the whole show.

Or it’s not really transformation.

Confusion between capabilities and system features

By |2018-12-11T20:06:34+00:00December 11th, 2018|Enterprise Architecture|

Sometimes, when a buzzword catches on, the meaning of that word gets lost.  Too many people use the word in too many ways, and after a while, when you hear the word, you really don’t know what it means.  This has happened to the word “capabilities” in EA practice.

I live in the trenches.  I work with Enterprise Architects from multiple different companies on a regular basis.  One thing I’ve noticed is that there really is no single definition for the word “capability.”

  • Do people have capabilities?  If I can write great Java code, do I have a Java coding capability (or, up a level, Object Oriented programming capability)?
  • Do technologies have capabilities?  If I have an identity provider like OKTA or Active Directory, does this technology have the “manage geo-distributed user identity record” capability?
  • Do computing systems have capabilities?  If I have a CRM platform, does it have the “track sales opportunities” capability?
  • Do enterprises have capabilities?  Does the company I work for have the capability to “offer product via online marketplace?”

I hope this helps illustrate the problem.  If I want to have a discussion with my business stakeholders about how to know if their enterprise architecture is fit for purpose, I want to have a method for describing how I would illustrate the gaps or deficiencies in the organization’s architecture.  I want the word “capability” to mean something.

In the EBMM, I suggested different terms for these concepts, so that the term Capability has one meaning.

  • People have skills.  Job positions require skills.
  • Technologies and Systems have features.
  • Enterprises have Capabilities.

So let’s say someone comes to you and shows you a list of things.  At the top of the list is the word “capabilities.”  How can you tell which one of the items are actually a capability?

Not always simple.  Making this differentiation is more art than science.

My rule of thumb is this: can I describe the people (organizational needs), process (workflow needs), tools (feature needs), and information (data needs) that would be driven by that capability?  If I cannot, I probably don’t have a capability.


Using Enterprise Architecture for Digital Transformation

By |2018-09-25T20:03:31+00:00September 25th, 2018|Enterprise Architecture|

It should be clear by now, if it wasn’t before, that the message of “digital transformation” has been accepted by organizations large and small.  While there are many definitions of digital transformation, and therefore many different ideas of the ‘scope of effort’ involved, there’s one thing that’s clear: effective Digital Transformation requires a strong and stable Enterprise Architecture capability.

In many organizations, the EA team is not ready.  In others, the EA team is ready, but is not well placed.  These are different problems.  And they require different solutions.

This article will help you to see whether you have an EA team that is incapable, or an EA team that is not correctly placed.  Once you know the problem, it is far easier to solve it.

Ready, Aim, Fire

We like to joke about companies that will should “Ready, fire, aim” in their projects.  It’s kind of a running gag, especially in IT where “change projects” occur all the time.  So many people will try to solve a problem before correctly diagnosing it that we are often resigned, especially as architects, to cleaning up the mess.  However, this is one mess that directly hits Enterprise Architecture.

Here’s a diagnostic to help you to determine if the EA team is both ready and placed, on a two dimensional grid.  For each question, select an answer.  The scoring rubric is at the end.

Note: The term Chief Enterprise Architect is a title I’m using in the following diagnostic.  It refers to the “person to whom all other Enterprise Architects report”.  This title is also sometimes called “Director of EA” or “Director of Strategy and Architecture.”


  1. How many levels below the CEO does the Chief Enterprise Architect report:  A. 1-3 levels. B. 4-5 levels C. 6 or more levels.  D. We don’t have a Chief Enterprise Architect.
  2. Among your Enterprise Architecture staff, how many have direct relationships with key business leaders around the enterprise?  (count the number of architects with more than five direct relationships each). A. >50% of the EA team have 5+ relationships.  B. 15-50% of the EA team have 5+ relationships  C. 30%+ have two or more relationships. D. <30% have two or more relationships 
  3. For the teams that report to the Senior Executive staff, how may of those teams know their named Enterprise Architect?  A. 50%+ of those leaders know who their EA is.  B. 20-50% of those leaders know who their EA is. C. 0-20% of those leaders know who their EA is.  D. No one outside of IT has any EA assigned to them.
  4. In your organization, how does the EA get invited into conversations with key business leaders?  A. The business leaders intentionally include their EA in frequent periodic reviews.  B. The business leaders invite IT leaders who frequently bring Enterprise Architects along. C. IT business leaders frequently update Enterprise Architects on their respective business areas.  D. Enterprise architects set up meetings and get on calendars with IT leaders to discuss status.


  1. How many strategic business initiatives at the company have an Enterprise Architect directly assigned and accountable? A. over 60%, B. 30-60%, C. Less than 30%. D. We do not make EA’s accountable on major initiatives.
  2. What is the average number of years of architecture (not engineering, project management, testing, or analysis) experience for the people holding the title of Enterprise Architect at your organization?  A. 8+ years of architecture on average. B. 5-8 years of architecture on average. C. 1-5 years of architecture, on average.  D. Less than one year on average.
  3. Among your Enterprise Architecture staff, how many have direct demonstrable experience with the “capabilities alignment” story (e.g. can drive the process by which a capability map can be used to build a strategically aligned roadmap)? A. 80%+ of the EA team, B. 50-80% of the EA team, C. 20-50% of the EA team, D. Less than 20%
  4. In your enterprise, what percentage of the “hot” (strategic with gaps) capability areas have current members of your EA team evaluated or contributed to in the past year? A. 30%+ of hot capabilities  B. 15%-30% of hot capabilities  C. 0-15% of the hot capabilities  D. No clear idea of what the hot capabilities are


  • A = 6 points
  • B = 3 points
  • C = 1 point
  • D = 0 points

Create separate scores for Placement and Readiness.

To be both “well placed” and “ready”, you need at least nine points for each measure.

For example: I could say Contoso EA scored 10 points for Readiness but only six points for Placement.  In that case, I’d say that the EA team is ready but not well placed.

So what do you do if you don’t get the score you want?  Go back to the diagnostic.  Which one of the items can you improve upon?  Pick key areas and improve them.  Then come back and measure again.

Once you are both ready and placed, you have a good business case for being directly engaged in a Digital Transformation effort.


Design Thinking in Business Capability Modeling

By |2018-04-13T18:57:57+00:00April 13th, 2018|Enterprise Architecture|

One of the most interesting and difficult challenges of Business Architecture is creating the capability model for an enterprise. In this article, I’ll explore how to use the practices of Design Thinking to support the difficult and sometimes contentious process of creating a business capability model for an enterprise. First, let’s understand the problem a little.

For an enterprise that doesn’t have a capability model, developing the first one can be tough. Fortunately, the efforts of the Business Architecture Guild have started to produce value in the form of Reference Models. Even with a reference model, the challenges can be substantial. That is because a capability model is not a foregone conclusion. There are many ways to frame the capabilities of an organization in a capability taxonomy and that framing is important. Framing the capabilities in a particular way can drive conversations (both good and bad). For example, if we describe different capability groups for Marketing, Sales, and Customer Services, in which group do we put “Customer Record Management”? Getting this right may be important in getting key executives to step up to their responsibilities in the organization.

A capability model is supposed to be independent of the politics and processes and structure of an organization, but to be honest, the most effective capability models reflect the needs, ownership, and strategy of the organization in subtle ways. I’ve seen capability models with dependency connections, with ownership groupings, and with budgetary groupings, all as “overlays” that are both useful to the planning efforts, and which influence the capability model itself. It’s a complex problem but one that we can solve with Design Thinking.

Design Thinking is an interesting technique that can be used to approach complex problems. Design thinking makes some basic assumptions: (a) We start without actually knowing what the destination is, (b) we center our solutions around deep empathy for the customer, and (c) we create a new design, a new thing, or a new way of interacting with something through rapid prototyping and iteration. Design Thinking can be used to design a bicycle, a space ship, a house, a business process, a software package, a vacation, and yes, a Business Capability Model.

In many ways, the techniques of design thinking are well suited for the task of generating a capability model. In most of the situations I’ve been aware of, stakeholders for a capability model have never seen one before and have no idea how to use one. It’s tough to assist in designing something that you’ve never used before. Consider: if you had never taken an airplane trip and someone asks you to design the perfect passenger cabin for an airplane… how well would you do? Design thinking does not assume that you have experience with the solution before you start. As a result, you can be comfortable that your “novice-developed airplane cabin” will at least be a reasonable one, even before you take your first flight.

With design thinking, there are five phases: Empathy, Problem Definition, Ideation, Prototype, and Test (with the last two in a quickly spinning cycle). So let’s apply these five stages to Capability Model Development.


Empathize — The foremost value of the empathize stage is to put the customer at the center of your work, and remove yourself from it. Your preconceived notions of the “right way” to build something, or “what something should look like according to Expert X” just gets in the way. Your customer will describe their “conceptual space” in their own way, and different people will do it differently. To truly empathize, you have to make sure you are representing the right stakeholders, and that you are actually listening to their issues and concerns.

One thing that I find, often, is that most people have “typical” problems. If someone has typical problems, their concerns will be well understood. But there are always outliers — people who seem to always have unusual problems. These folks can provide greater insight when you are building your understanding of the problem space, because their problems challenge the status quo. They don’t fit neatly into the box. Look for these people. Listen to them.

Empathy in capability modeling means, in my experience, to listen to how a team describes themselves and to capture it their way. Do they discuss processes and procedures? Do they discuss assets? Locations? Events? Information? Documents? Workflows? Your capability model will need to reflect a wide array of stakeholders, so as you move between those stakeholders, don’t begin by forcing them into your box. Step into theirs.

Sketch (literally, with pencil) a simple non-structured diagram that represents their way of thinking of their space. Yes, eventually you will build a capability model, but don’t start with the strict definition of capabilities. Empathize with where your customers actually live, and what they actually live with.

I wouldn’t expect it to be any more “sensible” than something like the following diagram.


Problem Definition — How many times, when we get to the end of our efforts, do we look back and say “We should have asked better questions?” Design Thinking puts this problem right up front. We believe we understand the stakeholders through our empathy, but before we put the capability model onto paper and start hashing it out, let’s be clear about what problem we are trying to solve.

Capability models, in my experience, are excellent tools for planning. We can manage a portfolio and plan for changes. We can observe processes and plan for improvements. We can evaluate readiness and plan for training. We can find overlaps in application functionality and plan for consolidation. It’s planning. But not every organization plans the same way, and few organizations have a mature planning process. So as you build your capability model, think about who will own specific capabilities, how those owners will use their parts of the model to develop those plans, and how those plans will roll together. Think about the inputs to planning: trends, strategies, changes in the ecosystem, changes in the competition, problems with existing systems, and technical debt.

Your result needs to be a question that frames the problem you are trying to solve. As you pose this question to your stakeholders, their reaction will tell you if your question was effective. Don’t be afraid to drop your attachment to specific terms or processes or methods. Let things flow a little. Phrase the question in terms of the customer’s needs. One good technique is to use the phrase “How can we …” in your problem statement.

“How can we frame all the abilities needed by our business model so that we can best plan and coordinate our forward march?”

Please don’t use my example as anything more than an example. The problem statement you create should “feel” like it evolves out of the language, terminology, and culture of the organization itself.

Ideation — A capability model created by a business architect and thrust upon the organization will be dead on arrival. That is not a prediction. That is a foregone conclusion. How do I know? I’ve done it. School of hard knocks. Let the stakeholders build their capability model a series of collaborative sessions. Ideation is the first step in that process.

The ideation step can use any of a number of techniques to open the stakeholders up to different ways to frame the capability model. At this stage, you are creating capabilities, so we are applying the first series of constraints on the process. There are a dozen different ways to frame ideas that do NOT end up with a capability model, but for the sake of this exercise, we will write them down and not pursue them. We need our end result to be constrained to capabilities. Other stuff will fall out.

If the company has a process model that they actively use, you can start there.  If they don’t have one (or don’t actually use the one they have), consider using one of the capability reference models from the Business Architecture Guild (businessarchitectureguild.org) as a starting point. This is far quicker than starting from scratch. However, it is only a source of ideas. Let the team reword, rename, join, split, and shred the starting “thing” any way they want.

To keep ideation from becoming a long involved process, I suggest a series of simple exercises to expand the number of possibilities, and then consolidate that list to the most feasible ones. Then expand again, and consolidate again. Each iteration, considering a different aspect of your thinking or understanding.

An excellent technique is the SCAMPER method, which pushes participants through seven different ways of thinking about the “starting” product to create a new “ending” product. Those seven ways of thinking are: Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse. There are a number of online resources available if you want to go deeper on using SCAMPER. Other methods may include brainstorming, worst possible idea, paint by numbers, and many more. All of these are designed to get creative juices flowing, especially for a group of people, while keeping the results controlled.

Prototype and Test — Capability models are a unique bird because they represent the abilities needed by an enterprise to achieve a purpose. For all intents and purposes, you are creating a list. That list of abilities often exceeds the organization’s internal capabilities. This is why we talk about the capabilities of an “enterprise” and not the capabilities of a “business”. An enterprise may involve many businesses, suppliers, partners, regulators, and even customers in providing the required list of capabilities.

Creating a prototype capability model is a process that is complex if done by hand (without a capability modeling tool). This is because you may have twenty stakeholders, and most of them do NOT want to see the entire organization in the capability model! They want to see THEIR PART represented in gory detail and want to see everyone else minimized. For this reason, you need the ability to prototype a complete model (for the enterprise) but to review segment-level capability models with the stakeholders. Without a tool of some kind, this can create a great deal of manual effort. (This is not a problem unique to Design Thinking… this happens with all capability model generation).

I’ve found that the prototype effort actually begins during ideation. Since we are building a knowledge product, and not a physical product or even a software product, the first prototype is actually developed in the collaborative session to some extent. It is the synthesis of that prototype with the work done by other stakeholders, in their own ideation processes, that creates the enterprise model.

Resist the temptation to go dark, work for a while, and spring an enterprise model on the organization. Work your way up from stakeholders who buy in, showing them models that are domain specific. Put four or five of the domain specific models onto paper and get feedback before attempting to create the first synthesized model. Otherwise, one domain will have undue influence over the entire structure of the capability model.

With each prototype, you are producing a new enterprise capability model and a complete refresh of domain-specific models. Run them past key stakeholders for quick responses. Remember their needs: this is a planning framework. Can they use the capability model to develop their plans? Keep asking the core question.

When you have sufficient representation across the enterprise to have created the enterprise wide model, you can circulate that model with the core planning teams in your organization: these teams may go by names like Strategy Development, Organizational Development, PMO, Enterprise Architecture, Finance, and Strategy Execution.


Design thinking is certainly not the only way to design a product, and it is relatively novel in specific areas of organizational and strategic planning. However, as this example illustrates, design thinking can be applied to purely knowledge based products like a capability model in a manner that hopefully builds better buy-in for the final result.

And who couldn’t use a little more buy in?

Useful links

Business Architecture, Setting the Record Straight – William Ulrich and Whynde Kuehn — http://www.businessarchitectureguild.org/resource/resmgr/BusinessArchitectureSettingt.pdf

Design Thinking Blog – Tim Brown, Ideo – https://designthinking.ideo.com/

Design Thinking and the Enterprise – Pramod Prakash Panda, AVP, Infosys https://www.infosys.com/insights/human-potential/pages/design-thinking.aspx

Design Thinking, What is that? – Fast Company, 20 March 2006 https://www.fastcompany.com/919258/design-thinking-what

A guide to the SCAMPER technique for Creative Thinking – Rafiq Elmansy, Designorate http://www.designorate.com/a-guide-to-the-scamper-technique-for-creative-thinking/

Note that this article was first published on the Infosys Enterprise Architecture blog.  I created this  article in my role as an Enterprise Architect for Infosys.  I strongly encourage my readers to check out the Infosys Enterprise Architecture blog for excellent articles on EA, EITA, and trends in technology.


The Human Value Proposition of Enterprise Architecture

By |2017-10-03T23:29:53+00:00October 3rd, 2017|Enterprise Architecture|

The profession of Enterprise Architecture struggles, in part, because we have done a poor job of outlining our value proposition to senior leaders of our respective companies. I have posted occasionally about the value proposition of EA.  I was a lead author on the FEAPO perspectives paper that discusses the value of EA.  However, I want to highlight one value proposition that is often missed: the human side of envisioning.


De-identification, Data Security and Testing with Production Data

By |2017-09-22T18:16:27+00:00September 22nd, 2017|Enterprise Architecture|

While we know that software can expose data, we sometimes forget that writing software can expose data.

When a system gets deployed, we typically build a development environment, one or more test environments, and a production environment.  No surprises there.  However, developing software with sample data, instead of “real” data, can allow defects that are difficult to catch.  On the other hand, using “real” data (typically a subset of production data) runs considerable data security risks.  In this post, I’ll discuss the notion of building a general purpose deidentification tool specifically for software development and DevOps purposes.  (more…)

Does Academic Sloppiness Hurt EA?

By |2017-03-30T18:10:10+00:00March 28th, 2017|Enterprise Architecture|

There are surprisingly few researchers publishing articles about Enterprise Architecture from universities.  Even well considered programs like Penn State and MIT may only publish four or five papers a year.  Therefore, when a single researcher (a doctoral candidate at a well regarded university) publishes no fewer than fourteen separate papers on Enterprise Architecture over the course of three years, a few directly through the British Computer Society website, folks like me notice.

Unfortunately, as this article will show, this researcher appears to be building a body of sloppy work that he promotes widely, potentially harming both the profession of Enterprise Architecture and the reputation of the British Computer Society for promoting him.


The Capability Instance – can capabilities be realized?

By |2017-10-12T04:52:29+00:00February 24th, 2017|Enterprise Architecture|

Bizbok 5.5 from the Business Architecture Guild mentions an interesting concept that I’d like to discuss here: the capability instance.  I’d like to caution that this description is a concept rife with conflicts.  I’ll explain in a moment.