Technology strategy
Birth of the Technology Radar
Large organizations with lots of technology inevitably face the task of managing and governing their decisions around technology: how long should the organization stay with existing technology, how much experimentation should we invest in, and myriad other questions that balance resources, cost savings, IT strategy, and capabilities. This article investigates some fundamental changes in the attitude about governance, how effective companies do it, and how the Thoughtworks Technology Radar metaphor helps broadcast guidance.
The birth of the Thoughtworks Technology Radar is documented in this article by Darren Smith. It started as an internal exercise to help us understand how our clients were adopting technology, and it seemed interesting enough to publish. Over the last few years, we've encouraged companies to use the same metaphor to build their own technology radar as a way of thinking more deeply about technology choices and trends within their organization. Towards that end, we've released a variety of open source tools to assist others in creating their own radar.
Increasingly, we see large companies utilizing the radar metaphor to solve a pervasive problem: how to effectively broadcast guidance decisions about technology to a widely dispersed group of engineers. Large enterprises commonly partition themselves into different divisions, departments, regions, locations, and other inventive partitions to organize the business. Often, these divisions result from mergers and other reorganizing forces, leading to scattered legacy around technology, architecture, and a host of other important technical decisions.
When effective, they look across the portfolio of options within the organization and determine which ones work best, encouraging teams to use the optimal choices. However, the enterprise architect role often carries a negative connotation among the “beneficiaries” of their decisions, often stemming from their choice of the governance model. However, enlightened organizations have recently rethought the role of governance.
The definition of the word govern, the root of governance, has many facets, and many teams end up using the wrong connotation. One definition of govern includes:
All new web development should use the most recent version of Angular.
This is a mild case. I’ve seen a truly byzantine software stack (including application server, publishing framework, and industrial strength database) mandated for every project at one large organization until they realized they were over-engineering everything. The motivation for this approach often comes from a deeper motivation about business' attitude towards software: is it strategic or overhead? If the answer is overhead, then enterprise architects leverage a governance model to impose consistency and therefore save overhead cost. For example, if everyone standardizes on Java or ReactJS, then developers are fungible across projects, training and tooling becomes simpler, and the cost is generally lower.
However, the downside to the command-and-control model derives from a one-size-fits-all attitude about building software.
I once worked for a giant enterprise that mandated a standard technology stack dictated by the enterprise architecture team, consisting of an Oracle database, a publishing framework, several XML libraries, a heavyweight J2EE distributed object model, and a host of other complicated moving parts. I was helping their developers debug a problem that was crashing their application server. During the course of the conversation, a developer admitted that the seven users of the system didn't like it very much. "Seven users!?!" I exclaimed. "Well, it will eventually be as many as 25," he sheepishly admitted. To add insult to injury, the application merely queried the user about information across several forms and issued a project code—it could’ve been written by a high school student in PHP in a few of hours, yet this large enterprise had already spent hundreds of thousands of dollars… and couldn't get it to work. A pervasive problem with the "governance as cost savings" model is forced over-engineering.
Inadvertent overengineering is the natural side effect of a governance as control model. Let's say that an enterprise architect has the task of determining a single relational database for their enterprise standard. To perform due diligence, she should visit each team to determine the most challenging data problem, and choose a relational database that can accommodate them. Then, she must find the team that has the biggest reporting challenge, and choose a reporting solution that meets their needs. The same goes for integration architecture, messaging, NoSQL databases, and every other technology in the enterprise. However, the side effect is that now each team must deal with the maximally complex solution for every category. For example, for the relational database, the tool that can solve the most challenging problem imposes needless complexity on the teams that have mundane data storage and retrieval needs (which is likely more common). By forcing each team to standardize on a single tool in each category, an enterprise architect forces the maximum complexity in every category onto every team.
While cost savings is often a key goal of the governance as a control model, the unfortunate irony is that the cost of development and maintenance skyrockets due to over-engineering simple problems.
Many modern architectures, including lots of microservices projects, have adopted a different model, using governance as guidance.
The other definition of govern holds the better interpretation for modern software projects:
However, even disparate technology stacks need commonality around operational concerns such as deployment, monitoring, logging, and a host of other desirable coupling points. To that end, the microservices community has popularized service templates and service meshes to handle the operational coupling necessary for functioning software.
The microservices model is the opposite of the consolidation model from the command and control world. While it has advantages around isolating architectural concerns, it also flies in the face of traditional approaches. Many companies strike a happy medium in what we've named Goldilocks governance.
In our book Building Evolutionary Architectures, we named a governance model after the Goldilocks fairy tale because architects following it strive for the same outcome as the eponymous girl in the fairy tale: finding the "just right" level of guidance versus control.
Having a unique technology stack per development team creates a lot of overhead and little chance at reusing assets, team member skills, operational support, and a host of other headaches. Thus, enterprise architects at many large enterprises have adapted a more nuanced approach that splits the spectrum between the previous "one size fits all" model and the "wild west" microservices model.
In the Goldilocks Governance model, enterprise architects choose several suitable technology stacks and assess which one suits new project development best. For example, a company may decide on small, medium, and large supported technology stacks and steer projects towards them accordingly. That allows some interchange between projects for teams and technology while still trying to avoid imposed over-engineering.
Of course, the Goldilocks model doesn’t prevent determined enterprise architects from still imposing overly rigid control. However, it hopefully encourages them to think about the value of technology on a more local project level, resisting the urge of over homogenization at the enterprise level.
Regardless of which governance model enterprise architects use, most companies face a challenge on how to broadcast their findings; that's where the Thoughtworks Technology Radar comes in.
The Technology Radar provides a great mechanism to broadcast this information company-wide. When you use the Thoughtworks Build Your Own Technology Radar tool, it creates a website that features a hyperlink per blip, creating a great doorway to more information about this technology or technique. Because each blip is a link, we have seen teams build impressive resources behind links.
For example, let's say a company is experimenting with a Bob's Web Framework. Enterprise architects need to verify if this framework handles the kinds of common applications they need, supports operational constraints, plays nicely with existing technology choices like security, and a host of other considerations. They allow three teams to build applications using the new framework, documenting their progress under the relevant blip on their governance radar. When developers ask about Bob's Web Framework, they can point to the ongoing experiments and preliminary results broadcast via the radar.
Our ring categories partition the adoption model for technology, but enterprise architects can easily re-purpose them to indicate governance levels. For example, several of our clients have constructed a radar for governance, using the existing categories to indicate the following:
We have seen enterprise architects use the Trial ring to set WIP (Work in Process) limits for new experiments by various teams. That way, they allow organic experimentation at the team level with clear visibility to other teams and harvest the successful experiments for the Adopt ring.
Using the Radar, enterprise architects and others who shepherd technology choices can show others their current thinking. Rather than a document that broadcasts to the outside world what a company's choices are, this radar acts as living documentation for what's trending internally. Our clients who use this approach republish their governance radar on a regular cadence to ensure up to date information.
While enterprise architects undertake this kind of evaluation all the time, developers eventually affected by their decisions find the traditional process opaque. By creating an easy broadcast mechanism via the radar, enterprise architects offer transparency, along with the benefits that follow. For example, developers who have experience with some technology may interject their experiences, good or bad, into the conversation. Using the radar to highlight experiments turns a former ivory tower exercise among architects into a social collaboration between any interested parties, yielding a better diversity of opinion. We encourage enterprise architects using the radar as governance to facilitate discussion and transparency for their decision process.
The Thoughtworks Technology Radar metaphor allows many interpretations. The idea of using it as a governance model came from our clients, but we're encouraging others to utilize it for that purpose because we have seen it become an effective living document. Thus, enterprise architects should revisit this document on a regular cadence: we’ve seen the spectrum from weekly for some clients to quarterly for others work, depending on how much transparency and engagement they seek.
The birth of the Thoughtworks Technology Radar is documented in this article by Darren Smith. It started as an internal exercise to help us understand how our clients were adopting technology, and it seemed interesting enough to publish. Over the last few years, we've encouraged companies to use the same metaphor to build their own technology radar as a way of thinking more deeply about technology choices and trends within their organization. Towards that end, we've released a variety of open source tools to assist others in creating their own radar.
Increasingly, we see large companies utilizing the radar metaphor to solve a pervasive problem: how to effectively broadcast guidance decisions about technology to a widely dispersed group of engineers. Large enterprises commonly partition themselves into different divisions, departments, regions, locations, and other inventive partitions to organize the business. Often, these divisions result from mergers and other reorganizing forces, leading to scattered legacy around technology, architecture, and a host of other important technical decisions.
Enterprise architects must wrangle this diversity of technology and create a cohesive strategy.
When effective, they look across the portfolio of options within the organization and determine which ones work best, encouraging teams to use the optimal choices. However, the enterprise architect role often carries a negative connotation among the “beneficiaries” of their decisions, often stemming from their choice of the governance model. However, enlightened organizations have recently rethought the role of governance.
Three types of governance models
Enterprise architects are tasked with governance around technology choices, a term with unfortunate ambiguities. We see three different governance models active today.
Governance as control
The definition of the word govern, the root of governance, has many facets, and many teams end up using the wrong connotation. One definition of govern includes:
- to control, direct, or strongly influence the actions and conduct of
- to exert a determining or guiding influence in or over
- to hold in check
All new web development should use the most recent version of Angular.
This is a mild case. I’ve seen a truly byzantine software stack (including application server, publishing framework, and industrial strength database) mandated for every project at one large organization until they realized they were over-engineering everything. The motivation for this approach often comes from a deeper motivation about business' attitude towards software: is it strategic or overhead? If the answer is overhead, then enterprise architects leverage a governance model to impose consistency and therefore save overhead cost. For example, if everyone standardizes on Java or ReactJS, then developers are fungible across projects, training and tooling becomes simpler, and the cost is generally lower.
However, the downside to the command-and-control model derives from a one-size-fits-all attitude about building software.
Trying to use the same software stack for every problem inevitably leads to mismatches in need and value.
I once worked for a giant enterprise that mandated a standard technology stack dictated by the enterprise architecture team, consisting of an Oracle database, a publishing framework, several XML libraries, a heavyweight J2EE distributed object model, and a host of other complicated moving parts. I was helping their developers debug a problem that was crashing their application server. During the course of the conversation, a developer admitted that the seven users of the system didn't like it very much. "Seven users!?!" I exclaimed. "Well, it will eventually be as many as 25," he sheepishly admitted. To add insult to injury, the application merely queried the user about information across several forms and issued a project code—it could’ve been written by a high school student in PHP in a few of hours, yet this large enterprise had already spent hundreds of thousands of dollars… and couldn't get it to work. A pervasive problem with the "governance as cost savings" model is forced over-engineering.
Inadvertent overengineering is the natural side effect of a governance as control model. Let's say that an enterprise architect has the task of determining a single relational database for their enterprise standard. To perform due diligence, she should visit each team to determine the most challenging data problem, and choose a relational database that can accommodate them. Then, she must find the team that has the biggest reporting challenge, and choose a reporting solution that meets their needs. The same goes for integration architecture, messaging, NoSQL databases, and every other technology in the enterprise. However, the side effect is that now each team must deal with the maximally complex solution for every category. For example, for the relational database, the tool that can solve the most challenging problem imposes needless complexity on the teams that have mundane data storage and retrieval needs (which is likely more common). By forcing each team to standardize on a single tool in each category, an enterprise architect forces the maximum complexity in every category onto every team.
While cost savings is often a key goal of the governance as a control model, the unfortunate irony is that the cost of development and maintenance skyrockets due to over-engineering simple problems.
Many modern architectures, including lots of microservices projects, have adopted a different model, using governance as guidance.
Governance as guidance
The other definition of govern holds the better interpretation for modern software projects:
- to serve as a precedent or deciding principle for
However, even disparate technology stacks need commonality around operational concerns such as deployment, monitoring, logging, and a host of other desirable coupling points. To that end, the microservices community has popularized service templates and service meshes to handle the operational coupling necessary for functioning software.
The microservices model is the opposite of the consolidation model from the command and control world. While it has advantages around isolating architectural concerns, it also flies in the face of traditional approaches. Many companies strike a happy medium in what we've named Goldilocks governance.
Goldilocks governance
In our book Building Evolutionary Architectures, we named a governance model after the Goldilocks fairy tale because architects following it strive for the same outcome as the eponymous girl in the fairy tale: finding the "just right" level of guidance versus control.Having a unique technology stack per development team creates a lot of overhead and little chance at reusing assets, team member skills, operational support, and a host of other headaches. Thus, enterprise architects at many large enterprises have adapted a more nuanced approach that splits the spectrum between the previous "one size fits all" model and the "wild west" microservices model.
In the Goldilocks Governance model, enterprise architects choose several suitable technology stacks and assess which one suits new project development best. For example, a company may decide on small, medium, and large supported technology stacks and steer projects towards them accordingly. That allows some interchange between projects for teams and technology while still trying to avoid imposed over-engineering.
Of course, the Goldilocks model doesn’t prevent determined enterprise architects from still imposing overly rigid control. However, it hopefully encourages them to think about the value of technology on a more local project level, resisting the urge of over homogenization at the enterprise level.
Regardless of which governance model enterprise architects use, most companies face a challenge on how to broadcast their findings; that's where the Thoughtworks Technology Radar comes in.
Broadcasting governance
A correlation exists between company size and difficulty in communicating detailed information across it. Enterprise architects in large companies struggle with how to let developers know what works, what is untried, and what should be avoided.The Technology Radar provides a great mechanism to broadcast this information company-wide. When you use the Thoughtworks Build Your Own Technology Radar tool, it creates a website that features a hyperlink per blip, creating a great doorway to more information about this technology or technique. Because each blip is a link, we have seen teams build impressive resources behind links.
For example, let's say a company is experimenting with a Bob's Web Framework. Enterprise architects need to verify if this framework handles the kinds of common applications they need, supports operational constraints, plays nicely with existing technology choices like security, and a host of other considerations. They allow three teams to build applications using the new framework, documenting their progress under the relevant blip on their governance radar. When developers ask about Bob's Web Framework, they can point to the ongoing experiments and preliminary results broadcast via the radar.
Our ring categories partition the adoption model for technology, but enterprise architects can easily re-purpose them to indicate governance levels. For example, several of our clients have constructed a radar for governance, using the existing categories to indicate the following:
| Adopt | Technique or technology proven to work within this enterprise and is well supported |
| Trial | Promising tool or technique that we're experimenting with on one or more projects. Several of our clients include links to projects in the experiment so that readers can delve into more detail |
| Assess | Promising new tool or technique that enterprise architects are evaluating for potential experiments. This includes things under active research |
| Hold | Just as in the Thoughtworks Radar, hold doesn't mean "abandon immediately" but rather "don't start new projects using this". Hold indicates that the enterprise has deprecated this tool or technique, and offers better alternatives |
We have seen enterprise architects use the Trial ring to set WIP (Work in Process) limits for new experiments by various teams. That way, they allow organic experimentation at the team level with clear visibility to other teams and harvest the successful experiments for the Adopt ring.
Using the Radar, enterprise architects and others who shepherd technology choices can show others their current thinking. Rather than a document that broadcasts to the outside world what a company's choices are, this radar acts as living documentation for what's trending internally. Our clients who use this approach republish their governance radar on a regular cadence to ensure up to date information.
While enterprise architects undertake this kind of evaluation all the time, developers eventually affected by their decisions find the traditional process opaque. By creating an easy broadcast mechanism via the radar, enterprise architects offer transparency, along with the benefits that follow. For example, developers who have experience with some technology may interject their experiences, good or bad, into the conversation. Using the radar to highlight experiments turns a former ivory tower exercise among architects into a social collaboration between any interested parties, yielding a better diversity of opinion. We encourage enterprise architects using the radar as governance to facilitate discussion and transparency for their decision process.
The Thoughtworks Technology Radar metaphor allows many interpretations. The idea of using it as a governance model came from our clients, but we're encouraging others to utilize it for that purpose because we have seen it become an effective living document. Thus, enterprise architects should revisit this document on a regular cadence: we’ve seen the spectrum from weekly for some clients to quarterly for others work, depending on how much transparency and engagement they seek.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
