The currency of a technical architect (TA) is an Architecture Description (AD), this is document describing a system, usually a digital software system. AD are distinct from actual software architecture, which is the "real" system itself as it exists (or will exist). AD are therefore always an approximation or version of the "truth". A key part of the architect's job is to see to it that the AD give as good a representation of the real system as possible. The set of AD describing a system is therefore never "done" and is a set of living documents.
There are many different types of "architect" within the digital domain, these terms often overlap, and a TA may wear all these "hats" at different points.
- Enterprise Architect - concerned with the wider context, not just software and digital systems, but capabilities of the business or organisation
- Technical Architect - concerned with the technology choices of a system
- Solutions Architect - concerned with the design and implementation of software systems
- Data Architect - concerned with specification of data and its uses in a system
Often as a TA, we need to create AD for an existing system that has grown organically and evolved in the real world. This is then a process of working backwards from the actual architecture to the As-Is AD.
The opposite process of starting with a blank page and working towards a AD for an imagined future system, is quite different. The TA must start from first principles and develop a To-Be architecture description of the system that should be built.
A TA does not come to a problem cold, they come with a set of principles that can help guide their decisions about an architecture. Establishing architectural principles early on in the process is important. Some examples of principles:
- User Centred Design
- Separation of Concerns
- Low Coupling
- High Cohesion
- Open Architecture
- Privacy by design
There are many different formal frameworks and approaches to doing systems architecture.
The ISO42010 standard, defines a set of requirements for creating AD of software and enterprise architecture.
Key aspects of the standard are:
- Stakeholders
- Concerns
- Viewpoint
- Views
- Model Kind
- Model
Identifying stakeholders is a first step when creating a set of AD. Stakeholders includes anyone who has an interest in the system at hand. Stakeholders can be grouped into broad categories (following the Rosanski & Woods approach).
| Type | Description |
|---|---|
| Acquirers | Oversee the procurement of the system or product |
| Assessors | Oversee the system’s conformance to standards and legal regulation |
| Communicators | Explain the system to other stakeholders via its documentation and training materials |
| Developers | Construct and deploy the system from specifications (or lead the teams that do this) |
| Maintainers | Manage the evolution of the system once it is operational |
| Production | Engineers Design, deploy, and manage the hardware and software environments in which the system will be built, tested, and run |
| Suppliers | Build and/or supply the hardware, software, or infrastructure on which the system will run |
| Support Staff | Provide support to users for the product or system when it is running |
| System Administrators | Run the system once it has been deployed |
| Testers | Test the system to ensure that it is suitable for use |
| Users | Define the system’s functionality and ultimately make use of it |
Once stakeholders are identified, the TA should list out their main concerns regarding the system at hand. Often these are best written as questions the stakeholder might ask of the architecture. Examples:
- "How can I continuously deploy my changes to the system?"
- "How can I control the costs of running the system?"
- "How can I ensure the system protects the privacy of patient data?"
- "How can I produce performance charts and reports that are easy to understand?"
User needs are a very specific type of concern relating specifically to users of the system. To follow a UCD principle, user needs would be given a higher priority to other concerns.
Concerns may be cross-cutting and shared by more than one stakeholder. To understand this a TA would map the unique concerns across the stakeholders, creating a matrix of stakeholders to concerns. For example:
| Trust User |
Cancer Alliance User |
Digital Analytical Team User |
NHSD Developer |
PCN User |
Somerset Developer |
|
|---|---|---|---|---|---|---|
| How can I upload CWT data? | ✓ | ✓ | ||||
| How can I monitor cancer waits? | ✓ | |||||
| How can I report in Power BI? | ✓ | |||||
| How can I download datasets? | ✓ | |||||
| How does eRS align? | ✓ | |||||
| How can I quickly answer user queries? | ✓ | |||||
| How can I test user issues? | ✓ | |||||
| How can I improve system knowledge? | ✓ | |||||
| How can I access different environments? | ✓ | |||||
| How can I see data at GP practice level? | ✓ | |||||
| How can I ensure outputs match? | ✓ |
In addition to identifying the stakeholders and their concerns, before beginning to design a to-be architecture for a system, the architect must also take account of any constraints on the architecture. Very few projects are entirely green field, with absolute freedom to make whatever technology choice seems the most appropriate, in general there will be very hard constraints on the types of technology, and structure of any future solution.
Some examples of the types of constraints that may apply:
- MUST use Oracle SaaS products as there is an ongoing commercial arrangement
- MUST integrate with the legacy BAU system via file transfer as this system is too expensive to replace at present and is business critical
- MUST ensure all data is kept in UK data centres and can be retained for the minimum legal term of 7 years
In addition to these business, technology and infrastructure constraints all systems will usually have to meet a set of non-functional requirements (NFRs), these also act as constraints on the choices of technology an architect may make:
- Performance: financial trading system MUST have low latency and be able execute 100 trades per second
- Scalability: social media platform MUST be able to handle 100 million users creating 1Bn posts per day
- Security: healthcare system MUST protect patient data and ensure only users authorised by the patient have access
- Availability: payment system MUST be available 99.999% of the time and have a high level of fault tolerance
In the same way a "real" architect would create elevations that depict the plans and design of a building from different directions, a systems architect will define "viewpoints" that frame set of concerns of the architecture. When following an architecture framework, the viewpoints to use will be specified by the framework.
For example the 4+1 framework specifies 5 different viewpoints:
- Logical
- Process
- Development
- Physical
- Scenarios (this is the +1 in 4+1)
The C4 model specifies 4 viewpoints that effectively "zoom in" on the software architecture of system, starting from a high level and getting more detailed at each level:
- System Context
- Container
- Component
- Code
The C4 model is primarily concerned with the software organisation of a system, and is therefore quite static. To capture the dynamic aspects of the system it has supplementary viewpoints: Dynamic, System landscape and deployment.
Each viewpoint defines what kinds of "model" of the system can be used in a view.
From each viewpoint the TA creates a view of the system. A view will only ever have one "governing" viewpoint. A view can be made out of one or more "models" of the system. Each viewpoint defines what kinds of model of the system can be used in a view.
A model is basically a diagram of the system that goes towards creating that view of the architecture.
In everyday practical use a TA may create many "back of the envelope" or "box and stick" models of a system. We have all seen these scribbled on whiteboards and drawn in PowerPoint. The proliferation of these type of diagrams led to a desire to standardise and formalise the ways of making pictures of system architecture. This lead to the creation of the Unified Modelling Language (UML).
UML defines different types or kinds of models that can be created. Falling into two distinct categories covering structure and behaviour, each kind has a specific set of formal rules governing how a model can be depicted:
- Structural Diagrams
- Class
- Component
- Deployment
- Object
- Package
- Behavioural Diagrams
- Actvity
- Communication
- Interaction
- Sequence
- State
- Timing
- Use case
In addition to UML other modelling languages exist, which can help describe a system and how it works. One of the most well used that has gained popularity in business settings as it emphasises process over software structures is Business Process Modelling Notation (BMPN)
Some architecural frameworks are quite opinionated about the tools to use when modelling architecture, often these tools are proprietary and require training to use effectively.
As opposed to these more fully featured toolsets there is an increasing number of light weight "diagrams as code" type tools, that enable an TA to quickly produce architectural models using simple text based markup. The advantage of these tools, aside from their ease of use, is their ability to sit alongside code in code repoistory and to keep a history of changes as simple textual diffs.
journey
title CWT data uploader's user journey
section Correct errors and fill gaps in data
Communicate with MDT coordinators: 3: CDM, CPA
Extract from local cancer system : 2: CDM, CPA
Upload extract to CWT platform: 1: CDM, CPA
View summary of the upload in CWT: 3: CDM, CPA
Communicate with MDT coordinators: 3: CDM, CPA
Re-extract from local cancer system : 1: CDM, CPA
Upload the new extract to CWT platform: 1: CDM, CPA
section Align local data with national data
Run and download preview reports: 3: CDM, CPA
Check previews against local data: 3: CDM, CPA
Correct data: 3: CDM, CPA
section Correct shared care pathways
Agree referral dates with other trusts: 3: CDM, CPA
section Share data more widely within trust?
Some useful links
-
Frameworks
-
Modelling
-
Tools