I came up with this cheat sheet way back in 2009-ish. At the time I was a real junior architect.
Looking at the sheet now there’s clearly areas where I have a grasp of the concept but I’m not using the correct terms, and in other areas I’d probably approach things a bit differently.
For this post I’m not going to correct everything as I think the old cheat sheet still offers an interesting point of view. So if I was to redo this now, how would it be different? Who knows – sounds like I just got a new to-do item.
Basic questions that apply to everything
Who – What – Where – When – How – Why
Time based aspects
- Is this the first time (new) or a repeat (existing)?
- How likely is reuse: how soon, how often, by whom?
Structure vs Behavior
(That’s it, simple as that.)
Performance Influence Matrix
Factors relevant to performance.
|Users||Transactions (Handled by a package)||Data-Flow (between packages)|
|Frequency (peaks, etc)|
|Volumes (totals, etc)|
- Throughput – Transactions per unit of time.
- Performance – Elapsed time per transaction.
- Latency – Wait time for a response.
- Capacity – Number of users / entities the system can support for a given configuration at a fixed level of performance.
- Scalability – Ability to increase capacity.
- Reliability – Length of time a system can operate without failure.
- Response Time – Performance as perceived by a human.
Factors relevant to security
- Protection of data, both at rest and in-flight
- Protection of resources (misuse of services / functionality)
- Protection of systems (DOS, Out-of-band attacks, etc)
- Boundary defense vs in-depth (e.g. encryption)
- How will Authentication & Authorization be enforced, be managed?
Logical Layers (not including hardware)
- User Interface
- Application Layer (Service Layer or Controller Layer)
- Domain Layer (Business Layer, Business logic Layer or Model Layer)
- Infrastructure Layer (data access, logging, network access, security, email, file system, and so on)
- Design, Prototyping
- Development / Refactoring
- Testing (suitability, integration, performance, …)
- Deployment / Use
Management Matrix: Who owns and controls what?
The point here is to take the concepts of Stewardship and Custodianship and apply it to the different parts of the stack.
|The process (that the system implements)|
|The system(s) (software / services)|
Business / Project Management
- What are the Critical Success Factors?
- Is there a common terminology across all involved parties?
- Organization / Structure
- Navigation, Browsing
- Create, Read, Update, Delete
- Atomic, Consistent, Isolated, Durable
Architecture -> Capabilities -> Features
- Execution qualities: such as security and usability, are observable at run time.
- Evolution qualities: such as testability, maintainability, extensibility and scalability, are embodied in the static structure of the software system.
Some System Quality Attributes
- Accuracy: Indicates proximity to the true value (how close are you).
- Precision: The repeat-ability or reproduce-ability of the measurement (consistency within certain bounds).
- Modifiability: Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).
- Portability: The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.
- Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
- See “Performance Influence Matrix”
- Expected transaction & response times (average, worst case)
- response times
- transaction rates
- Service Level Agreements
- Percentage of time available and/or hours of availability
- Expected recovery time
- Backwards compatibility.
- Dependencies – do they change between versions.
- Extensibility: New capabilities can be added to the software without major changes to the underlying architecture.
- Modularity: Well defined components, separation of concerns.
- Maintainability: the ease with which a software product can be modified in order to:
- Correct defects
- Meet new requirements
- Make future maintenance easier
- Cope with a changed environment
- System resources (storage, memory)
- People (hours of business, location)
- Software (dependencies, minimum requirements)
- Physical location
- Political location (e.g. hosted internally or externally)
- Ease of access (maintenance) vs. Security
- Communication between locations/servers/etc (how, management matrix, etc)
Levels of Granularity
[Macro >] Systems / Components / Classes [< Micro]
Some possible Views & Perspectives
- Logical (typically coarse grained view)
- Functional (fine grained logical view)
- Deployment / Physical
- Business Process (and specific roles within that)
- Specific scenarios (both business and technical)
- Application (Class / Module / Package / Component / Service)
- Run-time (Concurrency / processes / threading)
- The User.
- Various stakeholders
- Security / Attack Surface
- Public / private, internal / external
Other things to consider
- Alignment with current and future technology stacks, industry trends
- User Interfaces
- Backend Interfaces / integration
- Responsibilities (both within the systems, and teams delivering them)
- Design Patterns
- Appropriate Granularity
- Maintainability (evolvement – extension – refactoring)
- Dependencies (on other parties, systems, services, standards)
- Interoperability adherence to standards, or: is achieved when the coherent, electronic exchange of information and services between systems takes place.
- Resilience / Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
- Resource constraints (processor speed, memory, disk space, network bandwidth etc.)
- Scalability (horizontal, vertical / out, up)
- Usability by target user community