The Ugly Truth: Constraints Are Your Best Friend

Finding Constraints

When I think about reality, I think about hard truths.

We have to pay our bills.

Gravity is always pointing down. Gravity always accelerates you at 9.8 meter per second squared.

Canada's Navigation law says you cannot interfere with water navigation. So, if you live on the other side of a working harbour you can go around or pay for a bridge that will get out of the way. Some days I have to wait for a boat to get out of the way so I can ride across the Pacific to go to work.

Now we know about reality—social constructs, the natural worlds, and the laws we live under.

Let's look for sources of architecture reality:

• Our enterprise context—the environment our enterprise exists in
• Our superior architecture—the prior decisions we made
• Our current state—the starting point
• Our architecture project—the deficiency we are addressing

Normally I'll tell architects to seek degrees of freedom. When I'm developing architecture to support strategy, and portfolio architecture I seek constraints.

At the top level we have unlimited choices. I need to eliminate options.

I need guidelines and guardrails to channel my thinking.

I need constraints!

Most of all I need a consistent set of constraints—I love well considered superior architecture and a clear architecture project.

NA Construction—Constraints as Friends

One of our training case studies is NA Construction—they were a Conexiam Consulting customer. We use NA Construction in our practical training EA with TOGAF and Navigate.

It is a fun case. I like it because we went end-to-end in a hurry.

In 18 months we developed a strategic architecture, a transformation portfolio, then several project architectures, and completed the implementation work to the 1st transition state.

It was a straightforward 18 months. First the architecture roadmap. Then we selected an ERP and implemented it, pouring 3 mini-ERPs and 4 HR systems into our shared platform. Then we consolidated over 100 bidding and project management systems into a single flexible cross-company approach with end-to-end data provenance to ensure data needs and data flows met project controls. Most importantly, we selected and implemented a common infinitely scalable project controls system.

We transformed their operations. Every one of their local operating entities could stand alone—bidding for and profitably managing a $25,000 project paving a strip-mall parking lot—or pull together to seamlessly execute on constructing a remote mine worth $4,000,000,000.

A customer seconded staff to work with us on project controls. The customer was so impressed with the new capability to come together and control projects they sole-sourced a $1.3 billion project instead of their normal practice of putting small manageable parts out to bid.

I love this case. It proves doing architecture doesn't take extra time—it focuses on value. The margin gain on that integrated $1.3 billion project paid for the transition.

Whenever someone questions the value of doing architecture, I think about margin. I think about an architected approach that doesn’t cost, but pays.

Lets Look at the Roadmap Constraints

The NA Construction [architecture roadmap was the inevitable output of the enterprise context, current state, and strategic architecture decisions. Company strategy was to compete on project controls, and business unit assembly.

Assembly and project controls required a common data source—the bid in terms of materials, labour, equipment, and production. Then common production reporting. Again in terms of materials, labour, equipment, and production.

That drove us to a simple implementation of an ERP designed as a shared information platform. Not a shared process tool. Bids were in an industry specialist tool. Project management was in an industry specialist tool. Field data capture was highly variable. All ruthlessly required to use the same materials, labour, equipment, and production data. All stored in the ERP.

What I enjoyed was the ERP project was simply a transition stage, not the target. Nor the point of high value delivery. >85% of the target value came from integrated project controls, and business unit assembly.

Building out and executing the roadmap was based on evolving constraints.

We eliminated endless debates.

Value came from assembly.

Assembly required consistent data and consistent tools—optimized for local activity. Every time a business unit bid on building a road, they used road construction materials, equipment, labour, and production terminology. It didn't matter if it was a country road, a new overpass, or the hundreds of miles of roads required for a remote mine. Even the specialty roads for 200-ton trucks working in the mine.

We delivered this excellence using best-of-breed industry tools.

Yep, best of breed construction bidding. Best of breed large project management. Field data capture using project-specific methods falling back to the lowest common denominator—import a CSV file.

I know you are thinking, that's just good architecture. And you would be right.

Did I mention we started with the ERP before we selected any of the specialist industry tools?

I simply had a few data architecture constraints—the ERP would be the shared data repository, you had to speak to the ERP through out-of-the-box public APIs, and we would not customize the ERP. We required a stable shared data platform.

When it came time to select bidding, or project management, or field data capture, or project controls systems we could use any software my specialists wanted. If, and only if, it spoke ERP through an existing interface.

Concluding My Friendship With Constraints

My thesis is simple. Roadmaps are filled with deferred decisions.

I often use the construct of ensuring transitions allow your stakeholder to reassess, then deliberately choose to Continue, Stop, or Pivot.

In the NA Construction Case we used deferred decisions to get-going. We started as fast as we could on the ERP. We made our ERP integrator cry—they so desperately wanted to create complexity and brittle specializations in the cause of business value. We wouldn't let them.

Finance was OOTB. HR was OOTB. Then when they asked about bidding, project management, and project controls you could see their hidden desire to create complexity and brittle specializations masquerading as business value.

I knew there was a risk that native ERP data structures and interfaces wouldn't be sufficient. The industry is filled with secret specialization and customization—all of the software vendors could have hidden interface gaps.

I had warned my stakeholders. It was fun to watch them negotiate implementation terms and conditions that specified OOTB commercial integrations were included. It was more fun to watch them hold the software vendors to the terms.

Did I mention we were done in 18 months. 18 months from the strategy discussion to the hallowed go-live-day. When we started implementation, we had deferred core decisions that would deliver 85% of the expected value.

We had clean decisions at our roadmap intersections. We went to every specialist team and asked 'what best-of-breed commercial system sets your heart on fire'? I sought and delivered as much enterprise agility and specialization as we could.

They got $1.3 billion sole-sourced. I got a trophy—a prize they invented to say thanks for an architecture roadmap.

So here is my challenge. Look at your work—AI Adoption, digital transformation, or simple infrastructure modernization—what are your red lines? What are the constraints that hold you to delivering value? How are you embedding them in your architecture roadmap, so when you get to an intersection your organization can deliberately choose to maximize immediate and strategic value?

Next week, I'm going to step away from architecture roadmaps, and move back to data architecture. As you know my team of EA consultants does everything they can to get me to think about things that help them. We have a cool digital product data architecture problem and they are driving me to solve data subjects and subject area models for digital products and the business.

Until then. Have a great day.

 

regards Dave

Dave Hornford
Conexiam

PS.  My project controls specialists chose a beta application. For a major ERP-based enterprise system we used beta software. Always know your real constraints and objectives. They wanted a tool that could grow with their practice for decades. As the launch customer, we helped shape it around our value proposition.