At IRM we often use this picture to talk about the stable parts of the business. Actually we have used it at least during the eight years I‘ve been working here.

The least stable part is the organisation itself. Many of us have been affected by organisational changes during the last year and just as many of us will be affected by a change this year. Since it changes all the time it would be unwise to base any software architecture on the current organisation.
As a side note: This is one reason to why I often talk about (user) roles as a bad thing to base the security checks on for a system, even though it is often well supported by the platform.

The most stable part of the business is the structure of the information we need. As long as IRM have been a consultancy firm we have provided services to our customers in projects for which we have always tracked the hours (time) each employee have worked. Surely the information changes too, for example we have for many years educated other in both internal and open courses, but this was not part of the business when IRM started back in 1982. The content changes (hopefully) rapidly with new customers and projects all the time, but not what information we need to track.

How we have performed our services and the internal work have changed over time. It is the process we try to improve all the time. Since the process itself is something that we want to change this is also unwise to base the software architecture on. Still this was a very common advise when SOA was hitting the hype curve, but I believe that is a mistake that happened because we so eagerly wanted to align our solutions better to the business process (of course the system need to support the processes very well, but it shouldn’t be the part that we base our architecture on).
If we dig a little bit deeper into processes they are a series of activities, triggered by an event, that are performed to deliver a value for a customer. The activities are more stable than the process itself, but even more stable are the events. Actually there is an event after each activity that triggers the next activity. An event can also be found when studying the state transitions of the information, for example visualized in an UML State Diagram. This have lead me to talk about the events as the line between Process and Information in the stability diagram above.

I would say that information and events are two important artifacts to pay special attention to when designing software. This spans from defining the correct aggregates (in DDD) to defining service boundary (in SOA) or Bounded Context (in DDD) to integration between systems. I haven’t written about business capabilities in this post, but also when using capabilities for example to define services, you need to make sure that information which must be consistent (not eventually consistent) belongs to the same capability and the most important way of communication between services are based on events.