That love for Obsidian is always amplified when I have to look up something on an organisational documentation platform. I can never find anything, it’s always out of date, and it has conflicting ideas all over the place. I’m pretty sure you can relate (if you even have one).

Using applications like Obsidian for organisations is not workable, they aren’t built for multi-user collaboration; it’s not their product focus. And the applications I come across in organisations are also not bad. Tools like Confluence, Notion, Slite, and even things like SharePoint sites are not the problem. They are good tools.

The issue is the way they are set up. An endless, mindless dump of folders with duplicate and contradictory explanations, sometimes even just a PowerPoint slide deck that might or might not be relevant.

And I’m always amazed about the lack of strategy in setting something like this up. How is it that I can find where the third King of the Belgians was born in a few clicks yet finding out what our expense policy is about is something you would rather ask a colleague, then look for on the organisational wiki?

I’ve done a lot of research about this over the years, and I would like to share my ideas on how to set up a documentation store.

This is going to be a two part post. The first one is the general outline and philosophy. The second part is about structuring project governance documentation.

The knowledge graph

A lot of organisational wikis are stored in folder structures. Something like this:

IT Department General
  ↳ 00_2025 Archives
  ↳ 01_Projects
	  ↳ Project Phoenix Redesign
	    ↳ Architecture
	    ↳ Data
  ↳ 02_Governance and Compliance
	  ↳ Move to cloud
	    ↳ Cloud_Usage_Policy_2026.pdf
	    ↳ License_Agreement.pdf

This mimics a file system and in the case of SharePoint is also often just a copy and paste from one. A bit of a dumping ground where you work from a file folder and try not to go out of it. Everything is trapped in its own container.

The idea of a knowledge graph goes in the opposite direction. In its rawest form, you do away with folders and structure altogether (we are not going to do that, but it makes the concept easier to introduce).

Wikipedia is actually a nice example of this. If you want to find the third king of the Belgians (Albert I) you could go to the “Belgium” page and find a link there to said king. But you could also go through the page of past kings, or even the “Summer Olympic Games” main page.

That’s the beautiful concept behind Knowledge Graphs, they create organic links with relevant information without the need for you to set it up.

You know, the way the internet works.

The MOC: The Map of Content

In this state it’s very chaotic. It would be a huge list of coupled documents, but you’d still have a hard time actually finding what you’d need.

That’s where MOC’s (Map of Content) come in. These are landing pages that help you on your way. Again, very much like Wikipedia. To go to a topic you go to one of the main ideas of the topic, and it will guide you there.

Belgium could be a MOC for guiding you towards its old kings, but so could World War I.

These pages can also include information themselves to introduce you towards the bigger concept. A MOC of Belgium would not direct you to a Belgium detail page, it would serve as both the main topic and the launch pad towards the deeper topics.

graph TD
  ALBERT["Albert I of Belgium"]

  BELGIUM["Belgium MOC"] --> ALBERT
  KINGS["Kings of Belgium MOC"] --> ALBERT
  WWI["World War I MOC"] --> ALBERT
  OLYMPICS["Summer Olympics MOC"] --> ALBERT

  ALBERT --> REIGN["His Reign"]
  ALBERT --> MILITARY["Military Career"]
  ALBERT --> LEGACY["Legacy & Death"]

Atomic Documentation

The problem, however, is that your organisation is not going to have the thousands of maintainers that a place like Wikipedia has. So we are going to have to deviate slightly from how Wikipedia does things².

The issue with long articles is that not a lot of people find the motivation to write them. It takes a lot of work to write a decent long explanation of a concept³.

It’s also a bit daunting to jump into a very long article and read the entire thing when you are actually just in need for a small part of the information.

There is also the point of keeping this up to date. If you keep explaining the full concept of how your cloud strategy works on multiple pages, you’re going to have to rework (and search) for all of these references every time the strategy changes. A classic example here is the architecture principles rewritten in every project.

This is where Atomic Documentation comes in: one concept per page. Reference the rest.

We borrow some concepts from the software development world:

• Single Source of Truth: If a Business Capability is defined once, it should be referenced everywhere, never re-typed.
• Transclusion: Confluence is pretty good at this for example. You can embed parts of a different document in the current document. I often find it better to just link, but the concept is the same. Make changes at the source and let the information drip upstream. Everything stays up to date.
• Rabbit Hole Exploration: Designing documentation that encourages exploration. Allowing a reader to start at a high level and drill down into technical specifics via links. This way you can bring information at different resolutions.

By following through on the documentation in a project you might stumble upon the architectural principles of the organisation. A page that you might not have been looking for.

flowchart TD
    ProjectA[Project Phoenix] --> App[SAP ERP]
    ProjectB[Project Unicorn] --> App

    App --> Cloud[Cloud Strategy]
    App --> Architecture[Architecture Principles]

    subgraph SSOT [Single Source of Truth]
    Cloud
    Architecture
    end

    style SSOT fill:#e1f5fe,stroke:#01579b,stroke-dasharray: 5 5

Metadata

Adding metadata is not strictly necessary, but it’s a nice touch. It also typically comes out of the box with most of these applications so it’s not too much work to set up.

I strongly believe that old data is not per se bad data. It’s not because the data is not refreshed every year that it is less valid⁴. That said, I do like a date for when it was added and when it was last updated. This can come in handy for information that is date sensitive. Think legal policy or technology policy that is linked to specific tools.

An author field is also a nice touch. It always helps when the data is scarce, and you want to know more.

I’m not sure about a status field. Having a label that the documentation is outdated could be nice. One that says that it’s work in progress is less useful for me. In my mind, all information is a work in progress…

Organized chaos

We have our small and numerous notes, we have our MOCs, but we would still like some extra structure. The next part goes a bit against the grain of the knowledge graph concept, but it’s needed in an organisation.

Leaving a dumping ground with MOCs and notes is too intimidating for new users to drop into. You’re never going to get that adopted. You’re going to need folders.

This is the current structure I’ve landed on:

• Projects
• Applications
• Processes
• Resources
• Archive

Projects

I’m going to discuss this one in the next post, but I guess you might have a vague idea of what’s going on in there

Applications

A lot of people go to these documentation sites to find information about applications. This is a core concept.

Under the Applications folder you can create a folder per application. Each with their own MOC.

Applications
  ↳ Applications_MOC.md (The Software Catalog)
  ↳ SAP
    ↳ SAP MOC.md
    ↳ Licence
	    ↳ SAP_License_Agreement_2024.pdf
	↳ Diagrams
		↳ SAP_Network_Topology.png
		↳ SAP_Network_Topology.vsdx
  ↳ Salesforce
    ↳ Salesforce MOC.md
    ↳ Salesforce_Security_Model.md

You might have scrolled up to compare it to the example of the “old way” of doing it and thinking what’s the difference here?

Well, the most important part is that we are giving people an onboarding ramp. We don’t actually care about this folder structure, but we use it as a familiar starting point. Once they are in, and they start following links they will no longer look at the folder structure as they have landed after two clicks in at a very different spot.

Processes

The same idea as the applications. A lot of questions will be: How do I do X? well you can go in the Process folder and explore your starting point.

Processes
  ↳ Processes_MOC.md (The Value Stream Map)
  ↳ Order to Cash
	  ↳ Order to Cash MOC.md
	  ↳ ... deeper in till you hit low level processes

The same idea here. When you talk about some deeper processes, you can link to different concepts, often applications. You might also end up in these structures from Applications or maybe even a Capability map. Speaking of which.

Resources

This is a bit of a dumping ground for the other things. A capability map with the levels would work well here, but also architectural principles or an expense policy.

You would still use MOCs, you would still link everything over the documentations. It’s not always clear what is where. For example, does a Microsoft licence agreement fit here under procurement documents, or rather under technology licences? It doesn’t really matter, again, this folder structure is not the point, it’s the connections.

Archive

You could also delete, but then you have broken links. If your software allows it you could add a banner to everything under this section. This part will also be important in the next article about the project documentation.

graph TD
    Root((Start)) --> F_App(Folder: Applications)
    Root --> F_Proc(Folder: Processes)
    Root --> F_Res(Folder: Resources)

    F_App --> SAP_MOC[SAP MOC]
    subgraph SAP_Subfolders [SAP Folder Structure]
        SAP_MOC -.-> F_Lic(Subfolder: Licence)
        F_Lic --> Lic_File[SAP Licence Agreement]
    end

    F_Proc --> O2C_MOC[Order to Cash MOC]
    O2C_MOC -- contextual link --> SAP_MOC
    F_Res --> Contract_MOC[Contracts MOC]
    Contract_MOC -- contextual link --> Lic_File

    %% Styling for clarity
    classDef MOCPage fill:#fff4dd,stroke:#d4a017,stroke-width:2px;
    classDef Structure fill:#f5f5f5,stroke:#999,stroke-dasharray: 5 5;
    classDef SingleFile fill:#e1f5fe,stroke:#0277bd,stroke-width:2px;

    class SAP_MOC,O2C_MOC,Contract_MOC MOCPage;
    class SAP_Subfolders,F_Lic Structure;
    class Lic_File SingleFile;

The Elephant in the Room

Your structure might be very solid, but the fact still remains of garbage in, garbage out.

And that brings us to LLMs.

You could just generate all these documents with your favourite LLM, but then you will have just wasted your time (and money). In my experience people don’t read auto generated documentation. It should take (a lot) more time to write than to read. And I understand that writing documentation is not the favourite pastime of a lot of people. ⁵ And you are never going to be able to stop people from auto generating documentation, but with Atomic Notes the temptation should be lowered.

The main problem with this setup is that it’s not compatible with auto generated documentation. If you don’t add links to other parts of the documentation, the entire system falls apart. Either the LLM stuff can’t be discovered or it floods the system and drowns out the rest of the setup.

I don’t think there is a solution to this, but that’s also the same with all documentation in general, the signal-to-noise ratio is getting out of hand.

You can put organisational guidelines and training forward, use a LLM to support writing and not replace it. But that also requires people to care enough to follow those guidelines.

Living documentation

I see documentation (and information in general) as an organic thing. This might just be the architect in me who likes to think in interconnected systems, but the value is often in the relationship, and not the individual piece of information.

That’s the entire philosophy of this setup. Interconnected information with signposts to point you in the right way.

We use small and easily scannable documents to quickly communicate one piece of information. Once we are dragging in different concepts we link, or create new small pieces of information. And encourage people to do deep dives if the time (and interest) allows it. If not, people still have a high level overview of what they need.

Stay tuned for the next part in two weeks where we dive into project documentation.

Birds don’t always perceive glass clearly, especially when it’s a tall apartment building and on their flight path. So there are birds that think they can pass under an arch, yet instead fly straight into a glass wall.

However, some of these buildings are also perfectly suited for nesting and resting places.

Now, I’m sure there are some meetings that architects and city planners have on the impact of their design on the local bird population. It’s probably not their clients first item on the list in ordering new buildings and spaces.

Another example is adding trees to streets to lower city temperature¹. A lower temperature in a greener city might have an impact on the sale of beverages in the local cafés.

All of these things are nearly impossible to map. It’s too complicated a problem². The same is true for organizations and enterprise architecture. Yet it’s an enterprise architect’s job to map out an organization.

The Rumsfeld Matrix

In strategic planning there is a framework called the Rumsfeld Matrix. It’s attributed to Donald Rumsfeld, yes, that, Donald Rumsfeld. But in reality it’s an older concept that was used before in the late 1960s.

The idea of the matrix is that you map out what you know and what you don’t know. That sounds very contradictory, how can you know what you don’t know, but you abstract it. We do this to ground ourselves and don’t lose the plot while we are setting up a strategy.

Every matrix has four quadrants, here it’s no different, and in this case they are:

The Known Knowns

This is what we know and what we have mapped. We have a full view of where we can find the data, what it looks like, how it arrived there, and how we can use it.

This makes up most of the diagrams an Enterprise Architect makes. Examples here are the CMDB, API documentation, Organizational charts …

The Known Unknowns

You always have a list of things you want to map out, but haven’t got around to yet. Think about a backlog of technical debt, or business processes that aren’t mapped out yet, but you vaguely know what they do. You know where you can go look for them and how you could use the information, you just don’t know the actual data itself. This also includes information that is too simplified to fully make use of.

The Unknown Knowns

Here we have the information that the “system” knows, but you don’t. Categorized here is shadow IT for example, or a weird workflow the COBOL developer uses in some legacy system to make sure the accounts work.

The system performs the task, but the documentation (and the architect) is unaware of how.

These are often rabbit holes that come on your path when you are looking into systems. The skeletons in the closet.

The Unknown Unknowns

Now we have the examples from the intro. Emerging situations that happen when two unrelated systems interact for the first time. Things that are typically results of factors way too complicated to actually map.

quadrantChart

title The Rumsfeld Matrix
x-axis "Unaware of the information" --> "Aware of the information"
y-axis "Not accurate information" --> "Accurate information"

quadrant-1 Known Knowns
quadrant-2 Unknown Knowns
quadrant-3 Unknown Unknowns
quadrant-4 Known Unknowns

Market Trends: [0.85, 0.2]
Legacy Code: [0.9, 0.10]
TOC Assets: [0.75, 0.35]
CMDB: [0.7, 0.7]
API Documentation: [0.85, 0.85]
Organizational Chart: [0.74, 0.90]
Shadow IT: [0.2, 0.85]
Tribal Knowledge: [0.15, 0.9]
Cascade Failures: [0.2, 0.2]
Market Pivots: [0.15, 0.15]
Cultural Feedback: [0.3, 0.3]

Causal Loop Diagrams

Remember in the intro that I said it’s impossible to map out an Unknown Unknown? Well you kind of can.

