This article was written in collaboration with Lukas Müller - Manager Solutions Architect at Amazon Web Services.

Misaligned development teams are your kryptonite in an organization full of superheroes. It is not about the latest cutting-edge framework – it is about our customers, our business, and how good and fast we can solve their problems. Werner Vogels introduced in his re:Invent keynote 2023 the fitting term of the frugal architect. Being frugal starts not with measuring costs but earlier. It starts with understanding the business.

In this article, we will describe that being a frugal architect is more than just designing and architecting technical solutions. Based on a fictional but typical scenario you will learn

• why defining business outcomes and understanding business value has to come first

• how a frugal architect uses feedback channels for technical and business decisions

A request from the CTO

Meet Samantha, the visionary CTO of a bustling tech company. Samantha's mind is always buzzing with ideas to drive innovation. One day, she contacted Alex, a talented Lead Engineer, through their Slack channel.

How can the story between Alex and Samantha continue? Let us explore two alternative realities. What if Alex acts wasteful? What if he acts frugal?

Let’s jump back into the matrix!

Alex, the wasteful architect

Alex proceeds headfirst with the data lake project without questioning its purpose or considering its potential impact on the company's business metrics. They gathered a team of five engineers and allocated a budget of $200,000 for the project. Over four months, the team built the infrastructure, including data storage, automated data processing, and a user-friendly interface.

All the allocated resources and budget are exhausted by the project, but the company does not witness any substantial benefits. Unaware of the potential benefits, the different teams neglected to fully use the new data infrastructure and stuck to their daily routines. The sales team still struggles with forecasting accuracy, and the marketing team continues to face difficulties in measuring campaign effectiveness. The overall impact on the company's growth and efficiency was marginal, and the potential value of the data solution remained largely untapped.

Once finished, all tasks in the team’s Kanban board are moved to "done". The project reached its end and everything turned back to business as usual. The data lake collects a lot of data without data consumer teams actively using the data in their day-to-day work and decision-making.

Observations:

1. Lack of clear objectives: The absence of clear objectives and a focus on customer problems and business outcomes led to a costly misadventure. Alex is happy by moving another task to “done” and feels comfortable in building what was requested: a data lake. Although numerous people congratulated Samantha at the release party, she was not able to measure and prove if and how the data lake helped to become a more data-driven company.

2. Missing customer-centricity: The project team missed collaborating with potential data consumer teams to understand their pain points and goals. Resulting in a data lake that is not actively used. Stakeholders are getting nervous as the initial budget of $200.000 was wasted. Additional OPEX costs will stress future budgeting to keep the data lake running.

3. Focus on output instead of outcome: Because of a lack of understanding of desired outcomes and goals, the project has become an expensive failure, eroding trust in future data-driven initiatives. So far, the only measurable impact is the waste of time, budget, and resources.

Alex, the frugal architect

Alex's approach to the data lake project takes on a different shape. He understands the importance of key performance indicators (KPIs) in driving success. Alex recognizes the need to lay a solid foundation aligned with business goals.

Alex organizes a workshop involving key stakeholders from sales, marketing, and finance teams. The purpose of this workshop is to gain a deep understanding of their pain points and goals. Receiving buy-in from everyone involved proves to be no easy task. Samantha initially seeks a quick solution, and some team members express skepticism and pushback on Alex's approach, demanding tangible results.

Alex recognizes the value of stakeholder buy-in and the importance of defining clear KPIs. Through a series of one-on-one meetings, Alex poses thought-provoking questions to stakeholders, such as

"Imagine you could measure everything: What would you measure?"

This gives invaluable insights into the perspectives and needs of stakeholders. It fosters a sense of understanding and collaboration, as Alex encourages them to define the metrics that matter most to their respective departments, emphasizing the need for clear, measurable goals to drive the project's success.

The stakeholders from sales, marketing, and finance teams collectively identify three important business outcomes:

• a 50% reduction in data retrieval time until the end of the year,

• a 30% improvement in marketing campaign analysis efficiency three months after launch, and

• a 90% accuracy rate for revenue trend predictions six months after launch.

Alex compiles a written summary outlining the potential benefits of a successful data lake implementation backed by the business. In addition, Alex conducts a "back on the napkin" cost-benefit analysis, clearly demonstrating that the six-month project, involving a core team of 12 people and an allocated budget of $300,000, will yield substantial returns through increased efficiency and tangible business outcomes.

With the CTO's approval and the limited budget secured, Alex proceeds to work closely with stakeholders. Single-threaded leaders are defined, and communication channels are established to share progress updates, gather feedback, and address blockers during the development process.

Observations:

1. Business Outcomes and KPIs as Proof of Success: The architect's focus on business outcomes and KPIs enables them to look beyond immediate tasks and foresee the impact of their work. By prioritizing the right goals, the business ensures that the project aligns with the broader objectives of the organization. By focusing on KPIs, we give control over technology decisions back to the business.

2. Involvement of stakeholders and iterative collaboration: The architect recognizes the value of involving stakeholders throughout the project. Iterating and learning from each other, fosters a sense of shared ownership and knowledge transfer, leading to a more successful outcome.

3. Understanding the role of delivering the right thing: The architect understands that the role goes beyond simply delivering a product or solution. Architects embrace the backbone of the project, unafraid to dive into the business context and support decision-making to support business goals and long-term success.

Conclusion

Being a frugal architect is about understanding business outcomes, speaking the language of business, building systems that evolve with business models, and aligning development efforts towards a common business goal.

This article emphasized the importance of business outcomes and understanding business value across all organizational sectors.

Defining clear goals and measurable KPIs helps development teams to make informed decisions. Be aware you will trigger fears just by discussing KPIs. Your best conversational skills, empathy, and the ability to connect with others will help to drive change.

We invite you to share your thoughts and experiences on this topic in the comment section below. How have you aligned your work with business goals? What strategies have you found effective in explaining the importance of business alignment to developers? Let's continue the conversation and learn from each other.

Now go build ... with purpose.