Technology Strategy Patterns: Architecture as Strategy

by Eben Hewitt

Yet, as technologists, we are businesspeople. A hammer doesn’t exist to be a hammer. It’s a tool to construct something else.

There are five basic steps to follow in formulating your strategic technology analysis. Here is a simplified outline: Establish context Analyze the trends happening in the world outside. Analyze the forces at work across your industry, your organization, and your department. Gain a view on your stakeholders. Understand your competition, the market, and the technology landscape. Identify strategic options in your products, services, and technology roadmap. Evaluate those options. Make a compelling recommendation with a coherent, cohesive, comprehensive strategy to gain approval and resources to execute your plans.

Architecture begins when someone has a nontrivial problem to be solved. The product management team states what must be done to solve the problem, and the architect describes how to realize that vision in a system.

Vitruvius expands on the three requirements that any architecture must demonstrate: Firmitas It must be solid, firm. Utilitas It must be useful, have utility. Venustas It must be beautiful, like Venus, inspiring love. This is sometimes translated as “delightful.”

architects are concerned with how technology can fulfill business goals given a long-term outlook across a variety of interrelated systems across many teams.

Here’s my definition of an architect’s work: it comprises the set of strategic and technical models that create a context for position (capabilities), velocity (directedness, ability to adjust), and potential (relations) to harmonize strategic business and technology goals.

three primary concerns of the architect: Contain entropy. Specify the nonfunctional requirements. Determine trade-offs.

The nonfunctional requirements are properties of the system that do not necessarily appear directly to the user. They are typically described as the “-ilities.” The ones I focus on most are scalability, availability, maintainability, manageability, monitorability, extensibility, interoperability, portability, security, and performance.

In short, you’re never quite solving a problem. You’re only trading it for one that you’d rather have.

Moreover, the less shallow or cynically minded among us are still rather prone to chasing exciting technology for its own sake, not unlike a dog chasing a squirrel. Intellectual curiosity is a wonderful thing, a best thing. But to ensure that your technology and architecture decisions are truly supportive of the business—that is, give it the best chance to create competitive advantage—they need to be not shopping lists of shiny objects, but squarely strategic.

Jomini’s definition of strategy helpfully divides the word. He writes, “Strategy decides where to act; logistics brings the troops to this point; tactics decides the manner of execution.”

For our purposes, strategy is about determining the problems and opportunities in front of you, defining them properly, and shaping a course of action that will give your business the greatest advantage. Balancing problem solving with creating and exploiting new opportunities through imagination and analysis is the cornerstone of a great strategy.

To be a good strategist, you need to be ready to deal with ambiguity. You need to be ready to pivot. You must form a hypothesis quickly about what must be done, then synthesize lots of data. You must then see options and possibilities available, determine a goal, and present your findings clearly with a recommendation on how to allocate resources to achieve that goal.

MECE stands for “Mutually Exclusive, Collectively Exhaustive.” It represents a kind of metapattern. It offers a quick way to check that the building blocks of your strategy work are valid and complete.

Logic Tree is used by strategy consultants as a simple tool for determining a set of relevant problems and possible causes. It helps organize your ideas, making quick work of examining any problem.

The Hypothesis pattern is a way of making a guess, based on some supporting suppositions and data, about what the root problem might be.

As a technology strategist, you have many jobs: Survey the landscape across your industry, organization, customers, stakeholders, competitors, and employees. Examine trends in technology. Determine what current priorities, problems, and possible opportunities are presented to your company. Analyze and synthesize these problems and opportunities into a course of action: decide what to do, and what not to do. Make strong recommendations for how to allocate your company’s resources, in what way, in what places, to what extent, and to what end.

This list is MECE: Spades, Diamonds, Hearts, Clubs This list is MECE: Winter, Spring, Summer, Fall Each entry in the list is mutually exclusive of every other one. There is no overlap in their content. Winter ends on a specific day of the year, and then the next day is the start of Spring. Every date on the calendar is, with certainty, part of one and only one season. There is no card in the deck that is part Spades and part Diamonds.

North, South, Southwest, East This is not MECE because it leaves out one of the elements, West, and so is not collectively exhaustive. It also includes Southwest, which is not topologically on the same plane as the other elements.

An insight is when you mix your creative and intellectual labor with a set of data points to create a point of view resulting in a useful assertion.

This is the simpler and more useful formula for how to make decisions under high levels of uncertainty: Create and hold a variety of hypotheses in our heads at once. Think about them probabilistically, using an informal application of the Bayesian method. Update them frequently as we get new information that might be more or less consistent with each.

But what the machine is learning is actually a function: what it’s learning is what function best explains the data. A machine learning job is one that, given a mass of data, determines how to frame the data in the context of a hypothetical function (f) that would explain the data, and that hypothetical function is the thing the machine learning algorithm tries to figure out.

You use a PESTEL analysis to answer this question: What strategic direction is suggested by the current and anticipated Political, Economic, Social, Technological, Environmental, and Legal climates?

We know what forecasting is: you start in the present and try to look into the future and imagine what it will be like. Backcasting is the opposite: you state your desired vision of the future as if it’s already happened, and then work backward to imagine the practices, policies, programs, tools, training, and people who worked in concert in a hypothetical past (which takes place in the future) to get you there. It’s a wonderful tool.

When creating a broad, multiyear strategy, you can apply these patterns in the order they are presented, starting with analysis: first consider MECE and create a Logic Tree (both described in Chapter 2), and create a set of hypotheses. Then, write your PESTEL analysis (see “PESTEL”) and conduct a Scenario Planning exercise (see “Scenario Planning”). You can then create your Futures Funnel (see “Futures Funnel”) diagram and perform a Backcasting (see “Backcasting”). That will then likely cause you to refine your analyses.

