Principles Document Amit Limaye

Principle #1 A good architecture is one which provides the required functionality for its stakeholders with the minimum complexity possible. Discussion: As we have often discussed in class the architects job is to reduce ambiguity in the system. One way to characterize how successful an architect is in this is to try and identify the essential and the accidental complexity1 in the system that is designed. Essential complexity refers to a situation where all reasonable solutions to a problem must be complicated (and possibly confusing) because the "simple" solutions would not adequately solve the problem. Essential complexity is required to represent a complex problem. This in contrast to accidental complexity which often arises due to a mismatch of tools and methods applied in the solution. Though one must reduce the complexity in the system to make it more easier to understand the essential complexity represents the simplest representation of the problem. All accidental complexity can be removed by a good architect and a good architecture has minimal accidental complexity. This can be also be seen in one of victor tangs examples of complicatedness, which I believe is accidental complexity. Complicatedness is introduced into the system when the architect chooses the wrong tools to express the solution(architecture) for a problem. Again in the same lecture victor tang presents the idea of good complexity which is a direct measure what is essential complexity and this cannot be eliminated from a system without losing some information about the problem or missing functionality. The principal thats why doesnt judge the architecture by how simple it can be made but rather by how much residual accidental complexity is left behind in the system. A less complex system which is simplified by removal of essential complexity will not serve the needs of its stakeholders. Principle #2 Tag Line: Performance metrics before you architect Descriptive Version: Architecture is defined by a measure of success. Prescriptive Version: Decide Performance metrics before you architect. This is one of the important principles I think we have covered in class until now and something discussed in OS0 as well. The idea behind this principle is to ensure that we define success for the project in measurable terms before we start the architecting process. Each stakeholder/beneficiary needs to be identified and we need to come up with a Figure of merit for each of them. I have always been calling it performance metrics, the figure of merit was recently discussed in a software architecture class I am
1

The terms are defined by Fredrick brooks in his book the mythical man-month

Principles Document Amit Limaye

taking with Prof. Nancy Leveson. By defining what would amount to success of a project and assigning relative priorities to each of these metrics we can make informed decisions or tradeoffs in the architecting process about meeting some goals and maybe keeping some of the goals unfulfilled or partially fulfilled. The performance metrics for me comes from my earlier experience in software engineering projects across different companies. Depending on the constraints and the application of the system different qualities of a system become more or less desirable. For example in some system speed is of importance while resources consumed to achieve that speed are not important while in some constrained embedded systems resources limit what architectures can be implemented and can mean sacrificing some raw speed parameters. Another tradeoff we can often see being made the tradeoff of feature richness versus feature reliability. These tradeoffs during the architecture phase are informed directly by the performance metrics we have used to define success for the project. In the absence of such metrics the tradeoffs can drive you away from the actual goals of the system and despite having implemented everything you might discover that the stakeholder needs are not completely met. Principle #3 Tag Line : Granularity of architecture specification Descriptive Version: Specifications with different granularity at different levels for different stakeholders are understood better. Prescriptive Version: A specification should have different layers with different levels of granularity depending on the stakeholder it is addressed for. To understand anything you must not try to understand everything -Aristotle Discussion: Any system can be organized into different layers which can be of interest to different stakeholders in the system. The architecture should be organized in a fashion where the granularity in the specification can be tailored to the particular audience. A classic example we could discuss here is the example of an OSI stack in the networking world which is organized into different levels with the overall intent of the system to ensure communication between two endpoints on a network. A person working at a particular layer needs to only understand the details of that particular layer and only talks to other layers through pre-defined interfaces.
2

Principles Document Amit Limaye

The architecture specification at each layer has a different level of detail for the other layers depending on the information about other levels needed by the implementer at that that level. So for example an network application programmer needs to be aware of the high level architecture specification for the lower layers but does not need to worry about the details of the actual architectural elements involved in the end-end delivery. This concept can be extended to other system as well where the architecture granularity can be used as a mechanism to reduce unnecessary complicatedness( from Victor Tang) in the system. This also works very well with the concept of information hiding and prevents an information overload for stakeholders in the system who might need all the information. Principle #3 Tag Line: Modularizing guidelines Descriptive Version: A good modularization strategy reduces the communication between modules Prescriptive Version: Modularize to avoid cutting through across components with high level of communication. Modularization is often used by the architect as a means of reducing visible complexity in the system to various stakeholders. By hiding the details of the module behind predefined interfaces the architect can make the system much easier to understand. But it is essential to identify the right modularization strategy. The modularization of a system should always aim to reduce communication between the modules and design modules such that they are relatively independent of each other. Two modules which need to communicate extensively which each are often reduced to a single module. Also if there are many interdependencies in the modules a change in one might cascade to changes in the other module. In such cases as well the modules are best brought together in a single module. In software system often the most important relationships between components are the functional relationships and modularizing a system along functional lines is often the most natural choice.

Principles Document Amit Limaye

Principle #4 Tagline: Scalability and flexibility principle Descriptive Version: Architecture has to be scalable and flexible to fit either change in requirements or to be adaptable to unforeseen applications Prescriptive Version: Always make architecture scalable and flexible Discussion: An architect has to always assume requirements, assumptions and constraints are always temporary so designing an architecture that presents a very rigid solution to satisfy all current constraints. Flexibility is very key criteria since it is the quality of the architecture that decides the adaptability of the architectures to changes. An architect also has to assume that the system he designs will be reused to solve problems with bigger scope which will challenge the assumptions made in the original architecture. An architecture should be able to localize impacts due to scope changes without having to do the entire architecture. But there is a tradeoff involved, architectures that are typically tightly integrated and rigid are designed to perfectly fit all assumptions and scope will provide better performance. It is essential to be cognizant of this and decide how many degrees of freedom to provide the architecture. The same principle can be often extended to other illities in the system. Often increasing the performance of a system along one of the illities will have consequences on the other axis like complexity. An architect needs to continuously think about the tradeoffs associated with architecting a new illity in the system. Principle #5 Tag Line: No clean sheet architectures Descriptive Version: An architect is always beholden to what exists. Prescriptive Version: Always understand the limitations and assumptions of the system your architecture is going to be a part of. No architecting exercise happens in a vacuum and nor does any system get designed independent of interacting systems. There is typically something that already exists and imposes constraints on the options of the architect. One has to be always aware that there might be systems that exist to solve parts of the problem and the new architecture has to be able to integrate with what exists. The limitations or assumptions that the supporting systems make about their environment sometimes limit the options the architect has. It is important to be cognizant of the limitations of these systems.

