In previous post we leverage a videogame analogy to stress how important it is for a team to surface proper taxonomy. Once defined, we can use it to support discussion, organize activity, tidy up materials, … Luckily, we do have a specific domain ready to exercise this method. ​​​​​​​Let’s shape our solution ubiquitous language.

Shell

Every user journey starts from a frontend. It can be a web application, a desktop application, a command line interface, … In our case, goal is to stich solution pieces, making heterogenous script set a compelling user journey and thus supporting the mind shift user needs to operate: exercising flagships through a proxy, aka the solution.

You may have noticed there is no such match in Rayman taxonomy. It’s perfectly fine. An analogy is used to provide a backbone, something to start from. But it is not frozen. You can amend it and enrich it to conform the domain you are working on.

Taxonomy Decison Record (TDR): Shell is the solution landing page.

Stages

As stressed before, standard human beings are not that good to process complex workflow at once. We are already used to adopt splitting or chunking activity to cope with that issue in many domains (Agile, C4, code).

First step in our case is to split workflow into bounding contexts like data prep, solve, post, … Pay attention to the fact that we are not talking about product/solver split, for obvious reasons:

• A stage can combine multiple products/APIs.
• A stage can use no flagship at all.
• It is BUT stage implementation details. As for code, details should not leak. ​​​​And by the way, end-user doesn’t care. Really.

As solution should not be a one-shot delivery, sticking to this rule would ease activities such as:

• Adding/removing stages.
• Complexifying/simplifying stages, e.g., moving from a local flagship launch to a remote API call.

TDR: Stages are the solution high level split. Stages are product agnostic.

Sections

Sticking to Rayman analogy, now we have defined stage boundaries - bounding contexts acting as biomes - it is time to refine content. One could decompose stage in sections, dedicated to a given activity, such as:

• Check prerequisites
• Perform some actions like importing geometry, refining mesh, tweaking simulation, …
• Assess results

Once again, no need to specify involved flagship/API yet.

TDR: A stage is a sequence of sections, dedicated to a given activity. Sections are product agnostic.

Semantic and layout

Regarding hierarchy, it is important to discriminate between:

• Semantic split, e.g., stages and sections
• UI layout, e.g., horizontal, vertical, …

Semantic split is not tied to a single visual layout. But whatever visual we pick (horizontal, vertical, …), we do have a semantic split first. By the way, we are used to leverage this well-known UI pattern, the Model View ViewModel, aka MVVM, for years now.

​​​​​​​Corollary: Semantic split does not constrain UI layout.

Objectives 1

Section requires a bunch of objectives to complete, such as in our case:

• Launch a flagship and operate
• Provision a backend worker and schedule work
• Assess configuration or results prior to engage downstream

Sections are described within shell (embedded recipe, hyperlink to external recipe).

TDR: Objectives are section recipe and land within shell.

Objectives 2

Objectives could also be integrated within flagship (via dedicated ribbon, smart help, …). Main idea here is to support end user by locally materializing sub workflow, especially when complex or disruptive.

Providing deep integration improves UX but comes with a price compared to plain old Vanilla product. Ensure you smartly balance between added value you bring to end-user and underlying cost (development but especially maintenance) it implies.

TDR: Objectives can also be complemented by dedicated product integration.

Skills 1

You may have noticed due to color scheme used on the previous picture, that skills we are empowered with in our case are of course products, APIs, services, scripts, … Those are the components we leverage to fulfil objectives we were assigned to.

In case of products, be sure to spend time refining your needs. Claiming for product XXX is good, but usually not what you are really looking for. Your interest is about feature YY and feature ZZ of said product XXX, which is not the same. Materializing those needed features will surface meaningful APIs for the underlying product and thus support driving satellite roadmaps. Remember, the more specific you are in your requests, the smarter outcomes will be served back to you.

TDR: Products, APIs, services, scripts are our skills.

Skills 2

Try also to describe the expected automation level you are looking for:

• Operating, i.e., user is manually performing tasks.
• Monitoring, i.e., user is there but for task supervision.
• Automating, i.e., user is optional for task completion.

And be kind enough to stage your journey. You may target full automation at the very end, but peacefully live for the first iterations with partial automation or even manual operation. You may even survive using placeholders, waiting for the requested services to be ready, and making a seamless swap at the end.

TDR: Skills can be automated, mocked, swapped and even sharpened.

Rules 1

Time to describe specific rules stage or section have to comply with. It starts by materializing needs, e.g.:

• Collaboration
• Concurrency
• Asynchronous processing

which leads to good practices or constraints, e.g.:

• User management
• Data management
• Session management
• Workflow management

which can be promoted as rules and be enforced accordingly, providing both support and awareness to end-user. By the way, you can gauge the complexity of a stage/section by the number of rules you apply to it. A too complex one may mean you should refactor it, e.g., splitting it in two.

TDR: Stages obey rules that enforce execution context and behavior.

Rules 2

Identifying traits rules apply to may help to shape a generic traits library, that can be leveraged to shape a generic rules library, that can be in turn leveraged to speed up section and stage creation.

For example, both licensing and offline rules leverage the network trait. Offline rule shares with collaboration and asynchronous the same synchronization trait. Materializing this matrix helps to surface rule interactions, compatibilities and incompatibilities.

TDR: Rules is a trait assembly. ​​​​​​One should be able to pick, customize and assemble traits to create new rule.

Tooling

We need an engine or framework to run the solution we are crafting. Ideally, it will deal with cross-cutting concerns such as authentication, data persistence, …

We will benefit of having an SDK to support solution crafting, as well as providing compelling debug facilities.

All deliveries should come with meaningful technical documentation, focusing on both personas, namely solution developer and solution user. Once again, ecosystem is crafting and continuously improving documentation.

TDR: Ecosystem to provide framework, SDK and compelling support (documentation, tutorial, sample).

Closing

Leveraging the videogame analogy, we built our own domain specific ubiquitous language. We crafted a clean taxonomy, complemented by visual and description. We also materialized points we should pay attention to. It’s now time to exercise all we defined to sketch a solution and see how it smooths the journey…