There are many opinion about what software architect does, what skills are required and whether we need them or not. I’ve been in this role for a long time (20+ years), even before I’ve “acquired” the “official” title. I was lucky because a year after the graduation I’ve build the whole application – gathered requirements, architected, designed, coded, tested, operated the application as well as provided customer support. Since then most of my life I was building the complete application rather than working on its pieces here and there. And that’s how I’ve learned it at the first place.

First, let me be clear – I think that architect is required and important part of any software team or “part” of you if you are a MicroISV. And it doesn’t matter whether this person is called architect or engineer or he-knows-how-to or somehow else. There should be someone who knows how to build the whole building, not just superbly paint a single room.

So, some of my thoughts about the skills that good architect needs as well as pros and cons of this role.

Skills

Know how to do it yourself

I think that if you cannot sit down and write the whole application that you are designing yourself, there is a very slim chance that it will be designed properly, because when you design/architect an application, you actually write it in your head.

E2E knowledge

Architect has to know it end to end. From understanding how the business works to the work of customer support and everything in between (requirements, design, development, QA, operation). Without this knowledge it’s difficult to build application that will add value to its users, will be delivered on time, have a reasonable cost and will make the team happy. And this leads to the next required skill.

Side note: why did I put team happiness in this list? Long story short: in a long run happy team makes great product, unhappy team – crap.

Compromise

Meeting these requirements (value for the customers, time to market, cost and team happiness) during the whole lifecycle of the product is difficult.

• Should the product quality be sacrificed to ship it on time? 
• Should additional development effort be allocated to make a tool for operation team which will make operation easy? 
• Should some components be build in house or purchased?
• …..

Architect faces these questions every day. And the quality of the final product depends on his ability to find optimal solution – find a win-win path.

Keep it all in your head

You should be able to store the whole application in your head. You may not remember all the details, but overall layers, tiers, components, data and execution flow as well as storage design is a must. Application is a composition of multiple pieces (layers) and without seeing the “whole picture” it is difficult to build well balanced application. E.g.: design of particular database tables may be perfect from a DBA perspective, but will require a lot of unnecessary and badly performant code in data access and business layer.

Review code fast

High software quality is not only guaranties the happiness of your customers (functional quality), but also how fast you can deliver new features (structural quality). If your application has 0 bugs, but code is ugly and architecture resembles Winchester House, then there is no way you can add functionality fast. But how can you ensure high structural quality? Yes you can have all these static code analysis toolsin place and they help. Too some extend. But the only way to guaranty a high structural quality of your application is to review all the code. “I don’t have time to review all the code that is checked in?“. Yes you do. It takes 30 minutes to review regular check-ins of a 10 developers team. If you know how to do it right and if you teach your team to write good code (I’ll share my experience later). 

And don’t fool yourself – sooner or later you will review “that” code, because when it breaks one day badly or prevents your from adding a new functionality without total rework, you will have to review & clean it up. So, better do it daily when it’s easier to spot a small problem and fix it early.

BTW, if you know a better way to ensure high structural quality, please let me know.

(To be continued)