Switch the order of Strategize and Connect to have Strategize first

[skleanthous]

Hey all.

I would like to suggest switching the order of Strategize and Connect to have Strategize first.

I'm recommending this because I've often found that how we connect our system, and even the patterns and technical aspects we use when connecting, need to support how we view the subdomains of systems in question. For example, if we have a core domain with some connections to other non-core systems, selecting a specific pattern of integration over another may allow the core domain to evolve freely.

For an example from my current domain, assume we have a core service A that is responsible for retail order management from a logistics point of view. We (as a system) need to price the draft shipment and also see whether a carrier can ship the shipment. The pricing is a supportive subdomain and the responsibility of service B. Ignoring other subdomains, let's compare these two ways of designing the communications:

1. A processes the draft shipments and calls B to get prices
2. A processes the draft shipments and pushes processing to B which subsequently processes and stores the pricing info (for example A publishes an event that B subscribes to)

Choosing option 1 means that A is now free to evolve its behaviour (not just communication contract) with the minimal possibility to require changes to B for the system to work.

Option 2 however is the opposite. Our core domain may need to evolve in such a way that our supportive one can't support requiring potentially big changes.

To not leave this in theoretical space, one example of change in behaviour is introducing two-leg movements (using two carriers to deliver a package: one collects and takes to a depot and another from the depot to the recipient). Option 1 only needs internal changes (or introducing another sub-domain), and service B can still quote normally without knowing what depots are. With option 2 however, now suddenly we need coordinated changes across our system.

[yellowbrickc]

I agree :+1: I would add though that the whole process should be traversed forward and backwards again and again when discovering inconsistencies or decisions which eventually not fit anymore. Maybe we could add this sentence/advice at the beginning or at the end.

[skleanthous]

Shall I create a PR with the re-ordering of strategize and connect then?

I can also add the comment about traversing it back. I think the whirlpool model somewhat already encapsulates that, but maybe it's better to explicitly describe that people may want to reverse (and not wait to compete a cycle) as discoveries are made.

[emgsilva]

These are great ideas!

Maybe you can make a PR trying to articulate both ideas: recommending "always traversing it back" (as we most of the times get new insights as we do the "Strategize" part, but also the "Organize" for that matter); but also mentioning your point of switching order, namely: sometimes may be worth to do "Strategize" before "Organize" and "Connect" (and that is fine - these phases should not be seen as a linear approach, they are more like a "good default).

[skleanthous]

Tbh, I'd prefer to flip the order of Connect and Strategize, so the "default"will have Strategize first, for the reasons I outlined in my initial comment. I am still quite happy to speak about going or traversing back, but it's important imho that the current order changes exactly because in most cases Connect is informed by our decisions and discoveries during Stratgize.

[NTCoding]

I think @skleanthous makes a good point. While this process is for beginners and learners, and the order depends on the context, I do think a subtle nudge to explore core domains before getting into architecture is the right way to go.

Regarding the 2nd issue about messaging, maybe now is a good time to address that but in a separate PR. At the moment we do 3 things:

1. The evolutionary/iterative message at the top
2. The cyclic arrows around each section
3. All throughout the readme there are caveats and guidelines about varying the order

After 2 years, I think it's great to revisit this fundamental point whilst considering 2 fundamental challenges:

1. How do we keep it simple for beginners as an onramp
2. How do we avoid it being seen as The One True Way or a rigid process

@yellowbrickc Can we talk about this in another PR?

[Max-Git]

Thanks @skleanthous for the suggestion. That made me realize that I'm almost always doing Strategize first and then Connect in trainings or while consulting 🙂 It feels indeed more suitable to know what are your core, supporting and generic domains first in order to choose the best strategy to connect them.