Identify Architecture Goals
Architecture goals provide the motivation and rationale for decisions. Architecture goals are often driven
by the software requirements - particularly in Artifact: Supporting Requirements, as they are not always obvious from the
use cases alone [ALL02].
Architecture goals define how the system needs to respond to change over time.
-
what is the expected life-span of the system?
-
will the system need to respond to technological changes over that time, such as new versions of middleware or
other products?
-
how frequently is the system expected to adapt to change?
-
what changes can we anticipate in the future and how can we make them easier to accommodate?
These considerations will have a significant effect on the structure of the system.
Identify Architecture Constraints
Often, the system that is developed will be integrated to an existing environment. To ensure a smoother integration as
possible, you need to gather information about this environment and identify any architectural constraint.
Architectural constraints can be:
-
the network topology
-
the use of a given database vendor or an existing database
-
the web environment (servers configuration, firewall, DMZ, and so forth)
-
the servers (hardware model, operating system)
-
the use of given third parties or given technology
-
the compliance to existing standards
For example, if there is just one type of database used in the company, you will probably try as much as possible
to use it to leverage the existing database administation skills rather than introducing a new one.
These architectural constraints combined with the requirements will help you define the best candidate
architecture
Survey, assess and select from available assets
To assess and select assets to reuse on your project, you need to understand the requirements of the environment for
which those assets are being considered, and the system scope and general functionality required. There are several
types of assets to consider, such as (but not limited to) reference architectures, frameworks, patterns, analysis
mechanisms, classes, and experience. You can search through asset repositories (internal or external to your
organization), and industry literature to identify assets or similar projects.
You will need to assess whether available assets contribute to solving the key challenges of the current project and
whether they are compatible with the project's architectural constraints. You will want also to analyze the extent of
the fit between asset and requirements, considering whether any of the requirements are negotiable (to enable use of
the asset). You should also assess whether the asset could be modified or extended to satisfy requirements, and what
the tradeoffs are in terms of cost, risk, and functionality from adopting it.
Finally, you will want to decide, in principle, whether to use one or more assets and eventually record the rationale
for this decision.
Define approach for structuring the system
Structuring your system helps you manage its complexity using the well-known "divide and conquer" strategy. By breaking
it on smaller and more manageble pieces you make its development easier.
Layering approach is one of the most common used approaches for structuring and decomposing
systems. It is based on the concept of "layers", each layer grouping similar classes or components, and communicating
as much as possible only with its direct neighbours.
You will not be defining on which layer each class or component will go, but much more how many layers you need and
which kind of layers you will be using. For example, if you are developping a new middleware system, you probably do
not need a business layer.
It is later during design activities that you decide how these layers will be populated in terms of classes
and components.
Identify key abstractions
Requirements and analysis tasks usually uncover key concepts that the system must be able to handle; these concepts
manifest themselves as key design abstractions. You can take advantage of existing knowledge by identifying
preliminary entity classes to represent these key abstractions on the basis of general knowledge of the system.
When you define the key abstractions, also define any relationships that exist between entity classes. You can capture
them in a table, or on UML class diagrams (in a tool or whiteboard), and create a short description for each
abstraction.
The classes identified at this point will probably change and evolve during the course of the project. The purpose of
this step is not to identify a set of classes that will survive throughout design, but to identify the key concepts the
system must handle. Don't spend too much time describing entity classes in detail at this initial stage, because there
is a risk that you'll identify classes and relationships not actually needed by the use cases. Remember that you will
find more entity classes and relationships when looking at the use cases.
Analysis Mechanisms
Concept: Analysis Mechanism can be identified top-down (a priori knowledge) or
bottom-up (discovered as you go along).
In the top-down mode, experience guides the Role: Architect to know that certain problems are present in the domain and will require certain kinds of solutions.
Examples of common architectural problems that might be expressed as mechanisms during analysis are: persistence,
transaction management, fault management, messaging, and inference engines. The common aspect of all of these is that
each is a general capability of a broad class of systems, and each provides functionality that interacts with or
supports the basic application functionality. The analysis mechanisms support capabilities required in the basic
functional requirements of the system, regardless of the platform it's deployed upon or the implementation language.
Analysis mechanisms also can be designed and implemented in a number of different ways; generally there will be more
than one design mechanism corresponding to each analysis mechanism, and perhaps more than one way of implementing each
design mechanism.
The bottom-up approach is where analysis mechanisms are ultimately born - they are created as the Role: Architect sees, perhaps faintly at first, a common theme emerging from a set
of solutions to various problems. There is a need to provide a way for elements in different threads to synchronize
their clocks and there is a need for a common way of allocating resources. Analysis mechanisms, which simplify the
language of analysis, emerge from these patterns.
Identifying an analysis mechanism means you identify that a common, perhaps implicit subproblem exists, and you
name it. Initially the name might be all that exists; for example, the system will require a persistence
mechanism. Ultimately, this mechanism will be implemented through the collaboration of various classes, some of
which do not deliver application functionality directly, but exist only to support it. Very often these support classes
are located in the middle or lower layers of a layered architecture, thereby providing a common support service to all
application level classes.
If the identified subproblem is common enough, perhaps a pattern exists from which the mechanism can be instantiated -
by binding existing classes and implementing new ones as required by the pattern. An analysis mechanism produced this
way will be abstract, and will require further refinement through design and implementation
Capture architectural decisions
Often it is useful to record key architectural decisions and working assumptions on an architecture overview diagram to
easier the communication of the architecture to the project team and to the stakeholders. The level of formality of
such diagram is project dependent. For example, on an agile and low-ceremony project, the overview diagram can take the
form of an informal, rich picture storyboard or iconic graph on whiteboard or drawing tool. Its role is to conceptually
illustrate the nature of the proposed solution, conveying the governing ideas and including the major building blocks.
If a non-trivial distributed system is required, then a Deployment diagram can be integrated into the
architecture overview diagram to capture the relationship between nodes. Detailed specification of nodes and
connections is deferred, except where they are important for estimating or assessing viability of the architecture.
Existing assets can be used, if available. Although this is the first deployment model produced in the project, and
it's produced quickly and at a high level, it might identify actual hardware and software products if they are known,
or if it's important to make these selection decisions at this time.
Validate that the deployment approach supports users (especially users at remote locations if this is required)
performing typical use cases while satisfying nonfunctional requirements and constraints. Validate that the nodes and
connections are adequate to support the interactions between components on different nodes, and between components and
their stored data.
|