Enterprise Architecture Tools – A sorry state

Why do enterprises need an architecture tool?

Consider the following scenarios:

• A new developer joins and wants to see some system overviews to get up to speed.
• A CTO needs to review his/her services and complexity to determine where to invest.
• A network engineer needs to find where to apply a patch and view where relevant devices are installed.

Gee, if only there were some kind of tool to provide an overarching view of all this complexity.

Enter the Enterprise Architecture Modelling tool.... 

The EA modeling tool is meant to solve this and promises so much more. A complete view of your business process, release management, productivity, code quality, the bond market, NFT floors, and panda-mating habits.

You gain visibility of planned initiatives from the business through operations, solution architecture development, release management, and deployment (DevOps).

unicomsi.com

Why is it that most organizations don’t/won’t use these tools? Surely this must be a perennial niche in the Saas market just waiting to be solved.

Another question is why they still look like the monstrosity below:

Well, EA tools can show all those things, but you have to have someone update spreadsheets, click boxes together, and document via .NET forms that look like MS apps circa Outlook 2003.

The problem is often that this individual can’t know everything and maintaining such a byzantine documentation tool becomes an impossible task.

What happens in reality

In reality, architecture is a mixture of views, diagrams, pages, and variable quality. The best architects can maintain a decent wiki, enforce documentation standards and try to fill in gaps to support onboarding and investigation.

Future state designs and decision logging works well when sensible patterns are adopted (will write more on this later). I’ve often found myself sharing documents to Dev/Infra teams to provide guidance on designs.

While I’d love to say “there should always be a clear diagram of all components and architecture”, I’d have to argue that it’s rarely worth the effort.

When good enough is good enough

Software development, Cloud Infrastructure and tooling are often messy. They vary in approach and don’t fit a one-size-fits-all tool. That’s the issue Enterprise Architecture tools face. Trying to cover multiple aspects and views means they have to be extremely malleable. This results in a non-trivial amount of time spent building dashboards over data that is often poorly maintained.

Good documentation should take into account its most obvious usage. Developer onboarding, sharing API specs, helping delivery and architecture get a picture of the whats and where.

Write for the future readers

It is always necessary to question why the reader will be referencing it. Will the next architect, dev team, tester, DevOps engineer find it useful? Or will it be condemned to fall out of date and out of sight. A relic of some previous initiative or point in time.

My recommendation

Focus on the standards and aims of your Enterprise Architecture rather than its visualisation. Tools can help but a well-organised wiki that has buy-in from Architects and teams will win every time. If you can win that battle, consider your EA mapping a success.