A project that produces a reusable asset needs to address many of the same concerns addressed by Software Architecture,
even for assets that aren't executable software.
Architectural concerns include:
-
The logical structure of components that make up the asset, and the relationships to other assets (for software,
this is covered by the Design Model).
-
The physical files that make up the asset, and how will they be packaged (for software, this is the Implementation
Model). The nature of the target user experience, as well as the target audience, may require the asset to be
reorganized. This may involve adjusting the way the artifacts contained in the asset are organized, or may
involve splitting the original asset into several assets.
-
The major technical decisions driving development of this asset
In order to address the specific concerns of reusable asset architecture, a template for an architecture document for
an asset is available (see Template: Asset Architecture Document). A brief outline of this template is provided
below.
At a high-level, the architecture of a Reusable Asset should include a description of its parts (the Asset Artifacts),
how those parts fit together, and how those parts can be customized/tailored to fit into a specific context.
For the Reusable Asset as a whole, the following should be described:
-
What environment/context is the asset intending to be applied within. This includes the development context,
deployment context, business domain context, etc.
-
How the asset consumer should use the asset -- an initial usage model for the asset (this can be viewed as the
Use-Case View of the asset)
-
What Asset Artifacts make up the asset, what are their inter-dependencies and relationships between these
artifacts, and what is the overall organization of these artifacts (can be thought of as the Logical View of the
asset)
-
How are the physical files that make up the asset organized (can be thought of as the Implementation View of the
asset)
Note: This aspect of the architecture is constrained based on the standard representation selected for the asset.
-
Any mechanisms for customization of the asset (e.g., variability points, framework parameters, etc.). What can be
customized and guidelines for customizing.
-
Any relationships to other Reusable Assets
-
Any constraints or limitations
-
The relative priority of the asset "use cases" (to assist in iteration planning).
-
What, if any, standard representation format is being used to represent the asset (e.g, Concept: Reusable Asset Specification).
For each Asset Artifact, the following should be described:
-
What is the type of the artifact -- e.g., document, model, script, template, plan, etc.
-
What part of the overall solution does the artifact provide
-
What customization options must exist for the artifact (the initial definition of the variability points of the
asset)
-
Does the artifact already exist, or will it need to be developed
-
What relationships/dependencies does the artifact have with other artifacts
-
What physical files contain the artifact.
The target user experience for the asset greatly determines the nature and structure of the packaging. Delivering an
asset for online browsing and purchasing on the Web will require a different set of documentation than will the asset
that is incorporated into the binaries of a development environment. When all is said and done, both user experiences
should deliver the content that you are seeking, but the routes to that end point may vary.
The degrees to which the asset consumer can access the artifacts of the asset may also affect packaging. For example, a
"white-box" asset may require more packaging and documentation than a "black-box" asset because of the increased
visibility of the asset's internals. For more information on types of assets, see Concept: Reusable Asset.
The documentation of asset architecture should be adjusted to suit the nature of asset. The elements described in the
Brief Outline section are strongly recommended, but additional content (possibly additional
views) may be needed to describe the architecturally-significant aspects of the asset. For additional tailoring
suggestions for architectural concerns, see the Software Architecture guidance recommended for your type of
projects.
|