Not in advance, mind you, more in a post-mortem sense.

The concept here is that you go over the events that took place like a script of a movie. Situation per situation. Then later when you have mapped that out, it could function as lessons learned for future strategic decisions.

In general, you have two kinds of loops.

Reinforcing Loops

You can see them as snowball effects, they amplify themselves. Both negatively and positively.

You can have a “success to the successful” loop where positive change is reinforced by more positive change:

	flowchart TD
	A[Well working Platform] -->|"attracts"| B[More Users]
	B -->|"generates"| C[More Funding]
	C -->|"enables"| D[Better Features]
	D -->|"drives"| A

But there is also the “death spiral” where the opposite is true:

flowchart TD
A[Pressure to Deliver] -->|"forces"| B[Quick & Dirty Fixes]
B -->|"accumulates into"| C[Higher Complexity]
C -->|"causes"| D[Slower Delivery]
D -->|"escalates"| A

Balancing Loops

These loops seek stability or a target. They resist change, which is often why digital transformations fail. Death spirals are definitely something to avoid, but this status quo can be just as detrimental to your organization.

An example here is the typical modernization project:

flowchart TD
A[New Innovation Attempt] -->|"requires"| B[Integration with Legacy Systems]
B -->|"triggers"| C[Increased Maintenance Effort]
C -->|"consumes"| D[Decreased Time for Innovation]
D -->|"suppresses"| A

A map is not the territory

I really like that quote. It’s not mine, it’s Alfred Korzybski. A diagram or map is only a representation of what you actually put on there. An abstraction. Even with the most detailed map in the world, you will still only show what you know.

And that’s a good thing.

What I’m saying is that the goal shouldn’t be to map out all the things³. There is no way you’re going to be able to do that. You should focus on the things that give value and make abstractions when there is no clear value.

I’m not convinced Causal Loop Diagrams actually are all that useful as the parameters of your strategy will always keep changing, and even in the case of these diagrams you are making assumptions and abstractions.

It is however very important to be mindful that there are a lot of things happening in an organization that you cannot be aware of. And shouldn’t be aware of. This keeps you out of the false sense of knowledge when making strategy.

PS: as a reader exercise I challenge you to think where AI agents and LLM’s are located in the matrix. Is an LLM a ‘Known Unknown’ (we know it’s there but don’t know what it will output) or an ‘Unknown UnKnown’ (It’s a black box, and we have no real way to look inside)? I’ll leave that to your next architecture review meeting.

It was a cool place to work, with a lot of smart people.

At some point they started to talk about standardizing their data transfer objects, the data that flows over the API connections, in these common models. The idea was that there would be a single Invoice, User, Customer concept that they can document, standardize and share over their entire application landscape.

Everyone had the same idea of what a user was, from database engineer all the way to the sales people. They called it unambiguous language.¹

The Canonical Data Model

What they were inventing is now known as a Canonical Data Model. A centralized data model that you reuse for everything. And to be fair to that team, there are companies that make this work. Especially in highly regulated environments you can see this in play for some objects. In banks or medical companies it’s not uncommon to have data contracts that need to encapsulate a ledger or medical checks.

It also brings other upsides, regarding onboarding and integrations it’s rather sweet. The Payroll team needs the customer data, everyone knows exactly what they can expect and what they need to send.

graph TD
    subgraph "Canonical Data Model"
        CDM[User Model]
    end

	CDM --> Billing[Billing Service]
	CDM --> Sales[Sales Service]
	CDM --> Shipping[Shipping Service]
	CDM --> Support[Support Service]
	CDM --> Marketing[Marketing Service]

The problem is, however, that it’s a horrible setup.

Bounded context

When that team was often talking about domain driven design concepts (value objects, unambiguous language) they seemed to miss the domain part. More specifically, the bounded context.

The bounded context is the lens you use to look at a concept. Let me explain in the most technical way possible, with a JSON object.

Say you want to kickstart the idea of a CDM as someone working in the domain of billing, and you propose your Customer object. ²

{
	"id": "40bb524a-3e0e-4a4a-93df-399819b3fd68",
	"name": "Acme Corp",
	"vat_number": "BE0123456789",
}

Now you get some people from the other departments together and ask them, what do you think?

After a few workshops your Customer object is now:

{
	"id": "40bb524a-3e0e-4a4a-93df-399819b3fd68",
	"name": "Acme Corp",
	"vat_number": "BE0123456789", // Billing needs this
	"credit_limit": 50000.00, // Sales needs this
	"delivery_instructions": "Back door", // Shipping needs this
	"support_tier": "Gold", // Support needs this
	"marketing_opt_in": true, // Marketing needs this
	"last_invoice_date": "2024-01-01", // Data is leaking
	"crm_lead_source": "Conference" // Why is this in the Shipping app?
}

Congratulations, you’ve just built a God Object.

A customer can mean a lot of things to a lot of different people. This is the bounded context. For a sales person a customer is a person that buys things, for a support person they are a person that needs help. They both have different lenses.

Now if we keep following the Canonical Data Model, this Customer object will keep on growing. Every week there will be a committee that decides what fields need to be added (you cannot remove fields as that impacts your applications).

In the end you have a model that nobody owns, has too much information for everyone and requires constant updating.

Enter the Data Mesh

A way to solve this, is data mesh. This takes the concept of bounded context as a core principle.

In the context of this discussion, data mesh sees data as a product. A product that is maintained by the people in the domain. That means that a customer in the Billing domain only maintains and focuses on the Billing domain logic in the customer concept.

They are responsible for the quality and contract but not for the representation. That means in practice that they can decide how a VAT number is structured. But not how the Sales team needs to format said model. They have no control or interest in how other domains use the data.

How we do this is through a concept called anti-corruption layers. These are transformation layers at the outside of your domain that transform incoming and outgoing data into/out of domain models.

So the data mesh connects small fiefdoms, each owning and shaping the data relevant to their domain.

graph LR
    subgraph "Billing Domain"
        BC[Billing Customer
- id
- name
- vat_number
- payment_terms]
        BillingApp[Billing Service]
        BillingApp <--> BC
    end

    subgraph "Sales Domain"
        SC[Sales Customer
- id
- name
- credit_limit
- account_value]
        SalesApp[Sales Service]
        SalesApp <--> SC
    end

    subgraph "Support Domain"
        SuC[Support Customer
- id
- name
- support_tier
- ticket_count]
        SupportApp[Support Service]
        SupportApp <--> SuC
    end

    BC <-.->|Anti-Corruption
Layer| SC
    SC <-.->|Anti-Corruption
Layer| SuC
    SuC <-.->|Anti-Corruption
Layer| BC

It’s a very flexible design but while Data Mesh solves the coupling problem, it introduces a new set of challenges.

If I’m an analyst trying to find ‘Customer Revenue,’ do I look in Sales, Billing, or Marketing? The answer is usually ‘all of the above.’ In a pure Mesh, you don’t make multiple calls, you have to build multiple Anti-Corruption Layers just to get a simple report. It requires a high level of architectural maturity and that is something not every low-code or legacy team possesses.

You also need a very capable team, not only from a technical point of view, but also from an architectural point of view. All of your teams need to be very aware, and willing, to fully commit to this setup. That includes low-code and legacy teams.

And what about SaaS and 3rd party? Sure, you can abstract that. Something you also have to do with the CDM, but it’s again more infrastructure.

I’m also not sure about the data and analytics teams. They now have a ton of overhead.

Federated Hub-and-Spoke Data Strategy

Let’s try and see if we can combine these two strategies. On one hand we want a clear data setup that is discoverable, reportable, and has easy integration. On the other hand we don’t want the huge model overhead, slow design committee, and data quality.

Big enterprises have Data lakes/Data lake houses. They are mainly hosted in tools like MS Fabric, Databricks, Snowflake, … Data scientists love these tools. These days these tools come battery included. They have out of the box APIs, transformers, notebooks, serverless code, …

What if we leverage that setup? We centralize our data in a central lake. Yes, that is back to the CDM setup. But we split it up in federated domains. You have a base Customer table that you call CustomerIdentity that is connected to a SalesCustomer, SupportCustomer, … Think of this as logical inheritance, a ‘CustomerIdentity’ record that is extended by domain-specific tables through a shared primary key.

-- Central Lake
CustomerIdentity { id, name, email, createdAt, updatedAt, createdBy }

CustomerSalesDomain { customerId, accountValue, salesRep, ... }
CustomerSupportDomain { customerId, supportTier, lifetimeTickets, ... }

When you create a new Customer in your sales tool you trigger an event. The CustomerCreate event³. The CustomerCreate trigger fills out the base information for the Customer (username, firstName, lastName) in the central data lake, at the same time we store our customer (base and domain specific data) in our local database. You also do this for delete and update events. The base information goes to the server, the domain specific data stays on the sales tool as a single source of truth.

The CustomerCreate event (or update/delete) also triggers all the other tools that are subscribed to that event. That being tools with Customers.

Every night there is a sync of the domain tools to the central lake to fill out the domain tables with a delta. Please note that the Lake is not the single source of truth here. It might be for the CustomerIdentity, but not for the domain data.

%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#2d5016','primaryTextColor':'#000','primaryBorderColor':'#1a2e0a','lineColor':'#2d5016','secondaryColor':'#4a7c2c','tertiaryColor':'#fff'}}}%%
sequenceDiagram
    participant Sales as Sales Service
    participant Lake as Central Data Lake
    participant Support as Support Service
    participant Billing as Billing Service

    Note over Sales,Billing: Real-time Customer Creation
    Sales->>Sales: Create Customer locally
    Sales->>Lake: CustomerCreate Event
(id, name, email)
    activate Lake
    Lake->>Lake: Store in CustomerIdentity
    Lake-->>Support: Broadcast CustomerCreate
    Lake-->>Billing: Broadcast CustomerCreate
    deactivate Lake

    Support->>Support: Create local Customer record
(with base data)
    Billing->>Billing: Create local Customer record
(with base data)

    Note over Sales,Billing: Nightly Domain Data Sync
    Sales->>Lake: Sync domain data
(accountValue, salesRep, etc)
    Support->>Lake: Sync domain data
(supportTier, tickets, etc)
    Billing->>Lake: Sync domain data
(vat_number, terms, etc)

graph TB
    subgraph "Central Data Lake"
        CI[CustomerIdentity
- id
- name
- email
- createdAt
- updatedAt]

        CSD[CustomerSalesDomain
- customerId
- accountValue
- salesRep]

        CSuD[CustomerSupportDomain
- customerId
- supportTier
- lifetimeTickets]

        CBD[CustomerBillingDomain
- customerId
- vat_number
- payment_terms]

        CI <-.->|extends| CSD
        CI <-.->|extends| CSuD
        CI <-.->|extends| CBD
    end

    subgraph "Sales Domain"
        SalesApp[Sales Service]
        SalesDB[(Sales DB)]
        SalesApp <--> SalesDB
    end

    subgraph "Support Domain"
        SupportApp[Support Service]
        SupportDB[(Support DB)]
        SupportApp <--> SupportDB
    end

    subgraph "Billing Domain"
        BillingApp[Billing Service]
        BillingDB[(Billing DB)]
        BillingApp <--> BillingDB
    end

    SalesApp <-->|Real-time Events
Create/Update/Delete| CI
    SupportApp <-->|Real-time Events
Create/Update/Delete| CI
    BillingApp <-->|Real-time Events
Create/Update/Delete| CI

    SalesDB <-.->|Nightly Sync
Domain Data| CSD
    SupportDB <-.->|Nightly Sync
Domain Data| CSuD
    BillingDB <-.->|Nightly Sync
Domain Data| CBD

Now if we have a call from the sales tool to the Support tool, you only send over the base customer data⁴. And the Support tool enriches that base data with their own specific domain data.

We don’t do this for only the Customer data. You’ll want to do this for all shared data.

Consuming data without breaking domains

This is not a simple setup, I’m very aware of that. I would not propose it if I didn’t see some big pro’s.

Upsides

First up is that you have a central data record that is at most a day old. That sounds a lot in development terms, but is very doable from a data and analytics point of view. If you really need to, you can always tweak the events.

Governance tooling (Purview, Atlan) works well with centralized lakes. Data retention, GDPR, data sensitivity are big things in enterprises. We can all fully utilize these and sync them downstream.

The domain owns the domain data. We support the bounded context approach while still making the data discoverable and traceable outside the IT department.

This supports Legacy, SaaS, Serverless, and Low Code applications. You will not hook them up to the event chain, but you can connect to the central data lake. They almost always support GraphQL. I’m personally not a fan of GraphQL, but I do see a good case here.

The payloads are very controllable. We don’t send over these massive objects. But we are still able to fully migrate the data from the central place.

We have separation of concerns. Our domains focus on transactions (OLTP) and our lake focuses on analytics (OLAP).

Downsides

That CustomerIdentity base table needs to be very lean. You might run back into discussions about adding fields. This will require discipline, but it’s way easier compared to the CDM version. Domains can duplicate common fields (FAX in Sales AND Shipping). Not an issue, storage is cheap.

You will have to avoid the best category of bugs: racing conditions. Yes that’s an issue. We have been writing and dealing with them since the first computer systems. Stick to good practices, and it’s not the death sentence everyone always claims it is. ³.

These nightly syncs need to be thought out, especially if you are in multiple (all?) timezones. This is something you can fix with queues. You’re using them anyway for your events.

Data architecture is very personal

Please don’t go out there and implement this like I’ve written it out. This is not a one-size-fits-all approach. This post is more to give you an insight in a possible architecture.

There is so much more to really dig in into this approach. But for now it can just be a nice thought experiment and maybe part of this can be somewhere in your toolbox for when you might ever need it.

