Elegies in rough shuttered concrete – how to avoid monstrous carbuncles of enterprise architecture

Nobody wants their firm’s enterprise architecture to be the equivalent of an underused, over large concrete bus station in the wrong place. Read on from some top tips.

Focus on the real world business need

Your revisions to your enterprise architecture may be coherent, detailed and maybe even beautiful in a geeky sort of way but it’s of no use unless it’s focused on what the business needs. That’s business needs not wants.

Before even you begin revising your enterprise architecture start making a list of use cases and then grade them as to what has the most benefit. Grade them again for relevancy. Grade them again for effort. Grade them again for risk. Be critical and challenge the right of an item to be on the list and its gradings. For example, if you’re having trouble with on premise/off premise client matter integration then think through what’s causing this and if it’s actually an architecture problem rather than a user, application or platform problem.

Sadly this is not a one off exercise or even a periodic exercise, it is a continuous process. User use cases will never stop, change will be the only constant, there will be no completion, no perfection, enterprise architecture revisions are like a Forth bridge and at any point in time a ship of Theseus.

Give your customer the illusion of progress

Having aligned your user use cases into business needs, the next step is to entertain your captive audience with updates.

• Amuse them with what changes they’ll see and how it will impact how they do things.

• Delight them with the irritations you’ll remove and the new features you’ll introduce

• Reassure them that you are not moving their cheese and you are not going to force them to think.

• Open up the floor for discussion of future use cases or possible use case changes.

In other words communicate or, if you’re management, delegate the communication.

Goal Congruence, herd those cats, get all the noses pointing in the same direction

If your customers and users feel that you are not addressing a business challenge adequately, then they won’t complain, they won’t even moan to colleagues in the next organisational silo. They’re not stupid and despite what you may think, the IT department does not have monopolies on talent, originality and common sense.

If the unaddressed business challenge or need is annoying enough then each silo will develop its own unique solution to the problem, given a degree of discretionary budget which they will have sand-bagged in each year. This behaviour is sub-optimal and has the following drawbacks:

• It preserves and entrenches silo mentality in that the silo becomes a bunker.

• Each excess overlapping unique solution to the same problem is redundant and most likely inefficient.

• Each silo solution will imperfectly align to the original firm need.

• Each silo solution will be a road block on the highway to an enterprise solution.

• Because each silo solution was developed with a lack of visibility of both the whole problem, any gaps and any other silo solutions there that silent individual business unit budget cost.

Encourage cross working seminars where folk can discuss their “non IT” working practices and share all the applications, websites and process that have not been supplied or used as standard. Don’t let them forget to include all those VBA and "spread-marts" too. Take notes and use these as a use case candidates for your next architecture iteration.

Business first, flexibility second, technology last.

As technologists we tend to think it terms of “What can be built with this tool?” As architects we are designing that which the business needs. As pragmatists we know those needs will change and the pace of change will accelerate.

When looking at enterprise architecture it is tempting to be technology centric and view all the business needs as nails and the solution is therefore is lots of hammers because we happen to have a lot of hammers and we are very familiar and skilled with bashing things with them. However if the pandemic years have taught us anything it is that alignment and adaption means surviving and thriving. So nowadays, we chose the tools based on the job and we don’t bend the job to fit the tools.

Eyes to the future

Ideally your firm will grow and you want your enterprise architecture to grow with it. If you fail to anticipate future growth requirements then your enterprise architecture will fail too. Design your road map based on what’s in 3D not 1D. Your road map should take you to decision points with potential branches or continuations where you chose to scale up, scale out, continue or reassess. Your road map should not be a linear progression. Plan for change, plan for performance, plan for scale and plan for efficiency. Open architecture is a constant friend in every ever changing technology space even with a plan. Always keep that friend close.

Security is Job Zero

This does not mean that your job security should be your first concern. However, thinking of enterprise architecture security at the outset will give you more job security! Think of security as front and centre (and sides, top, bottom and core). Build everything on top of security. Storage Security, Access Security, Transport Security and Application Security.

A security breach is a risk and just like any risk you can conceptualise it and take steps to mitigate it.

Harden the architecture so it is harder for security breaches to occur. At this point think of security like a fire, start building out things which are fundamentally secure (fireproof)

Next accept the fact that even your hardened architecture will be breached so reduce the possible points of breach (sources of ignition)

What do you do to stop the breach from spreading (firebreaks, sprinklers etc.)

What do you do to monitor your architecture for breaches (smoke alarms, temperature monitors)

Successful cyber-attacks on organisations occur daily, so security must be included in the basic design of the enterprise architecture. Before sign off and before any work begins on the implementation test and validate your design assumptions. Ideally get somebody else to test and validate.

Hope for perfection, aim for ideal, settle for the very good.

A true work of art is but a shadow of perfection. Thankfully most technologists are not artists and those who are do splendid work in UI\UX design and development. Perfection has an innate attraction. Everyone wants to build something perfect. This laudable and admirable goal is not something you can achieve in enterprise architecture. Future proofing and scalability are the ideals and they can and often are specified, usually by folk whose job isn’t to deliver on that specification.

You’re very welcome to set sail for Perfection on the good ship Enterprise Architecture but the voyage is long, the passage is costly, the ship is slow, navigation is poor, there are many storms and ports along the way and you will be bunking with two tiresome shipmates – Messrs. "Overbuilder" and "OverArchitecture".

However there’s a fast ferry that will get you to a place called FrontLoadedValue. It’s about 80% of the way to Perfection and I hear it’s very good.

Take the ferry.