Friday, December 21, 2007

Decomposing Goals

Name: Decomposing Goals
Type: Principles
Status: draft
Version: 2007-12-21
Source: D. Doerner ('The Logic of Failure'), own thoughts

Gist: to explain why - for a complex, dynamic, interrelated endeavour - it is paramount to decompose global, complex, vague goals into specific goals.

Also see: Specifying Goals, Courses of Action

A global goal is a goal which has only few (one) evaluation criteria.
A vague goal is a goal which has only few (none) measurable evaluation criteria.
A complex goal is one that can be decomposed in two or more goals that are more specific.
An implicit goal is one you're not conscious of now.
Note: Quite often it is possible to say "problem" for "goal", as a goal is a problem turned upside down.

P1: Using a single word for a goal seems to imply that there is one thing the word stands for. Example: "User-friendlyness" Looking closer, we find that there ist no such one thing, it is composed of several other things (subgoals), like "percieved performance", "nice GUI" etc.
Note: This decomposition is subjective.

P2: The subgoals may contradict each other, like "percieved performance" and "wealth of functions". This is why we need to decompose the goal: otherwise we have a single goal which is in itself contradictory. This makes people feel uncertain and insecure.
Note: Often people don't know why they feel uneasy when confronted with such a goal.

P3: Subgoals usually will be handled in one to three different ways:
- dissection of central and peripheral goals, to be able to focus on the central ones
- dissection of important and urgent goals, also to be able to focus, but dependent on outside constraints like "deadline"
- delegation of the goal, to get rid of the difficult goal

P4: Conflicting (sub)goals get handled in two ways:
- finding a balance in reaching these goals, i. e. compromise
- ignoring one of the goals completely for the good of the others
- eupemistically re-arrange the whole system of goals, for the contradictions to dissappear ("if we had 'new' citizens...")

P5: Implicit goals can be uncovered by asking "What do I want to keep?" while aiming at some change.

P6: Confronted with a complex, global, vague goal, we usually find a (wrong) subgoal either because it seems apparent or because we are able to solve it. After a while this makes us feel even more uncertain, because we seem to not get closer to the goal.
Note: An apparent goal may not be the important nor urgent, and may be perpheral.
Note: In the IT world, this behavior surfaces as the confusion of means and ends. E. g., people think gathering data is the end, while it is a means to empower decion making. We usually do so because we feel secure in what we do.

P7: Confronted with a complex, global, vague goal, we proceed "ad hoc" in the sense we don't care for future problems caused by our problem solving. More uncertainty.
Note: "Ad hoc" has its advantage, it's better than doing nothing. This of course also is dangerous if we feel pressed to do something.

P8: Confronted with a complex, global, vague goal, we proceed "ad hoc" in the sense we ignore implicit goals. More uncertainty.

P9: Ultimately, feeling really uncertain and unsecure, we tend to dive deep into one of the goals and ignore the rest. This goal is the new holy grail.

Thursday, December 20, 2007

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.

Thursday, December 06, 2007

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,

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.