Architects Don’t Decide
Architecture needs to blend in with the terrain and work with the environment. Many factors influence architectural decisions. We need to work with our survey teams. Here's a tale about why we shouldn't rush into those decisions.
Join the DZone community and get the full member experience.
Join For FreeAs pointed out in the article A Little Architecture from Robert C. Martin the job of the architect is not:
…to lead a team and make all the important decisions about databases and frameworks and web-servers and all that stuff.
It is to make these:
decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, the web server, and the frameworks.
As the article pointed out, juniors have many different views about the tasks that a senior developer does than the senior themselves. It is not only the subject of the decision, however. This is a bit more. Juniors see the position of an architect as a position of power. He has the right and the power to make decisions. Having that power is always good. You long to have the position of power, don’t you?
When you get into the position of being an architect, you realize that the power is not a privilege. It is a reponsibility. The system the team develops, the architecture, the network, hardware, and the operations are not a playground to satisfy your curiosity. It is a professional environment that works based on profit and loss, budget and costs, money, money, and money. The decision the architect makes should not be biased by the actual person’s interest. This is, by the way, a very common mistake. “Let’s use NoSQL because that is so fancy! We have to use big data!”
The actual decision should lead to a solution that meets availability, performance, reliability, scalability, manageability, and cost criteria. (By the way: the first six critera should be met, the last one should be at least met and minimized, but that is a different story.)
The actual decisions on the architecture and solutions (finally, when unavoidable, also about frameworks, databases, and other stuff) depends on many things. License structure, license cost, company culture, available developers, deadline/time to market, and architecture already in place to name a few. If you consider all the constraints you have to meet, you will not have too many choices. There will be compromises and finally you will end up with the only one selection that fits. That is going to be your decision.
Did you really make a decision?
Topics:
team collaboration,
software architects,
team management
Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments