The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links



Post Categories

Image Galleries

More than one order matters

Order matters. In real life when you’re in a library or a city or in your kitchen. And in software development. Order, the right order, helps understanding. Where there is order orientation is easier. Compare a city like Mannheim, Germany:


…to Algier’s traditional quarters, the Casbah:


Where, do you think, it would be easier for you to find the house of a friend?

Order is helpful, even important. But often order is hard to create and/or to maintain. Why’s that? What’s order anyway?

Order’s definition

If you look at Wikipedia it seems order is quite an elusive thing. There is no single page just defining the order I’m talking about and you very likely have in your mind.

Yes, order is about “an arrangement of items”. But it’s more than a “sequence”. The Free Dictionary defines it as:

“A condition of logical or comprehensible arrangement among the separate elements of a group.”


“A condition of methodical or prescribed arrangement among component parts such that proper functioning or appearance is achieved.”

That clears it up, doesn’t it? :-)

No, not really, I guess. So let’s dissect the definitions:

  • “arrangement”: Order is about “things” (elements, items, “component parts”) and their relations. Arranging “things” this way or that changes their relations with each other.
  • “proper functioning”: Order has a purpose. Elements in order serve the purpose better than elements in disorder. Thus order is the result of a conscious effort aiming at creating something “useful” through order.
  • “comprehensible”: Ordering items leaves them in a state which is easier to comprehend than the state they were in before. Reasoning about the items and their relations becomes easier. This requires some logical system consisting of rules and principles, though.

To sum it up I’d say “order” means:

A conscious arrangement of items according to a logical system to best serve a specific purpose.

This explains why Robert C. Martin says in his article “Does Organization Matter”:

“The organization structure that works for a thousand line program, does not work for a ten thousand line program. And the organization structure that works for a ten thousand line program does not work for a hundred thousand line program.”

He speaks of three different purposes which a single order cannot address. A 1K LOC program very likely serves a different purpose than a 10K LOC program or a 100K LOC program. That’s why they need different orders.

And in his article “Screaming Architecture” he argues that even two programs both with the same number of LOC should have different orders if their domain differs, because the order (structure) should mirror the purpose.

Order’s purpose

Since creating order is a conscious effort, it not only needs to enable some purpose (e.g. a motor pulling some weight or a software enabling online shopping), though. It also needs to serve its creators. Creators (and observers) need to understand it, otherwise it would be hard to create it in the first place or change it later on for adaption to a changed purpose (requirements).

An intelligible order is an order where cause and effect relationships can be determined. In software development this means questions like “If I change this here how does that affect the behavior of the software?” and “If I change this here how does that affect the evolvability of the software?” become easier to answer with more/better order.

Take these two arrangements of Mikado sticks as an example: For which arrangement do you find it easier to determine what happens when you move a stick?


To me, the purpose of order itself is to arrange items not just in any way to serve a “behavioral purpose”, but to arrange them in a way so that complexity is minimized.[1]

That’s why the “logical system” is so important behind any order. Because a “logical system” is an abstraction. It lifts a huge number of trees onto the level of a forrest. Causal relationships are easier to recognize if there are less details to take into account.

Multiple orders

By now it should be clear why order is important in general and in software development in particular. Without order, i.e. a conscious arrangement of code items following some “logical system”, a software’s behavior is pretty much accidental. And reasoning about it in order to fix a bug or add a feature might be near to impossible.

However, it should also be clear, a software system cannot be ordered in just one way.

Take a kitchen for example. I’m sure you appreciate an orderly kitchen with cupboards and drawers as containers for silverware and dishes.


The order is high - or to venture into the realm of physics: the entropy is low - because if you know the location of a single fork or plate it’s easy to reason about the location of other pieces of your household. There is a conceptual system behind how all this is arranged in a kitchen. And if not in your own kitchen then at least in a restaurant’s kitchen ;-)

But why arrange kitchen items in an order? Why not pile them up in a corner of the kitchen? That might damage them, it’s bad for hygiene - but above all it makes it harder to find an item when you need it. The specific purpose of the order in a kitchen is to enable efficient cooking and serving.

Now look at this picture:


That’s items taken from a kitchen - but in a different order. The same items can be arranged in different orders for different purposes. Here the purpose is to make eating easier.

And finally this:


Again items taken from a kitchen - but in yet another order.[2] What’s the purpose here? Maybe to ensure all items are cleaned best or maybe maximum load (with less cleanliness).

Anyway, as you see, the same items can be arranged in multiple orders to serve multiple purposes.

And I guess it also has become obvious that order is relative. Order is in the eye of the beholder. You need to at least understand the “logical system” behind an order to appreciate an arrangement. That’s why - if you’re like me - you should visit a gallery of modern art only with some kind of guide. Otherwise you might see chaos where there indeed is order ;-)

Multiple software orders

Now finally on to software. What kind of order does software need? And what is it that needs to be consciously arranged?

The last question is easy to answer. It’s logic and data that needs to be arranged. With logic being programming language statements producing behavior, i.e. transformations, control statements, and hardware access/API calls.

But to what purpose should these language constructs be put in an order?

I suggest to order code to fulfill some requirements. Creating order takes time, i.e. it costs money. So it better serves the source of money, the customer. That means it should be of some use to her. What’s of use to a customer is stated in a requirements document.