I would go even further and say that I see a resurgence in their usage in big enterprises. Even companies that moved away from them seem to have a renewed appetite. Sometimes they are rebranded as integration platforms / iPaaS, but they are still very much the thing under the hood.

This seems like the perfect opportunity to write an article about what they are, how to use them and what the pitfalls are. From an enterprise architecture point of view that is, I’ll leave the integration architecture to others.

Enterprise service buses can do very technical things, but that is not what I want to focus on today. I know there are real upsides (and downsides) to the translation layers in these tools (for example), but today we want to focus on what the business value is of using an ESB.

What is an ESB

When people ask me what an enterprise service bus (ESB) is, I like to use an airport metaphor.

You can see an ESB as an airport hub, specifically one for connecting flights. An airplane comes in, drops their passengers, they sometimes have to pass security, and they go on another flight to their final destination.

Most people like to have a direct flight, but from an organizational point of view it makes sense to have a lay-over. You can bring people from New-York to London, and then plan flights from London to places in Europe. Not everyone from the original flight in New-York wants to go to Milan, but other people from other flights might want to.

So what does that all mean in a technical sense?

An ESB is a mediation layer that can do routing, transformation, orchestration, and queuing. And, more importantly, centralizes responsibility for these concerns.

In a very basic sense you connect application A to one end of the ESB, and application B & C the other. And you only have to worry about those connections from and to the ESB.

graph LR
AA[Application A] --> ESB
ESB --> AB[Application B]
ESB --> AC[Application C]

The big upsides for the organization

With the basics out of the way, let’s focus on these other aspects. But let’s focus on them from an organizational point of view.

Decoupling at the edges

Say you want to replace an invoicing tool. This is probably not a small operation. You will have to see what processes run in this tool, what data supports these processes, and how to get them. Once you have all that, you will have to make a gap analysis versus the new tool. This will include work on all the applications that feed the invoicing tool this data.

graph LR
AA[Timesheet tool] -->|Timesheets| InvoiceTool[Invoicing tool]
Ab[Employee Database] -->|Employee Information| InvoiceTool[Invoicing tool]
AC[CRM] -->|Client Information| InvoiceTool[Invoicing tool]
AD[SAP] -->|Project Information| InvoiceTool[Invoicing tool]

Now if you were to have an ESB in place for this, you would only have to focus on the ESB to Invoicing tool part.

graph LR
AA[Timesheet tool] -->|Timesheets| ESB
Ab[Employee Database] -->|Employee Information| ESB
AC[CRM] -->|Client Information| ESB
AD[SAP] -->|Project Information| ESB
ESB --> |Invoicing Information| InvoiceTool[Invoicing tool]

Next we have to focus on what the new invoicing tool needs in terms of information. If it’s the same, but with different field names, that is all handled in the ESB, and we would not have to touch the other applications. This drastically reduces the blast radius of change.

If we require extra information, we would still have to touch the connections going to the ESB, but it would only be to add fields. We don’t have to worry about REST vs SOAP vs FTP stuff. As that won’t really impact downstream.

Centralized integration control

An ESB can also give you more control over these connections. Say your ordering tool suddenly gets hammered by a big sale. The website might keep up, but your legacy orders tool might not.

Situations like this break down at the weakest link. You can work around that with smart architecture, but you don’t always have control over that with SaaS or legacy tooling.

Here again with an ESB in the middle you can queue these calls. Say everything keeps up, but the legacy mail system can’t handle the load. No problem, we keep the connections in a queue, they are not lost, and we throttle them. Instead of a fire hose of non-stop requests, the tool now gets 1 request a second.

That is not ideal from a product point of view, people have to maybe wait 10 minutes for their order confirmation, but the sales went through. The people will get their product they bought, and you don’t have the awkward conversation with the leadership about how we lost a bunch of money from lost sales from the architecture that wasn’t up to par.

The focus is on absorbing variability at the platform level instead of the application level.

Operational visibility

If, in theory, all connections go over the ESB ¹ you can also keep an eye on all information that flows through it. Especially for an enterprise architect’s office that’s a very nice thing.

You can have with little effort an overview of everything that is connected and what data flows over it. You integrations teams will now have deep knowledge about all the connections, something that normally is spread out over different teams and tools.

Also from a security point of view this is a big win. You have an overview of all connections and what they all use as standards, a perfect starting (and tracking) point to modernize them. Without messing up all the other connections.

But that is all in theory

All of those upsides are very true. But that’s only the case if you go all in and are very strict in how to use them. And that’s where a lot of the bad experiences come up.

Hidden business logic

Take for example that translation layer. Your source has a firstName and a lastName field, but your sink only accepts a Name field. OK, no problem name = concat(firstName, ' ', lastName). No harm done.

But then for American users it needs to be with middle names. So we might get an if/else in there. And then for Asian users it’s last name and then first name. That if/else is now a switch.

Before you know it you are writing business critical logic in a text-box of an integration layer. No testing, no documentation, no source control …

In reality, you’ve now created a shadow domain model inside the ESB.

This is often the core of all those “ESBs are dead” posts.

Tight coupling disguised as loose coupling

Yes you can plug and play connections, but everything is still concentrated in the ESB. That means that if the ESB is slow, everything is slow. And that is nothing compared to the scenario where it’s down.

You are also putting all your eggs in the same basket for vendor lock in. If you have a few hundred applications connected to this central platform, what are you going to do when they hike the price 50%? Decoupling all of these applications away from this central layer is going to be a momentous undertaking.

You could always build one yourself, but that is again a team that needs to exist and building an ESB from scratch is a huge undertaking². Not something I would recommend for non-tech companies.

If you are not explicitly willing to run an integration platform as a product, you probably shouldn’t build one.

Skill bottlenecks

You can always train people into ESB software, and it’s not necessarily the most complex material in the world (depends on how you use it), but it is a different role. One that you are going to have to go to the market for to fill. At least when you are starting to set it up, you don’t want someone who’s never done it to “give it a try” with the core nervous system of your application portfolio.

If you compare it to point-to-point connections, those are done by software developers. Be it Java, .net, JavaScript,… profiles. You already have those, and they can jump in from another team if there is a time crunch³.

Cost

It goes without saying that you pay for this service. Some companies charge per connection, others per data usage. There are different cost strategies.

This is an extra cost you would not have when you do point-to-point. The promise is naturally that you retrieve that cost by having simpler projects and integrations. But that is something you will have to calculate for the organization.

Modelling an enterprise service bus

Now how do you include this in our meta-model. This is actually also a discussion point. Is this an application or a platform or a system? My suggestion is (like in the case of Entra/active directory), map it to your connections. Let me explain.

graph LR

Application1 & Application2 & Application3 <--> ESB
ESB <--> Application4 & Application5 & Application6

If you map your ESB as an application you will quickly run into this diagram. Everything is connected to the ESB, and every connection goes out of the ESB. It’s impossible to track what actually goes where.

You could argue that that’s not an issue, as you can indeed connect everything in the ESB and see it as a data source. But the value of your diagramming will be useless then.

ESBs collapse many architectural concerns into a single box, which breaks most modelling conventions.

What I like to do is (and most EA tooling allows that) is to add parameters to the connections. One of these parameters is the type of connection⁴. I then colour code these connections. For example, all orange connections are ESB connections.

graph LR

Application1 <==> Application3
Application2 ==> Application1
Application2 -.-> Application4
Application2 -.-> Application5
Application5 <-.-> Application6

linkStyle 2 stroke:#ff6600,stroke-width:2px
linkStyle 3 stroke:#ff6600,stroke-width:2px
linkStyle 4 stroke:#ff6600,stroke-width:2px

But that all depends on the type of diagram you want to create.

When to use an ESB

Enterprise service buses only make sense in big organizations (hence the name). But even there is no guarantee that they will always fit.

I would only really advise using them if your application portfolio is relatively large and is changing often. They also mainly shine when there is a mixture of SaaS, legacy, and more modern in house applications.

If your portfolio is full of homemade custom applications I would maybe skip this setup. You have the developers, use the flexibility you have.

There is also the funding aspect; these setups add another cost that is not always clear at the beginning for most organizations (if you pay per MB, it can be really hard to grasp how much GB you are shipping over these connections).

So yes, I’m sure I’ll read another post on Reddit in a few months about how enterprise service buses are a thing everyone should avoid, and everyone is going to be sharing their horror stories in the comment section (some of these are pretty good). But I’m sure I’ll be seeing ESBs for years to come at all big organizations. Even if it has a new name or logo this time around.

So yes, you can map the AS-IS. You can design the TO-BE. You can even claim you’re doing both, which is the classic architect escape hatch.

And I had to be honest with him, it was mainly a throwaway joke poking fun at the fact that most architects when they get a question, the first thing they will answer is “it depends”.

But that mail exchange stuck a bit in my mind over the holiday break. Enterprise architecture claims to bring clarity, but often hides behind ambiguity. And maybe that’s something we need to confront.

Borrowing YAGNI from the developer world

When I was a developer², I was always attracted to highly opinionated libraries and frameworks. I always preferred a single way of doing things, over three different ways to do it, and they all have their pros and cons.

Even if that way of doing it was not how I would personally do it. I know that the person that made the library or framework thought about it deeply, came to the conclusion “this is best”, and fully supports and documents that single way.

It just makes the framework or library easier to talk about and understand.

This is part of the YAGNI (You ain’t gonna need it)³ mindset. Don’t start covering and building scenarios that might or might not actually happen in the future.

Translating the same ideas to enterprise architecture would be the typical preparations that we build into systems for future strategy. Building a new application has connections for data in the form of a REST API, but also building an optional sFTP part in case that you have to connect some legacy tool to it in the future.

flowchart TB
    subgraph Opinionated
        direction TB
        Application[ERP] ===> intA((REST Interface))
        Application[ERP] -.-> intE((Potential future sFTP Interface))
        intA ==> AppA[New Application]
        intE -.-> AppB
        AppB[Old application that we might connect in the future]
    end

    subgraph Unopinionated["Just in case architecture"]
        direction TB
        ApplicationB[ERP] ===> intB((REST Interface)) & intC((sFTP Interface)) & intD((GraphQL Interface))
        intB ==> AppC[New Application]
        intC -.-> AppD
        AppD[Old application that we might connect in the future]
    end

That is very unopinionated software. How do you connect to this application? Ah, here are the options.

That sounds nice from a service point of view. But if everything is internal, that service that you provide to other applications is going to cost a lot of money in development and maintenance of these options. That lack of strategy at this level will also make your entire application landscape less coherent, as there is no unified way of working.

“It depends” as architectural debt

Don’t get me wrong, I’m not advocating here for abandoning backup plans and putting all your eggs in one basket. What I am advocating for is architectural courage.

Are all these “it depends” and “future-proofing” mantras there to get to a more correct solution, or just there to minimize your personal responsibility if it all goes haywire?

If it’s the latter, you have to ask yourself what the value of that architecture really is. If the business leans on your expertise to set up a project and for every decision you have you just cover all options, there is no real point in your expertise. You are just another meeting and checkbox in an approval process.

You also have to calculate the cost of it all. In the above senario where you cover all your bases and build a REST API and an sFTP connection because “you might need it in the future”, you will have to maintain, secure, document, train and test both. For years to come. Just another think that can break.

That would be ok if that senario actually plays out. If the company strategy changes, and the company never connects the two applications, all of that has been for nothing.

In the case of not optimizing ahead of time for that senario (but still keeping it in the back of your mind). You can just implement it when it’s actually needed. There will be a lower cost, the company will have appetite for the change, and you might have a clearer view of the actual data that will flow over the connection.

xychart
    title "Cumulative Cost: Upfront Optionality vs. Adapting when needed"
    x-axis "Time (Years)" [Y1, Y2, Y3, Y4, Y5]
    y-axis "Cumulative Effort/Cost" 0 --> 100
    line [20, 40, 60, 80, 100]
    line [10, 20, 30, 50, 70]

The myth of “easy swapping”

Then there is the conversation of the easy-off ramp in implementing new software.

When implementing new applications, you already prepare for ways to off-board the application by making your systems hot-swappable or technologically agnostic. Even going as far as having applications that can use whatever data-provider or environment.

A lot of architects will tell you that’s an essential part of architecture.

You can do these things with enterprise-service-buses and interfaces or gateways, maybe even front-loaded microservice middleware. There are more technological options than you can imagine, and all of these are great conference talks.

The problem is, like in all nifty architectural setups, the actual users. It’s cool that you can hot swap your incoming data from one service to a different one in less than a week! Now we just need six months of new training, new processes, new KPIs, new goal setting and hiring to use said new data source.

Technology can be made swappable, but organizations almost never are.

Besides that, how often have you actually ever swapped a database in a system? I know ORMs are great, but the entire claim that you can swap back and forward from MySQL to MongoDB has always been a moot point to me. You build applications with a certain flavour of data storage in mind, why would you suddenly want to change over to a total different flavour?

Please remember that you can always change setups in the future. That is part of the entire agile way of working that companies like to talk about.

Choosing a side

I’m not suggesting we should all become architectural “dictators” who refuse to listen to edge cases. But I am suggesting that we stop being so deep into “what-if” and start focusing more on “what-is.”

The next time you’re sitting in a design session and that familiar urge to build a “just-in-case” abstraction layer hits you, pause. Ask yourself: am I building this because the business needs it, or because I’m afraid of being wrong?

Being opinionated doesn’t mean being rigid, it’s more about actually having a plan. It means having the courage to say, “This is the path we are taking because it is the most efficient one for today.” If the strategy changes in two years, you deal with it then, with the benefit of two years of lower maintenance costs and a leaner system.