Principles Document Amit Limaye

Also every system operates as a part of a bigger system typically called the context and it imposes its own set of limitations on the new architecture. In summary an architecture in which everything can be completely architected from the scratch independent of either existing systems or the environment is never possible and assumptions of independence are dangerous.

Principle #6 Tag Line: Open for extension but closed for modification Descriptive Version: A good architecture is extensible but protects the core elements from modification. Prescriptive Version: The architecture should be open for extension of but close to modification Any architecture has to be designed with the assumption that it will be extended and used in scenarios not foreseen by the architect or the initial customers. It is important that the architecture doesnt overfit the requirements and become too rigid in the process. The architect might not be aware of all uses of the systems during the architecting phase but he often needs to understand the parts of the architecture which have a high level of uncertainty and might be extended for applications. The architecture should be extensible to address these new scenarios. But the architect also needs to identify components which are at the core of value delivery of the system and are relatively stable. These components should be tightly guarded against modifications by later users. These might be related to what the architect considers to be the primary value processes or operands. The output of these processes could be consumed by other processes to extend the value of the systems but these processes cannot be modified without compromising system integrity. We discussed Netflix as a system in one of our projects. Netflix extended its primary value delivery processes by allowing people to stream DVDs instead delivery by mail but could not successfully modify it later to charge people separately for mail and streaming DVDs.

Principle #7
5

Principles Document Amit Limaye

Tag Line: Contract by interfaces only Descriptive Version: A good architecture does depend on the internal working of the external system. Prescriptive Version: Any interactions with the environment should be strictly enforced at the interface and the architecture should not depend on anything else but what is specified at the interface. Interfaces in the system are points of maximum leverage and are also the most dangerous points in the system. They are the most complex elements of any architecture but also provide the capability to hide the divide the complexity of the systems into parts that can be tackled individually. Modularization is only successful if modules work only with the information provided at the interfaces of these modules. If a developer of a component makes any assumptions about the internal working of the component than the entire idea of dividing complexity is defeated. Division of complexity can only be achieved if the interface design is such that anyone interacting over the interface has to only consider what is exchanged over the interface without knowing which module resides on the other end. As such the contract between different modules in the system should only exist at the interfaces which would allow each of them to manage complexity in the system better. Principle #8 Tag Line: Constraints on the architecture. Descriptive Version: Some constraints are present due to either legacy reasons or mistakes in the needs gathering phase. Prescriptive Version: Be really sure about the constraints you put on your architecture (test its validity) Every architecting exercise starts with a set of constraints in which the value delivery has to be achieved. In many cases these constraints are present either due to legacy reasons or due to an incomplete understanding on the system. It is important to analyze each constraint imposed on the system and analyze the assumptions or reasons behind the presence of such a constraint. The assumptions sometimes dont hold either because of technology changes or changes in the process the system implements over time. Constraints are also sometimes arbitrarily imposed due to a lack of understanding of the system. It is sometimes useful to relax the constraints which are doubtful and then design a system free of these constraints and then add one constraint at a time. This might help in identifying redundancies and also understand the consequences of violating some of the constraints.
6

Principles Document Amit Limaye

This leads to better tradeoff decisions in the architecture. Principle #9 Tag Line: Iterative Process. Descriptive Version: Architecting is always an iterative process. Prescriptive Version: Dont try to identify all elements of the architecture in one pass. You will need to revisit the architecture multiple times and add incremental details in every pass. Plan to throw one way. You will anyway -F.P. Brooks Jr. Architecting is an iterative exercise and one should never expect to get an optimum solution in one pass. Infact more than often a first pass effort will miss some stakeholders and may not satisfy the most important needs of the identified stakeholders. Since the customer is the ultimate judge of the success of an architecture and it is often difficult to understand all the needs of the customer. The first attempt will either help the customer identify what is missing from his identified needs or will uncover new needs for the customer. The first pass will lead to more needs and stakeholders being identified leading to a more complete solution the next time. This is an iterative process where each incremental improvement helps in understanding of new stakeholders and latent customer needs. More than often you will have to start afresh after a couple of iterations to ensure that the architecture is consistent and does not suffer from band-aid effects where new need is addressed by hacking into an existing approach.

Principle #10 Tagline: Boundaries are regions not lines. Descriptive Version: A boundary between two systems is often fuzzy and is not a predefined line but rather a region in which stakeholders on either side of the boundary operate. Prescriptive: Always test boundaries of a system. A problem can sometime be solved more easily by expanding the boundary of the system.
7

Principles Document Amit Limaye

Discussion: A system rarely has very clearly defined boundaries and though we strictly talk in terms on interfaces in terms of boundaries an architect needs to be aware of what exactly gets exchanged at the boundary interfaces. If the exchange at the existing interface is too complex in terms of objects/processes that are exchanged over the interface it can perhaps be simplified by extending the boundary of the system slightly beyond the pre-defined boundary so as to make the transaction at the interface simple.