A couple of years ago, we were working hard on a distributed system with lots of microservices that did their jobs all over our business domain. Surprisingly, we managed to add new features without making a lot of mistakes or not letting each service get confused about what they were supposed to do.

How did we do it?

We had different teams, each responsible for a specific scope of our business. Each team looked after a set of these microservices, and they communicated with each other in different ways like event-driven architecture or API-based communication. We also created special SDKs for each team to make their business logic intact and encapsulated. These tools helped us keep our business knowledge safe and separate.

You would be amazed at how we made big decisions about how everything should work while still delivering our customers new features on time.

Why We Planned a Bi-weekly Architects Forum

Architects work together with the team to make important decisions when their responsible module/s changes affect the whole system or need to integrate or operate with module/s from other teams.

We believed architects needs to think ahead of time compared to the team’s timeline and facilitate to achieve overral architecture vision while delivering the teams’ OKRs.

Architects also to review recent developments in their modules and to plan for future topics related to the “next” and “later” stages. During these meeting, we discuss planned technical debts within the team and seek input from other architects (this also occurs in the tech lead forum). The goal is to proactively identify what’s coming next and assess its impact on the “next” and “later” phases of the architecture and product vision to maintain the agility of architecture.

We periodically review our architectural principles and assess any deviations from them. In such instances, we recommend that tech leads include plans for addressing technical debts in the next sprint planning with the product owner. The goal is to maintain the overall architecture and preserve the architecture vision.

Moreover, we avoid skipping the meetings with excuses like “there’s nothing specific to discuss regarding team progress.” Instead, we proactively engage in discussions about new technology suites, share experiences, and contribute to defining the next-level architecture. These conversations aim to align with the next and later stages that adhere to the product architecture.

How we made decisions

“We organized people around the value”– while preserving autonomous teams, Teams need to be organized around the flow of value to achieve the desired outcome.

The objective is to build a business case/s for potential shifts in strategy, Team scope/resources, and budget allocation. A simplified process for standardizing these particulars should include:

Problem Statement: This explains why the feature/issue is critical for the organization, originating from direct customer feedback or product owner insights. Product owners collaborate with UX designers to formulate business use cases, wireframes, and design flows.
Context: While engaged in UX design for product purposes, product owners hold discussions with the team of architects, representing various business-bounded context teams where applicable. This involves providing relevant background and problem details to the technical teams, such as time-to-market requirements or specific customer needs.
Solutions: Architects engage in technical discussions and propose different solutions, taking into account trade-offs like time-to-market, team efforts, integrations, and non-functional requirements (NFRs) such as scalability, reliability, and security. They also consider the product’s “now,” “next,” and “later” stages, as well as solutions tailored to meet specific customer needs.
Benefits: Architects, product owners, and delivery managers collectively assess each solution and make decisions based on what the organization stands to gain from the investment, considering product and feature aspects.
Risks: This section highlights the trade-offs and potential consequences of not taking action on this opportunity, whether it pertains to enhancing solution reliability or catering to specific customer requirements. Then planning for what are the future-proof placeholders of technical debts.

By considering the above points coming up with value flows for each responsible team and provide clear guidance to the team to produce their desired outcome.

Taking Responsibility

In the purpose of delivering exceptional value through our software architecture and feature development, the concept of value flows being assigned to feature delivery teams plays an important role and making their own decisions as autonomous teams.

This assignment ensures that all teams are not just working within their isolated environment but are synchronized in phase and collaboration levels. Such alignment is essential for product organizations, aiming to achieve a specific outcome.

However, achieving this alignment comes with its own set of challenges, including navigating through phases of uncertainty when things are not proceeding as smoothly as expected while agile advises us to proceed with uncertainty and we need to overcome it.
In complex environments, what will happen is unknown. — Scrum Guide 2020

Only what has already happened may be used for forward-looking decision making. — Scrum Guide 2020

Taking Responsibility is the most critical factor in delivering desired value. Architects, tech leads, and product owners are not just leaders in title but are the people ensuring that their teams remain focused, aligned, and motivated toward the common goal. They bear the responsibility of not only setting clear objectives but also enforcing the necessary actions to achieve these goals. This involves:

Clear Communication: Articulating the value flow and the importance of working in sync, ensuring that every team member understands the role they play in the broader vision.
Proactive Problem-Solving: Identifying potential roadblocks in advance and working collaboratively to address them before they impact the delivery.
Adaptability: Being open to change and leading by example when shifts in strategy or tactics are required.
Accountability: Holding themselves and their team members accountable for their contributions to the project. This includes celebrating successes and learning from setbacks.

