Principles of architecture
- 1. Principles of Architecture The mythical man month was first published in 1975, and I am amazed how relevant it is today even after so many advanced in technology. The book and my course at MIT encouraged me to define the principles of architecture for my reference. AKSHAY BAGAI
- 2. Architect takes a project from vision to reality An architect understands the vision, explores options and creates a path to execute the project. He sets guidelines which help choose between options. An architect must ensure that the team understands the direction of the project, and architect should understand Stakeholder, Technology, Business Strategy and organizational structure to create a direction. A new project is a vision, and the path from vision to reality is ambiguous and uncertain. An architect needs to understand Stakeholder, Technology, Business Strategy and organizational structure and develop a roadmap. For technology, an architect needs to have In-depth understanding of the domain and pertinent technologies, technical issues and development methods. He uses these to identify and address the architectural challenges and build a system point of view. For business strategy, an architect needs to understand not only the influence of corporate strategy but also of the market competition. Having this context, an architect is equipped to design a solution that the team can bring to life. Reference http://www.bredemeyer.com/pdf_files/role.pdf "Vision without execution is hallucination." - Thomas Edison
- 3. Architecture intricately combines form and function A good architecture is one that meets the needs of the stakeholders (especially the users) to their satisfaction, does not violate established principles of system architecture, and takes into account the relevant ilities by allowing for maintenance, evolution, further development, embedding, etc. as the customer requires. An architecture is an embodiment of concept, and the allocation of physical/informational function to elements of form and definition of relationships among the elements and with the surrounding context. The form in an architecture is the sum of the elements or the arrangement of the physical/logical embodiment. Function in a system is activities, operations and transformations that cause, create or contribute to performance. An architecture has a “Concept, which is a product or system vision, idea, notion or mental image which maps Form to Function. It is specialization of function and mapping to its physical embodiment of form. Good architecture is intuitive to use for the user, easy to navigate, visualize and work with for a developer, easy to evolve for the company. It should capture not only the primary requirement, but also non-functional and quality requirements. References http://energy.gov/sites/prod/files/2015/04/f22/QER%20Analysis%20-%20Grid%20Architecture_0.pdf Thinking in Systems: A Primer Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values “The test of the machine is the satisfaction it gives you. There isn't any other test. If the machine produces tranquility it's right. If it disturbs you it's wrong until either the machine or your mind is changed.” Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values
- 4. know thy stakeholder Although the V-Model showcases Stakeholder Analysis as the first task in a project, this activity can be divided into two tasks – stakeholder identification (which happens in the beginning) and stakeholder management (which usually happens throughout the project). In the beginning of a project an architect identifies the stakeholders to uncover the goals and requirements for the system, and then during the execution he must ensure that the appropriate stakeholders are involved in the project delivery. For complex systems, Stakeholder identification is one of the most important tasks. First, the architect should identify the stakeholders of the system. A complex system might have a large number of stakeholders and the Stakeholders do not always have a very apparent relationship. An architect must work to uncover these relationships and understand the impact of both direct and indirect relationships between stakeholders on the success of projects. The architect should then apply such an understanding to inform decisions on stakeholder management strategies in a positive way and build a common platform for engineering, external affairs, and management within a project to consistently communicate important information about stakeholders. Second, an architect must ensure that the stakeholders are managed appropriately. Find ways to convert troubling stakeholders to project proponents. “You cannot force commitment, what you can do…You nudge a little here, inspire a little there, and provide a role model. Your primary influence is the environment you create.” - Peter M. Senge References: - System Architecture: Strategy and Product Development for Complex Systems (Edward F. Crawley, Bruce G. Cameron, Daniel Selva), Pearson, 2016. “A true architect is not an artist but an optimistic realist. They take a diverse number of stakeholders, extract needs, concerns, and dreams, then create a beautiful yet tangible solution that is loved by the users and the community at large. We create vessels in which life happens.” - Cameron Sinclair
- 5. Draw a boundary Defining a Boundary is essential to determine the scope of the project and to focus on the details. A clear boundary definition communicates a clear problem domain. When an architect starts a project, one of the biggest concern in determining requirements is distinguishing what the system should do from what it should not do. It is often difficult to make decisions about boundary, but it is also often difficult to communicate about this issue with all the people involved, analysts and stakeholders. Boundaries help to separate the things that are applicable to the project and the areas that are out of scope. Boundaries not only help to clarify the problem domain, but also help to identify the systems or interactions which are out of control of the project and may need consideration. For example consider a company wants to develop a new mobile phone, if it considers the charging device in the boundary of the project then it would design a new charger for the phone, however if the charger is out of scope of the project then it is imperative to decide the “interface” for the charger. In either case, a boundary clarifies what is project intends to achieve. References Thinking in Systems: A Primer System Architecture: Strategy and Product Development for Complex Systems (Edward F. Crawley, Bruce G. Cameron, Daniel Selva), Pearson, 2016. “There are no separate systems. The world is a continuum. Where to draw a boundary around a system depends on the purpose of the discussion.” ― Donella H. Meadows, Thinking in Systems
- 6. Think Holistically – Everything is connected There are known-unknowns and unknown-unknowns. The purpose of holistic thinking is to uncover as many unknown-unknowns as possible. Holism in general terms is the idea that all the properties of a given system cannot be determined or explained by its component parts alone, but the system as a whole determines in an important way how the parts behave. Apply holism for system architecture to think wide about a system, and uncover something that will ultimately be important for the system. Any project has known-unknowns, things we don’t know much about, and unknown-unknowns, something we don’t even know is there. Holistic thinking helps us uncover unknown-unknowns so that their potential importance can be thought through. To ensure that all the possible perspectives have been considered, an architect should develop frameworks and spend considerable time to think about the context. References http://www.philosophybasics.com/branch_holism.html System Architecture: Strategy and Product Development for Complex Systems (Edward F. Crawley, Bruce G. Cameron, Daniel Selva), Pearson, 2016. “Always design a thing by considering it in its next larger context – a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” – Eliel Saarinen
- 7. Manage influences A system architecture is influenced by many factors. When designing the system, an architect should understand that these influences will govern the final architecture, however as it is his responsibility to juggle these influences and provide maximum benefit at cost. An architecture is the summary result of a set of decisions. Architectural decisions include the motivation and rationale for component selection, interconnection mechanisms, coordination mechanisms, and the selection of architectural styles or idioms. An architecture has many upstream influences and downstream influences. A companies corporate corporate strategy defines the companies approach to succeed in the market, marketing strategy defines how the company wants to position itself, the current state of technologies define the possible options and regulation in the industry defines the mandatory requirements. Apart from these, the downstream development of the system is an equally significant source of ambiguity. The Downstream influences of architecture are development, operations, design for illities. An architect role is to compress and extract the relevant downstream details and inject them back into the decision making process up front. An architect not only must interpret and condense all these influences in order to reduce ambiguity, but also consider all these to make architectural decisions. Spend adequate time on these architectural decisions, because they are extremely expensive to change later. References http://www.sei.cmu.edu/library/assets/understanding_arch_influences.pdf http://www.amazon.com/System-Architecture-Strategy-Product-Development/dp/0133975347 System Architecture: Strategy and Product Development for Complex Systems (Edward F. Crawley, Bruce G. Cameron, Daniel Selva), Pearson, 2016. The cat only grinned as Alice approached... “Cheshire-Puss,” she began, rather timidly... “Would you tell me, please, which way I ought to go from here?”. “That depends a good deal on where you want to go to,” said the Cat. -- Alice’s Adventures in Wonderland, by Lewis Carroll
- 8. Be ready to change Any project requires regular adjustments and decisions, but on the other hand too many adjustments leave the project in jeopardy. A project manager should be deft at judging when an adjustment is required. No amount of planning before a project can uncover all the variables in a project. Project execution requires continuous adjustment to achieve the end goals. The initial architecture provides guidelines for the decisions required in the project, and the project manager should ensure that the project is ready to adapt to changes required while execution. However, as shown by the system dynamics model of project management, the project is impacted by many factors and too many adjustments might leave the team confused and without focus and the project deadlines in serious trouble. Project manager should consider the ripple effects of each decision and should not be “reactive” in changing the course of the project. A calm demeanor and cautious planning must be followed throughout the project. References System dynamics applied to project management: a survey, assessment, and directions for future research http://onlinelibrary.wiley.com/doi/10.1002/sdr.377/pdf Project management lectures ESD.411 “First, have a definite, clear practical ideal; a goal, an objective. Second, have the necessary means to achieve your ends; wisdom, money, materials, and methods. Third, adjust all your means to that end.” - Aristotle
- 9. Ask the right questions – and seek answers An architect should be adept not only in the technology or problem domain he is solving, but also in the art of framing and asking the right questions from the right stakeholders One must spend adequate time to frame the questions. Ambiguous questions result in ambiguous answers and may have a direct impact on the consequent architecture. An architect has the primary responsibility of resolving ambiguity in the project, and the way of reducing ambiguity is a clarity in the aim. An must ensure that right questions are asked not only during the requirements phase of the project but also while the implementation. The correct questions in requirements phase result in appropriate results from the product. Finally, The architecture provided by the Architect, just provides a direction and framework which the team should follow. There will be numerous instances in the project execution when the team requires direction, the culture of asking the right questions would yield answers which are beneficial for the project. As the cartoon on the right illustrates, there are many examples when there is a huge gap in customer wants and project deliverables. Right questions can save the project! References Project experience: I have seen many errors in software becase of incorrect framing of the requirements questions. http://www.brainyquote.com/quotes/quotes/w/wedwardsd384036.html “If you don’t know how to ask the right question, you discover nothing” – W. Edwards Deming
- 10. Set SMART Goals SMART goals provide a clear direction for the project and free up the energy that is wasted on unfocused goals. Goals help in removing the ambiguity surrounding the project and gives team a clear direction. The goals provide guidelines for the project, so an architect must spend adequate time to define and refine goals. Developing a plan to meet a goal is akin to having a map and directions for a journey. For a project, taking SMART steps can help free up energy that is wasted on unfocused goals and eliminate the frustrating process that is commonly referred to as spinning one's wheels. Individuals and teams can focus energy and effort toward the desired end by clarifying plans and deciding what is required to meet the goals. “SMART” provides clear guidelines on goal definitions. A goal should be Specific, Measurable, Attainable, Relevant and Time-bound. So, for example rather than set a general goal of increasing business, a company might instead target increasing new business by 10 percent. A significant amount of research and judgment is required to make SMART goals. The goals should not limit what the project can achieve, but rather stretch the team to achieve maximum value. References https://eds-a-ebscohost-com.libproxy.mit.edu:9443/eds/detail/detail?sid=502895e9-21d9-4b08-a3ac-a0038b3a7922%40sessionmgr4005&vid=10&hid=4103&bdata=JkF1dGhUeXBlPWNvb2tpZSxzc28saXAsdWlkJnNpdGU9ZWRzLWxpdmU%3d#AN=100259301&db=ers Your goal should be just out of reach, but not out of sight. - Denis Waitley and Remi Witt
- 11. Be cautious – Not Timid An architect should be aware that one tends to over design and be over cautious when one is designing the system second time. And thus, when designing a system, the architect should actively engage senior architects. In this context, an architects first system is apt to be spare and clean. As the design completes embellishment after embellishment occur to him, and so he realizes the short comings of the design. When he designs the second system, he would over design and try to accomplish all the gaps of the first architecture and incorporate all the bells and whistles. This is a recipe for disaster. The architecture would become over complicated, over designed and over documented for anyone to comprehend. The only solution to this problem is the self cautiousness of the Architect. He should be aware of this tendency. References The Mythical Man-month Once bitten twice shy (a very common proverb in English and possibly all other languages. I can certainly assert that it is extremely common in Turkish and Hindi) Second System Effect (The Mythical Man-month)
- 12. Be creative – tame constraints Constraints are an opportunity to be creative and find solutions. A very crude Indian concept is Jugad, which means frugal innovation. Every project has opportunities of creativity and an architect can use them for the benefit of the project. An architect should not be deterred by constraints, rather he should look at constraints as opportunity and build options to solve them. The core concept of the Theory of Constraints is that every process has a single constraint and that total process throughput can only be improved when the constraint is improved. A very important corollary to this is that spending time optimizing non-constraints will not provide significant benefits; only improvements to the constraint will further the goals. I believe that not only is this is theory applicable to architecture, but it is a vital point of applying creativity. Every constraint is an opportunity for an architect to infuse creative solutions in the project. There are numerous examples in industry when a company excelled because of finding solutions to the constraints. References http://www.leanproduction.com/theory-of-constraints.html In the midst of chaos, there is also opportunity ― Sun Tzu, A Arte da Guerra
- 13. Build a project dictionary Common Vocabulary and Data Definitions ensure that everyone involved understands the same thing. A common vocabulary will facilitate communications and enable dialogue to be effective. An architect must develop a project vocabulary. Ambiguities resulting from multiple parochial definitions of data must give way to accepted enterprise-wide definitions and understanding. An engineering team works together to perform a specific goal. There could be significant confusion in the team if a common vocabulary is not cultivated. NASA lost a $125 million Mars orbiter because a Lockheed Martin engineering team used English units of measurement while the agency's team used the more conventional metric system. This could have been prevented if the architect took extra caution to establish the vocabulary. From my personal experience, this principle is extremely important for software development. References http://www.cnn.com/TECH/space/9909/30/mars.metric.02/ http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html Project experience "The language we use influences the way we think." - Steven Pinker