And the thing we often forget is that the business hates all of these “what if” senario’s, they just don’t care about it. They mainly want it to work. If your “opinionated” choice needs to change later, they won’t remember the technical specifics of why you didn’t build three different API types. They’ll remember that you got the project live on time and it worked when they needed it.

So, let’s stop taking the escape hatch of “it depends.” Pick a lane, document it well, and build it simply. I promise, the sky won’t fall and your application landscape (and your sanity) will thank you for it.

We as architects might actually be to blame for this. We keep on coming up with related concepts that are very close to each other and then naming them ever so slightly differently.

I think this could be a fun pair of concepts to dive into as it touches some deeper architectural ideas. So let’s learn when you stream and when you chain.

What is “Value”

We cannot start talking about Value Chains and Value Streams before we actually know what we are going to chain or stream. In the context of TOGAF and ArchiMate, “Value” is not just money; it is the benefit a person or a group of people get.

This can take many forms. It can be financial; selling a product for money. But it can also be producing that product (the value is having a product) or providing a service (hiring a person).

If we are talking about value, the “who” is critical. This can be a person or a group of people. You cannot have value if nobody actually finds it valuable¹.

In the case of hiring a person, you have multiple people that get value: The team that now has more people to handle the workload, but also the person that is hired as they now have a job.

And how do you stream said value?

To achieve value, we break the path toward the outcome into stages. At each stage we add (ideally) incremental value, where the final stage should bring the promised value.

If we map out what we actually do in organization, we can measure it. We can add SLAs ² to the stages of the value stream. This ensures a standardized quality outcome. We formalize the way we work in an organization.

This might feel like a business process, and there are indeed overlapping ideas. A value stream is more the rough outlines. It is however a good idea to link your business processes to these parts of the value stream. So you can start tracing them down towards processes, software and roles. ³

The nice thing about value streams is that it slices through the organization. Something a business process is too specialized to fully do.

To onboard a new customer, you lean on different business units working together to actually fully onboard the new customer. You will need the legal team to help with the contract, a project team to set up the project, a finance team to set up the billing…

If you see that your onboarding of customers value stream doesn’t work that well, you don’t go blame the legal team because they take too long to go over the documents. You look at the entire stream to see where there are bottlenecks.

This is how you often discover issues like missing or late information to the right teams.

Then what is a Value Chain?

Enter Michael Porter and his book Competitive Advantage, where he coined the concept of the Value Chain.

In the book, Porter takes the organization as a collection of distinct activities that, when combined, create profit. We then take these activities and group them into “Primary Activities” (like Inbound Logistics, Operations, Sales) and “Support Activities” (like HR, Technology).

This mean that you have units that create direct customer value, and units that support the primary activities in creating value. These support activities create just as much value, but they have a different client: the primary activities.

By mapping an organization out like this, you can take a deeper look at the units themselves and how they work and create value. All at a deeper detail compared to the overarching organization that has a too broad overview.

The total outcome of these groups is a Value Chain. So every organization has one Value Chain. Some organizations use sub-value chains, where every activity has their own value chain, but then we are getting dangerously close to Values Streams again.

But aren’t Value Streams and a Value Chains the polar opposites then?

You might have noticed that a value stream brings a view of an organization working together to create value, where a value chain is creating silo’s and breaking an organzation apart.

That’s correct, but they solve different functions and contexts.

Porter’s Value Chain describes how the organization thinks about its strategic functions. They focus on the work inside each business unit and how it can be organized and optimized. Very siloed, and vertical.

Value Streams, on the other hand, describe how the organization actually delivers outcomes across those business units. They follow the processes for start to finish.

They are perpendicular viewpoints. Different lenses of looking at the work.

… Sadly, there is an extra layer of confusion.

And then there is IT4IT

So IT4IT storms the scene in 2015 and takes the idea of the separate units and dials it way up.

In this setup we take an IT unit and give them their own value steams, business capabilities, processes … basically everything a full organization has. This feels like the opposite of the previous section, because IT4IT decomposes IT into its own set of value streams and capabilities.

IT4IT splits the IT function into four end-to-end value streams (Strategy to Portfolio, Requirement to Deploy, Detect to Correct, Request to Fulfill). Each of these Value Streams is an implementation of other IT practices like SAFe, ITIL and even TOGAF ⁴.

Whether that’s a good idea is not part of this post.

So in short

Value Streams and Value Chains are different concepts that handle different things.

If you are looking at end-to-end flows, you will be dealing in Value Streams. Here we try to map out these streams to optimize them and add SLA’s. They cross business units so when you improve the maturity of one of these streams you handle multiple teams.

If you want to optimize the inner workings of business units themselves, you will be dealing with a Value Chain. These look at what a business unit does, how it does it, and what it needs. That value is combined into a Value Chain.

If you’re working with IT4IT, you model the IT department almost like its own miniature enterprise, complete with its own value chain and value streams.

If you start up an enterprise architecture office, you have two types of strategies people use. Some people start by mapping everything that exists, in whatever state it happens to be. They then assess what they have and start building a gap analysis towards a better, more uniform state.

The other group of people start at the end point and work their way back. They sketch out the ideal state and map out the bare essentials towards getting there.

The funny thing is that this is one of the few times that architects don’t say “it depends”. Most people have a very clear preference for one approach or the other.

Let’s see how each approach works.

Please note: this article is mainly based on the business layer and strategy layer of enterprise architecture. So most of this discussion will be about things like Business Capabilities, Operating models, Value streams and the like.

Mapping the AS-IS.

My guess is that if you’re tasked with setting up a new architecture office, the chances of the organization having a high architecture maturity are rather small.

That means that they might have a CMDB with applications ¹ or an Excel file with a list of applications they use. They might have business lines in an organogram or some home-grown interpretation of capabilities or an operating model.

In the case of mapping out the AS-IS this is now your hunting ground. It’s time to start interviewing people and hunting schemas and PowerPoints.

You will quickly find that whatever frameworks or models you’d like to use won’t fit the structures you’ll find. And worst of all the information you’re finding is incomplete and incompatible with each other.

You might find business units that are linked to applications in the CMDB that are totally absent in the business units section of the strategy slides of a C-suit strategy meeting.

This is OK, you are mapping out the current way the organization works. If you find incompatibilities, that’s actually a good thing. You are already creating value by pointing that out.

Once you have gathered “everything” ² you can call that your baseline. Then it’s time to try to mould this towards a structure that fits together. Connect the free-form jazz version of a capability map you found in a slide deck somewhere to industry standard value streams.

Once you have an overview of things you’ve designed (or used standards for) to the things you have found, you can start to clean up and improve the AS-IS. Slowly but steadily towards a more mature model.

The big upside of this approach is that you are working with terms and information that is familiar to the organization. People will recognize the works you are linking applications and business units to, as they probably use them themselves.

Going straight for the TO-BE.

The second option is not to bother with anything like that at all. If you’ve gone through this ordeal once, you know it’s a frustrating exercise.

You will not find a capability map, you will find six. And the same people who use one of those six capability maps will happily create a seventh in their next strategy meeting.

That also means that the concepts you find aren’t actually carried or used in the organization. If you find a value stream outline in a management slide, chances are that’s the first and the last time those value streams are shared.

Furthermore, the chances of these structures being made by a single person in half a day before a big meeting are also high.

The idea of skipping the AS-IS altogether comes down to: why base our architecture on structures that are not only, very low quality, they are also probably not carried in the organization.

It will take you, at least, six month to interview and gather all the stakeholders and information. That is an investment of six months into something that you want to move away from.

So here you start with your ideal structure that is based on frameworks or industry standard work. Things you know fit together and where, if you open an enterprise architecture book, you will recognize.

You will have to explain all these concepts and structures to the people you work with, but that was always going to be the case. The big difference here is that you are going to explain structures that you know are sound, and don’t have to explain very shaky company structures that you found somewhere in a slidedeck from five years ago by some guy that doesn’t even work here any more.

And what about applications, servers, and data?

I mentioned in the beginning of this article that this post is about the business and strategy layer, but I wanted to briefly touch on this as well.

Always use the AS-IS.

I’ve seen people, when there was a big migration or merger going on, try to get away with only mapping out the TO-BE. That’s a mistake.

Situations like migrations and mergers are where architects can bring a lot of value, it’s often when they get hired.

Ignoring the entire setup because ‘it’s all going to change soon’ is skipping the work where architects can actually provide the most value.

My experiences with both.

As mentioned before, I’ve done both in my life. When I started out in EA, I thought it was madness to just ignore the AS-IS of an organization and just dive into something totally new. I found it very arrogant to be honest.

Now that I’ve had a bit more experience, I’m starting to realize that if an organization has low maturity in these things, it’s often not something that is very close to their heart. So why try to shoehorn these concepts into your strategy.

That being said, I’m still an architect, so I have to say: It depends³. If you walk into an organization, and you see that senior leadership is constantly talking about their value streams. You should obviously adopt those. Even if they don’t make sense or don’t fit the frameworks you’re used to.

The same with capability maps, if they are using a capability map as a central structure to report on, don’t try to swap it out with a better one. They will never adopt your suggestion.

So here are my suggestions. See what’s actually being used in the organization. If they work around a certain structure, adopt that AS-IS. You’re not going to win that fight. But make the surrounding structure yours.

That means that if they have well-defined processes, you can link these to your own capability map to track maturity and report back on those. Don’t go searching in archived PowerPoints for some capability map you might or might not find.

So yes, you can map the AS-IS. You can design the TO-BE. You can even claim you’re doing both, which is the classic architect escape hatch. But you will always have to convince people about the concepts you’re using, even if it’s concepts the organization is already using.

If something already exists and people use it, adopt it. If everything is a mess and nobody agrees on anything, skip the archaeology and design something that makes sense to you.

The rest is just iteration.

The CMDB is our source of truth of all the applications, servers, and it’s all linked to service lines and capabilities. Furthermore, it’s maintained by a team and it’s fully ITIL aligned. It’s a treasure trove!

All of that is true. But the CMDB is a horrible place to base your architecture upon.

What is a CMDB?

A CMDB is a catalogue in a ticketing system. The market leader in this space, and the one I keep bumping into, is ServiceNow.

These platforms started out as a way to support and track helpdesk/support issues. You have an issue with some software or hardware, you log a ticket in the system, and the engineers can get to work on that ticket.

Over time we all wanted more insights into these workflows so we started to add inventories to this process. A list of applications to link the bug or issues to, a list of service lines that needs to follow up on the ticket, the environment and server the application runs on, …

These days, applications like ServiceNow have so many extra inventories that it could do every thing in an organization … in a very mediocre way.

All of these lists are there to support the workflow of incident/change/bug/problem.

If you look at these inventories, you can quickly see a lot of the same material we use in architecture. It has a list of applications, this can be used as our application portfolio. These applications are linked to servers and environments, great, we already have a big part of our technical landscape mapped out!

These applications have owners, service lines and teams? Great, we have a business layer.

The issue appears when you take a deeper look at what’s actually in these lists.

The conceptual mismatch.

Different definitions

If you take a look at the applications in the business application list you will start to scratch your head as an architect. You will bump into Word plugins, Excel sheets, websites, and even multiple parts of the same bigger application.

The same thing with Service Lines and Capabilities. Why does marketing have five service lines and IT thirty-five? Why are all these capabilities just things that IT does?

The answer is very simple, cause those are not architectural lists, they are lists to handle tickets and support issues.

They use the same words but with very different meanings.

If your business application list contains macros and Word plugins, any attempt at portfolio analysis becomes meaningless.

Different rates of change

Every time a ticket comes in to a system that is not yet in the CMDB, a new business application will be created. If that new system does something that is hard to link to a current capability, there will be a new capability.

If it turns out that it’s very important, a new team and service line might be created in the CMDB to support this.

The opposite is also true. If we no longer use an application, that can result in the removal of entire service lines and capabilities.

All of this can be done in the span of weeks. I’ve seen capabilities created on a Monday and removed by Friday because someone needed the ticket to route correctly.

You don’t want to base your enterprise architecture on capabilities that come and go.

Why are these lists so volatile?

The answer is very simple, cause those are not architectural lists, they are lists to handle tickets and support issues.

Different Structures

Say you see information on the server layer of a CMDB that would actually be more suited on the application layer. Think of a version number of the application that runs on the server.

Moving that field to the application layer and removing it from the server layer would be a dangerous move. All of these lists have entire workflows behind them and are deeply relational. Moving a field might break structures all over the system.

The people that manage the CMDB know about these workflows, but you don’t. It is a different domain after all.

Some of these fields that seemingly make no sense are actually mandatory from an ITSM point of view. They might even be duplicate fields on different layers with different information.

Why is this all so messy?

The answer is very simple, cause those are not architectural lists, they are lists to handle tickets and support issues.

What using the CMDB as your architectural source of truth implies

Don’t get me wrong, you can base your architecture upon this entire system. But in that case, you also have to realize the deeper implications.

If you take the structure of an IT service management as your base, you also position your entire IT department as a service to the rest of the organization.

Architectural models shape how an organization thinks about itself. If your model is rooted in ITSM, then everything becomes framed around incidents, support, and change control and not strategy, capabilities, or value creation.

Application rationalization, Capability maturity, and ROI calculations are out. Your main focus will be IT-architecture.

I do use the CMDB as an information source

It would be madness to start from scratch. You can’t just ignore all the information that is in a CMDB and go to every department and ask them what applications, services, and connections they have. That would be a massive waste of money.

CMDB teams do good work, it’s just a different domain.

I sync my enterprise architectural tool with ServiceNow ¹, But not one to one. I sync the basic information: Name, description, technical/business owner, and other similar information directly to my business application components.

