1.2 Boxes and arrows, oh my
When planning almost anything, architects draw diagrams. These diagrams are not just a tool but a powerful language that simplifies complex ideas, empowering you to navigate the intricate world of software architecture. They help you create several layers of abstraction, focusing on the software’s critical parts, identifying relationships and dependencies, and deciding how to assemble a complete system from separate components. This power is in your hands, giving you control over the complexity of software architecture.
You must also document your thought process for others to study and understand. After all, you are not the one doing all the building, and you want to ensure the others know what they are doing and why you made the technology decisions. You could write a lengthy novel, but a simple diagram usually relays the same information. A picture is worth a thousand words.
Just as in any form of communication, it’s crucial to consider your audience. In this case, your target group is typically project managers, IT managers, and software engineers, not necessarily other seasoned architects who are well-versed in different notations such as Archimate or UML. Everyone will judge your plan based on its understandability and the quality of your design choices. If you haven’t already, I recommend choosing a common language to ensure your message is clear and accessible to all.
The C4 Model, a modern, structured approach to creating architecture diagrams, is a beacon of clarity and consistency in describing and visualizing systems. It guides you through different areas of architecture with its four defined views: context, container, component, and code. The language of the C4 Model is simple enough to be learned fast yet powerful enough to convey the most important aspects of design. Let’s demonstrate C4 with a simple example, and you’ll see how it instills confidence in your design process.
Let’s consider a practical example to illustrate the application of software architecture principles. Imagine you have to design a system for tracking wildlife, specifically pigeons. You need an IoT device that attaches to pigeons, ensuring it doesn’t have any negative impact on the animals. Now, how do you get the information where it is needed? The tracking device connects automatically to open wifi when pigeons are near one and uploads the data. Then, you need a server-side that feeds all that data into the database. You also need a reporting tool to plot the routes and analyze where the pigeons have been.
On top of all that, since you are tracking billions of pigeons, there is a vast amount of data, and the local law requires you to store that information for 25 years; you need a cost-effective archival system for the data you don’t frequently need. Phew. You might end up with the following C4 Context diagram:
And boom! Just like that, you have defined the context. Without extra requirements for analytics, you are proposing a standard off-the-shelf software. Also, you defined a few key technologies, including the most critical interdependency of this system. We want to ensure the components are not using vendor-proprietary protocols so we can switch components at will as the system evolves. REST/JSON suits this, and PostgreSQL is also easily replaceable. We have done some architecture, and everything should be easy to explain to anyone who has to implement the system.
On the C4 Container diagram, we have drilled down to the context, showing the software architecture’s high-level shape and the components’ responsibilities. Please note that the same software ingests and archives the data, which is a significant design decision. The technology choices are further defined. If this system had user interfaces, a component would be responsible for them, but this system does not require one. The Power BI tool does that job just fine, at least for now. If one is needed later, the selected Ruby on Rails can implement UI effortlessly, which is a good prospect.
In real life, the architecture design has to pass checks. Does this architecture design implement, or at least support, our strategy? Does it adhere to the architectural principles? If it doesn’t, how can we improve the design? Remember, other architects, project managers, and managers are there to give you infinitely valuable feedback. All you have to do is to ask for it and go through your design with them. This process of seeking feedback is not a sign of weakness but a testament to your commitment to excellence. It’s a reassurance that you’re not alone in this process, and there’s a support system to guide you.
Two warnings must be shared, especially with new architects.
First, it’s crucial to remember that as an architect, you should never design anything you could not implement yourself. It’s tempting to see the latest technology and incorporate it into your design, but if you don’t understand how it works and the potential pitfalls, it’s not a good design. A good architect knows how to implement things hands-on, not because they have to, but because it’s essential to understand the practical aspects of the design. The labor division of an architect designing and others implementing creates more value than the architect trying to implement his plan. Also, as an architect, you are usually expected to advise the implementors when problems arise. You’re not much of an architect if your design is not implementable.
Second, complexity is your worst enemy. It’s frighteningly easy to conceive beautiful designs that will fill hundreds of slides worth of diagrams. The sad truth is that no one will be able to implement that. You have to take a look at the immediate requirements, estimate what parts of the design would benefit in the long term from agility, and complicate only that part of the design. The rest would serve only the architect’s hubris. If the previous definition leads, after careful consideration, to just one box on a diagram and an explanation, that is all it takes, then so be it. By avoiding unnecessary complexity, you can focus on what truly matters, relieving yourself from the burden of excessive design and staying on track with your goals.
After you have a sufficient architecture design, another issue arises. Projects become unnecessarily complicated if all requirements are mandatory and the development team has to implement everything simultaneously. While others typically focus on running projects, architects usually identify the significant tasks and development order. The key is understanding what features projects can implement later and whether you can split the implementation between teams or vendors. These items in the design make projects more manageable and much easier to commit to the master plan. A manageable project plan is essential for prioritizing tasks and managing the project effectively.
Returning to tracking pigeons, it makes sense to implement the data ingesting first and then move gradually to implementing analytics. Archiving can wait since there won’t be anything to archive for a while. The older data will be archived, and we will have new data in active use for a while. Also, Steve is good at implementing back-end stuff but not very good with analytics. Bob is the analytics guru, so they must cooperate on this one.
A real-life roadmap can have more activities grouped by common themes. The difference is that identifying themes, grouping stuff, and planning which order is correct involves countless considerations. The same principles, however, still apply. By the way, upper management typically loves roadmaps. They. Love. Roadmaps. It tells them you have thought the development process over and gives a sense that things are under control. Which they, of course, are, mainly thanks to your planning work.
Like architecture designs, you should always seek feedback on the roadmaps you plan. The first discussions will usually be informal to gather early feedback. Later, you will present a roadmap that is nearly ready in more formal settings to upper management levels and get their guidance. Iterate, iterate, iterate—as many times as necessary.
While doing all this, you will notice more opportunities and prospects outside your original task’s scope. Please don’t include them in your plans simply because they are great insights. You should document and manage the opportunities and prospects separately. If you decide to implement everything, you will end up with an unrealistic project. The yardstick should be “How this fits with the original need,” not “Is this a good feature.” While sometimes it makes sense to fine-tune the direction of the development, you want to spin off projects as much as possible.
Spin-off projects are more of the previous principle that doing things later makes projects much more straightforward to finalize. Several separate projects are far less risky than one mega project, which must be cut into smaller pieces in any case. Also, managers prefer to make separate decisions about opportunities and prospects. This offers a more controllable environment than an architect yee-hawing into the sunset after drafting a megalomaniac plan.
The key takeaway is that architects use architecture diagrams to plan and communicate the what and roadmaps to plan and communicate the when and who. Both require iterating over the needs with the help of all the available stakeholders. If done correctly, everything planned is implementable. The plans have to be suitable for the implementation project to have any chance of success! You should build a habit of asking constantly for feedback from your stakeholder groups while designing solutions.