|
|
|
|
|
Top Down |
|
Strategic Framework |
|
Analysis / Design |
|
Architecture |
|
|
|
|
Ensure Essential Business Requirements are
captured |
|
Minimize risk of solving the wrong problem |
|
Minimize risk of missing key requirements |
|
Minimize redundancies |
|
|
|
|
|
|
Industry Best Practice. |
|
Plan and prioritize based on essential
objectives. |
|
Create plans based on factual information. |
|
Key Project Management Tool. |
|
Trace and manage impacts of all decisions. |
|
Manage Stakeholder Expectations. |
|
|
|
|
Variations of strategy planning have been the hallmark of systems
development. |
|
|
|
The absence of a strategy (plan) has been a key
contributor to project failure. |
|
|
|
|
Provides an shared understanding of planning and
prioritization. |
|
Ensures the business agenda is in focus. |
|
Often, we prioritize based on inadequate or
incorrect information. |
|
|
|
|
|
|
Framework suggests priorities and dependencies
which inform planning activities and tasks |
|
Easy to justify delivery decisions |
|
Easy to plan and justify resource requirements |
|
Control and confidence. |
|
|
|
|
Able to know what should be done - make sure
sure the right things are happening. |
|
Able to predict resource requirements. |
|
Easily maps to the project plan - easy to
justify management decisions. |
|
|
|
|
All decisions and the impacts of the decisions
are traceable up-and-down the framework. |
|
Downstream problems/constraints are easily
traced to objectives. |
|
Without these tools management makes decisions
that can unknowingly contribute to failure. |
|
|
|
|
Since all decisions are traceable, all
stakeholders are aware of impacts. |
|
Stakeholders are aware of solution roll-out
dependencies. |
|
The framework provides a single reference point. |
|
|
|
|
|
|
Mission |
|
Objectives |
|
Critical Success Factors |
|
Enablers |
|
The
following are more tactical, however, belong on the framework to
demonstrate downstream and upstream impact: |
|
Enabling Process |
|
Use Case |
|
Process Context View |
|
Interaction Diagram |
|
|
|
|
|
The Mission and Vision articulate what the
enterprise or project expects to achieve and why that achievement is
necessary. |
|
There is
a distinction between the Mission and Vision. However, for in this context
the author is treating them in the same manner as an ideal or achievable status. |
|
Without a Mission or Vision there is no ultimate
purpose and it is easy to lose focus, initiative, and momentum. |
|
|
|
|
|
|
To achieve the Mission and/or Vision certain
Objectives must be articulated to provide a path to achievement. These
objectives are measurable in at least two dimensions: |
|
How much? |
|
By When? |
|
That is, an example of an Objective may be:
“Sell 20% More Platinum Products By February 15, 2001”. Here, How Much is 20% More; When is by
February 15, 2001. This is the objective. |
|
Without objectives we have no way to to
determine what we are trying to achieve nor be able to measure success. |
|
|
|
|
Critical Success Factors (CSFs) are those things
that ‘we need to do well’ in order to achieve the objective. |
|
CSFs can be shared (networked) to more than one
objective. Often, this is a good indication of what you should focus on,
that is, when an CSF affects many objectives, one should pay particular
attention to that CSF. |
|
Without CSFs we do not know what we need to be
able to do well in order to achieve our objective(s). That is, we do not
have the tools to be able to control and measure success. |
|
|
|
|
|
|
|
|
An example CSF to the above example Objective
may be: in order to sell 20% more Platinum Products by February 15, 2001 we
must be good at: |
|
- Identifying Prospective Buyers |
|
- Identify Providers that provide the best and
least expensive services |
|
|
|
|
|
|
An Enabler enables us to be good at something.
This enabler is the name of the process that ensures we meet the CSF. In
the above example, the enablers may be: |
|
-Prospect Identification Process |
|
-Provider Management Process |
|
These are the names of the enabler functions
whose purposes are to ensure that we are “good at” the CSF or CSFs to which
they are associated. Enablers are often associated with several CSFs and,
indirectly, associated with one or more Objectives. |
|
Without naming the enabler we have no focus for
understanding the process we must analyze and design to be successful. |
|
|
|
|
The
following elements describe the more technical aspects of the business.
These get into more concrete levels of detail and through this lower level
of detail, begin to form the basis of candidate architectures and candidate
solutions. |
|
|
|
|
Graphical and textual representation of Actors
(users or systems) and Workflow (Process Map). |
|
Provides contexts for use cases and process
improvement. |
|
Informs the technical architecture. |
|
Provides opportunities for organizational
change. |
|
Without process maps there is no way to
determine if work is carried out in an effective manner and if resources
are used efficiently. |
|
|
|
|
A time-ordered sequence of events. |
|
An interaction between an Actor and a System. |
|
A description of the context and conditions
under which actions occur in the business. |
|
Without use cases it is difficult to put
business activities and business “things” (objects) into context. |
|
|
|
|
Use case analysis results in two key
deliverables: |
|
Process Context View |
|
Interaction Diagram(s) |
|
Other deliverables (as a result of analyzing the
above deliverables) include: |
|
Information Architecture |
|
Application Architecture |
|
|
|
|
A static view of the things (object/entity
types) that are used in the use case. |
|
Focuses the analysis activity and minimizes the
risk of overlooking key business requirements. |
|
Informs the design structure and highlights
development innovation and reuse opportunities. |
|
|
|
|
Highlights the relationships and dependencies
(measurable prioritization standards) for application development. |
|
Highlights opportunities for reuse. |
|
Informs data access patterns. |
|
|
|
|
The framework elements define and/or affirm the
various architectures that support the business objectives (and by
definition - the business). |
|
The various aspects of the architecture provide
a reference for understanding and evolving the business as well as
providing a reference for developing solutions to meet the business
(business and technology alignment). |
|
|
|