Architectural modelling and systems design

Posted in architecture with tags architecture modelling design systems-thinking -

Projects are initiated because there is a clear, albeit sometimes high-level, business objective in mind. We need to be able to guide the development efforts towards that goal, and we need to know when we have reached the destination.

However, software projects may require a large amount of time for the completion of a full implementation. As such, we need to ensure that we do not lose sight of our destination as we progress, and we need to be able to communicate this intent effectively to all relevant parties.

This responsibility falls under the role of the architect. The process involves deriving good system designs that will support the project over its life-span, while simultaneously supporting the technical endeavours.

An effective approach to this crucial phase of a software engineering project is to engage in model driven development. Here, the architectural output is that of one or more concrete software models. These capture the key elements of the system design. This might include and highlight aspects such as:

  • the structural decomposition of the system,
  • the key elements of application programmer interfaces or protocols that allow subsystems to interact,
  • the subsystems requiring replication for redundancy,
  • the subsystems requiring replication for scaling,
  • etc.

When I oversee the architecture of projects, I will evaluate the level and form of modelling that is needed in order to validate and communicate designs. While some of the techniques are introduced in more detail below, the important point is that this approach helps to ensure that systems thinking can be applied more effectively to the project as a whole, and that projects can be kept on track.

Ultimately this leads to more successful projects that remain aligned with the business objectives.


Architectural Models

As with many other disciplines of engineering, in software engineering we build models of the system before embarking on the effort to construct and assemble the finished product.

Depending on the complexity of the project, it is useful to realise that there can be many levels of modelling fidelity that can be employed. The initial steps can be the more traditional and “softer” modelling approaches, such as:

  • stories for simple tasks, where it might be sufficient to capture a basic written story. This might highlight the key elements of the design and position the implementation relative to the design intent.
  • design documents for slightly more complex systems, where it may become necessary to create a more complete and formal document of the design. This would generally contain strict definitions of terms, enumerations of subsystems, and details of user or stakeholder roles, as well as diagrams detailing how the system is to be decomposed and linked.

However, as the system complexity increases I start to introduce more explicit forms of modelling, such as:

  • process models for some systems where the key element that needs to be captured is the process flow. That is, the flow of data across many disparate subsystems. The actual implementation may require performing complex operations in each of these subsystems, however, often it is useful to model only the data flows. That is, the base message types that will need to move between systems and the primary states and data dependencies in those systems.
  • system models in other systems where more attention may need to be given to the internal state machines of different subsystems. However, for the purpose of modelling we can factor out and ignore issues of data persistence or subsystem replication.

For both of the more complex modelling requirements, the actor model of programming is well suited to building models. It allows for defining light-weight concurrent elements where the focus is on the state machines and the message flows.

In taking this approach, our architectural models become a far more stringent documentation of the design. That is, the design is in fact documented as code. Additionally, these models can be verified with a greater degree of surety since the models can be executed and their behaviour can be observed.

The nett results are:

  • earlier verification of design correctness.
  • more formal communication between design and implementation phases with much less ambiguity in intent.
  • earlier opportunity for identifying areas for improvement or potential dead ends.
  • a more natural stage for testing out new ideas that arise from changes in the business context or understanding, while not needing to immediately disrupt implementation efforts.

When further combined with mechanisms for verifying the alignment between these models and production code, we are then able to close the loop between development and architecture.

Ultimately, the projects are more focused and successful, as developers can focus on the details and minutia of the implementation, without having to tease out many of the necessary design decisions as a side effect of the software development process.

This increase in focus allows for more rapid delivery to production, with faster feedback to business and closure on projects.

Written by Stewart Gebbie