Engineering the Enterprise
Get a group of business architecture practitioners together and the conversation will inevitably turn to how hard it is to convince organizations of the value of business architecture. I wholeheartedly agree.
And yet, I've also thought: we clearly need a different way to talk about this. Because whatever we keep doing, it's not working.
Recently, I had a chance to try something new – a completely different audience. Instead of presenting to business leaders, I made my case to engineers and their product partners.
My hypothesis:
Business architecture is just engineering for the enterprise.
My audience already does some of this work. Investing in business architecture just shifts the mindset left - earlier in the process - and provides a common language through shared reference models to help us work as one enterprise team.
My logic:
- If I could convince them business architecture is engineering at an enterprise level
- And they already believed engineering has practical value
- Then logical transitivity would get them to the conclusion: business architecture has practical value
And I wasn't just going to tell them. I was going to show them.
Same problems, same mindsets, same approaches
Engineers and practitioners of business architecture face the same tension between:
- allowing decisions to emerge organically, and
- controlling everything through intentional design.
We benefit from both. But when we're clearly imbalanced, we need to course correct.
To show them, I used four thematic problems we both face, and demonstrated how proven engineering mindsets and approaches apply to solving enterprise-level concerns.
Here's my hypothesis proof.
PROBLEM #1: You can't get up to speed quickly
You've joined a new team or initiative. You want to run, but there's no onboarding ramp. You're spending too much time piecing together what's going on, how it works, and why.
Engineering mindset: What is the big picture and how can I learn more?
Engineers crave information at their fingertips. Before writing a single line of code, they want to know:
- What is the purpose, value, and criticality of what I'm supporting?
- How is the solution composed and what role does each piece play?
- What are the dependencies - both within what I own and with others?
- Where can I dig deeper when I'm ready?
- When I need to phone a friend, who do I call?
Engineering approach: Good documentation and complete catalogs
Engineers know the value of good documentation and complete catalogs. They tell us what we have, why it exists, and how it fits together.
For example, they leverage artifacts like a tiered solution architecture diagram, to describe the full stack solution for an experience: from the point of engagement, through service layers, down to the underlying infrastructure.
With this artifact, a new team member can ramp up quickly - and if change is needed, a heat map can triage where changes are most likely required, top to bottom.
A sequence diagram goes a level deeper, showing how a single transaction flows step by step.
This signals intended design - and can be observed with telemetry to show what was actually built. Engineers know how to trace through a problem and identify the source of issues.
Applied to business
The same approach applies to business using tools like value streams.
A value stream provides an end-to-end view of a process that delivers specific value to the organization.
At its core, it answers our first question - what is the purpose, value, and criticality of this process - by naming:
- The value we achieve (shown at the end)
- The steps or stages
- The intermediary outcomes from each stage
- The triggers that cause the process to move forward
From a shared base, note how we can layer on context that brings even more clarity:
- Business capabilities - WHAT we need to be able to do at each stage, the verbs or actions
- Information - WHAT data is involved, the things or nouns
- People - WHO brings the value stream to life
- Tools - HOW they do it
We're blending contextual layers (like the solution architecture diagram) and order of events (like the sequence diagram) all in one view!
Same, same
Just as documentation and catalogs help an engineer get up to speed and assess where changes are needed, tools like value streams do the same for business.
We're both aiming to decompose the system and provide a sense for how things move.
Same, same.
PROBLEM #2: Managing things is getting unmanageable
Now that we know what we have - let's talk about the burden of caring for it.
The effort to make even small changes can get heavier over time. Things organically get more complex. It takes intention and persistence to simplify.
Engineering mindset: Do more with less
What are engineers looking for to simplify their codebase?
Similarities. It's the flip side of Sesame Street's "which of these things is not like the other."
Engineers see the patterns in the noise. They look for similar data objects, replicated functions, and variations on the same logic - then design to reduce them.
Engineering approach: Consolidate the similarities
How does "do more with less" come to life in practice?
Engineers consolidate the similarities:
- Normalizing data contracts across source systems
- Encapsulating shared logic into reusable modules
- Defining abstract interfaces for the common behavior – and only override for differences that truly matter
Let's take our Cookies and Cream acquisition as an example. In the early months of the merger, the only practical solutions involved maintaining different points of sale for each type of shop. The owners also wanted to honor gift cards regardless of shop type.
Are these seemingly conflicting requirements reconcilable?
Yes – and the engineering answer is an abstraction.
Fortunately for Cookies and Cream, one of their existing point of sale solutions allows them to configure a reusable interface that both points of sale can call.
The interface normalizes the gift card redemption transaction, and handles orchestrating between the two different systems of record.
Over time, they can remove one of the gift card providers or replace both providers, without a change to point of sale.
Applied to business
The same approach applies to business using Business Capabilities.
At time of merger, Cookies and Cream have separate sets of people, processes, data and technology for ice cream and cookie shops. We talked about the duplication in our discovery post.
By putting on our engineering hats and using Business Capabilities as our abstract definitions for what we do, we can rationalize the variability. We default to similarities, and only differentiate where it truly makes sense.
During discovery we concluded to address the redundancies in this way:
This was an exercise of thinking through the lens of what to decide when variations in how made sense.
Same, same
Just as abstractions and interfaces help engineers refactor code for simplicity, Business Capabilities help rationalize redundant implementations across the enterprise.
By focusing first on the what not how, we can more easily identify commonality and then ask if the variations are worth the effort to maintain them.
Same, same.
PROBLEM #3: We've lost the thread on how everything connects
Let's double down on the idea that things organically get more complex over time, but it takes intention and persistence to simplify.
Why is this happening? Well, over time, our business has evolved.
Post-merger, Cookies and Cream took off and is now a nationally recognized brand running retail and wholesale operations.
During that period, we enhanced our capabilities and added new business models. Choices to accelerate time to market has led to solutions that were supposed to be "temporary" that may or may not still exist years later.
Maybe no one knows how it all works.
Maybe one person does, but she's retiring.
How many of you have had those types of conversations – Pam's retiring! What are we going to do?
We need to be able to survive in a world without Pam.
Engineering mindset: How can we follow the trail?
Unfortunately right now, we have no idea where the trail leads. We have no catalog. No traceability. It's a mystery – except to Pam.
What do engineers do about that?
Engineering approach: Design the flows
They design the flows to be extensible, reusable and traceable.
Over the years, we've learned the value of loose coupling, event based interfaces, and consistent integration methods.
Consider this example:
(1) One event, (2) broadcast to any number of consumers that need to react to it – including enterprise data access layers – that are (3) catalogued and observable universally.
And each designed event based flow is now a leverage point – a place to start unwinding the hairball – and illuminate the trail.
Applied to business
Now here is where the magic happens.
In a perfect world, we would have already designed the flows conceptually as part of business architecture – modeling out (1) the same business event, (2) the relevant consuming business capabilities that need to know about it, and what they will do with that information.
The names may not be exactly the engineer perspective, but the story is absolutely the same.
Same story
This is the natural progression we are striving for: a seamless narrative from business architecture to engineering. A shifting left of the engineering mindset – bringing clarity to everyone earlier and streamlining technical work later.
We're moving away from what Pam knows, to what we can all see.
Let Pam retire with peace of mind. We've got this.
PROBLEM #4: We're too slow to change because we are carrying too much baggage
Here's where the rubber meets the road.
We can agree to solve problems 1-3, we may even be energized to do it.
But words and energy are not actions, and actions that require effort from many people are hard.
We can only do so much, and when we context switch between priorities, we put ourselves into a place of perpetual coexistence, which is the worst place to live.
How can we shed the anchors before they drag us to a standstill?
Engineering mindset: Discipline
Engineers are always looking for things that can be improved. This creates an endless list of opportunities – so triaging the work into the backlog is part of the process. Great teams can say, without research: here is the work we need to do and the progress we've made.
Identify it. Prioritize it. Track it.
Engineering approach: Prioritize the debt
Managing product debt is like managing personal debt. You can pay off the minimums on your debts, but if you really want to get rid of debt, you need a plan:
- Pay off the highest balance first?
- Go after the ones with the highest interest rate?
- Clear the lowest balance first to eliminate a debt entirely?
All reasonable approaches – for different reasons. Engineers ask the same questions and decide based on context.
Two common paths:
In the first they are optimizing for efficiency.
All of these shapes represent debt in their product. For example, all of the circles could represent an upgrade to a newer version of a database because the old one is going out of support.
By optimizing for efficiency, and doing that work for each of their applications as a focus for this sprint, it helps put them in the zone. They get faster and more confident with each one.
When they're done, they've checked off that entire type from their list and not only does that feel good, but it also creates a space for them to focus on what's next since that type of debt won't come up for awhile again.
In the second, they are optimizing for end-to-end value.
In this example, they see how refactoring a circle, square and triangle represent and end to end body of work. By working that in the same sprint, they get the confidence sooner that it's all working as intended, and if something comes up to distract them later, they aren't leaving things in a middling state until they pick it back up again.
What they are trying to avoid is chasing fires, creating a real risk of perpetual debt – where we are always behind, and the types of debt keep getting added to the plate without any relief.
Applied to business
The stakes are even higher for the business because the debt can feel more intractable.
Duplicate functions, unclear ownership, manual work arounds, inconsistent data, brittle processes, half-finished coexistence – these are all evidence we have debt to pay.
But we need to think like engineers, and apply discipline to identify, prioritize and track the debt; while optimizing how we pay it down.
We can work together to modernize a data source. Or we can work together to enhance an end-to-end process.
We want to avoid the behaviors where we do not work together, where we all chip away but it doesn't amount to anything valuable.
Same, same
This is the nirvana state for business architecture. Where we aren't just designing the future, but we are backing it up with the discipline to follow through effectively, as one team.
Identify it. Prioritize it. Track it.
Just like engineers.
Same, same.
Hypothesis test
I believe that business architecture seems like a mysterious term but simply translates to applying engineering practices to the enterprise.
We have looked at four common problems:
- Understanding complex systems – and how we benefit from good documentation and complete catalogs
- Simplifying complexity – where we try to do more with less
- Tracing connections – by designing the flows, and
- Paying down debt – optimizing for things like efficiency or end-to-end value
Engineers solve these problems every day.
The same applies to business.
The tools look different. The scale is different. But the mindset and discipline are the same.
Engineers refactor their codebases.
Business architecture refactors the enterprise.
Same instincts, bigger blast radius.
Are you convinced?
Reflection
Before you move on, pause for a moment:
Where in your organization is "Pam" the single point of failure?
What business debt is slowing your team down most right now?
What would it look like to apply engineering discipline to your enterprise challenges?
References
- From triage to treatment plan: Building shared understanding
- Blending cookies & cream: A capability impact assessment
Have questions or thoughts about this post?
Email me at hello@eaforeveryone.com or connect with me on LinkedIn.