97 Things Every Software Architect Should Knw

       

 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

1. Duplication is evil
2. 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).