“Architecture Modelling? Won’t That Confuse Everyone?”

We’re don’t have to dumb down our architecture knowledge assets — because we never dumbed them up in the first place.

If the Stakeholder Can’t Understand It, the Architect Doesn’t Understand It Either

We’re using the Archimate architecture content meta model and iconography, in a Very. Very. Very. Simple. Manner.

Specifically, we are not using the advanced, whack-o, fancy-schmantzy, rockety-sciencey, UML-y, Archimate relationship connectors:

• Specialisation / Generalisation
• Composition
• Aggregation
• Serves
• Realisation

These relationships come from UML, and they are useful for technical, physical, project solution software and infrastructure design (but they rarely get used for that purpose).

Those advanced relationships make sense, and if you have any geek in you at all, you should bother the learn the thinking behind them.

We use nesting for reference architecture models. For domain execution architecture diagrams we use the dynamic relationships flow and trigger, and more nesting.

Why Architecture Modelling?

You cannot create a coherent view of your enterprise architecture if you are generating an endless succession of static, project-specific, MS Office documents, and storing those documents in your MS SharePoint corporate document / content repository. Or worse, shared, or local, drives.

MS SharePoint search capability has gotten better over the last five years. SharePoint is now an unavoidable, key component of our enterprise architecture knowledge management capability. It has taken a while, but I have learned how to use SharePoint. I can’t call it love, exactly. Respect, maybe.

But — you need to achieve fit-for-purpose coherence and consistency across a limited range of project and domain architecture views that need to be created. If that’s what you want to achieve, you need what TOGAF calls an ‘architecture content meta model’.

Architecture content meta models are fine. In theory. It is when teams of architects attempt to use an architecture content meta model that things can go off the rails. In theory, everything works fine. Rainbows and unicorns. In practice, it can be a steep learning curve. Depends where you start from, and who you have on your team. If no one on your team has ever used an architecture content meta model — in professional, applied practice — good luck.

Simple Archimate Notation Creates Zero Confusion

Guess what? No stakeholder has gotten distracted or confused by the wee icons in the top right of shapes on our architecture diagrams. Stakeholders don’t care about the icons.

Stakeholders look at the names of the objects on a diagram and they immediately know what they’re looking at.

The diagrams we create using Archimate are easier to understand than the bizarre, impressionistic, graphics-only, Visio and PowerPoint diagrams that get created by project designers. Shapes with cryptic abbreviations in them, connected by lines — with a few unexplained symbols here and there that only the person who created the diagram understands. No legend, of course. No date on the diagram, no status (draft or final approved), no contact details, no document control information. Most architecture diagrams represent the architect (who created the diagram) talking to themselves, explaining what they know. In graphical gibberish no one else on the planet would be able to interpret. No one else matters, apparently.

Compared to this fresh hell, using Archimate — in a simple manner — is a giant leap forward for human kind.

Enterprise Architecture Requires Formal (Meta Model Based) Architecture Modelling

I realise the following statement is Very. Aspirational:

It should be possible for every architecture view (diagram plus meta data) created in the organisation to be integrated into a consistently-defined collective repository of architecture views.

Obviously, this is not where we are today, is it? And, yes, I can hear you lot in the back, laughing hysterically. In theory, a nice idea. In practice, it’s extremely challenging.

Doing the above requires not only a commonly-used architecture content meta model, but an organisation-specific naming standard.

Stop Duplicating! Stop Duplicating!

Any half-way decent architecture repository tool allows you to define master objects that you can re-use on as many diagrams as you need. With proper use of a proper architecture modelling tool, you are not duplicating. You are re-using. And each time you re-use an architecture component in the repository, your understanding of that component’s role in the business technology landscape of your organisation becomes richer. And you capture more information about that object. Structured name value pair data. Unstructured text descriptions.

Good Architecture Requires a Naming Standard

Good architecture requires a well-defined, organisation-specific, naming standard for important enterprise business, information, application, and technology assets. This naming standard needs to be broadly understood and accepted within the organisation. Project people will still find reasons not to use it, or they will try to use it but their use of it will be rough. Very rough.

That’s okay, because — for important architecture knowledge — the architecture team can translate project terminology into into the normalised naming standard. Projects ain’t going to be able to do that by themselves, without someone helping them. That’s another service the architecture function offers to projects.

And if anyone in your organisation is trying to define a canonical enterprise data model, or developing .xsd message formats with name value pairs for all the MoM or API work everyone is doing these days — you may be able to reuse some of that intelligence in your architecture practice.

Attenuate Nomenclatural Obfuscation

As everyone knows — an architecture asset will often have 47 different names throughout the organisation. It’s not unusual for two completely different — totally unrelated — architecture assets to be known by the same name. That’s confusing. So yeah. You need a naming standard. But only for the important stuff. Not everything. It’s an architecture repository — not a CMDB.

