3 things architects need to know about starting a digital transformation project

I've been working with clients on moving from traditional monolithic architectures to modern cloud-native, microservices, and event-driven architectures. These projects have included organizational change and introduced new ways of working.

I am frequently asked, "How should we start?" regarding digital transformation. While working to solve complex problems with some of the best companies, our team has learned many lessons that have evolved into an approach to digital transformation that I want to share with you.

Our method (which is publicly available for anyone to use) offers many advantages:

• Drives enterprise design thinking at scale
• Builds on agile principles for colocated and distributed teams
• Leverages DevSecOps tools and techniques for continuous delivery and operations
• Fosters digital talent
• Enables site reliability engineering (SRE)

I am not suggesting that our approach is the best or is sure to work for you. Companies have different organizational structures, cultures, and forces, so your mileage will vary.

In this article, I'll share three lessons learned while working on digital transformation projects, and in a follow-up article, I'll describe four essential roles to have on a digital transformation team.

Our methods

Our team's approach enables business, development, and operations to design, deliver, and validate new solutions continuously. The practices and workflows cover the entire product lifecycle from inception through capturing and responding to customer feedback and market changes.

We focus first on business outcomes, not technology, and guide the solution journey from inception to delivery while reducing innovation risk.

The figure below shows the software engineering function's organizational structure (program management and related functions are not shown). This structure also informs which parts of the organization need to be formed as a digital transformation program begins.

Image

Lessons learned

I've learned three important lessons from my digital transformation work with my clients:

1. Start with the architecture and platform engineering squads.
2. Designing the squad is just as important as designing the product.
3. Give build squads autonomy and end-to-end ownership.

I'll break these lessons down in more detail.

[ Learn what IT leaders are doing to maintain momentum on digital transformation. Read the HBR research report. ]

1. Start with the architecture and platform engineering squads

In one of my engagements, we started the architecture, platform engineering, and build squads simultaneously. We found that the architecture squad was always struggling to keep up and never really managed to catch up. It's better to start the architecture and platform engineering squads first and give them enough time to build out the reference architecture.

The architecture squad comprises architects that are on the transformation program full time. The squad also has a chief architect. You could have two chief architects if you are pairing or need to change behavior. Every architect is assigned to up to two build squads. They provide the architecture support that the build squad requires.

As a transformation program starts, the squad needs to establish and build the reference architecture and a reference implementation. The architecture squad, just like every other squad, has a backlog with prioritized stories that they work from. The architecture stories are focused on the reference architecture and implementation. The architects work on designing these stories and pass them to the platform engineering squad.

[ Build creative, responsive organizations without dictating every action or planning for every contingency. Read Culture matters: The IT executive's guide to building open teams. ]

The platform engineering squad is a build squad that focuses on building out the reference architecture and the reference implementation that the build squads will leverage while concentrating on building products. The architecture squad plays the role of product owner for the platform engineering squad.

The architects create the initial set of architecture stories; however, once the build squads are operational, they can submit architecture stories to the architecture squads backlog for consideration. If the story is cross-cutting, strategic, or will occur frequently, the architecture squad will prioritize it. If it isn't, the squad returns the story back to the build squad that submitted it and leaves it to them to implement.

The architecture backlog is jointly managed and prioritized by the chief architects, the squad leads of all the build squads, and all the product owners.

The output of the architecture and platform engineering squads includes:

• Code and templates
• Architectural decisions
• Leading practices
• Reference architecture
• Reference implementation
• Developer playbook

Build squads leverage all of these artifacts to hit the ground running. Given that the primary consumers are developers, creating the artifacts in a tool or a location like a source code repository makes sense. Kyle Gene Brown covers this in his article on GitArchitecture.

2. Designing the squad is just as important as designing the product

We found that the squad's structure is extremely important. Figure 2 below illustrates the key full-time roles that are part of every build squad. There are also part-time roles, such as a user experience designer and an architect. See Roles in a squad and Build effective squads for additional perspectives.

Image

It's best to keep build squads small—ideally eight to 10 people. When squads are larger, everything takes longer, and productivity goes down. Start with three pairs of developers and increase to four as the squad matures. Also, have an SRE pair as part of the squad.

3. Give build squads autonomy and end-to-end ownership

When squads have autonomy and end-to-end ownership, they have accountability. We expect the squads to build, run, and operate the product. If their product fails and results in a service outage, they are the ones who wake up in the middle of the night to restore service. We found that the more ownership the squads feel and the more control they have, the better the product they ship.

Wrapping up

Many workstreams comprise a typical digital transformation program. How the process begins is relevant to a transformation program's long-term success.

This article focuses on the method and organization structure, and my next article shares the detailed role responsibilities for these key roles.

Thanks to Kyle Gene Brown and Dhruv Rajput for their helpful review of this article.

This article is adapted from Launching and scaling a transformation organization and is republished with permission.