By taking responsibility, our leaders established a culture of accountability, where each team member is empowered to contribute their best. This leadership approach ensures that, despite the inherent uncertainties in product development, our company remains on course to deliver as expected — or to adapt swiftly and smartly when the unexpected occurs.

Taking responsibility is not just about enforcing rules or deadlines. It’s about inspiring a collective effort towards achieving excellence, navigating through uncertainty with confidence, and ultimately, delivering a product that stands as a testimony to our collaborative spirit and commitment to our vision.

Thinking in Stages: “Now”, “Next”, and “Later” in Architectural Planning

An architectural approach that considers “now”, “next”, and “later” stages is essential for creating a resilient, scalable, and future-ready software system. It allows for a more strategic allocation of resources, better risk management, and the ability to adapt to changing business and technology landscapes. Why?

Scalability: Requires anticipating future load and designing systems that can grow. This might mean implementing more complex solutions now that will pay off as the system expands.
Reliability and Availability: Often demand redundant systems, comprehensive monitoring, and failover strategies, which might not align with the simplicity sought in KISS.
Security: Necessitates a layered approach and often complex solutions like encryption, authentication protocols, and secure data storage, which can add complexity contrary to KISS and YAGNI.

1. Adapting to Evolving Business Needs

Now: Addresses the immediate requirements, ensuring that the current needs of the business and users are met efficiently.
Next: Involves anticipating and planning for the near future. It’s about foreseeing upcoming changes or scaling needs that are not yet urgent but will become relevant soon.
Later: Consider long-term visions, which might be more hypothetical or subject to change as the market and technology evolve.

2. Managing Complexity and Risk

Focusing solely on “now” might lead to shortsighted decisions that don’t scale or adapt well to future needs, increasing technical debt.
Considering “next” helps in making informed choices that allow for smoother transitions and scaling when those needs arise.
Thinking about “later” ensures the architecture remains flexible and adaptable to long-term changes, but without over-committing resources or over-engineering for uncertain futures.

3. Balancing Cost, Time, and Resource Allocation

Immediate (“now”) requirements often demand more resources due to their urgency, but investing in “next” can reduce future costs and efforts.
By keeping placeholders for “later” stages, architects ensure the architecture can evolve without extensive rework, offering a cost-effective approach to long-term development.

4. Ensuring Scalability and Sustainability

By considering “next”, architects can design systems that are scalable and won’t require a complete overhaul as the product grows.
Placeholders for “later” stages allow for the integration of new technologies and methodologies, ensuring the architecture remains current and sustainable.

5. Facilitating Agile and Incremental Development

This staged approach aligns with agile methodologies, where the focus is on delivering value incrementally and adapting to change.
It allows for flexibility in responding to user feedback and market trends, enhancing the product’s relevance and competitiveness.

6. Encouraging Innovation and Future-proofing

Thinking beyond “now” opens up opportunities for innovation, as it allows architects to explore emerging technologies and trends.
It’s a way to future-proof the architecture, ensuring that it can accommodate new features, integrations, or shifts in business strategy.

Importance of At Least Thinking “Next” While Keeping Placeholders for “Later”

Prevents being short-sighted: By considering the “next” stage, architects avoid being trapped in a cycle of constant firefighting and quick fixes.
Facilitates Smooth Evolution: Planning for “next” makes it easier to integrate new features or scale the system without disruptive changes.
Enhances Flexibility: Placeholders for “later” ensure that the architecture is not too rigid, allowing for adaptability as new requirements or technologies emerge.
Optimizes Resource Utilization: It helps in allocating resources wisely, balancing between immediate needs and future growth.
Reduces Technical Debt: Proactive planning for “next” can significantly reduce technical debt, making the system more maintainable and less prone to issues. Tech debt is not an enemy, read more here: https://dilankam.medium.com/tech-debt-the-good-and-the-bad-329566cd69f8

Final Thought

Adopting a staged approach to architectural planning, with a focus on the “now,” “next,” and “later” stages, is important for building software systems that can bloom in an ever-evolving landscape. By carefully considering the immediate needs while considering future requirements, architects can manage a balance between addressing current challenges and preparing for tomorrow’s opportunities.

This strategic allocation of resources not only enhances scalability, reliability, and security but also encourages innovation and future-proofing. It empowers organizations to adapt to changing business dynamics while minimizing technical debt and ensuring the long-term sustainability of their software solutions.

So, when you initiate your next architectural journey, remember to think beyond the present, plan for what comes next, and keep the door open for the possibilities that come ahead.

Thinking in Stages: Planning for a Resilient Future