Part II: The Software Architect's Toolbox

In the first part of this series, Navigating the First Days as a Software Architect, I described the importance of identifying your stakeholders, talking to them, and collecting as much information as possible. It’s time to process that information and determine which tools can help you face the challenges.

Processing the interviews’ output

You’ll have a nice set of sticky notes with valuable information if you use the Miro template I shared in the first article or any other tool of your (or your organization’s) preference. Then, you can identify and extract some of the challenges ahead using this information.

Suppose the interviews went well, and you could summarize generic ideas. Those challenges are most likely in the first two rows: “Their expectations & your responsibility” and “Tangible result for short and long term.” In my example (see the picture above or the template), these challenges are items like:

• Help figure out solutions for new features or challenges
• Change the system technically to enable new business case offerings
• Build bridges across departments
• Get rid of technical debt
• Communicate the technical needs of the platform in a language everyone understands
• Coach, influence, and guide engineers so we can achieve our organization’s goals
• etc.

If the notes are insufficient to distill the challenges, you can create new notes that summarize them in one-liners and place them next to the originals.

Tackling the challenges: The Architect’s Toolbox

Tools are powerful ways to improve and make any task easier: hammer drills, blenders, pressure washers, etc. In software development, many tools are available: IDEs, CI/CD frameworks and solutions, code repositories, AI-powered co-pilots, etc. For product or project management, there are also lots of them: Basecamp, Airfocus, Asana, MS Project, etc. Many of these product and software development tools have embedded ways to follow specific methodologies or processes: Agile (e.g., Scrum/Kanban), MVP, DevOps…

People use these tools daily, and they give them structure and guidance on how to do their jobs. Using their toolbox, they can focus on creating value.

But what about software architecture? What tools help people map product and business ideas into a software solution? Note: I won’t be able to explain in this article why you need those tools and software architecture as a different concern of your organization; that’s for a separate blog post. I assume you already understood that you need a step between defining the product requirements and jumping into coding, no matter who does that in the organization.

Let me summarize what I discovered in the wild world of software architecture.

Solution-oriented tools

These are buzzwords such as Domain-Driven Design, Microservice Architecture, Event-Driven Architecture, Hexagonal Architecture, Clean Architecture, Blockchain Architecture, Service Mesh, ServiceBus (what!), etc.

Let’s be clear: these are not tools to structure and guide your work but rather ways to solve a problem. You may already know how valuable these tools are, so I’ll tell you how they can harm you:

• They won’t help you understand the problem you need to solve
• They assume you need them, but sometimes you don’t (e.g., “microservices are the way to go”)
• They’re sometimes marketed as the only solution (“we can move to the cloud using X”)
• They’re also a solution looking for a problem (“should we consider Blockchain, perhaps?”)

Documentation-oriented tools

The most popular in this category is the C4 model. Others in this category include ArchiMate, Architectural Decision Records (ADRs), UML (Class, Sequence, Component, Deployment, etc. diagrams), etc.

These are tools to capture architectural knowledge and decisions. They’re meant to provide a structure for documenting software, from high-level to detail. By nature, they’re static and mostly output-oriented. Some people may find them valuable to design new features, but they rely on the assumption that you have all the information and clarity needed to describe that software solution you already have.

Again, these aren’t tools that help you build software architecture; they’re only meant to capture the output.

Enterprise-heavy frameworks

These work fine for organizations that use them and the consultants that go with them. TOGAF, Zachman Framework, FEA, and many more are the names of some of these Enterprise Architecture frameworks.

You’d better have a central architecture department that defines the whole plan beforehand if you want to work with these, or you can hire the big consulting sharks to do it for you.

The REAL Software Architect’s Toolbox

After ten years of experience, I can confidently share my toolbox as a software architect. There are 14 tools here. Even if there are tons of articles about some of them, I’ll share my view, considering those challenges we want to tackle:

1. Stakeholder Interview - Your main channel to understand expectations and create relationships
2. Exploring Organization’s Goals - Understanding the business context and priorities
3. System Overview - High-level view of the current system architecture
4. Creating Architecture Vision - Defining where we want to go architecturally
5. Architecture Roadmap - Planning the evolution of the system over time
6. Architecture Kanban - Tracking architecture work and initiatives
7. Architecture Forum - Regular meetings to discuss architecture topics
8. Decision Records - Documenting important architecture decisions (ADRs)
9. Update Channels - Communication channels to share architecture updates
10. Regular Syncs - One-on-one meetings with key stakeholders
11. Design Sessions - Collaborative workshops to solve specific problems
12. Documentation Structure - Organized way to maintain architecture documentation
13. Decentralizing Architecture - Empowering teams to make architecture decisions
14. Architecture Community - Building a community of practice around architecture

Each of these tools serves a specific purpose in the architect’s daily work, from understanding the problem space to facilitating solutions and ensuring alignment across the organization.

The value of collaborative architecture

The key insight is that software architecture isn’t about imposing solutions from an ivory tower. It’s about:

• Facilitating conversations between business and technical teams
• Creating shared understanding of system capabilities and constraints
• Empowering teams to make informed decisions
• Building bridges across organizational silos
• Documenting decisions for future reference

These tools help you achieve these goals while maintaining transparency and building trust with your stakeholders.

Getting started with your toolbox

You don’t need to implement all 14 tools at once. Start with:

1. Stakeholder interviews to understand the landscape
2. System overview to document the current state
3. Architecture forum to create a regular touchpoint
4. Decision records to capture important choices

As you build trust and demonstrate value, you can gradually introduce more tools based on your organization’s specific needs.

Conclusion

The Software Architect’s Toolbox isn’t about technical solutions or documentation formats. It’s about creating structures and processes that enable effective architecture work. These tools help you:

• Understand problems before jumping to solutions
• Facilitate productive conversations
• Build consensus and alignment
• Document decisions transparently
• Empower teams to contribute

In the next part of this series, we’ll dive deeper into understanding your organization’s goals and how to align architecture work with business objectives.

Remember: the best architecture emerges from collaboration, not isolation. Use these tools to build bridges, not walls.