Tech Strategy: You Need it, But What is it?

As an executive, manager, or software developer you need a tech strategy. But could you honestly describe yours in detail? Do you even know what tech strategy really means?

Is tech strategy architecture? How about enterprise architecture? Does it involve programming languages and frameworks? Is a cloud strategy a tech strategy? What about digital transformation? It’s complicated…

A tech strategy creates high alignment. If you don’t have a clear tech strategy, everyone will make assumptions. Placing the success of your business on a whole organisation making the same assumptions is a rather large bet.

Don’t gamble when you don’t need to. I’ll show you the different flavours of tech strategy, and how you can work towards becoming an expert tech strategist. The following are the broad types I’ll cover, but the concepts generalise to any kind of tech strategy.

• Enterprise level tech strategy
• Business level tech strategy
• Product level tech strategy
• Project level tech strategy

If you get excited by tech strategy, come along and share your ideas at the following events where I will be presenting over the next month:

Craft Conference — Domain-Driven Architectural Alignment

Agile Manchester — Aligning Organisational and Technical Boundaries for Maximum Autonomy

Devoxx UK — The Art of Discovering Bounded Contexts

XP 2017 — How Software Developers Can Transform Organisations

Enterprise Level Tech Strategy

It’s common for large organisations to have a global tech strategy. The organisation may employ hundreds, maybe even thousands of IT people, yet have a single tech strategy apply across all of them.

I call this, enterprise level tech strategy. It also goes by other names including IT Strategy and Digital Strategy.

If you’d like to see a real enterprise level tech strategy, I thoroughly encourage you to have a look at HMRC’s 2016 IT Strategy (HMRC is the UK government department responsible for taxes).

So what does an enterprise level tech strategy contain? Let’s explore HMRC’s.

Business & Organisational Context

HMRC’s IT strategy opens with the “strategic context”. This short section briefly documents the purpose, goals, and responsibility of the entire organisation. It does not refer to IT at all.

For example, below is about 25% of the strategy context section:

We are the UK’s tax, payments and customs authority. We collect taxes and duties from 45 million individuals and 5.2 million businesses, support trade and growth through customs and pay tax credits to 4.6 million household and Child Benefit to 7.5 million families. We are also one of the country’s largest employers. Our work contributes to the country’s economic and social wellbeing and supports growth.

The United Kingdom is the world’s seventh largest economy and the second largest in the European Union and we play our part by making it as easy as possible for industry and business to trade, helping businesses to access reliefs that encourage investment, employment and growth.

Starting with the business context is sensible advice for any tech strategy. If you can’t communicate the problem you are solving, you probably shouldn’t be creating a strategy.

Nevertheless, HMRC’s strategy is a fine example of using the sheer prominence and importance of the organisation to capture the reader’s attention — also good advice if your tech strategy is an attempt to inspire.

A brief mention of customers and the benefits the system will provide to them is touched on in the context section. I hope you’re taking notes.

High-level IT Vision

Immediately after the strategic context, HMRC’s IT strategy lays out their high-level vision for using technology to support the business strategy. In HMRC’s case, their vision is making things digital.

Making tax digital

The government’s vision for making tax digital is about much more than simply adding digital tools to the current system; it’s about transforming the UK tax system into something that feels completely different.

Within the high-level IT vision section, HMRC’s IT strategy focuses heavily on the benefits to end users.

Taxpayers should not have to give HMRC information that is already has or should be able to get from elsewhere.

Taxpayers will be able to see their complete financial picture in their digital account, just like they do in their online banking.

Businesses should not have to wait until the end of the tax year or even longer before knowing how much tax they should pay.

Current IT Landscape

After defining the future vision, HMRC’s IT strategy then outlines the current IT landscape.

HMRC has a very complex IT landscape with nearly 600 different IT applications. Some of these were built at a time when data was entered into mainframe computers using punched cards.

We have achieved cost reductions through major contract re-negotiation, however the IT estate is still costly to manage due to a dangerous dependency on legacy mainframe operating systems and is difficult to change and keep pace with the increased and evolving IT demand.

This section of the document aims to create a clear shared vision of the current limitations. Managing expectation is always vital, and quite clearly HMRC are showing they have severe limitations.

Essentially, limitations are risks. Systems that aren’t easy to work with or estimate, potentially introducing significant schedule and budget variation, so it’s important everyone has full awareness of them.

Proposed IT Landscape

Finally, we get to the juicy details. Just how does HMRC plan to implement their vision? Firstly, they dive right into the nuts and bolts of virtualisation and cloud hosting.

The key to transforming our IT estate is re-engineering what we have so that the majority of our IT applications can run on virtualised infrastructure environments with as much as possible hosted on commodity cloud services.

Then it gets really interesting. They start to outline new systems/platforms and business capabilities.

