Technology addiction is dangerous.
I know what I’m talking about. I was an addict focusing on technology for technology, influenced by the engineering ecosystem I was in.
I then moved on, starting to ask longer questions.
The shift went from “Does it work?” to “Does it work for our business, today and tomorrow?” and “What’s the minimal solution?”.
We explored the key reasons to contain the technology entropy in “More Technology, More Problems”; this article focuses on the how.
This article shares how to build a technology radar for Quality at Speed streamlining your business, technology and organization.
Follow the QE Unit for more exclusive Quality Engineering from the community.
Start by acting the Quality Engineering way
The quickest solution would be to start cataloging all technologies in use. But minimal preparation makes the difference.
The following guidelines will get you off a right start:
- Use automation wherever possible to retrieve technologies in use;
- Be collaborative to build adhesion and obtain what’s out of scanners;
- Identify meta-data such as domain, functions and scope of deployment.
You can usually retrieve useful information in code repositories (e.g. Git) and deployment platforms (e.g. Gitlab, GitHub, Azure DevOps, etc).
Scanner solutions exist, but avoid adding another technology if you don’t have one.
Collaboration can be done sharing your initiative on the priorities planning, organizing a kick-off and following-up sync with stakeholders.
You can then move on building your technology radar.
Build your Quality Engineering technology portfolio
We can think of a technology portfolio as a mere list of technologies in use—but specific information provides you with a larger perspective.
Context is important for global and local decisions; a user interface technology is not the same concern for millions of end-users than for a few internal users.
Meta-datas are present in the QE version to answer the “Why”, “What” and the “Who”. Access it here.
These columns are part of the Quality Engineering technology radar:
- Why (mandatory)
- Functional domain, ideally in Domain-Driven Design (DDD);
- Functions provided by the specific technology;
- Impact from “minor” to “business-critical”;
- What (mandatory)
- Technology category;
- Technology name;
- Current Status that can be “Adopt”, “Trial”, “Assess”, “Hold”;
- QE Score ranked in descending value from the next three fields;
- Quality assessing the contribution to fulfill the requirements;
- Speed assessing the capacity to provide speed and evolution;
- Complexity in delivering and maintaining the technology;
- How (optional)
- Quarterly status specifying the status with a 2-3 year picture ideally;
- Technology versions with in-use & last major available;
- Deployment scope ranging from “1 application” to “global”;
- Support in charge of the operations, to identify managed ones;
- Owner in charge of the application service, no team name;
- Description to set a brief description of the technology;
- Documentation page link for more details;
- IsNew flag to identify recent, compatible with ThoughtWorks 😉
The Why columns can be filled with a general domain on the start. Over-time, you can refine the functions and impacts when splitting them up.
These first columns per technology can duplicate some lines. You may think “let’s refactor removing unnecessary columns”—please don’t.
These fields are useful in getting the usage of technology in context to constantly keep the global and local perspective for better decision-making.
If you lack time, focus on the first two blocks, “Why” and “What”.
Additional data enables more choices
These additional datas gives you a precise vision of technologies footprint at the global and local levels.
You can concretly make decisions in context:
- Domains enable to visualize technology per and across ecosystems;
- Functions let you identify duplicate technology per function;
- Scope & impact set a factual context of the deployment footprint;
- Status over-time gives you the historical and forecast picture;
- Owner clarifies who to contact and should maintain the documentation.
It is now time to leverage the collaboration set in the first stage to accelerate the filling of the document.
I strongly recommend you to perform data quality controls during that phase:
- Verify that all functional domains are represented;
- Check the list of functions for any main one missing;
- Evaluate the equilibrium of low vs mission-critical technology;
- Define technology owner for the lines missing this information.
Then, you can start making decisions.
Make Quality Engineering decisions on technology
Technology rationalization is about removing unnecessary complexity and streamlining processes—not about cutting costs or reducing headcount.
The process aims to make your organization progressing toward Quality at Speed with minimal Complexity, even if you may find financial optimizations.
The Quality Engineering process uses questions on business, technology, and organization to find appropriate solutions in your context.
The decision to implement a new technology requires good questioning. In any case, your burning Quality Engineering question is:
“Which minimal technology can improve Quality, Speed with less Complexity?”
—Antoine Craske, Building A Tech Radar With Quality Engineering
You can use the following questions to structure your reasoning.
Quality
- What are the most important functions per domains, why?
- Which functions are lacking the most Quality? Why? What can we do?
- Which functions are not covered by an “Adopt” technology?
- Which mature technologies could best support functions tomorrow?
- Which technologies to adopt, assess, hold & trial in the next year?
Speed
- Which technologies have less speed on which domains and functions?
- Do we have “Adopt” technology with a limiting speed?
- Which technology with Quality is lacking Speed? Can we improve?
- Which critical functions are lacking an “Adopt” technology?
- Can we consolidate technology supporting the same function?
Complexity
- What are the least deployed and important technology to clean?
- Are we up-to-date on our most critical and “Adopt” technologies?
- Which technologies could be removed in “Trial”, “Assess”, and “Hold”?
- What are the technologies not well supported by our organization?
- Which technologies should we stop supporting, or move to managed?
This exercise will give you redundant information about technology choices that you need to use to update the portfolio by:
- Adding the missing functions and new technologies identified;
- Filling the column Quarterly Status for the next 12 months;
You then need to make the plan a reality.
Build an ecosystem to contain technology entropy
More than the next 3 months, you need to create an ecosystem that will contain technology entropy over time.
Building a technology governance enables you to drive the implementation and continuously adapt to the reality.
You can reuse the initial guidelines of collaboration, automation & meta-data to organize your governance.
We different three levels of synchronization:
- Asynchronous for people to suggest update of technology;
- Operational sync to prepare the most important evolution;
- Steering sync with decision-makers to align the proposed scenarios.
The exercise can be performed every 4 to 12 weeks depending on your organization size, complexity and change rate.
Done right, you built a technology authority.
Quality Engineering streamlining technology authority
Technology is at the heart of digital businesses. Mastering its portfolio is a requirement to keep iterating with Quality at Speed.
This technology radar process maintains focus by continuously measuring the outputs of technology with the business outcomes.
The organizational perspective then cascades from the business and technology opportunities identified, considering your execution capability.
This is the Quality Engineering way of constraining software to continuous value delivery—containing entropy and fashion to settle in.
So, ready for your Quality Engineering tech radar?
Follow the QE Unit for more exclusive Quality Engineering from the community.
This work is available under the following license: attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)