Anarchy in the IT (and how Architecture can help)

“Our IT systems are a mess! No one understands them. We do not have any documentation, and the vendors need a statement of work before answering any questions!”

Sound familiar? This situation seems to be growing increasingly common. How did it end up like this? And what can we do about it?

How Many Ways to Get What You Want?

Frustratingly, IT system anarchy is a frequent problem in many organisations. It is not something that happens overnight, and usually accumulates over a period of years where it is ignored until a severity 1 production incident takes out half the business and the only person who understood the big picture has long left.

The key thing to realise is that there is a point when capturing concerns in a risk register is no longer sufficient, and action needs to be taken (hopefully before the production sev 1).

How Can Architecture Help?

Architecture is not just about architecting IT solutions for projects. The role of architecture also extends into enterprise governance; defining transition and target states to match the business vision; ensuring compliance with the target state across the complete IT landscape; making sure architecture debt is captured; defining organisational principles; working with the business to identify new opportunities; selection of technology; and much more.

Know What You Have Got (Current State)

This may seem obvious, but many organisations lack an IT Asset Management tool (ITAM). Others may have implemented such a tool but spent most of the budget on implementation and licensing with minimal consideration to providing ongoing funding to improve governance, training and overall ITAM processes. This can lead to a false sense of ITAM with the tool being neglected when key IT changes are made. e.g. after a change is executed for an update, updating existing support and operation documents, diagrams, owners, configuration items, conduct yearly audit and clean ups.

Without a useful ITAM, organisations struggle to understand what systems they actually have, who owns them, who supports them, what infrastructure is being used, whether they’re backed up and can be recovered, what they’re paying for, and what their SLA’s are. Likewise, they also lack an understanding of interdependencies across systems which makes outages and upgrades a risky proposition.

Architecture can help here through defining the current state and how all systems relate to each other through integration and networking i.e. the “big picture”. Architecture can also help to identify gaps in the overall support model and areas where knowledge is lacking.

Roadmaps and Target State

Having a target state and roadmaps are vital to helping govern technology and to manage deviations from the target state. This is not solely owned by Architecture and architecture will take many inputs from the business, technology and executive when defining.

Many organisations will already have a vision of where they want their technology to be but lack specifics in the destination and how to get there. Often the vision has not been adequately communicated to all stakeholders leading to confusion or the impression that no vision exists. Architecture can help with this by defining the target state and how to reach that state.

One thing to be careful when defining transition and target states is the temptation to implement new systems in parallel with existing systems or implement something like a strangler fig pattern. Doing this may be easier in the short term and seemingly lower in risk but increases the likelihood of ending up with legacy systems and code that are never decommissioned and contribute to even greater complexity.

Similarly, projects that are running short on funding will find an excuse to descope the decommissioning of systems unless there is an immediate financial benefit to the organisation e.g. license fees, infrastructure costs. This leads to users continuing to use the old systems and the need for ongoing maintenance and associated technical and architecture debt. There’s also an increased security risk associated with systems not being adequately patched.

IT Principles

Having a set of technology principles can provide the organisation with a mechanism to control the type of IT being implemented. They can be used to enforce not only the type, but also ensure that the IT selected also adheres to organisational expectations with regards to applications, security, data, infrastructure etc. Architecture can help define these principles and ensure projects are adhering to them via the Architecture Review Board.

Architecture Review Board

Having the best technology principles, roadmaps and target states in the world are not going to be much use if they are being ignored. This is where architecture will help via the Architecture Review Board (ARB).

The concept is simple – the ARB reviews technology decisions/projects and ensures they have been assessed against principles, roadmaps, business strategy etc. to determine if they align to the organisational direction. The board is not purely just comprised of architects and must also contain representatives from the business, SMEs, and executives e.g. CIO, CTO.

The point of the ARB is not to be an obstacle to decision making. It’s there to give assurance to the project that there is alignment and provide wider visibility within the organisation which can also help to avoid duplication of effort and conflicting projects. The ARB should be pragmatic and ensure controls and conditions are put in place for when there is a misalignment e.g. capturing architecture debt or escalating if required. But receiving ARB approval should still form a critical step in the project lifecycle or technology decision making.

Architecture Debt Management

Many organisations talk about architecture and tech debt but do little in the way of managing it or minimising it. Frequently it is seen as something for technology to own. The problem with this approach is that there is very little incentive for the business to minimise architecture debt which can lead to decision making that only factors in short-term gains and cost minimisation.

If the organisation is not considering architecture debt, then the first step for architecture is to define what architecture debt is, why it’s important, and to raise visibility within the organisation.
The next step is probably the hardest and that is to put in place processes to capture and calculate the potential debt as well as have the debt owned and accounted for with appropriate KPI’s attributed to the business.

It is critical that a realistic plan is developed and adequately funded to tackle exiting debt (what, when, how, how much). The plan needs to be owned by both the architecture and product/business owner.

Funding

Budgets for vendors are getting increasingly larger while at the same time internal IT teams are being cut back and starved of funding. A lot of this is due to the funding model used by most organisations where funding is on a project basis and for ongoing vendor support. Expecting individual projects with tight project funding to also own and define the enterprise architecture is a recipe for failure that will only lead to a poorly designed technology landscape.

It is therefore critical for organisations to understand the importance of architecture outside of individual projects and the ongoing contributions made by an architecture team. At the same time, architecture teams need to be conscious of the value they add to the organisation and highlight their contributions. Architecture should not be seen as a costly obstacle but as a means to ensure quality and alignment.

How Can Solution Architects Help?

IT Anarchy is common. Getting it under control is not. Knowing where to start is key. Organisations conduct annual security audits and pen tests to make them feel they have adequate security but neglect architecture and strategy. SA can perform an architecture audit to identify potential areas for improvement.

As an organisation, SA is well versed in assisting companies with solving their architecture and technology problems. We have extensive experience in not only architecting solutions, but also in implementing architecture and leadership processes within organisation to help wrangle anarchic technology and guide organisations in bringing clarity to their technology. Coaching is also available from Solution Architects to internal architecture teams to uplift and drive good practice.