Then filter out the applications that I think are not (architectural speaking) business applications ².

The capabilities, Service Lines, Business Functions I skip. These concepts are often too incompatible so that’s full manual work.

The other information that might be there in physical application layers I sometimes sync with a bronze data layer. A separate section in my architecture tool that is “dirty”. If your EA tool supports scripting, you can maybe start cleaning it op and sync it to your “clean” sections. It’s regularly not clear if the value is there.

Integrations I never sync. These are too important and too central to a metamodel to just blindly take over. They can be wrong or outdated. They can be incomplete (they just map what is needed to handle the ticket), or very workflow specific.

Stop trying to make the CMDB something it isn’t

A CMDB is a critical part of an IT organization, just as a tool like ServiceNow³. But these tools are there to fill a specific role, and that role is not enterprise architecture.

It’s very easy to look at these repositories and think that you don’t have to do the hard work of gathering all that information. But sadly, that’s not how it works. Believe me, I’ve been there.

Your architecture tool should not ignore all the information that exists in these applications, but you should be very aware of your source.

If you are just making a carbon copy of your CMDB, you might as well directly do your architecture in ServiceNow. And I’m not sure whether you’re going to have a great time. You will be fighting the tool and structure more than you’ll be doing actual architecture.

Architecture should be able to evolve as the business evolves. A CMDB can’t follow you there.

We always made a distinction between code debt and architecture debt: code debt being the temporary hacks you put in place to reach a deadline and never remove, and architectural debt being the structural decisions that come back to bite you six months later.

While I agree that implementing software patterns like the strangler pattern or moving away from singletons is definitely software architecture. Architectural debt goes way beyond what you find in the code.

How I see technical architectural debt these days.

As an enterprise architect I still mostly complain about architectural debt and estimates that are seen as deadlines. That much certainly hasn’t changed.

These days, I’m less concerned with how the software itself works. That’s just not feasible when your organization has hundreds of applications ¹. My main concerns are more about how these applications interact with the rest of the landscape. How the data flows, where data lives, whether there are bottlenecks, who’s going to maintain it, and what role will this application have in the future.

In an enterprise environment this is inevitable. There are so many applications and more than half of them are 3rd party SaaS applications. You need to keep on top of what you can control and let go of the parts you can’t.

The layers of architectural debt

But architectural debt goes way beyond the technical layers. Enterprise architecture is not technical architecture ².

And yes architectural debt can cost an organization a lot of headaches, but architectural debt on business and strategy layers can do even more damage.

Let’s dive into the issues at every layer.

Application / Infrastructure layer

As discussed in the intro, EA shouldn’t focus on the code level. I think that’s the job of software developers/software leads. They are in the code day to day, you are not. You can suggest software patterns or ideas (think event sourcing for applications that could be in the problem space), but they decide how they want to structure and maintain the code.

Instead, I focus on things like integration patterns. Do we still drop files over sFTP while also using a REST API? Maybe we can bring everything towards REST so we have a unified approach.

What about the systems we have running, what do they do? If there is overlap in functionality, then we can bring them together. Say for example file storage (a classic example). You might have free Sharepoint storage with every Microsoft account, but you might also rent storage space at AWS. Perhaps you could combine those.

And don’t forget about vendor lock-in. Finding the right balance between getting a discount for getting a lot of services from the same vendor, and them locking you in and holding your systems hostage behind huge migration costs is a real problem a lot of companies struggle with.

At this layer all the debt directly impact operations. Costs go up and time of delivery increases.

Business layer

Just like in the application/infrastructure layer we are not focused on the details. We don’t care about how many people work in what department and how the roles are defined.

What we are focused on is things like ownership and stewardship. If an application or process goes down, if there is a data leak, who are you going to contact?

Who are the people you need to get in a room if you want to modernize a department? Sure, you want to talk to the head of the department and the stakeholders of that department, but every department work with other departments. Just like applications, these processes, and flows are interconnected. You don’t want to modernize the processes of one department and break the day to day of five others.

What about outdated or phantom processes? If you give a new hire a business process overview to help them learn their role, and that documentation is wrong, that’s unpleasant. What’s even more unpleasant is if instead of a new hire, it’s an auditor.

So at this level it’s more about documentation. Outlining how departments work, who does what and what they need to do their job. If people work under wrong assumptions, they will also start projects under wrong assumptions. They will already be on the back foot before they start.

So here again it’s about cost and outside risk. Issues here will multiply issues on the operational side.

Strategy layer

An enterprise architect doesn’t build strategy, they assist the people that define the strategy.

To do that however, you need to have your rows in order. The better insights you can provide, the better the outcome (potentially) will be.

The main issues of debt here are mis-definition and half frameworks. I’ve waxed on and on about the value of Business-Capability maps³ for this exact reason.

If you want to understand what your organization is good or bad at, you can do a business capability maturity map. A huge exercise where you go over every capability and rate them with a scoring of chosen parameters.

Every capability now has a score, and we can start looking at what areas we need to focus on and improve (if they fit in our strategy for where we see the company).

Great! But what if we defined the capabilities wrong? Maybe the map is outdated, or it’s not a capability map at all but just a silo’d business department overview. In that case, you’re going to base your strategy for the next 3-5 years on wrong assumptions.

Debt at this level can have enormous long-term consequences. This is what blocks transformation exercises and could even make bad long term strategy look appealing.

Tackling architectural debt

Luckily, there’s some good news: unlike developers, enterprise architects have the time and visibility to flag architectural debt. We have the time and resources to create dashboards and gather proof of what is going on. We also have access to the right people where we can plead our case to.

And that is also how and what we should do. Showing misalignments to a CIO or COO is easier with a PowerPoint or dashboard, than with a God class that you want to refactor into a command-bus pattern.

Keeping stock is key. I have in my architecture tools clearly laid out what I consider debt. I also have a list in my notebook of things I want to tackle and the order in what I want to tackle them in.

Building that case is bringing all the data you have gathered together, an AS-IS and a TO-BE, and a business case of what the improvements would be, and the risks of not handling it.

From there, it’s mostly about picking your battles. There are places where it’s easier to tolerate architectural debt, think for example of a system of innovation versus a system of record. ⁴ You can tolerate it more in innovation projects than on core sources of truth. On the condition that they’re handled once the innovation period is over.

Also be prepared that most often you will get the answer: OK, you can go out and fix it. So be sure you have the bandwidth to actually go out and fix it. The debt will not just disappear by you just flagging it.

I came armed with slides, data, and what I thought was a solid argument, only to realize halfway through that the decision had already been made. The executives weren’t just leaning toward the other solution; they were quoting that team’s talking points word for word.

Everyone’s mind was already made up, just not in my favour. They’d clearly done the groundwork and convinced every one of their approach long before I entered the room.

It took me a while to realize what had happened.

What happened is called Nemawashi. A Japanese term literally meaning “turning the roots”, referring to preparing the soil before transplanting a tree.

Not something that is unique to Japanese culture.

The myth of the meeting room.

Nemawashi can be seen as backroom politics, but that shouldn’t be the case. The idea is that you check in before a big decision with all the stakeholders and go over all the points one on one. Making sure everyone fully understands what needs to be discussed and where everyone stands.

Afterwards, when the real meetings start, everyone is fully informed, had time to think it over and there are no surprises. That way there are no open disagreements and losing of face, everything is discussed in private.

The big meeting room gathering is more of a ceremony to adopt the solution.

This seems like a big time waster, but you have to think to yourself how many meetings you’ve been part of that resulted in a big emotional discussion that goes nowhere. It’s not easy to have the data ready to defend yourself to a discussion that ambushed you. And while people are arguing and trying to find the data, the rest of the meeting is just waiting for the follow-up meeting to further discuss the way forward.

Of course, this can look like office politics if done badly: if it’s about exclusion instead of inclusion. But that’s not Nemawashi.

The point isn’t to stack the deck, it’s to make sure everyone had a chance to play. Just look at the intro of the post. One person (or group) was left out of the discussion, and it’s an unfair fight.

But that’s also because the other side didn’t partake in the practice.

To me, we sometimes see meetings as a race for quick wit and eloquence. You go to a meeting room, and you all get the same information to a problem at the same time and it’s Ready, set, go!

The first person to quickly and convincingly suggests a solution wins. It is not often you see people react with “hmm, I really need to think this over and look at some data”. That obviously happens, but in my opinion way too seldom.

This is how you get quick fixes that take the road of least resistance. If you have no data and time to think you will go for shallow solutions.

Nemawashi means celebrating the roots, not the fruit.

Another side effect of Nemawashi is that the big grudges fall away.

Humans don’t think well in public. We anchor to the first opinion we hear, we defend our status, and we rarely admit uncertainty in front of peers. Nemawashi respects that, it lets people think in private before they decide in public.

Open disagreements, especially when people are watching, can feel very confrontational. Walking into a meeting room and seeing the same people that you had a big emotional discussion with a few days ago will colour the mood of the meeting instantly.

The opposite is also true. It might not be the best idea to publicly disagree with your lead in every public setting. These are things that are best done before big meetings and signal a unified department to the rest of the organization.

Having a one-on-one with someone you don’t like, that has very opposing views, is probably also best done before the meeting. You will notice that a more informal setting will make these conversations more palatable. Especially compared to these kinds of meetings where the CIO or COO is also in the same room.

In the end, it’s also not about winning or losing. It’s about getting workable solutions out of the door. These often happen when everyone is heard and had time to check the data.

Less talking, more thinking

Ultimately this isn’t about some corporate secret cheat code to fix your meetings. It’s more a mindset switch.

The highest value decisions are not made in a sudden public performance, but made in quiet, deliberate preparation.

Removing the culture of quick-draw arguments and fast wit solutions in favour of more one-on-one data sharing and discussions will allow us to make more sustainable decisions.

This might all feel like a big investment of time. Way more than just one big meeting and maybe a follow-up. But you have to keep in mind that the time in meetings and one-on-ones is nothing compared to the time the solution will be in place.

I’d rather spend an extra hour at the coffee machine with someone, talking over a problem, than having to support a badly thought out solution for the next four years.

We get blamed for delivering these massive solution design documents that take weeks to produce, eat into the time for development and in the end result into an encyclopedia that nobody reads.

The architectural drive to document and cover as much as possible naturally evolves into templates that are in the 40–50 pages (template alone).

Something I think we should move away from.

Why compact Solution Designs work better.

If you’ve ever been tasked on filling out these massive templates, you know that they are a cooperative exercise. Sure, a lot of architectural meetings happen during the design phase, but some parts are filled in by people from the business and some are filled in by subject-matter experts (SME’s).

Often what happens is that there is a lot of copying and pasting from other documents and “not applicable”¹ sections. That’s expected, if it’s not your job to fill out these intimidating documents it’s very tempted to just go with the bare minimum and go back to your real work.

So here is my claim for compact solution designs: Let’s make them as lean as we can, while still covering the important parts, and add more information if the project requires them during the project phase.

That way, we have:

• Less copy-pasting from other documents: just reference them if needed.
• They are faster to produce, we don’t eat too much into development time.
• Easier to maintain: clear overview what goes where, and you can actually know the entire document.
• People actually read it: should be readable in an hour.
• People don’t get burned out on these overly complex documents.

What belongs in a good Solution Design

First we need to know who the core audience is for our document. In the case of a solution design this is almost always technical people that are going to implement the solution.

So what does a technical person need to know to implement a solution?

• What are we building?
• Who is going to work on it?
• How long do we have?
• How are we going to build it?
• how are we going to maintain it?
• What can I use?

This is an actual document that technical people want to read, as it brings value. Don’t go over licensing costs or vendor solvability in this document. That’s not the focus of the people that are reading that document at that time. Do capture it in a different document (business case) and if there is an impact on the project, reference it, just don’t include it in your base template.

If your document captures everything, it captures nothing. As people will not take three days out of their workday to go over the entire document. And even if they did, they will not remember it.

My Design Document structure.

My document is segmented in five parts, and they all cover different areas. The idea of the document is that everyone (technical) in the project reads it cover to cover, but it still categorizes information in chapters.

Introduction

This is the setting the scene part of the document.

I like to start with a summary of the business case. Not a full-blown six pages deep dive, rather an executive summary. Something like half a page.

A big who-is-who is always welcome. I think a RACI makes a lot of sense here. Don’t forget about 3rd party people and vendors. A timeline of the project would also fit here.

Application Architecture

The future state of the application goes here. This can go on for a few pages. I advise for the usage of diagrams over big blocks of text. Diagrams are easier to share and less intimidating to read.

The biggest challenge in this chapter is deciding the detail level.

It would be incredibly rare (if ever) that you should go to the level of ERD or class diagrams. Only if you are doing something incredibly exotic, you could maybe work a use case out at that level. But for everything else, it’s a bad idea.

You don’t have the upfront knowledge to work it out to that level, and it will change anyway during the project. Just trust your team to come up with a decent solution at that level during the project. They are hired because they are smart, so let them be smart.

The level I would focus on is the integration level. Container/Component level in the C4 model. Draw them out in a schema, annotate them in text below.

Data Architecture

This is actually something that I often see missing from those big solution architecture documents; the data layer. Mapping out the data that flows between integrations, what format, and mapping is really handy to know.

If you’ve labelled the connections in the Application Architecture chapter, you could use those labels to go over the data that flows between them. This makes a lot of sense to display in a table.

If you have an ESB (Enterprise service bus) a translation table could be a nice addition. What maps to what.

I think a subchapter on Identity and Access Management is probably also not out of place here.

Technology & Infrastructure

A lot of companies use standardized setup’s for their applications, but it’s not a bad idea to give an overview.

Again, the level of detail is something to keep in mind. Don’t dive into the nitty-gritty here (unless it is needed in this project), just give an overview.

