Should you use a target state architecture or an architecture radar for your organization? In this post I’ll explain what each one is. I’ll then highlight the differences between them. Finally, I’ll provide my opinion on which one is better and why I think so.
Many organizations, once they get to a certain size, see the need to decide on a particular technology stack. And rightfully so, because a proliferation of various competing technologies leads leads to an organizational drain. IT people need to become conversant and in most cases proficient at JBoss, WebSphere, and WebLogic if all three of these application servers are used. It means the organization ends up going “wide and shallow” across these three instead of “narrow and deep” on just one. In other words, they don’t develop a deep level of expertise on one application server, making problems harder to solve.
Note that this applies to programming languages, databases, application frameworks, and the key libraries an organization uses. It can also apply to server operating systems, routers and other network infrastructure, firewalls, etc.
What is a Target State Architecture?
A Target State Architecture typically takes the form of a document, be it MS Word, or a page on the corporate wiki. Its purpose is to put a stick in the ground and say “these are the technologies we are going to use for our applications and infrastructure”. It goes on to specify the application server, programming language, the UI library, the dependency injection framework, etc. that the organization will use. It may or may not talk about the container technology to use, which really means whether or not they use Docker. Other sections of this document detail the process for making changes to the document, who approved it, and who the authority is behind the document.
What is an Architecture Radar?
An Architecture Radar is less prescriptive than a Target State Architecture because it provides a range of choices for each technology. it also provides some sort of ranking for each technology choice.
The classic example is ThoughtWorks’ Technology Radar. Here they take each of four broad categories or domains (Techniques, Platforms, Tools and Languages & Frameworks), and provide a level of recommendation for each item within those categories (Adopt, Trial, Assess, and Hold).
Organizations who decide on the radar approach have different names for their recommendations, for example Baseline, Target, Emerging, and Obsolete.
Similarly, you are not limited to the four domains that ThoughtWorks uses, nor are you limited to four domains. Whatever makes sense for your organization.
Differences Between The Two
The Target State Architecture is more of a prescriptive document that encompases all business units and all software teams. In essence it mandates the one item within each domain that we are going to adopt. Any others are not approved. If any do sneak in they need to go through some sort of approval process. It often ends up being a “one size fits all” document.
Furthermore, a Target State Architecture tries to predict the future by articulating the specific technologies that will best suit the organization. It’s essentially making a bet that the one item from each domain will be the best item going forward.
On the other hand, and Architecture Radar acknowledges the future is uncertain. It provides a number of items in each domain. It ranks each item by providing recommendations that reflect the organization’s confidence the item will best serve the organization.
Perhaps the most notable difference is an Architecture Radar provides teams with guidance. Ite helps them choose the appropriate item each domain. It allows them to choose from a predefined set of items based on their specific context.
Why an Architecture Radar is Better
So now dear reader you have come to the answer to the headline question. My opinion is an Architecture Radar is better. It provides teams with a degree of autonomy to choose the tool or technology that best suits their needs. At the same time, a Radar defines a set of guardrails by putting a rational limit on the choices within each domain. This helps reduce talent costs by limiting the number of skill sets an organization needs to have.
