|
Identify architectural goals
Describe the goals of the architecture by examining the product Vision and requirements, including architecturally significant requirements.
Also, talk to the project Stakeholder and Analyst.
These goals will guide your approach to important architectural and design decisions.
|
Identify architectural constraints
Understand any constraints (or opportunities) on the solution that are inherent in the existing environment
or organization. If available, examine the Supporting Requirements for any constraints that have already been
identified. Discuss any critical time and resource constraints with the Project Manager, as these will also need to be taken into account when arriving at your decisions. Discuss potential
constraints with the tester such as hooks for tests, and to identify architectural areas that may be difficult to test.
|
Survey, assess, and select available assets
Establish the availability of any existing software assets as suitable candidates for re-use. Make sure you consult
with others who have knowledge of existing assets, particularly the Developer(s) and other people outside the project team (such as production
support teams) in order to form a balanced view of the suitability of existing assets for re-use. Identifying reusable
assets could be done as a team brainstorming session.
|
Define approach for structuring the system
Decide how to structure the software, both in logical and physical terms. As a minimum, decide on:
-
How to partition the software when managing development
-
How the software will be composed at run time.
For each software partition, briefly describe
-
Their name and purpose.
-
Their relationships to other partitions.
These decisions will form the basis for structuring the Design and the Build.
|
Define approach for deploying the system
| Outline how the software will deploy over the nodes on the network. Work with stakeholders such as as network support and
deployment teams to ensure that the proposed approach is a good fit for the wider technical environment. |
Identify key abstractions
Identify the key abstractions that the system needs to handle. You can usually find these by looking for nouns that the
requirements emphasize or repeat, because they help identify what is important to the business. The Glossary is particularly useful for this. Work with the analyst and stakeholder
here, as they will have knowledge and materials that are relevant to this step. Work with the developer to identify key
abstractions internal to the system.
|
Identify architectural mechanisms
Catalog the architectural mechanisms that are necessary to fulfil the requirements. At this stage, it only
necessary to capture a relatively small amount of detail for each mechanism. Discuss the requirements
(especially Supporting Requirements) that are being addressed by each mechanisms with the
analysts and stakeholders to make sure that the requirements are unambiguous and well understood.
|
Capture architectural decisions
Capture important decisions about the architecture for future reference. Consider using the templates
provided for the Architecture Notebook.
|
|