Don’t forget to outline the different environments (dev, UAT, prod) and what is included in what.

Appendix

This is the it-didn’t-fit-in-the-other-chapters chapter. You could put architectural considerations/decisions here. “We know X is not the best way to do it, but we did it anyway for this and this reason.”

The takeaway philosophy

I rather have a less detailed, but still covering the essence, document than a fully encompassing document, that covers everything, but that nobody reads.

I wrote in the past about the role of an architect in a modern organization and I think this is very much part of it. Architecture offices shouldn’t be ivory tower groups that only produce big tomes of acronyms. They should be supporting teams with information about what is our strategy going forward and what is happening in different parts of the organization.

So slim down your documents and use that time to be more involved in the rest of the work. There are still a lot of questions that pop up during development that need answers, and people are not going to be looking for them in a document they forgot existed.

What people hear isn’t “we’re here to understand your work and make it smoother.”
What they really hear is: “We’re here to judge, strip the creativity, maybe even replace you with a machine.”

I very much understand where the sentiment comes from, but that is very much not the idea behind a standard operating procedures and process mapping. It’s actually quite the opposite.

What are SOP’s?

Think of an SOP as a cooking recipe. Not the kind you tear off the back of a meal kit, something closer to Kenji López-Alt’s style, the kind that tells you why every step matters with decent thought out details.

A good SOP covers the outcome we want, the steps to get there, the roles involved, and the expected result. Ideally, it also tracks updates and changes, so the process evolves alongside the organization.

In many industries like healthcare, security, manufacturing, … you don’t get a choice. Regulators require SOPs, and audits enforce them. That’s the compliance side.

Beyond compliance, mapping work across teams creates a kind of contract. Everyone knows what’s being done, how it changes hands, and what “done” really looks like. You create a shared understanding of not only your work, but also the work that comes before and after.

When new people start, you can use the SOP as part of their onboarding¹. This makes onboarding people so much easier and makes sure that there are no big hiccups in quality when roles change.

Stability Enables Creativity.

If I describe it like that SOPs sound like they box people in, giving the company all the control and leaving workers with nothing but routine. But that’s not the deal.

Let’s look at it differently, back to the recipe example:

Every Tuesday for years, you’ve made the same pot of chilli. By feel, no recipe needed. Then one day, you order chilli at a restaurant, and it blows yours out of the water. So you want to improve your version.

To do that, you require consistency. By standardizing the process: measuring ingredients, tracking steps. You create a repeatable baseline. And from there, experimentation becomes meaningful. Add espresso, swap peppers, try something new, and you can tell exactly what effect it had.

What we’ve described above is a form of Kaizen taking a process and, just by doing it, improving it very slightly to get a better result.

That is exactly what we want to achieve with work like this. We want to take a look at the work that’s currently being done, document it, and make sure the other work aligns to it by lowering the amount of overhead.

Focusing on the creative part.

And what about the day to day then? It’s nice that you can improve the flow, but you’re not going to improve the flow every day, what about the current job?

An SOP is not intended to map out the process 100%. It’s only intended to outline the base work. If part of your job is to go out and find the best vendors for retail, the SOP will not tell you what should be in your mails or how you do your market research.

It will just tell you to contact the vendors after you’ve done the market research. Maybe it can automate or streamline the boring parts of your job so you can focus on the interesting stuff.

If your job is fully standardized in a fully repeatable process that takes no creativity, problem-solving, or communication, then it might indeed be fully automated.

I personally haven’t seen a lot of those roles in a modern organization. In those cases I’ve always seen people being offered alternative roles (with re-training) that rely more on their problem-solving skills. You could argue that would be an upgrade.

SOPs as Memory of Innovation

If you keep a change log of your SOP’s, you also get snapshots of your organization over time, you’re building a time machine.

This is a very intriguing concept if you think about it. This can help explain, over the years, why some ways of working are in place².

It can even help organizations reach back to procedures of the past. Say that there is a housing crash that reminds everyone of the one we had in 2001. Well let’s look what we did in 2001 to counteract these issues and what effect they had.

You probably wouldn’t reinstate those exact processes. But by having that history documented, you gain insights that can inform today’s decisions. SOPs, in this way, preserve lessons that might otherwise be forgotten.

SOP’s as a way to cement your role

I use my mapped out processes to go to the rest of the organization to tell them what I can help them with. They function as an internal marketing tool for my department.

They also give me leverage. When I ask another team for data in a certain format, I don’t sound picky, I can point to the process and say, “Here’s the full process, and we use this format”.

I understand that there is a negative sentiment regarding process mapping and SOP, especially with the rise of LLM’s. ³. But I think it’s a reputation issue that focuses on the wrong perspective of the task.

They are mainly in place to automate the boring parts, so there is more focus on the important parts. And in regulated industries, they’re not optional anyway.

If you play your cards right, you can benefit greatly from documenting and reviewing them. They can make your job more interesting and give you extra eyeballs and tools in the future.

When they came back on Monday, they told us what the competition was doing, and laid out a brand-new strategy they’d dreamed up between hotel bars and expo booths.

That company no longer exists. Not because the strategies were wrong, or even the timelines. It failed because those plans were made in isolation, disconnected from a team that was already exhausted and out of motivation.

Projects execute strategy. People execute projects. And no project exists in isolation, they rest on everything that came before.

Strategy is not self-executing.

You can make the most perfect strategy and roadmap in the world, but if you don’t have the people to carry it out, then all you have a nice business case. An idea, not a project.

When we define projects, we often reduce people to headcount. “Three developers, one project manager, one ops person. Who’s available?”. But availability isn’t the same as readiness. A burned-out team won’t produce a winning outcome, no matter how strong the plan.

A good manager will look at the project and the team and assign people that might have done something like that before, or someone that can learn from the project. Yet we never look at the strategy or project planning phases if it is actually currently the right time to implement this based on the team’s morale or setup.

There is a famous book in management called “Playing to Win: How Strategy Really Works” by Alan G. Lafley. In the book the steps of coming up with strategy and how to implement it are described.

One of the steps in the process is “What capabilities must we have in place to win?”. The book mainly explores things like “do we have the right people and processes”, but It never seems to go very deep into, What is the status of said people and processes.

A Formula 1 car is built to win, but if the fuel tank is empty, you’re not exactly going to win SPA.

I hate the term “resources” for people.

People always look at me as I’m the biggest hippie alive when I tell them I prefer the term people over the term resources in planning meetings. It treats them as interchangeable units that reset after each project.

Teams provide continuity in your organization. Projects come and go, but the same people will handle them stay behind¹. They carry the learnings, network, and practices from previous projects, but also the energy level and issues. High or low.

Broader organizational context matters, too. A rumour of layoffs, true or not, changes how people approach their work. Some push harder to prove their value. Others disengage and update their CV.

Long before the first kick-off meeting, the tone of a project is already set by the state of the team.

Yes, but how do we work this?

As Alan Lafley reminds us: know your playing field. Strategy isn’t just about spotting opportunities, it’s about knowing when it’s the right moment to pursue them. Timing is as critical as vision. Acting too early can be as costly as acting too late, because execution depends not only on the market but on the state of the people who must do the work.

That doesn’t mean discarding ideas. Every organization should maintain a backlog of opportunities, a kind of “strategic inventory.” But treating that backlog as a to-do list to be executed immediately is dangerous.

The backlog is not a queue; it’s a library. Its value comes from being ready when the organization has the capacity and capability to act, not from sheer volume or speed of throughput.

When the timing is right, build the project carefully. Resist the temptation to fill roles by simply matching open availability to job titles. Instead, consider who has the relevant experience, who is motivated to grow, and who has the current energy to succeed.

Remember: a dysfunctional team produces a dysfunctional project. You can have the clearest strategy, the best tools, and the most generous budget, but if the team is exhausted, misaligned, or disengaged, the project will fail.

Sometimes the best move is to postpone a flagship initiative and focus on smaller efforts until the team is ready. It’s better to arrive later with a strong product than to rush something weak that damages both reputation and momentum.

In the long run, advantage comes not from speed alone, but from consistency, trust, and resilience. A delayed project can still succeed if it ultimately delivers value and strengthens the team. A broken project, delivered too soon, can erode customer confidence, damage reputation, and demoralize employees in ways that are far harder to repair.

Think of it as a hierarchy: IT at level one, Software Development and Ops at level two, and then individual teams, like: Software Team X or Ops Team Y, at level three.¹

What’s surprising is how rarely these structures reflect reality. In practice, I often see people from multiple teams collaborating informally on projects. Even more striking, these same ad hoc groups reappear in project after project, suggesting a pattern that isn’t captured in the formal architecture.

If you’re a bit familiar with domain driven design, you might see some parallels with Conway’s law. And that is exactly what we’re going to talk about.

Conway’s Law

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

This is Conway’s Law, most typically applied to software systems and products. In essence, products are a direct reflection of the communication patterns within the teams that created them. How they think, talk and view the world.

I want to take it one step deeper, I believe that organizations themselves are defined by these communication structures. As a result, the products they deliver inevitably embody those same patterns.

The challenge is that these communication networks are informal, fluid, and nearly impossible to map. Yet they are precisely what shape the outcomes.

How teams actually form

Here’s how it usually starts. You’re standing in line for coffee and run into someone from finance. A little small talk, a joke or two, and then they mention it’s tax season. They’ve hired a student to shuffle CSV files from one server to another by hand.

You blink. By hand? Why not automate it? You recall that Michelle from development built a similar integration recently, maybe you rope in a business analyst. Very quickly, what began as a casual exchange becomes the start of a new project. And a brand-new team.

This team doesn’t exist on any org chart. It emerges organically, based on who knows whom.

And once you’ve been part of a team like that, something else happens: the next time finance hits a snag, your name will be the first one they remember.

Communication patterns don’t just influence software design; they determine how teams themselves are formed.

The strength of weak ties

Sociologist Mark Granovetter described these casual, cross-cutting relationships as weak ties. In his seminal article, The Strength of Weak Ties, he distinguished between two types of connections:

Strong ties are the ones you lean on every day: your close friends, the teammates you talk with constantly. They’re steady, reliable, always in your orbit.

Weak ties are different. They’re the people you see now and then, the friend of a friend, the guy you bump into while waiting for coffee. They’re lighter threads, but they reach into places your strong ties can’t.

Your strong ties generally talk about issues and projects where you are also part of, your weak ties have an entire different world of projects. Where everyone in your strong tie group might have a strong opinion on Rust Vs Go, your weak tie connection might not know what an IDE is.

Here’s why it matters. If Conway’s Law says products mirror the way people communicate, then it’s these weak ties that organize these connections. They spark the ideas, highlight inefficiencies, uncover opportunities hidden inside silos.

And when those casual chats turn into projects, weak ties evolve into strong ones. That’s when the team forms, the solution takes shape, and Conway’s Law writes itself into code and process.

Is this a hidden pitch for back to the office work?

One of the best communicated teams I’ve ever worked on was scattered across the globe. Most of us had never met in person, maybe once a year, if that. And yet it worked. It worked beautifully.

The secret was communication, plain and simple. And the right tools to make it effortless. For us, that tool was Slack.

Slack wasn’t just for projects. There were channels for music, hobbies, random banter. You’d stumble into a debate about The Beatles versus The Beach Boys, and suddenly you were talking to someone you might never have met in your formal service line. Those side doors opened up connections that resulted in ad-hoc projects and innovations.

This design matters. I’ve consistently seen Slack foster such informal networks, but I’ve rarely observed the same in Microsoft Teams. Its structure tends to constrain communication, which, according to Conway’s Law, suggests something about Microsoft’s own internal culture.

That said, tools have limits. Large enterprises with thousands of employees cannot easily replicate the intimacy of hobby-based channels. And personal preference plays a role as well: I value face-to-face interaction, though I recognize that not everyone does.

The architecture you can’t draw

The big problem about all of this theory to my architectural mind is that you can’t formalize this stuff.

There’s no neat diagram that captures weak ties or coffee-corner alliances. But you can encourage it. You can make room for it to happen.

That’s part of the reason² so many companies push for people to come back into the office, to spark those casual conversations again. And sure, there’s some truth in that. But let’s not forget the remote world. The tools we use every day shape how we connect.

Too often, they’re treated as an afterthought. Microsoft Teams may come bundled with your license, but convenience comes at a cost: missed connections, missed ideas, missed weak ties. And in those gaps, you lose opportunities that might have made all the difference.

Knowledge of these systems often lives in the heads of a few long-tenured experts and is usually passed on through informal, almost ritualistic projects where newer employees are slowly initiated into their mysteries.

These applications are typically the usual suspects: ERP¹ or SAP-like systems, but rarely are they clearly defined. Most teams just refer to them vaguely as “those old central apps.” That’s understandable: every organization is different, and rigid definitions are hard to nail down.

That’s a bit of a shame. If we could define what makes these applications what they are, we can start to identify more of them, group them, and build some processes and governance around them. Make it all more manageable. That’s where Pace Layering comes in.

The three layers explained

Pace Layering or, as our friends at Gartner call it: Gartner’s PACE Layered Application Strategy is a strategic model for categorizing business applications based on their rate of change and purpose.

It breaks down the portfolio into three distinct layers: systems of record, systems of differentiation and systems of innovation.

System of Record (SOR)

These are the foundational platforms: your ERP things, CRMs structures, and core finance system monsters that support your primary business processes. They’re stable, slow-moving, and represent the source of truth for the organization. They don’t move quickly. Nor should they.

There might even be full teams dedicated to keeping these applications running. They are typically internally facing and are the source of analytics and reports in the organization.

System of Differentiation (SOD)

