The many hats of a software architect

Recently, at a tech conference in the Netherlands, I had a discussion with some folks on what being a software architect really means. Some people see it as some kind of authority that makes all the decisions about what the architecture should look like and what technical guidelines should be used. Others treat them as the folks that draw PowerPoint pictures from their ivory towers. And the most negative developers see them as an impediment for any kind of creativity. This triggered me to try to capture the many hats a software architect must wear.

Be a tactician

Being an tactician is definitely the first thing that comes to mind. You need to protect the balance between the internal quality, pragmatism in solutions chosen and the pressure being put on the system by the business. And that balance can be different per code base and the phase that code base is in. For instance, something that’s still in development may live with a slightly lower quality than something that’s already in production. Especially when you’re working towards a Minimal Viable Product, the rules can be bend for a while, provided you catch up after that. But anything that’s in production, must live up to the highest standards.

Being pragmatic is also far from trivial. Developers love to build spaceships that to go to Mars, even though it’s fine to…