What kind of software architect are you? Strategist or tactician?

If there’s one term next to agile that’s so overloaded nobody knows what to expect, then it must be architect. Yes, you can specialize it by prefixing it with software, as in software architect. And with that, you would be able to determine that he or she is probably designing some kind software system. But you still wouldn’t be able to understand what that means exactly. You have solution architects, system architects and enterprise architects, and to make matters worse, you even have agile architects. And within that realm, you can also designate a seniority level. So, you could start as a junior software architect, then move on to become senior software architect, then become the lead architect and eventually end up being the chief architect. But nothing means less then somebody introducing himself as “I am the chief architect” without explaining what that means.

Also, many people think that being an architect is similar to being a project manager or some other organizational function. And some organizations still treat it as such, where being promoted from senior software developer to architect is the only way for a developer to get a pay raise. In contrast to that, you’ll see that organizations which embrace the agile principles treat an architect more as a role or responsibility that every experienced software developer should have.

So what kind of architect am I? Well, I’m definitely a software architect. You won’t see me designing buildings anytime soon. I also consider myself to be an agile architect. For me that means that I’ll try to avoid doing any big design upfront, and instead provide the teams with a high-level design that defines the major responsibilities and includes the architectural constraints that they have to work with. But I wasn’t always like that. I used to have a lot of trust issues delegating design tasks to teams and always insisted on reviewing every little decision. I don’t have to tell you that this is something nobody benefits from. It’s not a scalable approach and has cost me a lot of energy already. These days, we voluntarily ask for people to take on the sub-system owner role. They get involved in new design challenges and review certain aspects of the code base, all based on their personal skill or interests. It’s a much more scalable approach and allows me to do some real coding throughout the day (which I still love to do). Good architects should do some real coding. You simply can’t judge the feasibility of a design if you’re not actively using new technology or tried new programming languages yourself.

Another aspect you can use to characterize architects is how they approach their design process. Typically you’ll see them balance between taking tactical and strategic decisions. Until I read Jeremy D. Miller’s recent discussion on long-lived codebases, I didn’t realize this difference. In numerous occasions, I’ve been wondering whether my tendency to go for a pragmatic solution (especially where others choose a much more elaborate and complicated solution) is me being too naïve, or others ignoring the KISS and YAGNI principles. In my opinion, if a (potentially) wrong decision can be easily reverted at a later point in time (it has high reversibility), a quick decision is fine. As long as common sense is being used and no technical debt is being introduced. Only if a wrong decision would have widespread consequences, a more thorough analysis and/or spike is warranted. With that knowledge, you could say I’m more of a tactical architect. I’ve even grown an allergy for strategic architects, especially if they can’t keep themselves from that endless search for the perfect solution (which obviously doesn’t exist). On the other hand, I do realize I can learn a lot from them. So when the circumstances are there and a problem with a low reversibility needs to be solved, I won’t hesitate to get a strategic architect involved.

So what kind of architect are you? Let me know by commenting below or tweeting me at @ddoomen.