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.

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