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:

Our homegrown JavaScript framework edged us over competitors but maintaining our technical advantage meant carefully crafting a lean, delta-force Web team. Though I averaged two interviews a day, we had only grown the team by three-four engineers each year. [But…] To meet our 2010 goals, I needed to double the JavaScript team in just one quarter. If I didn’t, innovation would stall and without revenue, our business would be in serious jeopardy.

This hints at something that’s often overlooked by most people in digital operations, other than a few senior technical people: your technical architecture dictates how effectively you can execute your business strategy. In Elaine’s case the decision to create their own Javascript framework put their business plan at risk, because it made it too difficult to hire suitable developers.

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.