These are the bulk of your applications, the ones that fill the gaps and target specific business needs, market nuances, regional regulations, customer expectations, and the likes.

Replacing these takes planning, but is something that happens more or less often. Typically, the applications have shared teams that manage multiple of these kinds of applications. They connect upstream and downstream with both SORs and SOIs.

System of Innovation (SOI)

This is the R&D part of the portfolio. Think prototypes, MVPs, R&D applications. Experiments designed to test value and adaptability. The development cycles are short, the risk tolerance is higher, and successful projects often graduate to SOD status.

The valuable part

Simply classifying your applications using pace layering is already a step up from what most organizations do. It forces teams to look at each system and ask: what role does this serve, and how fast does it need to move?

But here’s where the real power lies: once you know what layer something belongs to, you can start treating it the way it wants to be treated.

What I mean by that is: We want our System of Records as stable as possible so we want to implement rigid rules about documentation and change management. Yet at the same time we don’t want to slow down our innovation, so we apply looser restrictions on our innovation layer. We only start our deeper documentation on SOI applications once they have proven their worth and move up to the SOD layer.

For Systems of Record, you build walls. High ones. Movement is deliberate, documented, approved. These are the systems you defend at all costs.

Systems of Differentiation are the middle child, they get more responsive governance. They must be able to evolve, often in collaboration with business stakeholders, while still respecting integration constraints.

The Innovation layer? Let it run barefoot. Don’t smother it with process, give it space to grow wild. You’ll prune later. Just make sure it doesn’t step barefoot in a data breach or compliance audit.

This layered governance model avoids a one-size-fits-all approach. It enables agility at the edges while reinforcing stability at the core.

Making it multi tenant

If our organization has multiple tenants (think a multinational) we could centrally host and manage all of our system of record applications in the global organization.

This would bring standardization across all the member firms of the organization. Every sub company can rely on the core applications to do their jobs without having to duplicate work.

In exchange, this central company would be able to have standardized reporting and data to compare region and comply to global rules.

The system of differentiation applications could then augment the SOR processes towards the local markets. This is what the member firms themselves would manage and are different per member firm/country. This gives us a centralized way of working while still being open to market trends and member firm sizes.

Funding

This is obviously very organizational depended, but rules towards funding might also be easier to define.

In a multi-tenant setup, central governance can take charge of Systems of Record, just like SaaS subscriptions, giving member firms scale, lower costs and not having to plan the big slow projects.

Said member firms could host and licence their own differentiation stack and invest together from a central innovation budget pool into the System of Innovation applications. This makes sure that there is always budget for innovation and ensuring that innovation flows back into the member firms.

In a single-company model, the same architecture fits: central IT handles the stable Systems of Record, business units drive differentiation tools, and shared innovation emerges through collective investment.

Change management and projects

Change management benefits from the same structural clarity.

As we have a very rigid foundation we ideally want to keep it that way. This makes it a perfect candidate for waterfall delivery: detailed planning up front, followed by structured, well-documented rollouts.

The SOD and SOI project can move forwards in an Agile way and, in the case of SOI projects, we could even move towards Extreme Programming.

Each layer gets the methodology it deserves, aligned to its purpose and risk profile.

Theory of constraint

One of the most powerful ideas in systems thinking is the Theory of Constraints, developed by Dr. Eliyahu Goldratt. The core principle is simple: every system has at least one bottleneck: one limiting factor that restricts the performance of the entire system. If you want to meaningfully improve the system’s output, you need to improve the most limiting constraint.

If you’ve played Factorio, you’re already nodding. That one slow assembler choking your production line? That’s your constraint. If you haven’t played it², imagine a factory where one machine lags behind the rest: that’s where your focus should go. Optimize that, and the whole system improves to the limiting factor of the next machine’s constraint.

In the context of business applications, we’re talking about the performance of your entire application portfolio. And the constraint is almost always lurking in the System of Record layer.

SORs are the bedrock: customer data, financial records, contracts, inventories. Everything else depends on them. Differentiation and Innovation systems are build on top of that layer. So when the SOR layer is slow, outdated, or fragile, it limits everything above it.

In multi-tenant organizations, the situation is even more amplified. The same SORs are shared by multiple business units or firms.

Every improvement to that foundational layer, through decoupling, caching, data replication, … has a cascading, multiplicative benefit across the enterprise. Small improvements here can mean millions of euros.

Of course, this doesn’t mean SOD or SOI layers are constraint-free. They still need love, care, and focus. But if you’re looking to accelerate the system as a whole, the SOR is the first place to look.

Moving through maturity

Applications don’t stay static. As they prove their value, they can shift layers.

A System of Innovation might start as a scrappy experiment. If it sticks, if it delivers clear value, it can evolve directly into a System of Differentiation, or even a System of Record. The same goes for Differentiation systems. Once they become critical enough, they can be formalized, hardened, and moved into the SOR layer.

But let’s be clear: this isn’t a promotion.

The goal of an application isn’t to climb the maturity ladder. Each layer plays a different role in your portfolio, and the real objective is having the right tools for the right roles in an organization.

Yes, Innovation projects shouldn’t linger in limbo for years. At some point, you decide: invest further or shut them down. But a Differentiation system? That can sit comfortably in its layer for a decade. As long as it’s still giving your organization a competitive edge.

Moving on from here

There is a lot of value here, and everything described above is just the beginning. Once you’ve applied pace layering, you open up all kinds of extra insights.

You can link your applications to your business capabilities and ask: are the tools you consider differentiating actually supporting the areas where you aim to differentiate?

You can look at total cost of ownership. Are your innovations worth the money? Are your differentiators driving up costs without payoff?

And we haven’t even talked about data modeling ! Are you systems of record actually holding the data they claim to hold or is critical information quietly hiding in an innovation project or a differentiation app?

All of that can come later.

Even if you just go through your portfolio and start labelling what sits where, even just naming your Systems of Record, you’re already ahead of the curve.

The concept is very easy. When someone comes to you with a question to do something, instead of blindly doing the ask, take a step back and try to understand what they actually want to achieve. Often this task might actually not be the best way to achieve the goal they are set out to do.

What Is the Real Ask?

So let’s start with an example story.

A project team comes to you with the ask for a new project management tool. They’d already narrowed it down to three shiny options, each with slick demos and long feature lists. All they want is your take: which one fits best with our architecture and strategy?

Before you dive into the selection process, you ask: “What’s wrong with the one you have now?”

Their answer comes fast: “It’s old, it’s slow, and everything is manual. We’re already drowning, this tool is just dragging us down further.”

In this case, the tool is not really the issue. The real issue is that the team is overworked and/or understaffed for the current workload. Sure, the tool might be old and slow, but the real pain point is not going to go away with a new shiny tool. In fact, new tools bring migrations. Setups. Training. And none of that helps when you’re already gasping for air.

Instead, we can look upstream: Could we ease the pressure on their pipeline? Automate the worst manual steps? Give them breathing room without introducing a six-month, and figure, rollout?

They won’t be thrilled at first. No shiny new toy. But we saved serious money, dodged a risky project, and actually helped fix the real problem.

All because we paused to ask the question behind the question.

Why does this happen?

We as architects have the benefit of a bird’s eye vision of an organization. This is a luxury that not a lot of teams have. We sit where we can trace lines across systems and spot patterns that others might miss.

But the project team in our story? They were deep in the reeds, overworked, short on time, and grinding through manual tasks that drained their energy. From their vantage point, the tool looked like the enemy. And who could blame them? When you’re underwater, you sometimes dream of better scuba gear instead of the shore.

These conversations aren’t about proving someone wrong. They’re about collaboration. You’re not trying to be the smartest guy in the room, you’re trying to help. They know the grind, the details, the day-to-day. You bring the context and the different lens.

They might not be aware of what’s possible or what other teams are doing, and you are not aware of the processes they are using.

The question behind the question isn’t a challenge. It’s a sanity check. A way to align intent with action.

Why architects keep falling for the trap

We all want to be helpful, especially to a team that seems to be struggling. If they come to you with what looks like a silver-bullet solution, it’s hard to say no.

Telling them they can’t have the new tool, or that their idea might not fix the real issue, feels like letting them down.

It is, however, your job. 

Our role isn’t to rubber-stamp requests. It’s to protect the long-term health of the organization. And that means recognizing when a “solution” might actually add more weight to a system that’s already strained.

A quick fix that doesn’t solve the root cause becomes baggage. And that baggage sticks around for years.

Do the hard thing now, so you don’t have to dig yourself out later.

How to surface the question behind the question.

Getting to the real ask takes finesse.

If you come in swinging with, “What are you really trying to achieve?”, people get defensive. It sounds like a challenge. Like you’re poking holes in their thinking.

Same goes for, “It sounds like what you actually want is…” That reads as smug, even if you mean well.

So take a different tack. Ask about their pain points. What’s frustrating? What’s taking time? What feels like it should be easier?

Look for patterns. Oddities. Things that don’t line up. Compare their setup with how other teams work. Look at the rest of the organization.

And when you’ve gathered enough threads, step back and hold them up. _“So the tool’s slow and the work is tedious, and you’re already stretched thin. Would switching tools really fix that, or just add another burden?”

It’s a little like a detective story. You’re not here to interrogate. You’re here to investigate. To ask the quiet questions that lead to real answers.

And you’re not doing it alone. You’re on the same side of the table. Solving the same mystery.

Beneath the Surface

People don’t always ask for what they really need. They ask for what they think will stop the bleeding as fast as possible. That’s human.

Your job is to listen, poke gently at the edges, and find the story underneath… That’s what separates an architect from an administrator.

Sometimes that means you’ll disappoint them in the short term. But if you’ve done your job right, you’ll be solving real issues and not introduce future ones. Because in architecture, the easy answer rarely ages well.

A left over from an old proof-of-concept application that had something to do with GDPR. This field went out over the API as part of the “employee data” resource.

Now we all agreed that it’s probably not used, but it was still bundled into the “employee data” resource that went out to the rest of the application landscape. There was no way to know if it was unused, or if something obscure still depended on it.

I’m sure it’s still running to this day. Every morning, at 3 AM. 

Chesterton’s Fence

That forgotten flagging system? That’s a direct result of Chesterton’s Fence, a principle by G.K. Chesterton, that states that you should only remove something if you truly understand why it was there in the first place.

In architecture this is often spoken as gospel, but architects also often forgot to act on the second part.

Chesterton’s fence is frequently used in some political circles and think tanks, but we are not going there. This post is not about politics; we are only looking at it from a business and organizational perspective. Like a smart man once said: “I’m not brave enough for politics”.

How this works in architecture

A significant aspect of architecture is following up on vague leads.

A team says, “We don’t use that onboarding system any more.” You ask, “Are you sure?” And then you check. You check dependencies, integrations, the undocumented mess that holds the whole thing together.

We are now deep into Chesterton’s Fence, it’s about knowing what happens after you remove something. Not the removing itself.

But sometimes, that double-check turns into a rabbit hole.

You dig through missing docs. You talk to five teams. Three have left. Two don’t remember. Eventually, new projects pop up. Everything is always critical so you stop digging.

And the onboarding system fence stays. What started with good intentions into due diligence, quickly turns into risk avoidance and bloated systems. 

Fences around fences

In reality, what often happens is that teams build around these mysterious setups.

Remember that flagging system from the intro? What happens when that same company needs a new user flag? They don’t touch the old one. No one remembers what it does. That’s irresponsible! So they add a new field to the database.

Now every developer must guess which flag to use. One that might result in an error two systems further, or the one that actually works.

Down the line some developers will guess wrongly, slowing down feature development and increasing the risk of bugs. 

Scale that same issue up over ten years, and you have slowed down all your projects and innovation. Simple changes take six months, as there is just too much complexity to deal with.

This is not a risk problem; this is a knowledge retention problem

The real fear isn’t the fence, it’s the surrounding silence.

At some point, there was a very good reason to build the system like it is today. Nobody wrote it down, that person left and the system stayed.

Organizations know the value of documentation, yet there is often no time or room to write it. This is a self-amplifying problem where projects run over budget cause there is no documentation, and therefore everything takes too long to figure out. But at the same time there is no room to write documentation as the project is already overdue.

If you run into applications or processes that nobody really knows what they do, it’s already way too late. Doing a deep dive into the inner workings of the system will be a huge undertaking and one that probably doesn’t fit in the current timeline.

This should, however, be a wake-up call where you start to invest more in knowledge sharing platforms, process mappings and application/business owners of processes and technology.

Organizations forget. And the cost of that forgetting is paralysis.

So, should we follow it or not?

Chesterton was right: don’t tear down what you don’t understand. But in big organizations, no one tears things down. They build around them. Layer upon layer. Fence upon fence, until you’ve built a maze of fences no one can navigate.

The solution is a centralized knowledge system that actually captures information in your organization and makes time for people to own, read and write said documentation. Because if you don’t, every new project will have to tiptoe around yesteryears old mysterious baggage.

So yes, be cautious. But don’t be afraid to take a risk now and then.

Worst case, you break something. Best case, you find out what that fence was for. And maybe, just maybe, you can finally tear it down.

One of the first things that is being asked is: What are we really spending?

Not just the big hard numbers like contracts and licences, but everything. The hidden costs and invisible hours.

This is weirdly something not a lot of companies know. Today, we will take a look at just that: TCO (total cost of ownership), and how you can start mapping it across your entire application landscape.

The outline.

The idea is simple: take every business application in your landscape, break its costs into categories, and combine them into a single number. Or, if numbers aren’t available, a t-shirt size. Simple enough. Now do it for a thousand applications.

But things get messy when we actually start the exercise.