SWOT analysis can help you create a long-term broad-based technology strategy across your whole organization.

Using the Five Forces is about thinking of your company in a holistic way and doing the research—getting the data—to create insights about what’s happening to your company.

you can extend the AGM to consider not only your business and technology strategies, but your personal career strategy for growth and development as well.

In this chapter, we look at the patterns that operate internally within the sphere of your own company. There are more patterns in the corporate sphere than in the others, as the work of your technology strategy is primarily centered on how to position your company for competitive advantage. They are: Stakeholder Alignment RACI Life-Cycle Stage Value Chain Growth-Share Matrix Core/Innovation Wave Investment Map

Once you have your stakeholder list, add two columns to it: Influence Impact Influence refers to how important this person’s support is. What is her ability to change your direction, impose new priorities, dictate critical aspects, ensure your funding, or otherwise determine constraints for your technology strategy? It’s the degree to which she can impact your strategy. Impact, on the other hand, refers to the degree to which your strategy, as it becomes realized, will impact her.

During strategy season in late spring, you can use the Core/Innovation Wave as a planning tool to assist you in envisioning where the applications in your portfolio lie with respect to two key vectors: proximity to the core and innovation (see Figure 5-6). It’s useful in conjunction with an Ansoff Growth Matrix (see “Growth-Share Matrix”) and an Investment Map (see “Investment Map”) and Application Portfolio Management (see “Application Portfolio Management”).

The Process Posture Map gives you a picture of either 1) elements of your current state that need to be supported or revised or 2) a practical map of how everything in your enterprise architecture will work together. So you can use this map as a diagnostic or alignment tool for the current state, or as an image of the Beautiful Future, an aspirational vision.

The first step in a Process Posture Map is listing your processes in a pretty and organized way within a slide deck. Figure 6-1 shows an organized example of four main categories, with their processes under each.

Imagine you have a five-step process that you want to optimize, and you determine that at each step you have 80%, 85%, 90%, 85%, and 90% optima. It looks like you have a score of 86% overall, taken as an average. When taken as a product, however, the total optimization of the overall process is 47%: a very different picture.

First, list the projects. Next, determine their net value to the business based on standard metrics such as internal rate of return (IRR) or anticipated return on investment (ROI). Then, examine the quality of the project based on metrics such as the technology employed, the capabilities it provides, and whether the costs are in line and the timeline is on track. Finally, you can plot them in a heat map.

Here’s a secret: nobody knows what to do. The boss is a person with children and a sick parent and nagging concerns about who will win the pennant and what’s for dinner and the possible emptiness of existence—like everyone else.

The boss almost always wants to know one of these things: What is the project status? Do they need to do anything to help, or has the team got it? What is your recommendation on a particular proposed action?

Put a simpler way: speak truth to power. Tell powerful people what they need to hear, not what they want to hear. You’ll be seen as (and actually be) honest, forthright, forthcoming, objective, strong, confident, and smart. These are cherished, and rare, qualities. If your boss is a nut job who hates hearing the truth, can’t stomach bad news, or can’t hear that he might not be perfect, just get another gig. It’s over anyway.

According to Aristotle, to make a truly persuasive argument, include three key elements: Logical arguments (logos) Ethical arguments (ethos) Emotional arguments (pathos)

What you need is a fait accompli. Put simply, you have the meeting before the meeting, in a bunch of little meetings, to line everyone up. Then the big meeting where everyone is ostensibly there to hear your message and accept it is more or less over before it starts, with people by and large on board, because their buy-in happened already: it’s a fait accompli.

When this pattern is most deftly executed, people don’t have an experience of approving your work at all: they think you are merely representing them and simply relaying the strategy we all know is right. They will think, “We did it ourselves.” Strategy is the art of creating power. If you don’t give them power, they will take yours.

Here’s a second great benefit to employing Dramatic Structure: if you can’t honestly weave your request into this structure, if you don’t know clearly what the real reasons are that you want to move to the cloud or make all the programmers learn AI, or you can’t explain why everyone should stop doing Agile and start doing Fred’s Cool New Software Development Method, then you might not have good enough reasons.

Solving local problems is an important part of our jobs, and needs to be done. But architects and leaders who too frequently focus on too fine-grained matters, on small issues with few branches, can actually perpetuate and worsen the organizational dysfunction that they purport to address.

If you are a knowledge worker, your job is not your job. Your job is to destroy your job. Employ metacognitive thinking: stand outside and consider how you do what you do, watch yourself and your organization, externalize what you know, share your knowledge as fast as you can, create a new context, templatize and automate yourself out of a job.

You are always building a system: your architecture is a system, your strategy is a system, your organization is a system, your mental model as an observer is a system.

With these, you can usher the considerable raw material you’ve generated so far from the developmental concept realm into the material realm: One-Slider Use Case Map Priority Map Directional Costing Technology Radar Build/Buy/Partner Due Diligence Architecture Definition

It’s to say this: a lot of times what executives need is not a perfect number, but a directional cost. They really do want a rough ballpark and don’t expect it to be perfect. They want to know if it’s more like $1M or more like $10M.

I’m usually not a fan of partnerships. I’ve seen a number of them go poorly, and precious few go even well. Eventually, someone needs to decide if they want to be in this business or not, and if they do, they should own the solution and go be the best in the world at it. That said, partnerships can be a good way to test the waters if you really need to see more in order to make that determination. If there is no clear market leader, partnerships can allow you to work together as a longer-term way of deciding on an acquisition.

The product management team owns the functional requirements: what the system does. These items are expressed in epics and user stories and stored in something like CA Agile Central.

But the architecture team owns the nonfunctional requirements: how the system will be realized—and what’s their form of expressing the architecture?