In this post, I’m going to argue that Enterprise Architecture Modelling is dead, it was right to die, and it should be replaced with Enterprise Architecture Modelling. Confused? Let me explain.

When I first started as an Architect (with the actual title, rather than just “I figured out how to make this and no-one argued with me”) the place I was working at had a large, comprehensive, and detailed model of the entire enterprise. It covered many different layers and showed the deeply interconnected nature of the complex environment the company operated in and had to operate in IT.

It was truly beautiful, and in the years which followed I spent a great deal of time helping to maintain this model. It assisted in identifying the root cause of faults, and helped work out who was responsible for what, and helped with ensuring a consistent standard of design and documentation was followed.

It made sure we had a clear understanding of what we had, where it was, and how it interacted. It is incredibly valuable to have that understanding because most organisations have no idea what they have. And therefore, they can’t gauge their security posture, or understand their costs, or do many other things that business stakeholders will ask from time time.

It was also a massive pain in the bum.

The hours which had to be sunk into it to keep it up to date was huge, more than we could ever put it. Even if it could be automated with discovery of “assets” you needed a person to filter all the noise and keep it organised. Projects would duplicate resources all over the place, and would not file what they had back into the main model structure.

It was used to document past intentions and future state, but since it was a view on the current state only lots of diagrams would rot and become invalid - maintaining those as well as the main model was too much.

And it could only really live in a world that everything was heavily governed, that was strongly waterfall based with projects and explicit design before work began. If, as we did, your organisation starts to pivot towards “Digital” and towards speed as a priority - your model is not going to survive that.

It died. I miss it, but I’m glad it died, because it wasn’t maintainable before and it certainly isn’t maintainable in an “agile” (whatever spin you put on that term) environment.

So why then am I arguing that an Enterprise Architecture Model is needed?

The consequence of not having a model of some kind is you end up with no documentation, and scattered documentation in a dozen different formats even when you do get it. You get solutions that claim to automatically discover you application landscape that really are guesses and not curated enough to be dependable.

And you still need to document something of your environment and your landscape. That problem is not going to go away no matter how much the belief in speed at any cost is pushed. (Why I despise developer-driven agile is another rant in and of itself. Suffice to say, just pushing everything into prod and undocumented might be fine for a startup, you are playing with fire in any complex environment without a very consistent culture of co-operation and agreement!)

The problem with Enterprise Architecture Models of the past is they were just too verbose and decomposed to be maintained. It wasn’t that they didn’t provide value, they did, they just made it too hard to get value out of them.

If you look at the industry favoured metamodels for Enterprise Architecture you will find far too much decomposition of systems, and a tendancy to expect enumerating the very bottom of the layers (down in the weeds of metal and containers and networks) when that’s highly unstable and the most expensive to maintain.

What doesn’t tend to change are high-level needs - capabilities, applications and what other applications they talk to, who owns these things. Those high-level concepts are much more stable and durable over time.

Stop documenting what datacentre contains what rack contains what physical server contains what OS contains what JVM contains what EAR contains what application contains what applicaiton function and realizes what business function and realizes what business process and and and and..

We need an Enterprise Architecture Model that is light, and has very few different objects in the system. And given one starting from those high level concepts, it’ll be useful to help understand what we have, and be maintainable, and ensure even the most agile environments are still something that can be documented.

I don’t have a metamodel to sell here - I wish I did but I don’t - so this is more a call to put down the metamodels will hundreds of different reosurce types and get back to documenting those simple high-level layers.

Everything else, well you can fill out if you really need it, but don’t add anything assuming it has no cost to maintain.