OMNINEIn a roofing office in Alabama, two pieces of software sat side by side, each one healthy, each one doing its job, and neither one able to understand the other. Product names in the estimate templates no longer matched the names in the supplier library they were supposed to pull from, so every quote came out without materials and a sales team quietly became the integration layer between its own tools. Nothing was broken in the sense a vendor would recognize. What had failed was a decision almost nobody remembers making: what things are called, where each fact lives, and which system owns it. That decision gets made in every business, either on purpose or by accumulation, and the entire point of the second stage of the Omnine method is to make it on purpose, before any money moves.
Architect is where an engagement converts evidence into a design. You arrive carrying the two artifacts the first stage produced, a baseline of the operation and one problem named in a sentence and sized in a number, which is the pair described in Inside Assess. You leave carrying something a builder can build from. The full four stage sequence is mapped in how an Omnine engagement runs. This piece stays inside the second stage, because the second stage is where the value of everything downstream is decided, and it is the stage most owners skip without noticing they skipped it.
Where the value is decided
The claim that design decides value is not a designer’s self flattery. It is what the adoption data keeps finding. McKinsey’s research is specific on the point: of all the changes organizations make around AI, redesigning a workflow end to end is the one most associated with bottom line impact, and only about one in five organizations using the technology has done that work (McKinsey, 2025). Read that finding as a description of two populations. The minority redesigned the flow of work and then placed technology inside the new flow. The majority bought technology and placed it on top of the old flow, which is the pattern I took apart in why buying more AI tools is making you slower. Architect exists to put you in the first population deliberately. It is the stage where the redesign happens on paper, where paper is the cheapest possible place to be wrong.
The posture behind the stage comes straight out of my doctoral research. The leaders who adopted successfully were not the ones who had collected the most software. They were the ones who understood the system underneath the tools, the unified layer all the individual pieces were supposed to serve (Goodwin, 2014). Architect is that understanding turned into a working method: see the system first, and let the tools audition for roles inside it.
The three layers of a design
Every system that moves information has three layers, whether anyone designed them or not. The top layer is flow: the path information travels for the workflow in question, from the event that creates it to the action it enables. The middle layer is data and naming: what the entities in that flow are called, where each fact about them lives, and which system holds the authoritative copy. The bottom layer is tools: the software that executes the movements the flow requires.
Value is decided from the top down. A flow that takes the hand carrying out of the path creates value no matter which brand executes it, and a flow that leaves the hand carrying in place destroys value no matter how impressive the brand. Yet almost every owner shops from the bottom up, starting at the tool layer, for a simple reason: the tool layer is the only layer with salespeople. Nobody advertises the flow layer. No booth at a trade show sells you a naming convention. So the layer that decides value gets no attention and the layer that merely executes gets all of it. The second stage of the method is, mechanically, just a forced reversal of that order. Flow first, names second, tools last.
The flow drawing
The first artifact of the stage fits on one page. Take the single problem the first stage named and draw how its information should move once the problem is gone: boxes for the places information rests, arrows for every movement between them, and a label on every arrow naming its carrier, either a system or a person. Then draw the same page for how the information moves today and circle every arrow carried by a person. Those circles are the tax paths, the translation and chasing and rebuilding priced out in the communication tax your business pays every day, and the design’s whole job is to move as many circled arrows as possible onto system carriers without breaking anything the business depends on.
The discipline in the drawing is restraint. It covers one workflow, the named one, not the whole company. A design that tries to redraw the entire operation at once is a transformation program wearing a small business costume, and it will produce the dispersion the research warns about. One flow, drawn twice, current and future, with the differences between the two pages standing as the literal scope of the build.
The naming layer
The middle layer is the unglamorous center of the stage, and it is where the Alabama story earns its place in the method. Advocate Roofing arrived convinced its quoting software had broken in a version migration, and the felt problem pointed at a repurchase. The measured problem was smaller and stranger: the templates and the supplier library had stopped sharing a vocabulary, with a second, redundant supplier connection interfering underneath. The repair was an afternoon of work on the naming layer, after which estimates generated correctly with labor and materials included. The full account is in how a roofing company stopped rebuilding every quote by hand. The lesson generalizes past roofing: integrations are agreements about names, and when the agreement decays, two healthy systems produce one broken business.
So the second artifact of the stage is a naming table, and it is deliberately dull. For every entity the flow touches, the customer, the job, the product, the price, the appointment, one row records three things: the canonical name, the single system that owns the authoritative copy, and every other system that must map to it. Three rules give the table teeth. Every entity has exactly one owner. Every other place the entity appears either reads from the owner or is scheduled for removal. And a name change anywhere is a change request to the owning system, never a local edit, because local edits are how the Alabama drift begins. Notice that the second detail of the roofing story, the redundant supplier connection interfering underneath, was the same rule broken in a different place: one entity, the supplier’s product library, with two owners, which is one more owner than a system can tolerate. The table exists to make violations like that visible on a single page before they get expensive in the field.
If that sounds beneath the dignity of an AI engagement, consider what AI does to the stakes. A model that reads and writes across your stack inherits whatever vocabulary it finds there, and it acts on that vocabulary at machine speed. Show it three names for one product and it will confidently produce a fourth. Automation raises the price of ambiguity, which means the naming table is not a relic of old fashioned systems work. It is the load bearing wall the newest technology stands on.
The build, buy, or connect worksheet
Only after the flow is drawn and the names are settled does the tool layer get its turn, and it arrives through a gate. The decision tree in build, buy, or connect routes any single capability down one of three roads by asking two root questions, what already exists in the stack and whether the capability differentiates the business or merely plumbs it, and then pressure testing the branch with anchored questions about cost shape and ownership. The worksheet is that tree run in batch, once per capability, and written down.
The format is one row per capability the future state drawing demands. Each row carries the capability in plain words, what the stack already contains that touches it, the differentiating or plumbing call, the branch verdict, and one line of reasoning per anchored question so a future reader can re run the decision when the facts change. The default verdict is connect, overridden only when the tree forces build or buy, which for most small business calls it rarely does. The finished worksheet has a property worth noticing: brand names appear on it last, as answers, after every question that matters has already been asked. That is the shopping order reversed on paper, and it is the difference between a stack that was designed and a stack that happened.
What you are holding when the stage ends
Assemble the artifacts and you are holding the design packet: the current and future flow drawings, the naming table, the worksheet with its verdicts and reasons, and the measure carried in from the first stage, wired to the future flow so success is defined before anything is built. The packet is the stage’s exit gate, and the test for it is blunt. Hand it to a competent builder who has never seen your business. If they can build from it without calling you, the stage is finished. Every question they would need to ask is a hole in the design, and the time to fill holes is while the design still costs paper.
Two further properties mark a packet that has done its job. Nothing in it names a brand the worksheet did not route to, which keeps the design honest about whether the tools are serving the flow or the flow was bent around a tool someone already liked. And all of it is portable: the drawings, the table, and the verdicts hold their value with any builder, including one who is not me, which is the same designed in exit that runs through every stage of the method. From here the packet goes to the third stage, where the system it describes goes live.
Pressure testing the stage
The first challenge is the practical one: design sounds like a big company luxury, and a small business should just start building. The economics run the other way. A design packet for one named workflow is an afternoon or two of work, and the Alabama engagement prices the alternative, since skipping the naming layer nearly converted a repair into a repurchase. Large companies can afford to buy their way out of design mistakes. A small business pays enterprise tuition out of the owner’s pocket, which is exactly why the cheap insurance of paper matters more below the enterprise line, not less.
The second challenge comes from owners whose tools are already chosen: the software is bought, so the decision is made. The worksheet still runs, and it runs better with incumbents in it, because owned tools enter as the standing answer to the first root question and strengthen the connect branch. What the stage adds is the part no purchase ever settled, the flow the tools should serve and the vocabulary they must share. The naming table in particular is tool agnostic. It is the one artifact you will still be using after every current subscription has been replaced.
The third challenge is the newest one: the models are getting smart enough to untangle a messy stack, so why design at all. Set aside whether the claim is true today and notice what it asks for, a system empowered to act across your business while the business declines to say what its own words mean. Capability does not remove the need for the naming layer. It multiplies the consequences of skipping it, because ambiguity that once confused a person at human speed now misroutes an agent at machine speed. The smarter the executor, the more the design matters.
Draw the flow this week
The stage has a self serve form, and it costs one page. Take the problem your audit or your readiness read surfaced, draw its information path as it runs today, label every arrow with its carrier, and circle the arrows carried by people. Then write the naming table for the three entities the flow touches most, one owner each. Most owners who do this discover the same thing the method is built on: the expensive decisions were sitting in plain sight, unmade. If you have not run the front of the sequence yet, the Omnine AI Readiness Assessment sits at the start of it, and about three minutes there will tell you whether your next honest step is a drawing or still a measurement.
References
Goodwin, M. R. (2014). A qualitative descriptive multiple-case study: Fortune 500 leaders’ social business platform adoption (Doctoral dissertation, University of Phoenix). ProQuest Dissertations Publishing (UMI No. 3648813).
McKinsey & Company. (2025). The state of AI in 2025: Agents, innovation, and transformation. McKinsey Global Survey on the state of AI.