Кросс-пост "The practices of informational systems architecture". #СМС23
This post is the first in a series about the important aspects of the discipline (method) of informational systems architecture. The word “systems” in this long phrase refers not merely to the “architecture of informational systems” (any systems that involve some information technology or software, which is nowadays pretty much every system), but to systems architecture, and therefore, systems thinking. A discipline (method) is what people in a certain role do (the role of system architect, in this case) to make build systems. Every word in italics in the previous sentence has a specific meaning in systems thinking.
In this post, I describe the practices of systems architecture. Whenever I write “architects do X”, I refer to the role “architect”, not a position in the org chart of a person in that position.
The outline of the practices can be used as a checklist for multiple purposes:
- Not to forget something important when doing the architecture of a specific informational system.
- Evaluate the competence of candidates for informational systems architect positions on a project.
- Guide the development of people who play the role of a systems architect or want to start playing this role.
The most quirky of all, this list of practices is even somewhat useful in developing personal concentration (a transdiscipline of the intelligence stack), because humans in the modern world operate as cyborgs, biological bodies supported by numerous computer systems. Therefore, in developing and maintaining these support systems, everyone plays a role of a system architect!
Outline of the practices
If the practice doesn’t properly belong to systems architecture, the discipline to which it belongs is given in parens (more explanations in the discussion below):
- Model the data
- Analyse the system
- Discover, analyse, and manage requirements and the qualities of interest (requirements engineering)
- Find and document risks
- Set priorities and make plans (project/product/systems management)
- Define and document internal system requirements
- Develop and document the engineering methodology (enterprise architecture)
- Manage internal requirements
- Synthesise (design, develop, create) the system
- Negotiate new external requirements with the system’s stakeholders (product/systems management)
- Evaluate communication and collaboration risks (enterprise architecture)
- Manage and plan architectural changes and their lifecycle
- Evaluate the alternatives and estimate the risks of making the change
Discussion
In data modelling, architects use semantics, ontology, and the theory of information.
System analysis is creating multiple views (i. e., models) of the system according to the viewpoints. I’ll describe the possible viewpoints below in this post. With these views, architects do the following:
- Estimate how well the system (already existing or envisioned), or a particular system’s function fare according to the system qualities that the stakeholders of the system are concerned about. Discovering (gathering, eliciting), analysing, and managing requirements and the qualities of interest (areas of concern) are the practices of requirements engineering (product management, product ownership) and not of systems architecture, but nevertheless architects often do this, especially if there is no product owner in the org chart of the project.
- Identify conflicts of requirements (qualities, mutual needs) among the parts of the envisioned system. Architects then resolve these conflicts during system synthesis, described below. A related idea by Tyler Neely: “If it’s hard to model or check specific invariants of a system, it could be a symptom that the architecture is unsound.”
- Identify the pain points (hotspots, weak links), i. e., the places with the highest ROI of intervention to guide team priorities and future changes to the architecture.
As part of system analysis, architects also find and document risks (e. g., using Failure Mode and Effects Analysis) in the qualities for which the concept of risk makes sense. Some qualities, such as (functional) safety and resilience pretty much “consist of” risk analysis, there is nothing in analysing these system qualities but risk analysis. In analysing availability, durability, privacy, security, or calendar time (effort) of system creation, risk analysis is a large, but not the only part. In the context of yet other qualities, such as throughput and cost, risks are considered less frequently. Finally, there are qualities to which the notion of risk is hardly applicable, for instance, extensibility and maintainability. Risks inform the priorities and plans of the project team, too.
Setting priorities and making plans are among the practices of project management or product management, but, of course, architects and engineers frequently do it themselves.
Architects define and document internal system requirements, such as testability, debuggability, maintainability, and so forth. Internal requirements are closely related to the corresponding disciplines of engineering methodology: for example, system’s testability is related to the testing methodology, observability is related to the methodology of system operations (reliability engineering), and so on. It’s not a given that supporting a certain methodology implies some architectural requirement, but sometimes, it does: for example, as Steve Yegge noted, “retrofitting instrumentation onto a system that wasn't designed for it is almost as hard as adding an extensibility layer”. Formally, developing and documenting the engineering methodology are practices of enterprise architecture rather than system architecture, but these roles are often played by the same person on small and medium-sized projects.
Management of internal requirements includes:
- “Trading” these requirements against each other for achieving optimal team velocity and minimising the cumulative engineering effort expended on the project over its entire lifetime. The development velocity doesn't always need to be maximal if achieving this velocity itself will take more time than the entire project. Steve Tockey noted that “requirements have a half-life”. Priorities of internal system qualities also depend on the project’s strategy and future projects: for example, Will Larson recommends prioritising flexibility at the time of system growth because it saves a lot of time during system migrations and rewrites.
- Tracking internal system qualities, such as code metrics.
System synthesis is designing the system, or, in other words, creating the architecture. Architects use their knowledge of algorithms, design patterns, available platforms, building blocks (libraries and off-the-shelf components) to “assemble” the architecture or to come up with a solution to a conflict in requirements among the system’s components. When a solution is not obvious or is not found after simply trying every possible combination of existing algorithms (patterns, components, etc.), architects use more advanced problem-solving practices, such as TRIZ. It’s possible that the problem could only be solved with a novel algorithm. In a more “casual” sense, architects and engineers develop new algorithms regularly (there is no strict boundary between “algorithm”, “form of computation”, and “architecture” concepts). In a more “exalted” sense, developing new algorithms is the practice of computer science research, not engineering.
If there is no architectural (or algorithmic) solution to a conflict among external requirements (or requirements among the subsystems), or the engineering team couldn't find such a solution or implementing the solution is infeasible (which is just a special case of a conflict of requirements: maybe with cost, project timeline, or regulatory requirements), then architects inform managers how much certain requirements should be weakened to make creating a successful system possible. Negotiating new external requirements with the system’s stakeholders is a practice of product management, but, as well as gathering requirements, architects often have to do this themselves.
In deciding how constructive parts (subsystems) of the system map onto functional parts, architects consider the current enterprise design (team breakdown) and the future projections (such as spinning out new teams, dismantling teams, splitting teams, or merging teams) and evaluate communication and collaboration risks. This practice could be attributed to either system architecture or enterprise architecture, as well as the practices of engineering methodology. See Conway’s law. Stephen O’Grady writes how Amazon’s organisation design affects the design of AWS services.
Architectural change (lifecycle) management and planning involve the following:
- Creating detailed plans for architectural changes to an existing system, including engineering the systems that support the transition (i. e., scaffolding), rollout plans and rollback plans in case of unexpected problems in production.
- Documenting architectural changes, for example, with a record of alphas of project decisions.
- Prioritisation and planning of architectural changes so that they don’t conflict with each other. Typically, the latter means just making sure that only one architectural change is in the works and rollout at a time. When there are multiple proposed changes that are inherently in conflict (implementing one will block off another and vice versa), only one change should be chosen for implementation.
- Controlling that architectural documentation is updated when the change is complete and making sure that the systems that supported the transition are shut down.
When there is some uncertainty regarding how well the architectural change will play out, to inform change prioritisation and planning, architects evaluate the alternatives and estimate the risks of making the change. For this, architects apply (causal) explanative reasoning to the system behaviour and the underlying theories (more on this in another post in this series) and Bayesian logic. After the rollout of such a change, architects manage the evaluation of the outcomes (evaluation of the outcomes itself is a practice of validation, not architecture) and decide what to do next, for example, plan yet another change, taking into account the outcomes of the previous intervention.