Technology Strategy Patterns: Architecture as Strategy

by Eben Hewitt

Any technology strategy is, in a sense, a request to spend millions of dollars of someone else’s money. If you think of your work as a technology strategist in this way, you’ll do it differently. By which I mean better.

I hypothesize that in the future, people who can learn quickly as synthetic interdisciplinarians will be highly effective, and highly prized, because maintaining that distinction is increasingly a barrier to progress, creativity, and innovation.

There are two jobs in the world that people want to do the most while knowing the least about: architect and strategist.

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

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.

There are many different roles that architects legitimately play in different organizations. But the primary struggle I have seen comes when they are not focused on a deliverable, on what could be conceived as a “blueprint.” Without that focus, they tend to weigh in at project meetings or make declarations informally that can’t be remembered or followed.

One cannot be successful as an architect without thinking of not only what to do, but how to get it done within an organization, which requires knowing why it should matter to someone who isn’t a technologist.

Knowing that you’re in the business of building a business, and that technology is just an avenue by which you enable that, is a critical first step to being not only useful but powerful as an architect and strategist.

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.

“When you invent the ship, you also invent the shipwreck…Every technology carries its own negativity, which is invented at the same time as technical progress”

“Strategy decides where to act; logistics brings the troops to this point; tactics decides the manner of execution.”

Strategy Defenition

Any business aims to do one or many of these things: Grow shareholder value Grow earnings per share Increase revenue Manage costs Diversify or create new revenue streams Cross-sell more products Increase market share Increase share of wallet Increase yield Improve customer retention Reduce product error/defect rates Improve safety Improve time to market/speed of operations Grow through acquisition Of course, there are different emphases at different times. To achieve these aims, broadly speaking, the strategist asks these questions: Are resources devoted to the right areas, to the most important customers? Are we creating products and services that can thrive in a market in different time horizons? Where should we spend money? Where should we cut costs? Where do skills need to be added or strengthened? Where can productivity be improved? What culture, attitude, and skills are required?

Identifying business development opportunities, such as partnerships, joint ventures, cooperative arrangements with competitors, and the like Finding, proposing, and validating mergers and acquisition opportunities Building strategic capabilities within certain areas of the organization, such as helping create a sustainable AI practice in the face of growing trends Performing research based on data to recommend long-term directions for the company (generally 1–3 years)

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.

Learn from your executive and product leadership teams what areas of focus they have for their business strategy and product roadmaps, so you can be prepared to match your technology to them.

As architects, we’re asked to make recommendations with imperfect knowledge, and need to do research, try some stuff out, and make a call. The more times we show good judgment, make the right call through a fog of business uncertainties, and minimize opportunity cost and maximize returns, the more our own stock price goes up in the organization.

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.

The single most important thing you can do to improve your chances of making a winning technology is to become quite good at making lists.

Think of MECE as a lens. Every time you make a list, immediately test if it is MECE. Use it as a heuristic device with your team: inspect your list with the team as you’re meeting, be sure to ask if the current list you’re working on is MECE, and then refine it. Your team may groan at first, but they will gradually start to see the value, and then they will not be able to imagine how they ever lived without it. Make your work lists of lists, and make those lists MECE. Your recommendations have a better chance of getting accepted, supported, and executed on. And you will create more power for your organization and your team.

Mutually Exclusive and collectively exhaustive

Note that it’s a good idea to read and cite material like McKinsey Insights reports in your Strategy Deck appendix, as part of your data point collection work, to help you reach your own insights that lead to your strategy.

A common mistake here is use of the word “platform.” People in tech say it so much that they think they have one just because they said it, but it often is improperly used as a synonym for “system” or “application.” A true platform offers APIs that allow customers to build something new of their own on top of it. Android is a platform. Alibaba is a platform. AWS is a platform. Salesforce is a platform. Your mission-critical system might be important to your customers, and wonderful, but if people can’t make new applications of their own on top of your system without talking to you, it’s not a platform.

Train yourself to use ranges. Technologists commit the fallacy of false precision more than any other group of people I’ve seen — as much as 27.3% more.