To be a great software architect or developer, you definitely need to use your daily tools properly. But what are they? Which tools the successful architect should be masterly on. Also, it will help to understand the activities of architect doing in well organized software project.

Tickets

Tickets is your tool number one. To say the least, It’s even tool number one for each serious developer. As an architect, you must decompose tasks into tickets. They must be small enough (not more than 2 hours, I believe). And teach your team: “if you have a technical questions - please submit a ticket, don’t ask me in Telegram!”

SRS

Software Requirements Specification, or just a requirements, that your customer sends to you. You must create and maintain well-designed document including all the specs. And this is not easy. You should know all the rules, what to include, what to skip, etc. It must be simple, and understood by all the people connected to project. Read 10 Typical Mistakes in Specs by @yegor256.

Video about Requirements Engineering:

Diagrams

Explaining your thoughts and ideas to your team is what architect does in his routine. But text explanation is not the best tool when it comes to design or architecture. Here it comes to some modeling language, with standards, of course. The best one - Unified Modeling Language, or UML, for short. Thus, instead of writing the poems on “How our system actually works”, you will send a simple, properly organized, according to all standards, diagram to your developers.

Again, it must be simple. And I think that complexity is a key factor of a bad developer; I’m not even talking about the architect.

The best sources for learning UML, again the books!

Also, you should be aware of existing of Model Driven Architecture (MDA).

This video will help you:

Needless to say, good tools for modeling are Visual Paradigm and PlantUML. Despite UML having a quite large list of standards, you will probably use only few diagrams.

And the last one here. Please don’t use colors or any other attractive design elements. We are making those diagrams in order to be understood by others, not to impress people.

Code

Code style is very important. In order not to fail this one, we need to inspect the code as much as we can. But doing it manually, it’s quite hard, and mostly it is just another resource wasting. My advice to you is to automate your quality gate and code review process. The best tools for it: Static Analysis, Linters, and CI/CD pipelines.

Rightly configured quality gate will reject all not suitable changes automatically, assuming you have a read-only master branch.

Test Architecture

Each monkey can code the solution. But only a few people can build and maintain the elegant Test processes. I call it Test Architecture. It consists of:

  • Code Coverage
  • Load Testing Results
  • Testing of Non-Functional Requirements

Lets deep dive one by one. Code Coverage is totally base of your tests, as an architect you must “your” system, it’s coverage. Coverage must be collected and published.

Load Testing required primary for identifying system’s thresholds. You must know your system threshold. All the reports should be transparent and laying on your table.

Testing of Non-Functional Requirements can include many things. Speaking mostly for backend development: the main problem is thread safety.

My bottom line is that you must be a hands-on developer first, in order to be an architect. Simply without coding experience, mostly you will not be able to design your Test Architecture.

Release, Deployment Automation

Your software must be released and deployed automatically. And I don’t buy on your local scripts. We have large toolset on the market.

Remember, the good architect cares about the future of the product he’s creating.