Architecture questions at year end: what to settle before 2015
A few questions about IT architecture worth asking yourself at the end of the year - not for a report, but so that 2015 starts without unnecessary baggage.
The end of the year is a convenient time for conversations about what works and what does not. Reports are written, budgets are approved or nearly so, teams are slightly calmer than usual. This is a good moment - not for a formal audit, but for a few honest questions about the technological foundation the company is carrying into the next year.
I am not proposing a large methodology. Just a few questions that, in my experience, are worth asking now.
What we built this year and what is actually being used
Most companies launch several IT initiatives during the year. That is normal. But by year end it is useful to answer honestly: of everything that was launched, what is genuinely being used? What has become a dusty shelf?
This is not a question of project success or failure - it is a question about how we make implementation decisions. If several systems over the year were deployed and did not take hold, that is a pattern worth understanding.
Which integrations have become bottlenecks
Systems do not exist in isolation. They exchange data, call each other, depend on each other. Over time these connections accumulate and become a source of fragility: one component goes down and pulls three others with it.
At year end it is useful to draw - or ask someone to draw - a map of the key integrations. Where are the most loaded points? Where is there no monitoring? Where has something regularly broken over the past year?
How we stand with data storage and history
Data that is not preserved does not exist for analytics. Data that is preserved unsystematically is accessible only to the people who happen to know where it lives.
A question worth asking: if tomorrow you needed to answer a question about what was happening in the business a year ago - where does the answer come from? From a system, or from a specific person's memory?
If the answer is "from memory" - that is a risk that grows every year and with every team change.
What we are planning for 2015 and what technically stands in the way
Business goals for next year are usually already articulated. It is useful to go through each one and ask: is there anything in the current architecture or infrastructure that will create friction when pursuing this goal?
This is not looking for reasons to do nothing. It is early risk identification while there is still time to address things before they become urgent.
Access and accounts
A year is a good reason for a review. Of everyone who left the company this year, who still has active access? Which service accounts and API keys are running but unused? Which systems have not required a password change since they were launched?
This takes half a day for one person. And it can save considerably more if something goes wrong.
One principle for next year
Year after year I notice one thing: companies that handle technological complexity well do it not through more sophisticated tools. They do it through consistent simplification wherever it is possible.
Adding a new tool is easier than removing an old one. Resisting an unnecessary integration is harder than building it. But that discipline is exactly what determines how manageable the architecture will be in two years.
Happy 2015.