As an architect I always needed a cheat sheet to use
while taking architectural decision. We always tend put our technology ego and
our new technology thirst while selecting the technology rather than completely
concentrating on solving stakeholder’s problem. This book is manual for bitch
slapping whenever you fall into many of the pitfalls of know it all mode. Check
out the book @ 97 Things Every Software Architect
Should Know
Janus the architect
Janus is god from Greek who has a two heads facing in
different directions which depicts to see design for present, past and future.
Author brings the point that the
janus has two heads and not two faces, which means you have extra ear and extra
eyes, so as an excellent IT architect we should be superior listener and
evaluator.
This
article comes down all to the author portraying a good architect should be open
to new ideas, tools and designs that progress the project, team or profession.
He
also insists to never attend any management meetings or doing all the coding.
The architects should always have listened, evaluated and refactor their
processes, designs and methods to ensure the success of their work and projects,
which they have endeavored to ensure their products, will withstand the transitions and changes that are sure to come.
Don’t put your requirement ahead of your requirement.
As an engineer we sometimes recommend technologies,
methodologies to increase our weightage of our resume. Author of this topic,
clearly accepts this one mistake is common among all architects. Decisions are not only made for better
resume but also to try out new things in cost of business stake holders.
This
selfish immature decision will cost more to the architect and also to all the
stakeholders including developers because the technology can become a hindrance
to the completing project or technology chosen may be completely irrelevant in
solving the real problem.
Solution
to this immature issue is to having only stakeholders’ needs met in taking any
architectural decisions.
If
you feel the project does not help to get you what you want for your technology
thirst, it is better to switch projects rather than screwing every stakeholder
of the project and the project itself. With the right decision the project will
have happier team, a happier customer and over all less stress.
Chances are your biggest problem isn’t technical
We have all been there where we took up a failure project
or a failing project.
Does the project failed because we
choose Java instead of .Net or MSMQ instead of IBM MQ or WCF instead of Web
services? Mostly No.
Author
of this topic explains in a beautiful way, where the problems we face in most
of the projects are not rather technical. May be this article has more of a
managerial shade into it, but I believe it is must read for any stakeholders
including managers and architects.
He clearly explains to
solve all failing problems
We don’t
need confrontation, we need conversation.
He explains three tips for
effectiveness
- Approach events as conversation not as confrontations
- Approach these conversation only after you’ve got your attitude right(not when you are angry)
- Use these as opportunities to set mutually agreed upon goals.
Fight Repetition
This article is major piece for me. Repetition has been
beautifully covered by the author. He bring couple of truth about software
development
- Duplication is evil
- Repetitive work slows down development
When
I was starting my career I used to copy code from one class file to another and
there won’t be even a single variable change needed for the new class file to
compile because every code has an absurd naming conversion for all variables. I
was corrected by my technical lead at later time how copying code is a biggest
sin.
Author
says whenever you find the code is being copied then there is mistake in our
design because we know the system better than anyone as an architect.
He
also gives the best place to confirm
there can be a code copy are configuration files, business layer, Data access
layer, logging, auditing, transaction handing, authentication etc.
Repetition need to be corrected by someone and
the some one is always you (Architect).
Understand the business domain
This article is mostly based on building enterprise
architecture, even though we can use the topic’s artifacts in any part of
architecture.
Author
talks about understanding the business domain, business goal and business
requirement before designing architecture. For example good clarity in business
domain will lead to create a better workflow architecture approach. `
Understanding
specific domain will help in designing the system with heavy foresight, for
this author bring out the auto car insurance which can be created on the go,
even when you are driving your car. Customer may apply auto insurance from a
laptop or may be from mobile.
So
understanding the specificity of domain will help you design better. If you are
aware of business goal, such as will there be a business merger or an
acquisition of a company, then the architecture should have lots of layers of
abstraction for easier coupling with external interface.
He also
states that if the architect has better understanding of the business domain
and business goal then it is easier to communicate with the C-level executive
which creates lots of trust, which will help us to create better enterprise
architecture with their foresight included.
Great software is not built it is grown
I saved this topic for the last because it is my favorite,
I put it in a different way, if the project needs 9 months to develop and evolve,
then it needs 9 months of time. It is similar to a baby; you cannot give 9 resources
and get a baby in a month.
Author
explains very fluently about the concept how the project can only be grown; he
also says it is good to have a grand vision and grand design, but never to have
bigger design.
He
further justifies how the system should be concentrate on critical small part which
can be developed and tested.
The small system that is been built, can be
grown to become a bigger one which meets all the requirement of the stake
holders, he finally finishes the title by saying that “Do not confuse evolutionary approach with throwing requirement out, the
dreaded phrasing, or building one to thrown away”
This book is the best for an architect and I feel
it should be the first book read by every aspiring architect. They contain valuable
topics which are written by various architects with different perspectives. Six
topics I have chosen are my personal favorite and I have only taken the outline
out of the topics, so go get the book and read the whole article about the
topic. This book contains many beautiful
and fact full topics. Check out the
book @ 97 Things Every Software Architect
Should Know
Leave a
comment to share what you learned, and hit the “like” button to let others know
about it (make sure you’re logged into Facebook to like and comment).
