ARCHITECTURE SPECIFIC COMPONENTS OF THE EXECUTION PLAN
The following architecture specific aspects are included in the execution plan.
- Customer
- Objectives and target group
- Perspective
- Architecture use
- Architecture requirements
- Architecture extent
- Architecture content
- The relationship with other architectures
- Tactics
- Resource involvement
- Architecture acceptance
- Architecture management
1. Customer
The architecture customer should preferably come from upper (line) management. Selecting a customer outside of the architecture team forces the architects to re-examine why he/she wishes to define a specific architecture. He will need to clarify the architecture to the customer. This chapter also discusses the importance of the customer in the definition of the architecture. It is important that the customer actively participates in this and collaborates on defining the deliverables.
2. Objectives and target group
The enunciation of objectives should be short and sweet and as specific as possible regarding the expectations of the architecture. The objectives define the target group.
3. Perspective
An architecture has a specific perspective. It could be a description of the current architecture (today architecture), a view of a desired architecture (tomorrow architecture) or a combination of the two.
There is a further distinction in the tomorrow architecture: desired but likely not attainable or well defined design of how the architecture should look in say nine months. The general principles can be differentiated by hard directives and guidelines. In order to prevent confusion it is important to clearly define the unique architecture perspective.
4. Architecture use
The architecture deliverable should be appropriate for its intended use. The requirements are necessarily different depending on whether it is intended as a top management discussion piece or as a structured framework.
5. Architecture requirements
This section addresses the requirements placed on the architecture deliverable. These are closely related to the desired objectives and target group. The level to which external developments should be considered; the level of desired detail or the minimum set of aspects to be addressed is a few examples of how requirements can vary.
6. Architecture extent
The scope of the architecture could be an entire organization or simply a single department.
7. Architecture content
The dimensions: aspect; format and detail level are addressed in this section. Which aspects are included in the architecture and which deliverables are required, are documented. The architecture could involve: the products/services; processes; organization; data and or the technical infrastructure. The architecture could take the form of guidelines and/or models.
8. Relationship with other architectures
How does the proposed architecture fit into the grand scheme of architectures?
9. Tactics
How is the design of an architecture tackled? What are the activities involved and how much time is required? Time-boxing could be an option to ensure that the architects do not get mired in the modeling activities.
10. Resources
Interested parties are identified as is their involvement in the proposed activities. It is important to involve the organization in the architecture proposal for a number of reasons, not the least of which is the expertise that can be used and the buy-in this will create. A review board could be initiated to assess the (detailed) content.
11. Architecture acceptance
The final acceptance criteria and responsibility should be defined in advance. This prevents the delivered product floating around in addition to the constant discussions regarding the validity and mandate of the architecture. These types of discussions are often the death-knell of an otherwise respectable architectural vision.
12. Architectural management
The management of the architecture must be determined in advance.
