work in progress – being completed through Jan 2021
We’d appreciate any feedback you have in success or problems in getting this tech demo to work. Please send any feedback to firstname.lastname@example.org
Operating Model Tech Demo
This is a tech demo to show how to simulate information being processed through a business operating model.
The demo uses a fairly easy to understand operating model, so that we can focus on how to set up the apps and scripting to make it run. Its based a simple ordering process, including invoicing, customer payments, and stock reordering.
This tech demo uses Ruby and MongoDB for server-side scripting, however you could implement something similar in any language so long as you follow the required JSON over HTTP based comms conventions.
This is what it will look like when running.
Scroll down to Step 1 if you just want to get the tech demo set up and running.
Scroll down to Step 4 if you just want to get the base AIM installation up and running.
In an AIM operating model, there are 4 main building block that you can use to simulate the lifecycle of business information to achieve business outcomes.
- Functions – (cubes) can consume, transform, and produce information. These are your basic information processing building blocks. They are used for both processing information which is internal to a domain, and exchanging information across domains.
- Components – (planes) represent business domains, or the object-oriented building blocks of the business operating model.
- Flow steps – (connectors between cubes) are used to exchange information between functions, typically across domains.
- Info Stores – (cylinders) can store either the master version of information, or an operational copy.
Tech Demo Architecture Overview
The tech demo contains 3 business domains – ordering, warehouse, and finance.
Each domain will have its own MongoDB and REST API.
In addition to this there’ll be 1 more REST API that handles communications with AIM, and orchestrates REST API calls to the 3 downstream domain REST APIs.
The 3 x MongoDB collections are:
- ‘techdemo-orders’ – to receive customer orders and initiative shipping
- ‘techdemo-warehouse’ – to manage stock and supply chain
- ‘techdemo-finance’ – to handle billing, invoicing, and supplier POs.
It would have been possible to use a single REST API and MongoDB collection.
However, in a large Enterprise, there will typically be multiple large areas of complexity (domains), and an object oriented approach can offer benefits in dealing with this complexity.
Further, when we upgrade this tech demo (coming soon) to be based on multiplayer functionality, we’ll have 3 AIM models communicating with other, and in that case we don’t want our underlying domain logic and data persistence to be monolithic.
‘Architecture Multiplayer’ is based on the idea that different domains create their own model, and then collaborate to bring them together:
- Work out the points of information exchange
- Resolve who masters each type of information
This approach also follows object-oriented principles of high-cohesion and loose-coupling between domains.
- High-cohesion means that all the complexity of the ‘ordering’, ‘warehouse’, and ‘finance’ domains are kept internal to the domain.
- Loose-coupling means that we reasonably minimise the interactions between domains, so that we can independently vary a domain without a change to one breaking the other.
What can I do in the tech demo?
There are different levels of usage of this tech demo. The purpose of this demo is to publish how to use the most advanced features, being simulation of business information flows that comprise a business operating model.
However, you can use the simpler features as well.
This is a quick outline of what you can do in the tech demo.
Basic – only requires you to install AIM modeller and complete step 4
- View the business operating model. Inspect the functions and how they exchange information in a declarative sense. By declarative we mean for example that you can see the a Place Order function might send Order information to a Capture Order function, but at this stage the information payload design for Order is not defined. Payload definition occurs via scripting.
- Fly around the model using your XBox controller to understand how information is created, consumed, and exchanged.
- Use the model in workshops with stakeholders from different business domains to reach agreement on how information is created, consumed, and exchanged.
- Categorise information exchanges by type, e.g. sales flows, ordering flows, financial flows.
- Develop animated stories that fly around the model and tell any story you like. A story might explain a pain point, opportunity, change management, or project scope. See Telling Stories
- Run AIM on a flat panel in your business on a story loop, to democratize architecture and explain the current operating model direction to everyone in the business. This then allows for feedback and interation of the operating model, and change management.
- Create shaders that highlight elements of your model. This can be based on key/value pairs, e.g. finance elements=blue, sales elements=green, or gradients, e.g. 0.1=red, 0.9=green, and then AIM will interpolate colours in that range. This is useful for heatmapping your operating model as part of investment planning. See Defining Shaders
- Use Excel to manage properties for each function and component, which is then automatically updated into AIM each time you change and save the Excel file.
- Export to OpenExchange format, which can then be imported into many Architecture modelling tools, e.g. Archi, where you can then build out the application and technology layers required as part of creating a Solution Architecture.
- Export the operating model information into to Word Doc for further sharing.
- Use Excel to manage the Project Portfolio. Capture Drivers, Goals, Projects, and Project Benefits, overlaid atop your model. Use this to do investment planning, where you can assess if a proposed project is contributory to realizing the operating model, and whether proposed projects are even aligned to the operating model.
More advanced – Involves scripting
- Run the server-side scripting to simulate operating model information flows
- Control AIM via command line scripting — AIM exposes a REST API allowing you to programmatically control AIM – See AIM CLI
Step 1 – Download files
Download the following files
- MongoDB to store state when simulating information flows.
- VSCode for editing Ruby files, or otherwise use your favourite editor. VSCode has a Ruby plugin for formatting Ruby code.
- Ruby v2.6.6 – to run the server-side processing for the operating model simulation
- AIM modeller – to build and run the operating model simulation.
- Tech demo – The actual tech demo content, including AIM model, and scripts to drive scenarios, and start MongoDB and REST APIs -> Tech demo - 31 Jan 2021
Step 2 – Set up MongoDB
Set up MongoDB so we can have persistence for the operating model data in our simulation.
This will allow us to run Scenario A and have its output available when we run Scenario B, and so on.
Step 3 – Set up Ruby
Set up Ruby which we’ll use to run the scripts to drive our operating model simulation.
Previous versions of AIM provided a JScript server in which you could add your own JScript files that implemented data processing for business scenarios.
Moving forward, you can use any programming language that can implement a few basic REST API based conventions to allow communication between AIM and your data processing layer.
Step 4 – Set up AIM base install
Set up AIM so that you can load and run the business operating model for this tech demo. This will allow you to orchestrate running various scenarios that make up the operating model.
This is just the base install of AIM, which is a 5-minute process to unzip your AIM modeller.zip download.
Step 5 – Setup AIM to run operating model scripts
Set up AIM scripting so that you can simulate information lifecycles through the operating model design. For this tech demo, this includes persistence into MongoDB, so that one scenario can pick up the output of a previous scenario.