Stop overthinking it
You’re about to embark on a new project; the business has specified what it is they want, and now it’s up to you to build the thing. Often the business can’t articulate what it is they want, or they know the destination, but they can’t see how to get there. The technical team needs to get them to a better place than where they are right now. The working software over comprehensive documentation statement from the agile manifesto doesn’t really address the nuances of how most businesses are; but it leads us to an important point.
If you’re in an environment where there’s an enterprise architect who mandates what you’re doing and how you’re going to be doing it1; well then lucky you; you can blame them for the failure of your project. Sadly though, it failed long before that. We live in a world where the pace of technology forces changes on us at a quick rate; what’s new today, is old tomorrow, and deprecated the day after. If we find that we need to make a change, we have to have the skills and the discipline to do it.
As someone who has architect in their job title; I see the role as primarily advisory. I’m not the domain expert, or the language expert, so I shouldn’t be mandating the approach that we should take; the teams have to have the autonomy to choose the right tool for the job (so long as they can back it up). My job is to make sure that they have the support to make the best decision.
I have 5 questions that I generally ask:
- Why do we want to do this? - This might lead to other why questions, as we should dig down into whether the proposed solution is trying to fix a real problem.
- What’s the business’s definition of done? - if you don’t have a definition of done, then you can’t have working software.
- What’s the minimum we need to do to achieve done? - It needs to be flexible, so you can change direction, but you don’t want to be stuck in a situation where you don’t provide any value until late in the project lifecycle becaise you’ve over-engineered it in some utopian fashion.
- By doing this, will it be measurably better than it is now? - this leads us onto the next question
- How do we measure that improvement? - There isn’t a right or wrong answer here, what matters is that you think the question.
What should your architect be doing is a separate question… ↩︎