Typical Architectural Deliverables

1. Key architectural decisions document that captures the key decisions that were made, and the other alternatives that were considered. To download a template click here or go to http://bredemeyer.com/papers.htm and look for "Key Architecture Decisions Template".
2. Architecture document that captures the following:

• Architecture strategy as defined by the key principles, concepts, style, etc
• Conceptual architecture; modeling the areas that are architecturally significant.
• Architecture risk analysis
• Logical architecture of the architecturally significant areas, focusing on interface definition, and relationships amongst the entities. This also establishes the various layers and tiers.
• Define the various domain objects entering into and flowing through and out of the system.
• Analysis of the non-functional requirements, to derive the key characteristics of the run-time environment.
  
• Run-time view of the system

What it take to manifest an Architecture Plan

1. Buy in from top management.
2. A good understanding of the history, the current context, and the future direction of the solution space.
3. A good understanding of the existing business processes, and the willingness to change these processes.
4. A good understanding of the existing technical architecture.
5. A clearly defined architecture strategy.
6. A collaborative environment, where the team members are empowered to contribute. This not only helps in maturing the architecture but also helps in getting the implementers on-board with the architecture strategy.
7. A clearly defined architecture change management process.

Inputs to consider when designing an architecture

1. The history, the current context, and the future direction of the solution space.
2. A good understanding of the existing business capabilities of the organization in terms of people, processes, and technology. Along with that, a good understanding of the organization’s willingness, and its ability to accept change.
3. Results of the various proofs of concepts.
4. Inputs from different subject matter experts.
5. A good enough understanding of the business requirements and a thorough understanding of the various non-functional requirements.
6. Industry trends and standards.

Aspects to consider when performing a technology evaluation

1. The goodness of the fit of the product within the existing business capabilities (people, processes, and technology) of the organization
2. Evaluate the product against the expected or agreed upon non-functional requirements like availability, scalability, extensibility, robustness, etc.
3. The support structure provided by the vendor's organization.
4. The degree to which the product is compliant with open industry standards.
5. Popularity of the development platform
6. Hardware and software platform flexibility
7. Complexity on account of dependency of the product on other 3rd party products, and the associated licensing costs.
8. The long-tail effect
   

The Architecture Process

Here are the steps that I take, that help me define the architecture for any solution. Previously, I had attended a Software Architecture Workshop by Bredemeyer consulting, which helped me validate my ideas and helped me better structure the process.

1. Understand the history, the current context, and the future direction of the solution space. This helps me better understand the motivation behind why a solution is required.
2. Understand the available set of requirements and validate them against the ideas gathered in step 1.
3. Once I have a good understanding of steps 1&2, I establish the architectural strategy by defining the key principles, concepts, style, etc that would guide the architecture. These aspects of the strategy are then validated through brainstorming sessions and prototypes.
4. Identify the functional requirements that are architecturally significant. This helps me focus my attention on the key areas of the solution. The other thing that I have realized from experience is that it helps in the long-term manageability of the solution, if the structural approach were consistent across both architecturally significant and non-significant requirements.
5. Identify the non-functional requirements. I usually add this information to the corresponding use cases, and then trace them all the way down to the design documents.
6. Develop a conceptual architecture, to identify the various systems and sub-systems, their responsibilities, and their collaborations. This is again validated either through prototypes or through brainstorming sessions.
7. Define the logical architecture, to come up with the various interface specifications, and validate them.
8. Have the team build a reference implementation of the architecture.
9. Analyze the non-functional requirements, to derive the key characteristics of the run-time environment. This would relate to high availability, failover, load-balancing, number of processes, etc.
10. Incorporate any feedback from the development team, into the architecture. These set of activities fall under architecture change management.

How to manage expectations in “politically charged” situations?

In my view, the best way to work in a politically charged environment is to first have a good understanding of the different perspectives, identify what would influence those perspectives, and build relationships to influence a change. All the time, maintaining an objective standpoint by sticking to hard facts.