What makes a good Architecture - Rules of Thumb

There are rules of thumb that must be followed while designing an architecture.

These fall into two categories.  Process and Structure

Process for Developing an Architecture

1. The architecture should be the product of a single architect or a group of architects with an identified leader.

2. The architect \ team should have a set of functional requirements and non-functional requirements ( quality attributes ) that the architecture is supposed to satisfy. The quality attribute list should be prioritised.

3. The architecture should be well documented.

4. The architecture should be communicated / presented to the stakeholders who should be actively involved in its review.

5. The architecture should be analysed for quantitiative measures like maximum throughput and evaluated for quality attributes.

6. The architecture should lend itself to incremental implementation via the creation of a skeletal system in which the communication paths are exercised but at first have minimal functionality.

7. The architecture should result in a specific set of resource contention areas, the resolution of which id clearly specified, circulated, and maintained. If performance is a concern the architects should produce time budgets for the major transactions or threads in the system.

Structure of the Architecture

1. The architecture should have well defined modules whose functional responsibilites are allocated on the principles of information hiding and separation of concerns.

2. Each module should have a well defined interface that encapsulates changeable aspects from other software that uses its facilities.

3. Every task and process should be written such that its assignment to a specific processor can be easily changed perhaps even at runtime.

4. The architecture should feature a small number of simple interaction patterns . That is the system should do the same thing in the same waythroughout.

5. Modules that produce data should be separate from modules that produce data.

ATAM - Architecture Evaluation Method

ATAM(Architecture Tradeoff Analysis Method )  is one of the most common evaluation methods used in early stage of software development. Typically before signing off or apprving the architecture.

In the planning and preparation the evaluation team looks at the existing architecture documentation to identify questions or areas of incompleteness. If the documentation is deemed insufficient to express a sound understanding of the multiple structures of the architecture, the evaluation does not proceed to next step.

The ATAM method consists of the following nine steps:

1. Present the ATAM: The evaluation team presents a quick overview of the ATAM steps, the
techniques used, and the outputs from the process.
 2. Present the business drivers: The system manager briefly presents the business drivers and
 context for the architecture.
 3. Present the architecture: The architect presents an overview of the architecture.
 4. Identify architectural approaches: The evaluation team and the architect itemize the architectural
 approaches discovered in the previous step.

5. Generate the quality attribute utility tree: A small group of technically oriented stakeholders
identifies, prioritizes, and refines the most important quality attribute goals in a utility
tree format.
 6. Analyze the architectural approaches: The evaluation team probes the architectural approaches
in light of the quality attributes to identify risks, non-risks, and tradeoffs. To probe
the architecture, they use quality attribute questions. For example What properties in the runtime platform need to be tuned for the expected workload?
The architect should help define how many instances of http listeners, database connections,
server machines, and other architectural elements will be needed to meet the expected number
of requests.

7. Brainstorm and prioritize scenarios: A larger and more diverse group of stakeholders creates
scenarios that represent their various interests. Then the group votes to prioritize the
scenarios based on their relative importance.
8. Analyze architectural approaches: The evaluation team continues to identify risks, nonrisks,
and tradeoffs while noting the impact of each scenario on the architectural approaches.
9. Present results: The evaluation team recapitulates the ATAM steps, outputs, and recommendations.
  These steps are typically carried out in two phases. Phase 1 is architect-centric and concentrates
on eliciting and analyzing architectural information. This phase includes a small group of technically
oriented stakeholders concentrating on Steps 1 to 6. Phase 2 is stakeholder-centric, elicits
points of view from a more diverse group of stakeholders, and verifies the results of the first
phase. This phase involves a larger group of stakeholders, builds on the work of the first phase,
and focuses on Steps 7 through 9.
 
A final report of the ATAM results include a summary of the business drivers, the architectural
approaches, a utility tree, the analysis of each chosen scenario, and important conclusions. All
these results are recorded visually, so stakeholders can verify the correct identification of the results.
 
The following are some of the benefits of the ATAM process.

1. Promotes the gathering of precise quality requirements
2. Creates an early start at architecture documentation
3. Creates a documented basis for architectural decisions
4. Promotes identification of risks early in the life-cycle
5. Encourages increased communication among stakeholders.


I encourage doing couple of iterations of architecture development using this method as a criteria for evaluation and improvement in the architecture.

Architecture Requirements

An applications requirements can be classified in different ways. But the most clear demarcation is to divide them between functional and non functional requirements. The functional requirements address all the business problems or support the systems is meant to address. The non functional requirements form the basis of the Architecture of the system.

Thus the non-functional requirements are the requirements for the software architecture. Typically an architect will work with all stakeholders to come with these requirements( called somestimes concerns). From these requirements a list of ilities or Quality Attributes is derived.

These quality attributes can range from Scalability to Offshoreability. The best strategy is to prioritise these based on stakeholder input and knowledge of the domain. There has to be trade off in certain cases to optimise the cost of developing the architecture to satisy these attributes to the fullest.

Various tactics can be used to architect for these Quality attributes. Tactics are means of controlling  the parameters of a model of Quality Attribute.  These tactics and techonologies and patterns that are best fit and best practise to implement these tactics are part of the repertoiore of an Architect.

For example let us take the Scalability as a Quality Attribute

Oslo and MDD

MDD is model driven development. Oslo is the code name for the forthcoming Microsoft modeling platform. Modeling is used across a wide range of domains; it allows more people to participate in application design and allows developers to write applications at a much higher level of abstraction. This means more of the application definition will move into data than code. We have seen this trend with each new release of .net platform. The recent examples being wcf, silverlight etc. The principle behind MDD is model is the code. This type of development will allow us to develop without using languages like c# and java. According to Don Box the goal is to develop applications thru metadata. This may not work for all domains but the goal is to redue the gap between intention of developers and actual artifacts. Oslo is the first step in the direction of making everybody a programmer event though they do not know programming.

Enterprise Architecture Frameworks

What is enterprise architecture ? According to thought leaders in the field who are at Carnegie Mellon University it is defined as follows:--- A means of describing business structures and processes that connect business structures. The wiki definition addresses the how part very well An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, its decomposition into subsystems, the relationships between the subsystems, the relationships with the external environment, the terminology to use, and the guiding principles for the design and evolution of an enterprise Roger sessions in his book on simplifying archiectures defines it to emphasize why EA is important. "An enterprise architecture is a description of the goals of an organization, how these goals are realised by business processes, and how these business processes can be better served through technology" In simpler words "EA is the art of maximizing the value of IT investments" I think this is best definition from the point of view of EA sponsor. Frameworks Framework is defined as "A structure for supporting or enclosing something else, especially a skeletal support used as the beasis for something being constructed; An external work platform; a scaffold; A fundamental structure, as for a written work; A set of assumptions.concepts,values, and practices that constitutes a way of viewing reality." There are three prominent frameworks popular in the academic and practitioner community. Zachman Framework, TOGAF and Fedeal Enterprise Architecture. Roger Sessions has proposed a SIP process that is a perspective that analyses complexity of the enterprise and helps built an architeture.