When I ask developers what they've been working on, they show me code. When I ask business stakeholders what they need, they describe problems. The gap between these two answers is where most software projects fail.
I've spent my career trying to close that gap. Not by getting better at translating business problems into code - that was always the wrong goal. By making business problems themselves the primary artifact. By building systems where the business logic is explicit, visible, and verifiable, not hidden in implementation details.
For decades, this felt like swimming upstream. The tools didn't support it. The economics didn't favor it. The market rewarded people who could write code fast, not people who could model businesses well.
That's changing. And when I talk about "shifting left" - about our profession returning to Information Systems thinking - this is what it actually looks like in practice. Not philosophy. Actual artifacts.
The hidden cost of code as primary artifact
What happens when your treat code as the primary artifact: business knowledge gets encoded in deeply technical forms. A pricing rule becomes a conditional in code with nested if statements and cryptic variable names. A customer approval process becomes a state machine hidden in a Domain Service (if you are lucky). An order validation rule becomes a custom exception class that only a developer can read and modify.
This works, technically. The code runs. The systems process transactions. But something valuable has been lost in translation.
The business rule started as a concept in someone's head - "we can't process orders over 50,000 euro without manager approval." By the time it's embedded in code, it's been transformed through layers of technical abstraction. The original business logic is still there, but it's hidden. If you want to know what rules actually govern your business, you can't ask a business analyst or a product manager. You have to ask a developer, and that developer has to reverse-engineer the original intent from code written months ago by someone who may no longer be at the company.
When those developers leave - and they will - that knowledge walks out the door. You're left maintaining systems where nobody fully understands the business logic without reading code. You're left with documentation that's out of sync with reality because the code changed but nobody updated the spec. You're left explaining your own business to external consultants who need three weeks just to understand why you process refunds the way you do.
Unfortunately, this is still how most organizations operate. And the hidden cost compounds over time.
The alternative: business knowledge as first-class artifact
There's a better way. It starts with a fundamental shift: business concepts become primary artifacts. Code becomes implementation detail.
This isn't a return to waterfall documentation. This isn't creating a 200-page spec that nobody reads and immediately becomes obsolete. This is something different entirely. These are working models that define how your systems actually behave.
Domain Models: The language of business
Start with domain models. A domain is a bounded area of business knowledge - a specific area of concern where consistent language and rules apply. An Order Management domain. A Customer domain. A Pricing domain.
Within each domain, you model the entities and relationships that matter to the business. An Order has a Customer. An Order contains multiple LineItems. A LineItem references a Product. A Customer has a DeliveryAddress, a BillingAddress, a PreferredPaymentMethod.
Notice the language. Order. Customer. Product. LineItem. These are business terms, not technical abstractions. You won't see "CustomerDTO" or "OrderEntity" or "customer_service_response_wrapper." The model speaks the language of the business.
Here is what a domain looks like. In this case the production domain of a pizzeria. Notice how it describes the relation to other domains, it's primary products & services and the terminology used within the domain. All in business terminology.
Here's why that matters: a person from your sales team, your finance team, or your operations team can look at this model and verify it's correct. "Is it true that each Order is tied to exactly one Customer?" Yes. "Can an Order have no LineItems?" No, that would be invalid - we need at least one item. "Can a Customer have multiple DeliveryAddresses?" Absolutely, and that's why it's modeled as a collection.
These models have value independent of any code. They're not diagrams drawn after the fact to document a system. They're the specification. When code is written, it implements these models. When the business changes - when you realize you need to support customer groups, not just individual customers - the model evolves first. Then the implementation follows.
What I often see in mature organizations is that these models become organizational assets. The domain model is owned by business stakeholders and technical architects together. It's versioned. It's reviewed. It's a shared understanding of what the business actually is.
Process Models: Making business logic explicit
But entities alone aren't enough. You also need to model processes - the sequences of steps, decision points, and transformations that turn raw orders into shipped goods or that determine whether a customer qualifies for a particular discount.
A process model makes this explicit. An order processing workflow might look like: Receive Order → Validate → Apply Discounts → Calculate Tax → Check Inventory → Reserve Stock → Create Fulfillment → Notify Customer.
But there are decision points: "Is the order valid?" If not, reject it. "Is there sufficient inventory?" If not, backorder or cancel. "Does the customer qualify for loyalty pricing?" Apply it or charge standard rate.
The process in its executable form. If anything changes to the process, then this artefact changes first.
These aren't abstract; they're how you actually operate. And unlike code, a process model can be read and verified by non-technical stakeholders. "When do we check inventory - before or after applying discounts?" The model shows you. "What happens if a customer's address is incomplete?" The model shows the validation step and decision point.
The critical insight: this process model IS the system behavior. When you change how you process orders, you don't just change the code - you change the model first. The model is the source of truth. Code is generated from it or implements it.
Business Rules: Governance without code
Now, within these processes and domains, you have rules. Pricing rules. Eligibility rules. Validation rules. Approval rules.
In traditional systems, these rules are scattered. One rule is hardcoded in a microservice. Another is embedded in a database trigger. A third lives in a scheduled job somewhere. Nobody has a clear view of all the business rules that govern the system. When a rule changes, you have to hunt through code to find all the places where it's implemented.
What if these rules were first-class citizens? Visible. Governable. Written in language the business can read and verify.
"Customers in region A get a 10% volume discount on orders over $10,000." That's a business rule. It should be explicitly captured, not inferred from code. "Orders exceeding $50,000 require manager approval." Another rule. "A customer can't place a new order if they have an outstanding invoice over 30 days old."
Example of a business rule described in Business language. This is used as the specification for the system.
These rules should be:
- Written in natural business language, not code syntax
- Owned by business stakeholders (not developers)
- Versioned and tracked
- Easily changed without touching implementation code
- Auditable - you can see when they changed and why
This is not a new idea. Business Rule Management has been around for decades. What's new is that AI changes the economics. Now you can have tools that interpret these rules, that apply them consistently, that generate code from them, that verify systems against them. The cost-benefit analysis shifts.
Why these artifacts outlive code
Here's what makes this approach powerful: these artifacts - domain models, process models, business rules, product definitions - outlive any implementation.
You might rewrite your entire technology stack. You might migrate from a monolith to microservices, or from microservices back to a modular monolith. You might move from on-premises to cloud, or change cloud providers. Through all of that, your domain models remain true. An Order is still an Order. A Customer is still a Customer. The business rules still govern behavior the same way.
But more importantly: when someone leaves your team, the knowledge doesn't walk out the door. The business logic isn't locked in someone's head or buried in code only they understand. It's captured explicitly, in forms that can be read and verified. The next person onboarding reads the models and learns how the business actually works.
In my experience, this is where real organizational learning happens. Not in architecture meetings or design reviews, but in the process of building explicit, accurate models of what your business actually is.
This is Shifting Left
"Shifting left" doesn't just mean testing earlier, though it includes that. It means development itself shifts left. It shifts from implementation to modeling. It shifts from writing code to capturing business knowledge.
The value of a developer changes. A developer who can write 10,000 lines of code per year is now measured by something more meaningful: How well did you capture the business domain? Can stakeholders read your models and verify they're correct? When requirements change, how quickly does your modeling adapt? How much business knowledge is locked in your work, and how much is transferable?
Implementation still matters - someone has to turn models into running systems. But that someone might not be a human developer. That someone might be AI, guided by clear specifications. The scarce resource becomes the ability to understand the business and capture that understanding in explicit forms.
What would change in your organization?
Imagine if your development teams had clear domain models that stakeholders could read and verify. Imagine if every business rule was explicit, visible, and governed. Imagine if you could trace a requirement from a business concept through to where it was implemented, or understand your entire system by understanding its domains and processes rather than by reading millions of lines of code.
Imagine what that would mean for knowledge retention. For maintainability. For the speed at which you can change systems. For getting non-technical stakeholders involved in defining how their own business operates.
That's not hypothetical. That's how sophisticated organizations are building systems now.
What business concepts are hidden in your code? What would it look like to make them explicit? What would happen if you measured your teams not by output velocity but by the quality and clarity of business knowledge captured?
These questions get at something real. Because the future of the profession - the actual valuable work developers will do - is less about writing code and more about understanding business and making that understanding transmissible.
The code will follow. The models are what matter.
