The ACED model represents Architecture, Context, Engineering and Design. Intent flows from context, through design, architecture, and eventually into engineering.
During the process of developing software you work across all four activities, creating artefacts across frames of different sizes and detail. This is an iterative and agile process, working closely with stakeholders and reacting to new information to evolve the system.
Why on the outside of the system. This includes:
You use context to ensure you are going in the right direction. It is the big picture. Context is harder and slower to change than things you control within your system.
The functional contract to users and collaborating services:
Design creates the flow of your system along time and process. It is created to achieve an intent (from context), and is a prerequisite to creating an architecture.
Meaning and structure within the system:
Architecture refers to engineering, design, and context. It links things together and this information empowers you to safely change and evolve the system.
The realisation of the system:
Engineering is often about detail. You could also describe it as implementation detail.
When physically looking at something complicated you can take a step back to understand the bigger picture, or take a step forward to better see details. You can do the same in software.
But how this works in software is different. You can just zoom out and use the magic of high resolution monitors to achieve the same thing from one place, can you not? Well, yes and no.
The problem is if you put too much information into an image you end up risking miscommunication (and strained eyes!). Different people could extract different meaning, and it will take more time and effort to work out the big picture.
Stepping backwards and forwards is a convenient way to manage detail with the physical eye, and in doing so it naturally manages the breadth of what can be seen. You apply a similar principle in the ACED model by looking at applications and systems from different frames. Frames can range from high-level to low-level, and are split at natural structural boundaries - not only software boundaries, but also organisational boundaries.
We use frames when implementing software. We don’t necessarily resolve a need in the same frame where it originates - to amplify or limit its effects we will apply it further up or down the stack. You influence the development of lower frames through design and architecture in higher frames. Discoveries in lower frames can be taken to higher frames to benefit more of the system.
Some aspects of your design and architecture are only of interest to a subset of stakeholders. Using frames with the ACED Model you are considering what detail is needed where, matching design and architecture artefacts with purpose, and decision-making agency. Applying the ACED model improves your ability to communicate and collaborate successfully across natural organisational silos.
Today you are looking at an example set of frames. The ACED model is recognising frames, rather than standardising them. Frames allow us to apply architecture and design within different parts of a product or organisation. Each part of an orgnaisation will have its own stack of frames - the ACED model matches the frames to your socio-technical situation.
Parts of the model are your responsibility, others are not. You should only capture what is useful to your development process, and should reference rather than reproduce when referring to the work of others. ACED model is providing lineage to your design process and helping identify blind spots.
Select a frame to see how ACED model artefacts change as you move up and down the stack. These example artefacts are not part of ACED model, they are mapped against it. The ACED model is not applying all of these examples in one product. Use the buttons to see examples of activities working in each frame:
The ACED model is about being in control of your design and architecture. Theming your artefacts against each activity makes it easier to involve stakeholders, keeps the documents tailored to the tasks at hand, and makes it easier to evolve your solution.
Within each frame you are working in a similar way to a painter. The painter compiles photos and images that inspire them (context), they then sketch out the outlines of their work (design), and add the basic composition through use of block colours - this is your architecture and the enabling foundation for making the next stages easier. You then finally add in the details through engineering, working in smaller frames, potentialy on specific aspects - shadows, highlights, faces, etc.
In software you are working on a much more complex surface than a painter, and don’t have the benefit of walking away from a finished product in the same way that they do; you need to continue to evolve the products and keep learning through collaboration and testing of our assumptions.
The ACED model is used to:
Future plans for the ACED model:
The ACED model is one of a number of concepts we are developing. We can contact you when we publish new content, and tell you about our promotions, products and news. You can unsubscribe any time.
The Ministry of Software Design (MOSD) is a innovation hub in the United Kingdom. Our mission is to rescue the IT industry, where design and architecture are often poorly understood. Design is the key to architecting better systems, and architecting systems is the key to more maintainable and evolvable systems.
Our research and development are supported through our training, private speaking and consultancy services. Get in touch today.
