|
Define the Problem Context and Scope
The objective here is to define the context of the problem, the environment within which the problem is found. This
includes business level context, such as processes and functions involved with the problem. The scope of the problem is
also described, that is, is it local to a system or process, does it span the business domain, or is it a problem that
involves the complete enterprise?
The context and scope help the stakeholders to understand and agree upon the intention of the solution. The same
problem, interpreted for different contexts, can yield very different solutions.
The context and scope defines the intended area in which the solution will be deployed (e.g. workgroup, division,
department, entire business, etc.) and a definition of the users of the solution. If the context is well understood, a
short description may suffice, but for new technologies or processes a more complete description of the problem space
may be needed.
If the new solution is an enhancement to an existing system or solution, the existing solution should be described.
|
Identify and Define the Constraints
Express the constraints under which the solution is decided upon. These constraints impact risk and cost. They could be
things like external interfaces that the solution must adhere to, standards, certifications, or a technical approach
employed for strategic reasons, such as using a certain database technology, or distribution mechanisms. Time
constraints and financial constraints are also identified.
|
Define the Rationale
Describe options for the solution—optional approaches, capabilities or features and associated costs and benefits—and
options in approaching or deploying the solution. Solution options might include differing technical solutions,
differing mixes of options for technical solutions, differing mixes of 'make' and 'buy', and so on. In each case, the
effect of the option on the financial forecast, and on constraints (in turn impacting risk) should be described.
The objective is to provide enough information on the options to substantiate the decision. Remember that this
description must stand on its own and be easily understood by a manager or architect reading it in 6 to 12 months or
more—in other words it needs to be readable out of context and complete in its coverage.
|
Describe the Decision
Describe in detail the decision taken—include details on the solution and any other information that may be relevant,
such as the timeframe of the decision (i.e. short or long term), and any implementation or migration aspects, for
example.
|
Define the Implications of the Decision
The implications of the decision are described. They include things such as financial, maintenance, operations or
configuration changes or constraints, usually affecting current systems, operations or processes. Implications on other
decisions and on future plans should also be described.
|
|
