Previously, we saw the smells or the problems related to the architect's role. These legos represent one of them. They represent a lot of software architectures I see. Too many items and can't emphasize what's important. The reader and the implementers get equally confused by it. The meaning of software architecture is lost here. Let's start by defining what software architecture is. It is vital to establish this before we look further into the role of an architect. It may seem very basic, but there are many misinterpretations out there. Many systems are forced into universal architecture like this:
I have lost the count of how many times I have seen this as a picture of the architecture. Thankfully, at Headspring, we build a system in vertical slices. More on that later, but this picture doesn't give much information about the system. Let's see what the experts have to say.
Expert opinion on architecture
Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. - IEEE
The important aspect here is about relationships and evolutions than just blocks. Martin Fowler, on the other hand, emphasizes how spread out the knowledge needs to be.
Shared Understanding of the system - Martin Fowler
Ralph Johnson makes it a bit more practical and adds the time to the equation.
Things you wish to get right early in your system. - Ralph Johnson
The next one is one of my favorites. I saw it in Gregor Hohpe's book, 37 Things One Architect Knows About IT Transformation. Let's just stop reinventing the wheel is all that's about.
Design decisions about any system that keep implementors and maintainers from exercising needless creativity. - DSouza, Wills Objects, Components, and Frameworks in UML.
The Evolutionary Architecture book also talks about this. They measure the evolutionary nature of architecture with fitness functions. A fitness function is equivalent to a spec. How close we are to the spec. An evolutionary architecture consists of three primary aspects: incremental change, fitness functions, and appropriate coupling. In short, whatever makes the system easier to change.
Kent Beck brings the business into the mix. Can we have architecture without business input? I don't think so.
Architecture is a coherent story between business, development, and operations - Kent Beck
It also involves critical inputs from the business. It is not OK to ask the business folks to vacate the room when we talk about high-level design. Architecture, after all, is supposed to solve a business problem. If the business is not fully on board with the decisions being made in the name of architecture, the whole thing can fail.
I was once involved in a conversation about making synchronous calls asynchronous using messaging. A tech lead consistently questioned the presence of the product owner in those conversations. Instead of showing a spinning wheel to a user while the background operation is in progress, we wanted to say we received your intent, and we will get back to you when everything is ready. This is a big change in UX and hence a critical business decision. This is the Amazon purchase item experience. It is highly unlikely that this was built by Amazon without their business input.
My take
Essential characteristics and decisions which make the system easy to change make software architecture.
These decisions are nonobvious ones. In the universal architecture of BLL, DAL, and DB. Is it important to show those? What if it generated events out of that system? Yes, that will be more important to show than the three-tier nature of it. I would collapse those into just one box and show the events instead.
Another way to look at architecture is similar to a map. Imagine someone new has walked into a museum of your codebase. They need to know what they are looking at. Why is this here? What does it talk to? Where to go from here? How can they do some self-discovery without a meeting?
Good architecture makes this self-discovery easy. HATEOAS APIs include links about possible actions on a resource. They can figure out looking at your response object without going through extensive documentation or a day-long workshop. This is a crucial architectural decision about the HTTP APIs.
What is it not?
Architecture is not drawing endless pies in the sky. It is not just about the diagrams and pictures. We should not wait to write code until every architectural aspect is in place. A pie in the sky is very waterfall. However, jumping too soon without any decision can prove costly. You can always do quick tests and time-boxed experiments to validate crucial decisions. Making those decisions to set the direction is vital. For example, HATEOAS is a deliberate way of writing APIs. Try some specs out like CollectionJSON or Siren before you jump in. This is again the architectural choice you are making. It doesn’t have to involve a great design of every endpoint and how you are going to build that.
Capturing decisions is important, but it is also important to not let your favorite tools or tech completely take over your architecture. They become vendor focused and tend to be brittle. One time, I saw an architecture with more logos than ideas or decisions. Needless to say, that tech kool-aid job didn’t go too far.
Why?
Why should we care about architecture? I think this is a strange question. There is always an architecture to software systems. It just depends on how you let it happen. Completely upfront, completely accidental as you go, or something in the middle. We need to find a good balance.
For simpler systems, it may not matter, but as the complexity increases, it does matter a lot. If your app has a search feature and you keep using a relational database for that, the developers are going to face difficulties supporting state of the art search functionality. We can avoid a lot of wasted time and money by making a decision about a tool better suited for the job than the relational database. Thus good architecture removes the obstacles from the developer’s workflows.
It helps you avoid expensive mistakes. When you are in the weeds of implementation, the pressures of faster delivery are always mounting. With that, a chance of making the wrong choice on tool or technology is higher. Hastily jumping on to them and spending on license or support fees can prove very expensive in the long run. Trying to anticipate these decision points gives you a lot more breathing room.
Thoughtful architecture buys you a lot of flexibility. It helps deliver your software to the end-users faster. Does that sound familiar? Yep, it helps you achieve your agile methodology goals. When the change comes, you don’t have to turn everything upside down. Take events, for example. Event-driven systems rarely need to change when new consumers come online. They don’t care who consumes the events. If it is archived, thrown out, or successfully processed, it doesn’t matter. This is evolutionary architecture at its best.
Parting thoughts
To wrap up, architecture is not about pies in the sky. It is about important decisions. The decisions or compromises you have made to keep business moving forward. It doesn’t have to have all the details captured in one place. You can have multiple artifacts covering different aspects of the system. They need to serve a purpose. Whatever your team lands on for the definition, it needs to be well understood throughout the org to avoid a waste of time, money, and effort.
Comments