There will be three core tax administration platforms.

• Individuals Tax management platform (ITMP)

• Enterprise Tax Management Platform (ETMP)

• Customs Declaration Services (CDS)

And five cross-cutting platforms:

• Case management

• Data and risk analytics

• Debt management

• Finance

• HR

If you’ve been to any of my talks or read my blog posts, you’ll know I’ve worked with multiple organisations who experienced great difficulties due to poor alignment between organisational and technical boundaries. Is this IT strategy locking into place organisational and technical boundaries by explicitly calling out these platforms? Will those boxes be translated into hard-to-change organisational boundaries? I’ve seen it happen more than once.

The remainder of that section (IT Contribution to HMRC Transformation) is quite detailed. I highly recommend you read it all for yourself. In summary, the key takeaway is the continued blend of business needs with technology solutions.

In theory, it’s good to justify what you plan to do with some concrete details, but does this IT strategy become too detailed — is it ivory tower architecture?

Have a read for yourself and see what you think. Maybe you think it goes too far the other way. Perhaps it’s too vague and open to interpretation. Might each team interpret the strategy in their own way to push their own political agenda?

IT Architecture

Towards the end of the document, there is a more detailed section on architecture. It has a high-level diagram showing the high-level pieces of architecture, for example the Tax and Customer Application and the Case Management application.

Design principles and implementation strategies are then discussed for each of these components.

Case Management

Our focus on this platform will include:

• refactoring current case management applications to support a shared layer of functionality that can be used across current and future case management applications

Again, this is quite contentious. Is it too much detail up front? What do you think? I’ll share my opinions in future posts.

Other Sections

There are a number of other sections in the HMRC IT strategy covering:

• Accessibility
• Outsourcing contracts and supplier models
• IT Delivery approaches (HMRC are moving from waterfall to agile)
• IT Governance (who is responsible and what is the process)
• People training and skills
• Infrastructure and operations

Who Creates the Enterprise Level Tech Strategy?

Good question. It will vary by organisation, but in HMRC’s example, the document lists their CTO and head of IT strategy as the points of contact for all matters related to the document.

Contacts

For further information on any aspect of this document please contact:

Steven Walters, Chief Technology Officer, HMRC steven.walters@hmrc.gsi.GOV.UK

Kristian Miller, Head of IT Strategy, HMRC kristian.miller@hmrc.gsi.GOV.UK

Obviously, responsibility for enterprise level tech strategy resides with senior IT leaders. But is it solely their responsibility to create it, or is a more collaborative approach required? Should software developers being involved in creating enterprise level tech strategy?

I encourage you to become a contentious tech strategist and have an influence wherever you can. Equally, as a leader you should be collaboratively creating a tech strategy. These topics will definitely be explored in future posts.

Who is the Enterprise Level IT Strategy Actually Intended For?

In the case of HMRC, they don’t explicitly tell us who the document is intended for. However, it’s likely to be consumed by all of the IT managers, outsourcing suppliers, and probably lots of non-IT people who need to understand how the business will change.

The document is also made publicly, so perhaps it’s written with the general public in mind. Showing us how they plan to spend our money.

Understanding who needs to know and see a tech strategy is a crucial concern. If the information doesn’t reach the right people, your strategy won’t have the desired impact. Understanding the audience should also shape the presentation of our your strategy.

Department or Business Level Tech Strategy

In a large organisation, an enterprise level tech strategy is usually too high level to be inherently useful for a single business or department. It doesn’t contain enough information about specific sub-systems.

For example, Salesforce has around 25,000 thousand employees. I work in the marketing cloud, which alone has hundreds of developers and a run rate of $1 billion. So an additional, more granular tech strategy is needed.

The next level down from enterprise level is what I refer to as business level or department level. It’s a tech strategy that applies to a group of teams who work in a specific business or department. Roughly, it could involve anything from 50 developers to maybe 500.

At this level, the strategy is an agreement between many teams regarding global policies, rules of engagement, standardisations — how those teams plan to make individual sacrifices to achiever greater system-level benefits.

A department or business level tech strategy should still be deeply grounded in business needs and customer outcomes, but it zooms in and provides more technical details on a specific area of the enterprise IT estate.

In most examples I’ve seen, a business level tech strategy also emphasis key cultural traits including collaborative approaches across teams. For example, regular show and tell sessions, innovation time, etc.

Examples

A department level tech strategy can go by many names. Sometimes it will be random pages and diagrams in a wiki. Sometimes it will be a presentation delivered by a manager.

The following are real extracts from business level tech strategies I’ve seen over the past decade. Notice how they touch on not just the technology, but the supporting processes, people, priorities, and even values.

