Systems Architecture - do it, there is no try...

In my work I often get asked 'Why should we specifically invest in Systems Architecture?' Now, to me this is obvious, but to those not versed in the ways of the Systems Architecture Jedi it is a question which is very valid indeed... (resist Yoda speak, I must...).

There are several keys reasons that underpin why you should invest in Systems Architecture and I will detail these below.

Investing in Systems Architecture can save money

Systems Architecture is at its core about forward planning and setting up your systems in such a way that the cost of responding to change over time is a known and hence can be managed and minimised where required.

Without a unifying 'view' on your system architecture you can quickly fall into a trap I call 'reactive development' or project by project development - in effect everything gets developed in its own little bubble, with its own distinct view as to how it needs to interface with other systems and what it believes to be its responsibilities.

The dangers here are numerous:

• Duplicate functionality - a waste of money, time and effort.
• Due to duplication a 'shattered' data model - rather than the data being kept together its now split between at least 2 systems. Why do I say at least 2 systems? Think of what other systems are talking to just one system or the other, they now contain 'split' data as well (it's data turtles all the way down...).
• Technical spaghetti - no incentive to keep to common technologies or methodologies. This results in 'snowflake solutions' that use their own distinct mix of technologies to deliver a solution. (Note: I have nothing against new tech, just as long as its a planned decision to use, do not go in blind).
• Ility Speed Bumps - or put another way trying to get consistent cross system treatment to scalability, security, internationalisation, PII, etc becomes that much harder.

Although by far the biggest risk is not actually solving the problem the system was developed for, remember problems rarely stay still for long, they have a nasty habit of mutating or multiplying on you. The dangers above can conspire to make this outcome come about, as you consume resources trying to get out of the mire...

All of these failures in design can multiply to incur an insidious extra cost or delay, this won't show up on a spreadsheet in accounts, it will just be distributed as a hidden cost across everything.

Conversely, proper system architecture guards against these problems and puts a lid on cost blowouts, hidden or not.

Systems Architecture improves Design visibility

Something I keep referring to is what I term people’s ‘radars’ or rather how much they are aware of the technical space around them. Some people have time to watch their radars and get a good understanding of the technical landscape they operate it, but this is often not the case, most people are busy dealing with their own issues and problems and have little time to mentally pop their heads up and have a good old look around.

This leads to a sort of unconscious mental filter as to what matters or what does not, literally what is not in mind is not considered. For those developing any system this is dangerous as it leads to what I term ‘lowest common denominator design’; i.e. people design based on their immediate knowledge or visibility and they do not look outwards as to other solutions; things end up sort of cobbled together…

The problem here is you end up with an enforced feedback loop that is very resistive to real change; people literally cannot see what is right in front of their noses. Change becomes something to do the least to deal with; everything is a fix or a tweak and you end with the system equivalent of a big ball of gunk...

Now if proper systems architecture is done, it can open people’s eyes to the wider world and increase the coverage of their own radar without extra effort. This also means that change becomes something that can be dealt with as a large co-ordinated group, it ‘defangs’ change. It also means you get more leverage in your solutions, you create a solution which is more resistant to the negative aspects of change; and if done right this can actually be accumulative.

Systems Architecture improves Security

In these days when systems are getting breached on a daily basis, having a unified understanding of how your systems interact and exchange data is key to keeping them secure. A proper architecture road map allows you to put in place the security controls as part of the design process.

It's easier to get buy in with a plan!

A common situation with developing systems is that the decision makers on the resources for a project are often not versed in the finer technical points of why one way is better than other, or why JavaScript is better than Java, etc. They care most about a few specific things, namely:

• Does it actually solve the problem we are facing?
• How long will it take?
• What do we need to do it?

A good set of Systems Architecture Documentation can go a long way to helping answer these questions in a way which is explainable and evident. Such documentation can often act as a bridge between the technical and none technical worlds in a business and help each side better understand the other - making it that much easier to get the magical 'buy-in' to make a project fly without it's wings being clipped.

In conclusion

To me some of the reasons above are aspects of what I term as 'Architecture Debt' - or the act of deliberately not investing in your system architecture. This is distinct to 'Technical Debt' - which is choosing not to do something Good within a system, the Architecture Debt exists on a higher plane between systems - its the real technical Dark Side... and like Technical Debt it can over time bring your business to its knees if you are not careful.

If you want help with your systems architecture and how to get it right to deal with change. Please get in touch.

More of my articles on software & systems architecture

#security #architecture #privacy #cyber