Over a million developers have joined DZone.

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.

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

As 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?

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

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.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}