What does it take to be an Architect Software Engineer, let's review Grady Boock definition about that:
Architecture represents the significant design decisions that shape a system, where significant is measured by the cost of change.
It’s a little bit poor that definition because it doesn’t give us enough information to understand in deep what is about being an Architect. So, Let’s take a look the Farley David definition of what is about being an Architect:
Must be an evolutionary process, we will guide the design of our system by modifying the constraints that we apply to that design. These constraints, or rules of the road, are what we think makes sense at any given point. This forms an important aspect of our architecture, we create a kind of tourist map of the system that we can use as a tool to guide design choices.
So, the architecture of our software is the collection of constraints, that we agree to adopt and maintain that will provide us some protection from making dumb mistakes.
It’s important that every developer should be part of the architecture discussions, allowing everyone to have their own understanding of the architecture, and contribute to it as development proceeds.
Other great two definitions of software architecture by Ralph Johnson are:
It’s the stuff that we wish we could get right at the start of a project.
It’s the shared understanding that the expert developers have of the system design
Let’s change a little bit first definition:
It’s A SNAPSHOT of the shared understanding that the expert developers have of the system design.
It’s probably the first time, we don’t get the right design, but what is really important is to maintain the freedom to get things wrong, and the ability to learn and recover from things wrong too. For that, we need the ability to contain the complexity and to manage it.
Fundamentally the architecture of our system is realized in the shapes that we make our code. Good Architecture allows us to isolate one part of the problem from another.
Let’s see more formal architectural quality like from ISO 25000:
The architect role has seen a bit of decline in recent years, this is mostly in response to agile development reaction against big upfront design, and that is quite problematic, as well describe Date Thomas,
Big up-front design is dumb! but No up-front design is dumber!
So, at some point, you need to start your project, you need to take several decisions, and these decisions will be part of making guesses, based on your understanding of the problem (the domain), and your experience. You should treat this guess as an experiment. The question is, how could guess that your guess is wrong? try that. So we should try to work in an incrementally way, which allows us to experiment as much as we can.
