206-245-4311
Inside Architecture blog
Design Thinking in Business Capability Modeling
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.
Conclusion
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.
http://www.infosysblogs.com/enterprise-architecture/2018/04/design_thinking_capability_modeling.html
The Human Value Proposition of 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
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?
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.
Self Organizing Enterprise Architecture
Our language can limit us. Our words can prevent us from thinking about our world in a clear way. This article is about freedom from our own words. Read at your own risk.
The Capability Instance – can capabilities be realized?
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.
The concept of the “Nearest Common Manager” in 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.
The Repository Won’t Save EA
One thing most Enterprise Architects have in common: frustration with resistance to change. Channeling the words of some of my friends, frustration sounds like this: “We know many of the answers to common problems in IT, especially in how systems are developed and used, how data is organized and mastered, and how capabilities should produce shared components or systems. We know many of the answers… but no one listens!”
Yep. We do work and sometimes, no one uses it. Or we develop advice, and no one follows it. Common problem.
For some reason, the “answer” that I’ve heard bandied about is to buy software. “If we only had a repository for architecture, then people would use our models.”
um – no – not really.
If your models are not used, putting them into a collaborative storage and retrieval system will not get them used. It will make them more available, but in 85% of the cases, availability is not your problem. Either no one sees the value in using your models, or they don’t know how to read them, or using your models works against some political aspect of their lives.
It’s not that your stakeholders didn’t know the model was there. It’s that they don’t care.
Adding a repository won’t make them care.
Your first order of business is to build demand for the architecture models. Once demand is there, worry about the repository. Until then, a simple modeling tool will work.
Disruption – why you need business 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
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.