Course of Action

Name: Course of Action
Type: Process
Status: final
Version: 2007-12-20

Gist: to explain how to act upon a problem or complex, dynamic, invisible situation

S1: work out your goals see >Specifying Goals, to be used as guides and criteria for evaluation of your actions (see step 5).
S2: gather information about the situation and about how it changed over time in order to build a structural model of the problem
S3: build hypotheses about how the situation has changed and deduct how it will change
S4: plan your actions, decide on your actions, act (don't forget to think about doing nothing)
S5: check the effects (momentary facts AND tendences!) of your actions and refine your strategy with new evidence
Note: this is not a linear process. Trace back to any step whenever you feel you should.

Analysis Mechanisms for Eliciting Architecturally Significant Requirements

Name: Analysis Mechanisms for Eliciting Architecturally Significant Requirements
Type: Rule
Status: final
Version: 2007-12-06
Source: Peter Eeles, Senior Architect, IBM, 2004, http://www.ibm.com/developerworks/rational/library/4706.html

Gist: to provide a checklist of analysis mechanisms that can be used in order to find out about requirements that will be significant to the achitect.
Analysis mechanism DEFINED AS implementation-independent solution to a problem

R1: Consider the following analysis mechanisms when gathering architectural requirements.

Analysis-Mechanism - Description
Auditing - Provides audit trails of system execution.
Communication - Allows distributed processes to communicate.
Debugging - Provides elements to support application debugging.
Error Management - Allows errors to be detected, propagated, and reported.
Event Management - Supports the use of asynchronous messages within a system.
File Management - Provides services for accessing a file system.
Graphics - Supports user interface services, such as 3D rendering.
Information Exchange - Supports data format conversion.
Licensing - Provides services for acquiring, installing, tracking, and monitoring license usage.
Localization - Provides facilities for supporting multiple human languages.
Mail Services that allow applications to send and receive mail.
Mega-data - Support for handling large amounts of data in a client-server environment.
Memory Management - Services for abstracting how memory is allocated and freed.
Meta-data - Supports the runtime introspection of components.
Online help - Provides online help capability.
Persistence - Services to manipulate persistent data.
Printing - Provides facilities for printing.
Process Management - Provides support for the management of processes and threads.
Reporting - Provides reporting facilities.
Resource Management - Provides support for the management of expensive resources, such as database connections. Provides support for the management of expensive resources, such as database connections.
Scheduling - Provides scheduling capability.
Security - Provides services to protect access to certain resources or information.
System Management - Services that facilitate management of applications in a distributed environment.
Time - Services to synchronize time on a network, and to translate times into different time zones.
Transaction Management - A mechanism for handling ACID 1 transactions. ' The acronym ACID refers to four characteristics of a transaction: Atomic, Consistent, Isolated and Durable.
Workflow - Support for the movement of documents and other items of work, typically through an organization.

How to give a project a good start

Name: How to give a project a good start
Type: Process
Status: final
Version: 2007-12-06
Gist: describes what to do as a manager to make sure that the project after it's finished will be seen as a success AND something of real value has been produced.

S1: Meet with a few of your management colleagues and talk about the project's goals until you reach a consensus.
S2: Gather a kickoff meeting with these colleagues and make everybody bring one or more workers who are supposed to do the project work.
S3: Be as precise and specific as possible if some of the workers ask questions.
S4: Be specific about the project goals or concrete deliverables you might want to see. Let the project work out project organisation and courses of action.
S5: Ask the workers to explain their understanding of your vision.

Note: Surprisingly, you might have a hard time finding a project leader to happily go along with this behavior, for he can't sell almost anything as a success for you.

Specifying Goals

Name: Specifying Goals
Type: Rules
Status: final
Version: 2007-12-20
Source: various authors, including D. Doering ('Die Logik des Misslingens')
Gist: to describe goals (of an organization, of an IT system, …) in a clear and useful fashion
Note: like always, goals are a kind of requirement. So it doesn't hurt at all if you use the rules to lower levels of requirements, e.g. system requirements.
R1: Seperate different goals, even if they seem interrelated, for you can reference them.
R2: Name each goal unambiguously, use a short name.
R3: use the PAM structure:
P urpose
A dvantage
M easure
Purpose: Supplies a higher level rationale for the goal. Understanding the why gives you freedom in finding proper solutions.
Advantage: Differentiates the goal from others and from non-goals. So you also know what NOT to achieve.
Measure: Keeps you on track and supports your communication with the higher management. Gives you a clear sense of 'done' and provides satisfaction at the end. Makes it possible to evaluate measures concerning suitability and effectiveness.
R4: Iterate! There's nothing bad about changing goals along the way. Please restate the set of goals, though.
R5: Avoid comparatives, work until you know what they really mean. Try decomposing a comparative goal into a number of specific goals.
R6: Mind if you specify positive (get to x) or negative goals (avoid y). A positive goal gives you fewer opportunities to succeed than a negative goal, which can be good or bad. Be aware of the possibility that someone states a goal negatively because he does not know how it can be stated positively. You're bound to fail, not within the scope of the stated goals but in the scope of the real goals. Negative goals tend to be too global.
R7: global and specific goals are good, unclear goals are bad. try to make a global goal specific, however. if your global goal is unsufficient and you cannot come to a specific goal, try stating intermediate goals that maximise the opportunity of success. How? By specifying many subgoals with a good chance of reaching them. another way to put it is: try to set goals so, that by adhering to them you will be in a better tactical position towards your strategy.
global: the future state is determined by few (sometimes only one) criteria
specific: the future state is determined by many criteria
unclear: the future state is not determined by a sufficient number of criteria
R8: be extremely suspicious if you seem to have only one goal. this situation is very rare and the phenomenon indicates you forgot a number of goals.

3 Characteristics of Engineering

Name: 3 Characteristics of Engineering
Type: Principles
Status: final
Version: 2007-10-26
Source: Chris Britton, Microsoft, 2007 (http://msdn2.microsoft.com/en-us/library/bb508955.aspx)

The characteristics of engineering are:

1) The design is decomposed from top to bottom
Note: In contrast, software design is almost all low-level, and it is often hard to see how the entire system works.
2) All designs (high-level and detailed) are analyzed or tested to check for correctness.
Note: In contrast, software development relies almost entirely on testing the product only-in other words, the program code.
3) Implicit requirements, as well as explicit requirements.
Note: In engineering, there are some basic requirements-such as the fact that a bridge should not fall down-that do not need to be specified by the stakeholder.

And a nice quote of Chris': "Engineering is the art of scale."