/Tag: Enterprise Architecture

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.


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 concept of the “Nearest Common Manager” in Enterprise Architecture

By |2016-12-16T10:05:24+00:00December 16th, 2016|Enterprise Architecture|

I’m going to share a secret.  Something that no one talks about, but is critical to understand if you are to be an effective Enterprise Architect.  Are you ready?

People do what you pay them to do.

What a letdown.  Everyone knows that, right?

But we don’t talk about it because it is an assumption of every day work.  Those assumptions drive a great deal of behavior in an enterprise.  In Enterprise Architecture, we must think about the assumptions, because assumptions can stop progress without anyone realizing it.  Assumptions can impede communications.  Assumptions can cause good behaviors to be punished and bad behaviors to be rewarded.

So let’s look at this assumption a little more closely.  Who pays you?  Well, the guy or gal who can fire you if you don’t perform, that’s the person who pays you.  So, if your manager says “run every decision past me,” you are going to run every decision past the boss.  You are doing what you are paid to do.

This creates a hierarchy in an organization that is persistent and rather absolute, especially if you can be blamed.  No one will defy their manager’s manager.  On the flip side, if you are an individual contributor, you have no idea if you are doing what the CEO wants.  Only your manager tells you what to do.

How does this affect Enterprise Architecture?

EA’s are often called to work “across silos” or to collaborate with different groups.  There is no single manager that everyone in your “virtual team” reports to.  You cannot go to a single manager and ask him or her to support your efforts.

One concept that you should be aware of is the “Nearest Common Manager.”  This is the lowest ranked person that everyone on your virtual team ultimately reports to.  In many companies where I have worked, the nearest common manager is the CEO.

The thing that you should be aware of: whoever the nearest common manager (NCM) is, someone who is in communication with the NCM has to have your back… someone who the NCM knows and trusts has to know what you are up to, and has to agree with it.

When you hear the term “executive support,” this is what we mean.  Someone who can provide the air-cover that you will need with the nearest common manager.


Disruption – why you need business architecture

By |2016-11-30T04:34:11+00:00November 30th, 2016|Enterprise Architecture|

Business Architecture is, on occasion, a difficult sell.  In many companies, it can be tough to get senior leaders to give you to remit to use the tools and techniques of business architecture.  This is especially true in organizations that think of Enterprise Architecture as an IT function.  The following video answers the question “Why do we need Business Architecture?”

Your feedback is encouraged.


The European EABOK and Enterprise Architecture Pattern Catalog

By |2016-10-19T20:36:47+00:00September 24th, 2016|Enterprise Architecture|

A number of years ago, I joined up with a small group of architects determined to create an EABOK (Enterprise Architecture Body of Knowledge).  We got off to a good start and I even bought the domain (eabok.org).  However, the Mitre Corporation (a federally funded research and development corporation) trademarked the name before we did, based on a white paper they had released in 2004.  I was out-lawyered.  So the name was theirs.  They wanted to do an EABOK as well.


Nick Malik speaking at BBC on ‘Building Demand for Strategy for Non-Strategy Organizations’

By |2016-10-20T09:43:56+00:00September 6th, 2016|Newsletter|

Heading up Vanguard EA as Founder and Principle Consultant is Nick Malik, with over a decade in enterprise architecture and more than thirty years in high tech, he has a wealth of experience and advice to offer. Ahead of giving a presentation at the Building Business Capabilities (BBC) conference in Las Vegas, Nick explains why his presentation ‘Building Demand for Strategy for Non-Strategy Organizations’ should be on your list of presentations to attend.


Enterprise Architecture and Threat Modeling

By |2016-11-28T21:14:48+00:00August 29th, 2016|Enterprise Architecture|

What should an Enterprise Architect know about threat modeling?

I recently asked on a LinkedIn group about threat modeling and Enterprise Architecture. My first surprise came when the first set of responses were from folks who didn’t appear to understand what threat modeling was. So I guess the first order of business for anyone wishing to consider themselves an Enterprise Architect is to study up on what Threat modeling is.


The human element to strategy

By |2016-07-15T23:03:43+00:00July 15th, 2016|Enterprise Architecture|

There is no shortage of business thinkers and authors who will tell us this statement is true:

Anyone can create a good strategy.  The most frequent failure is in execution.

Unfortunately, this underestimates the difficulty in creating a “good strategy.”  While the statement above is absolutely true, it is not unusual to find companies that don’t have a formal strategy at all, or who fail to share their divisional strategies with all of their employees (a key measurement of strategy adoption in a company is “how many of your employees can recite your company strategy”).

One of the obstacles I’ve come to recognize in Enterprise Architecture is unique to companies that either don’t have a formal strategy or who do not share their strategy with their staff — you cannot align efforts to strategy if there is no consistent understanding of strategy across divisions.

I always knew this was true.  I’ve become more and more convinced that it is a hard-and-fast rule.  In other words, if you want to be successful as an EA in a company that doesn’t share strategy, this becomes your First Order Problem — how to develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

That’s it in a nutshell.  To be successful, your organization must develop a consistent strategy that everyone at the senior level agrees with and that they are willing to share with their staff.

First order problem — In other words, focus on this.  Make progress on this.  Measure yourself by your progress on this.  Associate yourself with the people who “should” own this, and align yourself with the people who actually do own this (rarely the same person). Find ways to be involved.  Find ways to contribute. Volunteer.  Make things happen.  Find ways to support incremental progress, while recognizing that the increment may not be good enough in the long run.  For EA to become known for “doing successful Enterprise Architecture,” a clear and communicated company strategy is ground zero.


Welcoming Archimate to Enterprise Architecture

By |2016-10-21T09:38:17+00:00June 28th, 2016|Enterprise Architecture|

I’m going to get some heat for that title… I’m sure of it.  Archimate has been a diagramming standard for some elements of Enterprise Technical Architecture for a couple of years now.  However, with the new release of Archimate 3.0, this interesting visual language is now directly useful to Enterprise Architecture from the perspective of a Vanguard EA.