Spell it Out, Stupid!

Another rule in our naming standard: Spell out any abbreviations for anything that people outside your team may not understand. You obviously know what MXZ means, but others may not. Have some consideration for them. You’re not creating architecture documentation for your self— you’re creating it for people who don’t have the same knowledge you do.

Who’s the Vendor, Stupid?

Another rule in our naming standard: If there’s a vendor, show the vendor name. Not everyone will know what the term “Glue” means as the name of an application component. However, if you add the vendor name, it’s a lot clearer.

Where’s the Meta Data, Stupid?

Another rule in our naming standard: Meta data. An architecture repository allows you to capture meta data in many ways. You can add meta data to each object. This meta data can be structured name-value pairs, or it can be unstructured free text notes. Meta data can also be captured into a document artefact that you keep on the diagram. We like the document artefact approach.

Those four ‘Enterprise Architecture Reference Models’ that you created give you a head start on your naming standard. Don’t tell me you haven’t got the four bare-minimum enterprise architecture reference models.

It’s Never Complete. It’s Never Perfect.

In our organisation, we’re making progress. It’s not perfect. We’re not there yet, and some things will never be perfect, and they’ll never be complete. But things are getting better.

Architecture is a Capability — Not a Project

Architecture is not a ‘project’. It is an enduring ‘capability’. Capabilities survive organisational restructures. Architecture needs to get done regardless of executive shuffles, HR re-branding, and any organisational restructuring required by your next ‘business transformation’ program.

Architecture Spans Projects

You want architecture views that show how a single architecture asset can participate in multiple architecture contexts. But you don’t want to duplicate that object for each architecture view you create.

Achieving this requires:

1. A single architecture content meta model
2. An organisational-specific naming standard for architecture assets

Projects Are Incapable of Doing Consistent, Formal Architecture Modelling

Projects have limited span of visibility. They have deep understanding of the applications and technology components under their direct management. They have a good understanding of other applications to which their components directly interface.

If you ask multiple projects to create a single project design artefact, and you give explicitly detailed instructions to those projects about how to create that artefact, each project will create an artefact that is different in degree and kind from what any other project will create. The results — being inconsistent across multiple projects — cannot be integrated into a consistent architecture repository.

Projects are incapable of producing Archimate architecture artefacts that are consistent across the range of projects that exist in your organisation. Project designers don’t have time to learn. It’s not a skill they’re interested in learning. We should not expect them have these skills.

A few project designers may think they understand Archimate, but they are unable to use it to produce meaningful All they are able to do is a bit of cryptical graphical boxes and lines,

Naive, impressionistic, informal architecture diagrams created by projects confuse everyone far more than they make things clear.

Don’t trust projects to give you everything you need. They’ll leave out important bits.

In creating technology architecture views, there is an opportunity for us to confuse ourselves and everyone else. When we are creating views of technology and infrastructure, we are creating a logical view of objects that exist in the real world. Project SMEs are experienced in defining physical technical build-specifications.

Logical views may show one single logical instance of an application load balancer when there may be 20 load balancers in the physical architecture.

Projects confuse physical instances of technical architecture components, with logical architectures.

Anatomy of Enterprise Architecture. Sorry. Post-mortem.

Before I begin, let me clarify a key point. Our architecture team is not a project team. Our span of view is the enterprise. We do not create project-specific solution architecture views. We don’t do that work for projects. They have to do that for themselves. Occasionally they ask us for help and guidance, and we’ll do a bit of mentoring. But only when we’re asked.

In our organisation, there are several major business lines within the ‘business technology group’ (it’s not called that) that have an architecture role. We’re talking about a large organisation here. Our closest partner in the architecture function is a business line that takes an enterprise-wide view of business applications, with a focus on the business capabilities, business functions, and business process that run on those business applications. That business unit has accountability for the enterprise portfolio of business architecture and application architecture.

Our business line takes a view of the same enterprise portfolio of business applications — but with a focus on the technology and infrastructure that those business applications run on.

We create end-to-end, across-multiple-projects, top-to-middle views of architecture. In our organisation, we call these Execution Architectures. No single project would be able to create these views, because any single project does not have full visibility of the whole architecture value chain for a domain. Execution architectures subsume multiple applications, showing the multiple workflow interaction paths, end-to-end, through the application architecture. We create these views for projects. Because they cannot create them.

We provide these architecture knowledge management services to business and technology executives, and project subject matter experts, who need a viewable, simple, end-to-end, view that they can challenge, question, understand, and use for their own narratives, to communicate to their peers, in different decision-making contexts.

No one — including the executives — are confused by what they see. We just get work done. We rapidly create accurate, comparable, consistent views of actual architecture facts and evidence.