Requirements can be divided into two broad and obvious categories:

  • Functional requirements
  • Non-functional requirements

But that’s not the only way to slice requirements. Here’s another perspective:

  • Runtime or behavioral requirements
  • Design time or evolvability requirements

Both categorizations can be brought together in a triple:

  • Functional runtime requirements; example: an online shop should let you search products.
  • Non-functional runtime requirements; example: product search in an online shop should be so fast it shows results while you’re typing.
  • Non-functional design time requirements; example: the online shop should be (quickly) adaptable to all sorts of unforeseen requirements over the next three years.

Maybe you come up with even more requirement categories. But even with just these three at hand the question is: How do you create separate orders for each of the categories?


The order creating the most heated discussions is the one pertaining to non-functional design time requirements. When you do object-oriented programming you do it for this reason.

Classes are modules like libraries and components and functions. Modularization thus is the art of imposing an order on code to increase developer productivity and code evolvability.

Here’s a class design as an example for a module order from a recent article of mine:



The order most desired is a different one, though. It’s the order needed to deliver on non-functional runtime requirements (or efficiencies) like performance, scalability, security etc.

How should logic be arranged to make a system scalable or responsive? And how do you call the containers for code to pack-up logic in for that purpose? I call them hosts as opposed to modules.

Hosts run code on a thread or in a process or on a machine or in a network. It’s the same code as arranged in a module order - but now arranged differently. Like with silverware and plates. Two purposes, two orders.

Here is an actor diagram from the same recent article as an example of a host order:


Don’t be surprised to see classes in this diagram. Classes are used to manifest some hosts in code.


But wait, there is more! What about functional requirements? What’s the order for them? Interestingly there is hardly any talk about order to fulfill functional runtime requirements.

There are some diagrams to depict functional order, e.g. flow chart, Nassi-Shneiderman diagram, sequence diagram, activity diagram. But their use is comparatively rare and not very systematic.

But functionality needs order like performance or evolvability. That’s why I suggest to become more conscious about it and to build skills to design it. The tool for that to me is Flow Design. Yes, I believe functional order is best expressed by declarative flows, that is data flows.

Data flows describe functional behavior as a series of processing steps connected by messaging.

Finally here is an example data flow from the mentioned article as an example of functional order:


The functional units you see are encapsulated by modules and hosts.

Designing orders

The orders for functionality, efficiency, and evolvability are orthogonal to each other. You can change the module order without changing the functional order. You can change the efficiency order without changing the module order. At least in principle, at least to a certain extend.

Because the orders intersect. They intersect at the function level. Functions are the smallest modules and the smallest units of the functional order and the smallest containers to contain logic for some efficiency requirement to be distributed across threads and operating system processes etc.

  1. Since the first requirement to fulfill is the functional requirement, functional order is the first to establish. Start by defining behavioral processes. You need to give the input-output transformation an orderly structure. They will be running whenever a user triggers a software’s behavior.
  2. Once functional units have been arranged in data processing flows start to arrange them in a host order. Distribute them in a way so they fulfill efficiency requirements, e.g. by running them on their own threads or even devices.
  3. Finally arrange the functional units in a module order. Distribute them in a way to maximize evolvability - without sacrificing any of the host order requirements.

Although I listed the order design steps in this order and recommend to advance in this way through software design, sooner or later you’ll change the sequence. Depending on the size of the project you might want to start with a coarse grained host order, then continue with the functional order, and determine modules last.

Anyway, it’s up to you. Just don’t forget to give your code an order in all relevant dimensions. There is always more than one order to code. And all of them matter.

  1. My personal definition of complexity is simple: A system is complex if cause and effect relationships are not clear. Your TV set is not complex; it’s perfectly clear to you what happens when you press a button on its remote control. But an airplane is a complex system. Unless you’re a pilot it’s not clear what’s gonna happen when you press a button or turn a knob on the dashboard in a cockpit. On the other hand a system is only complicated if cause and effect relationships are clear or can be found with some reasonable effort. Now think about relationships with friends and your spouse: Are your social systems complicated or complex? ;-)

  2. Believe me, even if you sometimes might think there is no order to how items are place in your friend’s dishwasher, there is an order. Just try to add another item to an already fully loaded dishwasher and your friend will certainly tell you you’re doing it wrong ;-)

Print | posted on Thursday, May 21, 2015 3:42 PM | Filed Under [ Software design ]



# re: More than one order matters

Another interesting post. It reminds me a bit of aggregate modeling around bounded contexts. Have you every heard of Event Storming as a way of modeling the real world? You might find that an intersting way of exploring a problem domain.


Jason Wyglendowski
5/26/2015 2:47 AM | Jason Wyglendowski

# re: More than one order matters

Yes, have read/heard about EventStorming. To me it's a coarse grained approach to exploring the behavior of a software system.

You can look at a system's behavior from different perspectives:
-activities: you focus on what needs to be done, the process of transformation
-events: you focus on results, on what has been done

Sometimes one is easier than the other. In the end, though, you need to implement activities. Which might produce notable events.
5/26/2015 8:15 AM | Ralf Westphal
Post A Comment

Powered by: