"I often want to model ‘what if’ scenarios, i.e. what the various architecture domains would look like if we proceeded with Option A, or B etc ... [but] I don’t want my various different options to ‘bleed’ into each other in the model. ... The only way I’ve found round this in the past is to duplicate parts of my model to keep them separate (in different packages etc) - which is a bit ugly."
Of course, the problem Robin identifies is more than just time sequence dependencies. Sometimes we have to explore the differences between A-followed-by-B and B-followed-by-A, but there may be many other permutations to explore. If you have to duplicate parts of the model for each permutation, this severely limits the number of permutations you can compare.
Many architects will try to solve this kind of problem by abstraction - coming up with a model that abstracts away from the differences between the options, so that the model supports all the possible options and all the possible permutations between the options. However, the standard model isn't then much good for comparing the options. In some cases it may be worth building a flexible capability that can support both A and B, but how do I tell whether this is one of those cases?
(Michael Bell's SOMF modelling approach does allow AS-IS and TO-BE to be shown on a single diagram, but I don't know how practical it is to put multiple alternatives on a single diagram.)
What Robin highlights here is that the standard modelling tools and notations aren't always very helpful at supporting choice, especially when the choices get at all complex. Often it seems that the tools only really work for documenting the architectural and design choices that have already been made, rather than for making the choices in the first place.
The best answer I can give Robin is to use the available tools, but to adopt a different modelling style. But I need a good case study to work on. Contributions welcome ...
an email just arrived from Michael Bell providing a little more explanation of how this works in SOMF.
ReplyDelete"Indeed, conditional modeling has not been established. Current modeling languages obviously support the TO-BE paradigm, ignoring solutions’ permutations.
There are three chief modeling methods that can accomplish this. The first is associated with an approach that is called USED-TO-BE, which depicts in diagram or a script that describes past design solutions. The second is the AS-IS model that illustrates the current state of a design (an intermediary state that differs from the USED-TO-BE). The third identifies two different FUTURE scenarios: The Time Machine model that allows you to go back in time and apply changes based on different design or architecture assumptions. The Thread or the Projection method is also a futuristic model that enables to create a few detached or combined threads to help foreseeing outcomes of future architectures.
SOMF enables you to view these three perspectives. It really depends on what type of transparency you are trying to apply to your design. These can be tracing architecture best practices, business ROI, hardware reuse, etc. with SOMF you can also develop design permutations, however, it would be too complex to catch all in one diagram. Thus, create different perspective for each, or focus on the chief concerns in single diagram."
Thanks Michael.