Screw Viewpoints —If It Makes Sense, Put It In There

The idea of an architecture viewpoint can be needlessly constraining to the architecture view your really want to create. We will selectively — where it makes sense and helps the view — add elements of business architecture, application architecture, information and data architecture, and technology / infrastructure architecture — to a single diagram. No rules. We understand the rationale behind viewpoints, but we don’t slavishly limit our views to a single viewpoint. There can be many viewpoints. Be flexible. Don’t play by the rules.

It’s Not About The Architecture Modelling Tool

We never mention the name of the vendor software application we’re using for architecture modelling. We talk about ‘the architecture repository’. We don’t talk about ‘drawing diagrams’ — which is what you’d do with Visio. We talk about ‘creating accurate formal views of our architecture’.

Architecture Modelling Is Not About Diagrams — It’s About The Data

Get used to the idea that architecture diagrams are just ephemeral, throw-away, end products. They have transitory value in different contexts, for limited periods of time. The data you use to generate those diagrams? That data is the gold. Which Samuel L Jackson knew a thing or two about:

Architecture Products

Our ‘products’ are viewpoint-defined, meta-model-based, sustainable, summary analytical information assets generated using relational data in an architecture repository. Not Visio. Not PowerPoint. Not Excel.

Executives love that they have a visual diagram that they can gaze up, ask questions about, challenge, absorb, understand, and then use as a tool to communicate their personal narrative to their executive peers and their staff.

But we’ve stopped printing large-format paper diagrams. We still produce those for the execs — who still like having a big diagram blue-tacked to their office walls that they can use as a focal point for face-to-face discussions.

Because of COVID, everyone is now using online video team meetings. So all architecture content is directly published to the corporate MS SharePoint portal. Which provides a hyperlink that stakeholders can bookmark in their browsers

There is no ‘enterprise architect’

‘Enterprise architecture’ only exists when it is realised by a team. Enterprise architecture is a team sport. It’s a contact team sport. There will be blood. It’s not about any of us as individuals. It is always and only about us as members of a team. It’s not about my personal performance. It’s not about my personal knowledge. Or yours. It’s about our performance as a team.

Re-Branding

Whether we ‘enterprise architects’ like it or not, the term ‘enterprise architecture’ is in general disfavour among business technology executives — the people for whom we directly work.

This is not surprising. Since the ’90s, enterprise architecture has been going through a Hype Cycle arc. For every team producing useful business knowledge assets valued by executives and subject matter experts (Plateau of Productivity), there are 100 teams trying to keep up with a fire hose of projects (Trough of Disillusionment).

Here’s what we did. It’s a ‘good news’ story. Not many of those around these days.

Our team had to keep explaining why we were called ‘Enterprise Architecture’ when we were obviously not doing anything of the sort. We got tired of the endless debate and contextualising.

So we consciously re-branded our team from ‘Enterprise Architecture’ (which we were not doing) to ‘Architecture Products’. Which is a lot less pretentious. We produce architecture knowledge assets. We create products. You know, like your agile product teams.

And we have drawn up a very simple Architecture Services Catalogue that states clearly (and shows examples) of what we do — and what we don’t do. We don’t over-promise. The things on our Services Catalogue are things we’re resourced and skilled to do. Happy to talk about other stuff, but we can’t do it for you. Give us more resources and we’ll talk about it.

Having an Architecture Services Catalogue limits the variety of things you have to do — so you get some repeatability into your workflow. Every time we do a new instance of an existing product (viewpoint), we’re re-using skills and techniques we’ve been improving on for two years now. The more you practice something, the better you get at it. Velocity increases. Accuracy increases. The techniques you develop for engaging a community of business and technology subject matter experts become more effective.

Perception of our team has gone from ‘not sure what they do’ — to ‘they only do specific things, but those things are really useful. Wish they could do more.’ Absolutely happy with that. Failure is an orphan, success has many fathers. We are happy for our clients to take credit for what we’ve done for them.

By way of contrast, a lot of architecture teams are always on the back foot, reactively responding to new, different, requests for help. They’ve got no theme. No play book. They’re always trying to do new things they’ve never done before. Trying to keep too many spinning plates on sticks going at the same time. Too many meetings. Nothing ever comes out of those meetings. No product. No repeatability. Do less. Do it better. A good architecture team is lazy.

Draw a Line.

Stuff above the line is the important stuff you have to do something about. Stuff below the line — you have to make the tough decision to keep an eye on it, but acknowledge that your team is not resourced to do everything you’d like to do. Too much detail? Below the line. Too much change? Rapid change that you would never be able to keep up with? Below the line. Nothing is ever perfect. Nothing is ever complete. Nothing is ever final. Learn to live with a certain amount of risk, mess, and uncertainty. Try to make some sense out of the stuff above the line.