Ever since the term digital transformation entered the business lingo, it has been mostly used as a buzzword, if not a joke. Then came 2020. It became blatantly clear that the companies that were the most digitally mature were the ones best prepared for the disruption brought about by the pandemic.
Fast forward to 2022, the next disruption is lurking just around the corner. The Web3 concept with blockchain as the underlying technology is gathering momentum. While there’s a lot of contention about cryptocurrencies, NFTs, and the metaverse, the more digitally mature businesses are already investigating possible use cases of Web3 technologies.
As CEOs around the world now pay closer attention to their companies’ digital strategies, digital transformation has become a fact of life. The goals are clear: organizations need to be more efficient, more flexible, and better fit to deliver innovative services and products to their customers.
With these clear goals in mind, companies develop their digital strategies, i.e. long-term plans of action aimed to reach digital maturity and reap the harvest of digital transformation. They know what they want to do, or at least, what the desired outcomes are, but actually getting there remains a huge challenge.
Digital enablement through technical architecture
While digital transformation is a complex undertaking that involves many moving parts, my view is that technical architecture plays an absolutely critical role in doing it right. In fact, I strongly believe the key to a successful digital transformation is a carefully thought-out technical architecture combined with the people that build it and make use of it.
What then makes a good technical architecture? Before discussing this I need to tackle something else. In my work, both as a digital architect and a software engineer, I have always found Conway’s law to be something to bear in mind in any IT project:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
—Melvin E. Conway
Conway wrote these famous words already back in the 1960s and while many people considered them gospel truth ever since, it was in 2011 that MIT and Harvard Business School researchers put forth evidence in support of his hypothesis. Put simply, Conway’s law means that IT systems mirror the organizational structure of their creators.
Transforming organizational structure
In the context of digital transformation and technical architecture, Conway’s law has two grave implications:
- Digital transformation without change in organizational structure replicates the company’s existing organizational constraints.
- Any flaw due to organizational structure will be manifest in the company’s technical architecture.
That’s why you can’t just rely on a methodology like SAFe or agile and hope for the best. Digital transformation is not about replicating your business structure and processes in software. It’s about actually transforming your business for the 21st century.
This of course requires being open to changing the status quo and having the guts to reorganize your teams into a modern structure. One tried and tested approach is switching to POD (Product Oriented Delivery) teams, as opposed to multiple departments in charge of different parts of a product or service.
An example of this I often come across is a separation between the devops team and the team delivering vertical product features. While it makes sense on paper—and it’s usually a natural expansion of IT departments to move their traditional IT operations people into devops roles—this usually ends up being just a swap of labels, so that there’s no actual change in structure.
My experience is that it’s far better to have devops people work as part of the teams that are responsible for the delivery of verticals. This is because such a setup creates autonomy for the POD teams and effectively enables them to eliminate the delays and inherent communication issues that arise when working across teams.
Regardless of structure you invariably need different teams to collaborate. As a leader you can enable this through various workshop techniques. One of my favorites is Event Storming. This is a great way to get a huge group of people on the same page, so that they can understand and collaboratively solve the problem domain. What’s great is that the output of their work can then be translated into code using domain-driven design principles.
Why technical architecture matters
Ok, so by now you’re probably thinking: ‘Wait… wasn’t this supposed to be about technical architecture? Why all the talk on organizational structure?’ Well, the point is that it’s not possible to successfully implement a digital strategy without designing technical architecture and organizational structure hand in hand.
After all, this technical architecture will be continuously built and used by people within an organizational structure. We’ll come back to the people aspect once again, but let’s already dive into discussing technical architecture.
Ultimately, technical architecture is a set of constraints. Now, you have to be very wise in where you create constraints and where you consciously don't. The trick is to know how to apply constraints while maintaining flexibility. This can be a mind-bending exercise.
Depending on your goals and needs, you will want to set on a core of constraints that lay the foundation for your architecture. Something to build upon that will reliably hold the whole thing together. In other aspects, you may want to refrain from setting constraints so that you can freely adapt your architecture as the business environment around you inevitably changes.
For example, you might place the constraint that all systems produced by the different teams must integrate using an event bus, however how they implement the systems within is up to them. This is the kind of high-level constraint that will ensure you can continue to leverage new technologies as they become available for different problems, while you can continuously rely on all your systems being interoperable as time goes on.
Connecting all the dots
With proper organizational structure and technical architecture, digital transformation occurs naturally and allows you to remold your business indefinitely, just as you need to. The best part is that a flexible architecture allows you to do so while minimizing technical debt. You have your architecture foundations that you can rely on, while everything else can be moved about freely.
In this scenario, multiple teams can work on numerous architecture facets without stepping on each other's toes while being autonomous and having the ability to interoperate. By setting up quick plan-do-check cycles, your company can grow in multiple directions at the same time and cross-feedback between teams can lead to improvements that wouldn’t be possible otherwise.
Again, figuring out all the details for that dream technical architecture must go hand in hand with rethinking the company’s organizational structure. And that’s often extremely difficult to achieve within the org itself. Sometimes you just can't see the forest for the trees and need a fresh pair of eyes.
This may come in the form of you reinventing yourself as a leader, or possibly finding a champion internally. Getting external help is also an option and one that more often than not can get you a long way quickly.
The task here is to look at your business goals and strategy, at your org chart and team structure, as well as at your processes, and come up with a holistic design that addresses all of these dimensions in one fell swoop. Setting up your teams and technical architecture right is a game changer for any business, because when you unleash people within your organization, you actually unleash communication and the flow of ideas. Only then can you adopt an iterative approach and take deliberate strides towards digital transformation.
Final words
Wrapping up, how should you approach digital transformation in 2022 and beyond? I believe this ultimately boils down to the following evergreen practice:
- Align yourself with the goals of your organization and understand your digital needs. This is the digital strategy part, where you set up plans for the long term that inform your digital maturity efforts.
- With your digital strategy in mind, redesign your org chart while drawing out plans for your flexible technical architecture. A skilled digital architect will help you make it right.
- Get the right people to build the architecture properly and empower your teams to own, grow, and adapt it, as needed.
- Above all, be brave. This is no easy task and people often resist change. The world around has changed and continues to do so, therefore digital transformation is inevitable and your digital maturity can be your unfair advantage.
I wish you to be brave so that you don’t fall victim to the ill effects of Conway’s law but instead learn to harness them and achieve your digital goals.
Let me know if you have any questions or thoughts in the comments below.
