There’s a lot to think about when architecting and designing systems these days (or on any day, really), and it’s especially easy to over look something when you're under pressure (in a meeting or on the phone).

If you’ve ever had that nagging feeling that you’ve forgotten something important (like rotating the domain protocols) then this might be the answer: the Architectural Cheat Sheet (PDF 48Kb) (or below).

What is it?  A cheat sheet of information and system qualities that span 4 single sides of A4.  I have mine printed 2-to-1 and double sided, which I’ve laminated – so it’s a single physical page that is easy to carry around, and which makes me the envy of my peers :).

Some of the statements might seem a bit vague - that can actually be helpful: "Context", Whats context - what's applicable to what you're working on?

When to use it? 

• Meetings and phone conversations – you can scan the cheat sheet for things you might have forgotten, which can be quite easy if discussions have been intensely focused on one particular area of the system.  It’s also perfect for those “does anyone have any other questions” type moments. 
• Brain-Block Buster: it’s great for the late afternoon when your brain is getting tired (and the coffee’s wearing off).  Perhaps you’re going through your design or doing QA for someone else: have you considering data volumes and through-put?  Security? (I have six points under security – how quickly can you think of them now?)  System Life-cycle?  Data Life-cycle?  Evolution and execution qualities?

So enough talk – download it now and use it (it’s free as-n beer and rights), and stop making your brain do all the work (save it for work that is deserving of its attention).

Bonus Point 1: as useful as the cheat sheet is, the biggest benefit I got was compiling it in the first place – that’s where I got real benefit.

Bonus Point 2: I’ve also done a Data Architecture / BI Cheat Sheet as well (coming soon).

-------------------------------------------------------------

Architectural Cheat (v3.0 September 2009) 

Basic questions that apply to everything (in no particular order):
 
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 | Behaviour
 
 
Performance Influence Matrix: factors relevant to performance:

• 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.

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 defence / encryption
• Authentication
• Authorization
• 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)

Lifecycle

• Design, Prototyping
• Development / Refactoring
• Testing (suitability, integration, performance...)
• Deployment / Use

Management Matrix: Who owns and controls what?

• What are the Critical Success Factors
• Is there a common terminology across all involved parties

Information Architecture

• Organization / Structure
• Labeling
• Navigation, Browsing
• Searching

Information Lifecycle

Search, Create, Read, Update, Delete

Transactions

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.  

Accuracy: Indicates proximity to the true value (how close are you).

Precision: The repeatability of the measurement (consistency within certain bounds).

Modifiability: Define the effort, time & cost required to make changes in the software. Often, the measurement is personnel effort (person - months).  Related to Compatibility & Dependencies (the degree of impact on other systems, etc).

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.

Performance:

• See “Performance Influence Matrix”
• Expected transaction & response times (average, worst case)
• response times
• transaction rates
• throughput

Availability: Service Level Agreements:

• Percentage of time available and/or hours of availability
• Expected recovery time

Compatibility: 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.
 
Operating constraints:

• System resources (storage, memory)
• People (hours of business, location)
• Software (dependencies, minimum requirements)

Deployment

• Physical location(s)
• Political location (e.g. hosted internally or externally)
• Ease of access (maintenance) vs. Security
• Dependencies
• Communication between locations/servers/etc (how, management matrix, etc)

Maintainability: the ease with which a software product can be modified in order to:

• correct defects
• meet new requirements
• make future maintenance easier, or
• cope with a changed environment  

Levels of Granularity

• Systems
• Components
• Classes

Some possible Views:

• 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)
• Class / Module / Package / Component / Service
• Concurrency / processes / threading
• The User(s)
• Various stakeholders
• Data
• Security / Attack Surface
• Public / private, internal / external  

Others to consider (random list):

• Alignment with current and future technology stacks, industry trends
   
• Support: strength of community (and its location)
   
• User Interfaces
• Backend Interfaces
   
• System Context
• Responsibilities
• Patterns
• Platform(s)
• Appropriate Granularity
• Supportability
• 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.
• Portability
• 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)
• Security
• Usability by target user community