Business Architecture, Rules, and Requirements

We know to treat business rules and business requirements differently. One example – treat external government regulations as rules (because they are less subject to change than requirements). When you have multiple systems in an architecture, while “rules” makes sense for one system, “requirements” make sense for another. What do you do?

A Single-System Rules Example

Imagine you have a system that is responsible for calculating taxes on orders. Imagine that system is calculating VAT (value added taxes) in China.

After you analyze the regulations, you determine that the following rules describe what you must implement:

1. There are two groups of customers. General VAT payers and Small-Scale VAT payers.
2. General VAT Payers pay 17% VAT and will receive a Golden Tax invoice* (so that they may recoup their taxes later from the government).
3. Small Scale VAT Payers pay 17% VAT and do not receive Golden Tax invoices (because they may not claim a refund of those taxes).
4. All taxes must be calculated accurately (per product on an invoice, for a given customer) within 1 RMB per rules 1 – 3.

* A Golden Tax invoice is an additional piece of paperwork that, when required, must accompany the company’s standard invoice. This Golden Tax invoice is presented to the government to initiate the refund of taxes paid (and waived).

This is not the complete set of rules – I have simplified them for illustrative purposes, so don’t go implement anything based on this.

Your system receives invoices, updates them with the correct taxes, and returns them to the calling system. An invoice includes identification of the customer, and the products that have been sold to that customer. You document the four business rules above, and your developers implement a solution.

Given an invoice, your system calculates the taxes correctly per the four business rules. You’re done! Ship it!

A System As Part of An Architecture

Would that life were so simple.

How does your application communicate with other applications? Your tax-calculator has to receive an invoice without taxes, and return an invoice that includes properly calculated taxes. Your developers decide to implement your software as a service provider. The outside application passes an invoice, conforming to a defined schema, and the invoice is returned, conforming to a defined schema. Now are you done? Not quite. Who determined what is in the schema, and how did they reach that conclusion?

To illustrate the problem, consider this: Does your schema include a field for the invoiced customer that identifies if the customer is a General VAT payer versus a Small Scale VAT Payer? Or does the schema ignore that field, relying on an expectation that your software will somehow know, or somehow request that information from some other application?

The problem is, in an architecture – where any number of applications co-exist, someone has to determine who does what (in terms of the applications, not the people).

You can’t write a requirement that states “the invoice that is passed to the tax-system must include the customer’s VAT payer status.” You can, but you can’t do it until some design decisions have been made. Is that putting the cart before the horse? Design driving requirements?! No, it isn’t.

While the “who does what” decision is inarguably design, it is architectural design. And as such, while it happens before system requirements, it happens after architecture requirements.

In previous articles, with an implicit focus on a single application, we argued for a distinction between requirements and design, and described software development as being analogous to an onion. The architectural element adds a couple more layers to the onion.

• Market Needs drive architecture requirements (create invoices for customers to purchase products)
• Architecture requirements drive architectural design (one system creates invoices, another system calculates taxes)
• Architectural design determines the scope and requirements for a single application.
• Within the defined scope, the application’s requirements drive design.
• Continue into implementation and testing of the application.

[Note: Not shown, but just as important, is “end to end” testing of the architecture, across applications. We’re skipping that to make a single point about architecture and requirements – but it is still critical, so don’t skip it when executing.]

Requirements on Other Systems

Your tax-calculator application has defined an API that places requirements on the invoice-creation system. By defining that the API will include a “General vs. Small Scale” VAT Payer flag, you are placing a requirement on that other system.

This hints at one of the challenges of developing architectures. Someone has to determine if the current customer is a General or Small Scale VAT payer.

One (obviously poor) approach would be to ask the customer for every transaction what their VAT-payer-classification is. This is fine (and possibly even required) for first-time customers. But for a repeat customer who orders products every day, this would get tiresome for the customer.

Perhaps you have yet another application that just keeps track of existing customers. Your invoicing system is optimized for processing orders, not keeping track of customers. The architectural design decision is to maintain that information about existing customers, instead of asking the customer for every transaction.

Now you are starting to get some propagation of requirements.

• The tax-calculator system must know the VAT-payer-classification of each customer (to support rule #2).
• The architectural design sets the scope that the invoicing system must make the determination of a customer’s VAT-payer-classification. Therefore, the tax-calculator must be told what the customer’s VAT-payer-classification is, by the invoicing system.
• When invoices are created for existing customers, the invoicing system must get the VAT-payer-classification data from the customer-master application.
• When invoices are created for new customers, the invoicing system must record the customer’s VAT-payer-classification.
• The invoicing system must tell the customer-master application what the customer’s VAT-payer-classification is, for future reference.

Rules or Requirements?

When dealing with rules and requirements, this can be confusing. It is a business rule to account for VAT-Payer status when creating invoices (so that a Golden Tax invoice will be created in specific circumstances). But it does not look like a business rule to say that the invoicing system must tell the customer-master system the VAT-Payer-classification of each customer.

And that’s ok. It is not a business rule. It is a requirement.

Remember Traceability

The key to resolving this apparent conflict is to acknowledge that these other artifacts are requirements – and they are requirements that are needed to support the business rule. The business rule is dependent upon these requirements to be implemented – given the architectural design.

Remembering that this is a traceable dependency makes this easy to keep track of.

Remember Traceability

There’s another important reason to remember traceability. You need to know why the invoicing system must tell the customer master the VAT-payer-classification of each customer.

The architectural design requires the customer-master to keep track of the information. To keep track, the customer master needs to be told initially. The architectural design also requires the invoicing system to defer to the customer-master application for existing customers. And the architectural design requires the invoicing system to pass the VAT-payer-classification to the tax-calculator.

Design Before Requirements

Technically, yes, this puts design before requirements. But only architectural design – specifically, the allocation of responsibilities to each application, and the definition of how those applications must communicate with each other (or at least what information they must pass).