Guideline: Define the Architecture Guideline
Guidelines to support the Architecture tasks
Relationships
Related Elements
Main Description

Identify Architecture Goals

Architecture goals provide the motivation and rationale for decisions. Architecture goals are often driven by the software requirements - particularly in 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.

Identify Analysis Mechanisms

See Analysis Mechanisms.

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.