Total Cost of Ownership feels like a clear, manageable concept, until you try to measure it. What begins with server costs quickly spirals. What about storage? Backups? Do you include electricity, if you’re hosting in-house¹? And that’s just the surface of it all.

There is also the cost of building, maintaining, training, … I’m sure you can think of dozens more parameters.

Remember, we’re doing this at scale. Every extra detail you include means another person to ask, another number to update, another layer to manage.

But here’s the trade-off: too little data, and your TCO becomes useless. You want something clear. Something that tells the story of the cost.

For example: Application X costs 500,000 per year. You break it down: 180K on infrastructure and another 100K on training. Suddenly, you’re not just seeing a total cost. You’re seeing an opportunity. Maybe that training cost tells you it’s time to invest in better UX.

That’s what this is really about: not just knowing the number, but knowing how to change it.

For me, the best way to go about this is to map this out in categories, and the ones I’ve settled on are: 

• Development
• Licensing
• Infrastructure
• Support & Maintenance
• End-user Support
• Misc

I won’t go through every detail of every category, this isn’t a textbook, and every organization has its own quirks. I will however give you a rough outline that you can use to shape it to your needs.

Development

This category covers in-house development.
If you’ve built the application yourself, take the total cost: FTE’s ², tools, consulting, whatever it took to make the thing. And spread it across five years.

Why five? Because without that, you get a big spike in year one that skews everything. You want apples to apples.

If the application is off-the-shelf or SaaS, this category will likely sit at zero. And that’s okay. Not every column needs to be filled.

Licensing

This is your “buy” column: SaaS, commercial software, vendor tools…

Licensing can be deceptively complex. You’ve got per-seat pricing, per-admin models, resource usage tiers… I always normalize it. I use “cost per unit” as a base metric. It helps highlight inefficiencies fast.

For example, if someone only reads reports, maybe they don’t need that premium admin licence. Trim where it makes sense.

Infrastructure

This covers servers, storage, backups: the whole physical and virtual stack.

In some cases, infrastructure is bundled into licensing (think cloud platforms). If that’s true, you can merge them. If not, keep them separate. Just be consistent.

What matters most is visibility: where the app lives, and what it costs to keep it breathing.

Support & Maintenance

Now we’re into the hard stuff: the cost of keeping things running. Bug fixes. Patches. Support tickets.

Some companies calculate this by assigning a cost per bug. That works, but I prefer a more stable approach: support hours, tracked in FTEs. This will deviate less per month and doesn’t feel like punishment to the people working there.

Here’s how I break it down.
Two support engineers cover five applications? That’s 2 ÷ 5 = 0.4. Round it up to 0.5 FTE per app. (I always move in steps of 0.5, there is no need for more details I feel)

If that application constantly escalates bugs to the dev team, bump the number.

It’s not perfect, but it gives you something consistent to track.

End-user Support

This one’s slippery. It covers training and minor feature requests. The human side of keeping an application usable.

Track training in FTEs. Not just the students, but whoever’s doing the teaching. That includes onboarding, train-the-trainer sessions, and refresher courses.

As for feature requests: draw a line:

• Big, roadmap-changing features go in Development.
• Small asks, tweaks, quality-of-life fixes go here.

And if you rely on a vendor for this kind of support? Log it here, not under licensing. That way, you can spot where the support load actually lives.

Misc

The vaguest one, but an important one. This is where I track three things: criticality, sensitivity, and legacy. I express each one as a percentage.

Is it business-critical? Does it handle sensitive data? Is it built on something ancient and fragile? The higher the percentage, the more weight it carries.

Yes, I know, that’s very unscientific and vague, but I do think it’s essential. We’re going to use these in the next step.

The thing about numbers…

Numbers are sensitive and not always easy to get hold of. And when you’re dealing with this many systems, they don’t always show up when you need them.

Not only that, but as you probably noticed in the previous chapter, we mix percentages, FTEs, exact figures. It might seem messy, but that’s the only way to capture something so layered.

You have to realize that the end number you’re going to end up with is not accurate. It is impossible to get a real accurate number out of this. There’s too much guesswork, too many estimates, too many people giving you ballparks instead of precision. That’s reality.

Don’t chase perfection. You won’t find it.

So give people options. If they know the cost, great. Write it down. If they don’t, let them give you a T-shirt size: S, M, L, XL, XXL. It’s fast, and surprisingly helpful at scale.

This helps if you run into situations where people just can’t answer you with real data. How many days a month do you spend on average on bug squashing? If you don’t have a clear setup to track these things, it would be impossible to know.

Remember: you’re doing this for 1,000 applications. Progress beats precision. Every estimate you get is better than one more week waiting on the “real” number.

Getting to the final number

Now comes the tricky part: turning estimates into meaning.

Start by defining your defaults. What does a “Medium” look like for bug reports per month? Feature requests? These won’t be perfect. That’s okay. Set some gut-based baselines and refine them as you go. An “M” for some companies can be a “S” for others they can and even will change over time. Don’t be afraid to revisit them later on.

The same with the FTE calculations, that’s the cost per day of a person working in that position. Again, an average.

Once those are locked in, total up your categories. You’ll have a rough annual cost per application.

Now, what about that Misc tab with the percentages? Those percentages: criticality, sensitivity and legacy should affect the rest. Not by simple addition. You’ll need to apply a weighting system to the total cost. A legacy app doesn’t just cost money it also costs effort.

It’s up to you how you want to weigh these multipliers. I would not just add the percentage to the number, as that would quickly get out of hand. Instead, you might want to use a lighter touch. It’s best to experiment here.

Scaling it up

Once your model’s ready, it’s time to gather data. Keep the entry points soft and friendly. A well-designed form, a guided tool, a low-code application with just the right help text. These things matter.

Don’t overload anyone. Break your model into pieces, and send each one to the person best suited to answer it. Let Finance handle licensing. Let Ops tackle infrastructure. Let people speak in their own language. The last thing you want is to scare people with information they know nothing about.

And whatever you do, keep the calculations hidden. Not to be secretive, but to protect the integrity of the answers. If people can see how the sausage is made, they’ll start shaping the meat.

Once you have everything set up, it’s selecting the right people and sending out the forms.

Don’t expect instant returns. You’re building momentum, not flipping a switch.

Try to do it in small sections and run a POC first, where you only scope out a 20. That way, you can see if you have some faults in your system. Before you open it up to maybe batches of 50 to 100’s.

The end goal is for people to come to you with the information so you don’t have to chase them every few years. That will only happen if your insights at the end of the project give enough value and reach the right people.

So, make sure that you also present this information with some actionable insights. That should be very doable with a setup like this.

TCO is messy, imperfect, and often imprecise, but so is everything worth understanding. Start somewhere. Adjust as you go. Just don’t wait for perfect.

Over the years, I’ve settled into a structure that helps me define projects that not only link to the strategy above but also looks at my own team’s enviroment, I thought I’d share it here.

Working with the given strategy

Strategy usually comes down from the top. The C-suite sketches the big picture, department heads slice it into projects, and those trickle down to the teams. It’s not always a very transparent process, but that’s how it works.

Knowing this, there are some ways you can take (partly) ownership of this process by injecting your own projects into it. We’ve talked a lot on this site about organizational layers¹ so there might be some projects that you can think of that benefit the strategy that layers above you might not see. What you see depends on where you sit. That means there might be gaps in vision, gaps that you can fill.

First things first is getting to know the strategy. That sounds extremely obvious, but it’s something, so many team leads skip over. Having a conversation with your boss about where the company wants to go towards in the next X years and where your boss’s boss wants to go, and why. The bigger picture stuff. If you’ve never done that, you’d be surprised how suddenly some questionable decisions from the past suddenly make a lot more sense. This is something I would do at least yearly.

All the work will be routed in this. If you can pitch your projects in the framework of the company’s strategy your odds of a successful pitch will skyrocket, most of the convincing has been done for you already. Not only that, your boss can easily pitch that project to the higher ups. Everyone wins.

Converging strategy into projects

Ok, you’ve got the strategy. Now how do you turn that into projects? I like to use a bastardization of Teresa Torres’s opportunity solution tree. It’s a startup thing, but it works just fine in the grand halls of enterprise.

I use it like this²:

You take one of the strategies. An example would be: we want to reduce cost. The next step is to start linking broad actions that we could take to handle that strategy. EG: automate processes, eliminate underused software, look at licences. Don’t judge the ideas too much yet, this is the part where you make the mess.

You can do of these things alone, but it’s probably better to get some smart people in the room from your team. Again, you only know what you know. More brains, more angles.

Once we have these vague ideas, it’s time to shift from vague to specific. It’s possible that you can’t find a real project for an item in the tree above, or that if you go deeper into it, it turns out that it was not a great idea. This is good, that means that you are already filtering out the fluff.

The last step is thinking of a proof of concept, this is another filter layer. What can we quickly build that proves this idea has legs? If you can’t find something that can at least proof rather quickly if there is value or not, it’s probably not something to pursue. This process turns abstract strategy into stuff that ships and also gives you the ammunition to pitch it, as you walked the logic all the way down.

You might end up with something like this ³:

This is good, but it can be better

You could stop here and have a solid list of projects. Your boss would be impressed. But I think the real kicker would be to have projects that serve more than one strategy.

At the “vague idea” stage, before turning anything into a project, pause. Run the same exercise for your other strategies. Build separate trees. Then take a step back. Look across them. You’ll start to see overlap, ideas that touch multiple goals at once. Those are the winners. The projects that move more than one needle. The ones that get budget and visibility.

This is where the real value starts showing up.

Once you start defining projects, focus on the ones that serve multiple strategies at once. For example:

Say the sales team manually emails orders to the delivery team. You could replace that with an API connection. That alone cuts labor costs. But there’s a second win: if you’re also planning Project X, and it needs real-time order data, that API suddenly becomes critical infrastructure. One move, two wins.

So now your project becomes: “Build an API that connects sales and delivery across product platforms.”

And when you kick off Project X, you’re already set up to automate and move faster. You didn’t just deliver a feature. You moved strategy forward on two fronts.

But I don’t have the freedom to define my team’s work

Most teams don’t. But this is a first step towards something like that. What we are doing here is helping your boss look good to their boss. We reach out and help find answers to the questions they get asked.

The first time you try, you might get brushed off, plans are already locked in, no time for new ideas. That’s fine. The second time the strategy to project planning comes around, you have a higher chance to be in the room where it happens, as you’ve proven in the past that you understand how these things work.

And yes, your team is probably already busy. Everyone is. It is important to remember that you’re reaching out with potential projects that we can do, ideally replacing assigned work with chosen work, not taking on the extra projects. Suggesting projects doesn’t mean you’re committing to them: it means you’re helping to shape the conversation.

Replace assigned work with chosen work. That’s the shift.

Applications support processes

An organization is a collection of people that come together and either provide a product or provide a service; that’s the most zoomed-out version of an organization you can have. To provide this service or product (from now on just service, spares me keystrokes), you have your people, processes, technology and information ¹. The people that do the work, the processes that the people follow to do the work, the technology that allows them to do the work and the information that is shared between all of the previous three.

You need all four to produce your service, but the leading one here is the process. That’s the one that provides the blueprint of the work to be done. That means that the people and technology in this context support the process.

You build or buy new technology to support the needs of the process.

Emerging vs leading strategy

Now, you might argue, new technology can allow for new processes to develop. In that case, it would be technology that steers processes.

Take, for example, you buy a new ERP that greatly simplifies the way you handle your logistics. In this case, you have bought a new tool that has a particular way of working, and your previous way of working needs to be adapted to the new tool.

And that is correct, but it’s also not as it should be.

We have currently only looked at processes and technology, there is also the strategy layer that has been left out till now. In the example before, we have what is called an emerging strategy. A strategy that organically grows from the way the organization functions. Some people also call it a passive or reactive strategy. ²

This way of working allows external parties to greatly influence the way we work. We are always chasing the ball, and most of our time will be spent trying to patch and connect everything, as the organization becomes a patchwork of disconnected ideas and incompatible ways of working..

The opposite of this is a leading strategy, where we dictate how the processes should run and match the software to that process. Here we are in control of what we want to achieve and how we are going to achieve it.

In terms of the previous example, that would be going to the market with the way (RFP) you want your logistics to be simplified. Find the closest match and try and adapt it to your way of working. Here you learn from the experiences that made your organization an enterprise in the first place. You don’t get to this point by not knowing your market, product, customers and ways of working. Why risk all of that by just blindly implementing the way of working of a third party?

So waterfall?

That does indeed give a very top-heavy and waterfall vibe to it³, but that is not necessarily the case. Leading strategy is not static strategy: It’s not because you plan out your strategy that you can’t adapt it to new opportunities. It’s just very important to take a look at where your strategy comes from, as that dictates the direction of the entire thing.

There are companies that use execution methods like waterfall or agile as a strategy, this is an extreme version of reactive strategy. A better method here is to take your learnings from the execution method and adopt it in your leading strategy. So strategy then delivery followed by a feedback loop.

Say, for example, you move your infrastructure to the cloud and part of your negotiated tier pricing includes a “free” database component. You would not blindly adopt said technology because it is available. Even if it is a better match for the application.You would have to take a look at why you would want to implement it. Ignoring whether or not this would lower the TCO (total cost of ownership) of the application, you will have to look at what the benefit is of the migration. If, for example, you were able to speed up the application by 30% or handle way more users at the same time, this all would be meaningless if your processes don’t require it.

If your technology outpaces your process needs, that’s not innovation that’s premature optimization. The role of technology is to support the people doing the work, not to chase hypothetical performance gains.

The technology is there to support the people in doing their jobs. If you just implement technology in the hopes that it will have a positive impact on the organization you are just trying to find a problem to your solution.