Enterprise Requirements Series—Article 6
This article explains why business rules are foundational architectural inputs rather than simple documentation. It demonstrates how policies, regulations, contracts, and operational decisions shape software architecture by defining system behavior, workflows, security, compliance, and data management. The article argues that enterprise architecture is the technical expression of business decisions, making requirements engineering the bridge between organizational policy and software implementation.
Building Better Software by Engineering Better Decisions
Ask ten developers what architecture is, and you’ll probably hear answers involving cloud platforms, microservices, APIs, databases, messaging systems, or infrastructure.
Those are all important.
None of them determine how the business operates.
The most important architectural decisions in enterprise software are often made long before anyone selects a programming language or designs a database.
They are made when the organization defines its business rules.
Architecture does not create business behavior.
It implements it.
What Is a Business Rule?
A business rule defines how an organization conducts its business.
It answers questions such as:
- Who may approve an expense report?
- When should an order be rejected?
- Which customers qualify for a discount?
- How long must records be retained?
- What regulatory requirements apply?
- When must additional approvals be obtained?
These are not technical decisions.
They are operational decisions.
Software simply automates them.
Every Business Rule Changes the Architecture
Consider a simple purchasing system.
If managers may approve purchases up to $5,000, the workflow is straightforward.
Now suppose the organization changes the policy.
Purchases over $5,000 require director approval.
Purchases over $50,000 require executive approval.
Government contracts require legal review.
International purchases require export compliance.
Suddenly the architecture changes.
Additional workflow states appear.
New security roles are required.
Additional notifications must be generated.
Approval history must be retained.
Audit records become mandatory.
The software architecture did not change because technology evolved.
It changed because the business rule changed.
Business Rules Define System Behavior
Requirements describe what software should accomplish.
Business rules define how it behaves.
Two organizations may purchase identical software platforms.
One may require two levels of approval.
The other may require six.
One organization may archive records after three years.
Another may retain them permanently.
One organization may allow managers to override exceptions.
Another may prohibit overrides entirely.
The software may be identical.
The architecture cannot be.
Architecture exists to express business behavior.
Business Rules Are Hidden Everywhere
One of the greatest challenges in requirements engineering is that business rules rarely exist in a single document.
They are often scattered across:
- Corporate policies
- Procedure manuals
- Regulatory guidance
- Contracts
- Spreadsheets
- Email conversations
- Meeting notes
- Tribal knowledge
- Experienced employees
Some organizations discover their most important business rules only after a key employee retires.
Others discover them during production failures.
Requirements engineering exists to prevent both situations.
Developers Should Never Invent Business Rules
Eventually, every development team encounters an unanswered question.
What happens if two approvals are submitted simultaneously?
Can a manager approve their own request?
Should deleted records be recoverable?
How should duplicate customers be handled?
If the requirements do not answer these questions, someone eventually will.
Usually the developer.
That is not where business policy should be created.
When developers invent business rules, organizations unknowingly transfer governance from business leadership to software implementation.
The resulting system may be technically correct while remaining organizationally wrong.
Good Architecture Begins with Good Requirements
Architects often receive requirements documents filled with features.
Create reports.
Manage customers.
Process invoices.
Generate dashboards.
Those capabilities describe functionality.
They do not explain business behavior.
Without documented business rules, architects are forced to make assumptions that eventually become design decisions.
Every undocumented business rule increases architectural risk.
Business Rules Should Be Explicit
Organizations frequently assume everyone already knows the rules.
That assumption rarely survives software development.
A business rule should be:
- Clearly documented.
- Owned by the business.
- Measurable.
- Traceable.
- Testable.
- Version controlled.
- Approved by stakeholders.
If a rule changes, the organization should know precisely which requirements, designs, tests, and software components are affected.
That level of traceability is impossible when business rules exist only in conversations.
Architecture Is the Technical Expression of Business Decisions
Enterprise architecture is often described as the structure of systems.
That definition is incomplete.
Enterprise architecture is the technical expression of business decisions.
Business objectives define requirements.
Requirements document business rules.
Business rules shape architecture.
Architecture guides implementation.
Implementation delivers business capability.
When organizations recognize this relationship, architecture stops being viewed as an IT discipline and becomes a business discipline supported by technology.
Looking Ahead
Software rarely becomes difficult because the programming is complicated.
It becomes difficult because organizations operate under hundreds or thousands of interconnected business rules that must be translated into reliable, repeatable system behavior.
Requirements engineering discovers those rules.
Architecture organizes them.
Software automates them.
Understanding that relationship changes the way successful organizations approach every technology initiative.
Requirements Reality
Every business rule ignored during requirements becomes an architectural problem later.
Coming Next
Article 7—Every Requirement Needs an Owner
Requirements do not become correct simply because they are documented. Next, we’ll examine why every requirement must have clear ownership, accountability, and business authority before development begins.