• “All new services to have the capability of continuous delivery”
• “All teams to achieve hybrid engineering”
• “Our craftsmanship is second to none and we never compromise on the exceptional quality of what we deliver”
• “Services must be written in .NET or Node.js”
• “We prioritize the highest value-adding features and issues for our customers”
• “All teams demonstrate user behaviour logging”
• “It’s essential we can respond quickly to changing business requirements. The best measure of our effectiveness in doing so is via frequent predictable releases through a steady rhythm of working.”
• “When we can solve problems using other people’s tools or software, we have a preference for things which have already been proven”

I would also expect to see some high-level diagrams on a business level tech strategy, along with discussions of key technical systems.

Who Creates it, And Who is it For?

A strategy at this level will be the responsibility of an IT leadership position. It could be a chief architect, director of engineering, or lead developer. However, producing the document would most likely be a collaborative activity involving people at all levels.

Primarily, this type of document is for those delivering the work. It’s usually a blueprint or a guidebook acting as an alignment point across different teams. But it should also provide some level of usefulness to a non-IT audience.

Don’t Neglect Business Level Tech Strategy

Lack of an explicit tech strategy trips teams up time and time again, often to painful effect. For example, one department chased autonomy so highly, they neglected key parts of their tech strategy. They learned their lesson the hard way…

One day, one of their developers left. This caused a bit of a problem. He had so much freedom and autonomy, he’d built a service in Clojure. Problem was, he was the only developer who knew Clojure and he’d just left.

I often advocate for autonomy. It’s a defining characteristic of high-performing teams. But you still need a tech strategy to create an alignment and avoid embarrassing scenarios like this one.

Product Level Tech Strategy

A specific business or department may have multiple products. Products owned by different teams and at varying stages of their lifecycle. Each product may need it’s own tech strategy.

In one brownfield environment, our strategy was to ruthlessly refactor and rebuild the system. The business context told us the product was useful and had lots of future potential. It was a key strategic piece for the business so paying back technical debt was a profitable long-term investment.

In another brownfield environment, due to technical debt once more, the cost of saving a product was so high, the return on investment to the business did not justify the effort. So our strategy was to avoid touching the system, adding only small improvements where absolutely needed.

Both of these situations had something in common. In other parts of the business, different products had a completely different strategy. For example, in the first scenario, most of the other teams were already deploying to production many times a day. Even though they worked on related product areas, legacy wasn’t even part of their product’s tech strategy.

Therefore, within a single enterprise level tech strategy, there were many parallel product level tech strategies in play. Much of the detail and vision cascaded down from the enterprise level tech strategy.

Product level tech strategy often involves a lot more detail. Architectural diagrams, discussions of certain parts of the code etc. It usually contains team working practices — branching strategies, testing preferences, and so on.

Even at this level, a good product level tech strategy will be immersed in the business context and driven by customer outcomes and the product’s strategy. It will primarily be for those doing the work, but equally, product managers and stakeholders need to have some awareness of what’s going on.

I’d say, a product level tech strategy is rarely a coherent document. More a bunch of ad-hoc wiki pages and diagrams. It doesn’t need to be like a formal IT strategy since it’s closer to the ground and will change more frequently.

But even without the polish of a formal strategy document, you should still understand the key elements needed for a product level tech strategy. I’ll be showing you one possible framework in the next post.

Project Level Tech Strategy

Within the lifetime a product, there may be certain phases or initiatives — mini projects. These projects may have a specific goal, and thus require a strategy. For example: “remove all technical debt in the rules generator”.

Depending on the size and scope of the project, it could be a sizeable document with diagrams and discussions. Or it could even be as small as a verbal agreement among a few developers based on a whiteboard session.

Without a shared understanding of how a team(s) will work together, the resulting lack of alignment will lead to ambiguity and wasted effort. So a strategy is still essential, even at the project level.

But is a project level tech strategy really a tech strategy? It’s a million miles away from an enterprise level tech strategy at HMRC’s level.

So What is Tech Strategy & When do we Need it?

Tech strategy is a collective set of non-trivial decisions created to guide the use of technology and related factors in order to achieve business or end user outcomes. It involves not just technology choices, but process, organisation design, and cultural elements.

A single tech strategy can apply to organisations comprised of thousands of people, or teams comprised of just a few. Accordingly, organisations could contain hundreds or thousands of active tech strategies.

So don’t get too hung up on the phrase tech strategy. It’s very generic. But do be precise where you can — qualify the level of tech strategy you are referring to if it’s not entirely obvious.

When exactly do you need tech strategy though? Should every organisation have an enterprise tech strategy? Should every product have a strategy?

The important thing for now is to become a good technical strategist. And as you’ve seen, every tech strategy has a similar structure. So in the next post, you’ll learn about a heuristic called the Tech Strategy Pyramid for helping you to create a quality tech strategy. Future posts will also explore the need for a tech strategy, but if you have opinions, you are free to leave a comment right now.