Using Enterprise Architecture for Digital Transformation

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.”

Placement

  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.

Readiness

  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

Score:

  • 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.

 

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

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.

design-thinking-amalik-1

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.

design-thinking-amalik-2

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

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

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.

(more…)

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

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…)

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

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.

(more…)

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

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.

(more…)

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

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.

 

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

Translating business capability maps into business impact

Creating a business capability map is just part of the challenge businesses and chief information offices face. Taking the information in the map and making it work and translate into real, tangible business impact can often present far more obstacles than the development of the map itself but without this crucial step the benefits of undertaking the task of creating a business capability map are generally lost. (more…)

By |2016-12-15T08:53:36+00:00December 15th, 2016|Newsletter|0 Comments

Does Business Architecture Start With Value Chains?

Creating value chains can be integral part of decision-making thanks to their ability to illustrate how a firm is delivering a valuable product or service to market. A value chain can support other decision tools and benefit competitive strategies with the additional information they supply. (more…)

By |2016-12-14T20:58:26+00:00December 14th, 2016|Newsletter|0 Comments