Proposal/Question: add experimental area

[codeliner]

Hi,

first of all thank you for the great resources provided here. I'm learning Wardley Maps at the moment and since the core domain charts are inspired by it I was wondering where to put the work of pioneers?

I made an extended version of a core domain chart to visualize my current understanding:

I've put the experimental area next to the core because we don't know yet if an idea will turn into a core domain. What do you think? Does it make sense?

[NTCoding]

Hi Alexander,

I think your approach makes a lot of sense. What I have been doing so far is using a separate notation (either a colour or question mark) to indicate an experimental concept (which I call a big bet). But I also think what you've done here is very nice too.

My feeling is that it is good to keep both options on the table. Some situations might be suited to one or the other.

It would be awesome if you could create a PR with an example. So far I've added one example to the repo https://github.com/ddd-crew/core-domain-charts/tree/master/examples but I'm going to add more.

Would also be good to get @yellowbrickc's opinion!

Thanks

[yellowbrickc]

With pleasure!

I like a lot the example of @codeliner because I think that something experimental cannot belong to core (yet). It is disposable. If I know that it belongs to the core domain then it is not experimental anymore. Does this make sense for you @NTCoding?

About the visualization: I like it a lot with "success once, failed twice" + the explicit name 👍

[emgsilva]

This is a great idea (especially having "semantics" to describe this phase/step on the product development on the chart). However there may be some "caveats" on positioning in this way:

• if it is plotted on that particular part it breaks the purpose of the axes of the chart: we would read experiments always as very differentiating and also with some degree of complexity (which is not always the case)
• I think by using the "color labelling" as Nick mentioned we can plot a "potential bet" (which starts by an experiment) for core. However, may also be on supporting... or may even be part of extending an existing BC/Product (mixing colors - sort of "discovery" of new developments within an existing product by experimentation).
• the interesting part that may not be captured so well with labelling/colors is the "failed experiments"...

[yellowbrickc]

I see what you mean. Experiments should not be too complex bc they could become too expensive compared with the result. Maybe I was trying to be too precise like developers tend to be? 😆 What about the mix: the visualization from @codeliner positioned in the core domain, like in the original diagram from @NTCoding

[codeliner]

Thx for the feedback!

@NTCoding

My feeling is that it is good to keep both options on the table. Some situations might be suited to one or the other.

Yeah, I thought about the "big bet" and if it fits my example, but also came to the conclusion that it is a different situation.

Some context why: I run my own (small) software development company and my team usually helps other teams to reach their goals. This is our Core. We invest into and work on Open Source libraries, which I categorize as Supporting. Last year we took some budget and time to run different experiments to see if we can turn our knowledge and experience into a product. And one of this experiments is on its way to become a Core domain. So more or less what I've shown in my example.

@yellowbrickc

I think that something experimental cannot belong to core (yet).

That's exactly my feeling, too. At least, it's my understanding of the evolution cycle and the PST concept defined by Simon Wardley.

Also when working with clients I'm looking for a way to clearly separate experiments from Core because you need a totally different set up, maybe even different people to run the experiments.

But yeah, we're talking about different types of experiments here:

1) Almost all startups place a big bet -> that's their Core for sure

2) Extending an existing BC/Product (like listed by @emgsilva ) starting with experiments -> yeah, this can happen within Core or Supporting, but should this be represented on the core-domain-chart? It happens within the business capability and is up to the team which is responsible for it. Not sure how much this can/should influence strategic decisions?

3) Running experiments to actively discover next Core Domain(s) -> I think this type of experiments (or should we call them Innovations?) always have model complexity. If not, a competitor would have discovered the innovation already. Once discovered, it is very differentiating, otherwise it would not become the next Core (now it can be a big bet or a first-to-market core, ...), which is the moment when Settlers turn the cheap experiment into a product.

[codeliner]

@NTCoding Do you have a template for the examples? If I send a PR, I'd like to use the same format as the existing examples.

[yellowbrickc]

I think this discussion, sharing the different experiences and real example are a very important part, thank you all. I think we should also port it in the repo, under /examples. What do you think @codeliner, would you include it in the PR?

[NTCoding]

There is an interesting theme here about whether bets/experiments can belong to the core. To answer that question we need to think about what it means to be core: core is where we should focus most of our efforts as a company because we believe the payback can be greatest.

So anything can be your core domain if it's the most important thing you should be doing as a business to gain a business advantage. The example of a startup is relevant: they might not have a revenue stream so their core domain is a big bet.

One of the challenges with visualising current vs future, is not de-emphasising the future. There is a natural bias for companies to keep milking their existing revenue streams. I try to emphasise that if you're not making big bets on the future, you might be in big trouble when your existing revenue stream starts to fall away.

[NTCoding]

@codeliner I'm sorry I don't have a template this is just a keynote file. In future I will use this Miro template: https://medium.com/nick-tune-tech-strategy-blog/strategic-ddd-remote-collaboration-toolkit-ab3176f878aa

But your example doesn't need to match. I think it will be easier for people to share examples if they don't have to worry about making the colours match etc.

Cheers :)

[codeliner]

Ok, I'll prepare a PR next week and try to include the discussion as well as a good example. Maybe I need some help with phrasing the description. My English writing skills are not perfect, but a draft is definitely doable ;)

@NTCoding

I try to emphasise that if you're not making big bets on the future, you might be in big trouble when your existing revenue stream starts to fall away.

I consider big bets as one of multiple strategic options to prepare for the future. As the name suggests you're taking a high risk by allocating resources and budget to a big bet Core domain. If your bet is correct revenue will be great, if not you're maybe game over or at least have to go back to start. I'd also put big bets into the Core and I like your suggestion of using a question mark for it.

Another option is to build an ecosystem around your Core by exposing an API and let other vendors build their products on top of yours. This way, you can observe the ecosystem and identify trends. Wardley describes this strategy in his book. You can lower the risk of a bet, but you have extra effort to maintain the ecosystem.

Yet another option is to use dedicated innovation teams (pioneers) with a fixed budget and/or time frame for each experiment. That's the option I visualized in my example. Here you don't place big bets. You make smaller bets to lower the risk of failure. You won't have luck with all bets but hopefully with one or two. For me this does not belong to the Core (yet). You don't focus all your efforts on it, because it is gambling.

Another real world example from a client (maybe I include this one in the PR and not the one from my own company): We were working on a digital transformation project for a fashion manufacturer. Goal was to help them digitize B2B sales. Looking back I'd say this was a big bet. Anyway, the interesting thing is that the company has a dedicated innovation team that is not involved in any operations. The team has a fixed budget per quarter and can use it for any experiment. For example they experimented with virtual showrooms and 3D rendering of clothes. Therefor they contacted universities and vendors to try it out. But the idea did not find its way into the B2B sales Core (yet), because 3D rendering takes too long and is too expensive for their fast changing collections. I'm pretty sure this will change in the next years.