On and off over the last few weeks I’ve been thinking about Elaine Wherry’s painful story of hiring developers. But the thing that triggers the whole tale is worth drawing out further:
In more obvious cases choosing a new programming language for a project can make it very difficult to maintain, and choosing a particular vendor for a subsystem means you have to be sure their product roadmap ties in with your plans. In less obvious cases particular architectures will determine which teams, departments or companies end up with responsibility for different aspects of your business systems.
I facilitated a conversation a while back in which several architecture options were presented to the key business stakeholder. I coached the architect to present the options in terms the business impact of each one: short term and long term cost, which functions would be easy or difficult to evolve as the business evolved, which offices would become responsible or be unable to take responsibility for which aspects, and so on. From that presentation it became abundantly clear to the business stakeholder which option was the right one for the way she saw the business evolving. She explained that immediately and succinctly to those present, and we all walked away knowing we had made the best decision. (And, yes, it did bear the test of time.)
Technical architecture decisions aren’t just about technical trade-offs. They’re about business options, too.