I often dive deep into research on a topic when an idea resonates with me. I might read a paper, an article, or find something in a book. What starts as curiosity becomes a full-fledged exploration. I read broadly across science, psychology, and sociology, always seeking the connections between disciplines and outcomes.
During one of my executive classes at the Wharton CTO program, I came across the concept of activity system mapping. That framework sparked a cascade of insights. It helped me reframe a long-standing question: how can technologists, particularly lead engineers, software architects, and CTOs, quantify and increase their impact on the business?
Gregor Hope’s “Software Architect Elevator” defines the three-legged stool of software architecture: skill, impact, and leadership. For many technologists, “impact” is the hardest leg to build because we are accustomed to recognition for technical excellence and rarely for business results.
The impact of software architecture is measured by the benefit achieved for the business, typically through increased revenue, reduced costs, faster time to market, competitive advantage, or the ability to respond quickly to changing customer needs. These are the hallmarks of a strong architecture.
So, how do you ensure your work drives business value? According to Michael Porter, strategic impact stems from five pillars:
- Increasing revenue,
- Building desirable and profitable products,
- Reducing costs to serve,
- Enabling scale,
- Establishing competitive differentiation
These pillars are rooted in Michael Porter’s work on competition and strategy. Crucially, you don’t achieve them by mimicking competitors. Strategy is about making deliberate choices to be effective and different.
One exercise I now recommend to teams is mapping their day-to-day technical work to business value. If you are working on an established and successful product, list the top 3-5 reasons your customers are buying it and staying with it. If it is an emerging offering, list 3-5 reasons why you think your customers will buy it. Then, add 2 more: increasing revenue and lowering costs for your enterprise. Place these items into the center of your diagram: they are your strategic priorities.
Critically, technical activities are never a strategic priority. For example, “API-first” is not a strategic priority — it is an activity serving the purpose of a strategic priority. But enabling a platform strategy where external partners build on your APIs to expand your ecosystem and moat is. Strategy translates technical activities into business leverage.
From there, list all your daily activities – features, experiments, and processes. Then, map connections between them and to strategic priorities. You’ll quickly see which activities drive value, which is disconnected/orphaned, and where your architecture does not align with strategy.
Done well, this map becomes a compass. It clarifies where to invest energy and where to pivot. It’s also not static. I recommend doing it monthly or quarterly, including your team and executive leadership.
Software architecture isn’t just about choosing the right patterns or writing clean code. It is about making deliberate choices that move the business forward. By mapping your activities to strategic priorities, you start seeing architecture not as isolated technical work but as a value delivery system. You’ll also begin to notice which activities generate traction and which are just consuming cycles.
The Dulin Report 