When I was first recruited as an Architect, honestly I was
not entirely sure what to expect. The typical ask from an architect in a
project is to help during proposal stage, clarify requirements and provide a
design that the implementers can start on. Apart from the usual suspects I
learned over the course of time that there were other things that go into
making an effective Architect. I will try to outline some of those here, which
I hope will help others in the future.
1. Nail down the specifics
Many times I have found that the entire ask
from a client would be a one-liner, which could be interpreted in multiple ways.
After passing through the different layers of procurement, sales, marketing,
etc. the one-liner would have morphed into a multi-liner that would have lost
the original one-liner in translation. To successfully identify what the client
really need, you would have to peel back each layer and figure out the history.
What a client needs and what the client
wants differ in 80% of the cases, once you have done this. If possible, it is
always good to have a chat with the client on what problem he/she really wants
to solve. It could turn out to be something completely different. One of the
best ways to identify this is to nail down the specifics.
The
specifics could be about use case scenarios test cases, set-ups, processes,
etc. Don’t talk about your design or solution at this stage. The important
thing is to understand what they really need.
2. Know your patterns
It is no secret that design patterns holds
the key to coming up with a successful design for a solution. Software (or
Hardware) architecture is about using patterns in the right way. Each pattern
has different scalability, complexity and extendibility. Learn not just the
patterns, but their limitations and adaptability. While the client may be
asking you for a specific requirement, look beyond it and bring additional
value to make sure that the design you come up with can meet future
requirements that he/she could face. You may not be implementing it at the
moment. But the design itself, should lend itself to future additions. Don’t
hesitate to show case it either. If a client knows you have put the extra bit
of effort to solve his future problems too, he will come to you when the need
arises.
3. Automate everything
I can’t stress the importance of this
enough. Before you set out on a new project make sure you have as many
automation tools as required to cover all aspects of the execution. While an
architect may not be expected to do this, it is something that should be done
to ensure a smooth execution. Continuous Integration, automated test
tools/cases, automated design/API document generation, code checkers, code
analysis tools, etc… ensures that you put the effort in solving the problems
instead of chasing down loose ends. Tie this in with your requirements/design
to ensure that it gets executed. This may not be easy when dealing with legacy
projects or those with lots of third party components. You may need to take a
call on how coverage you can achieve. Try to stretch and cover as much as
possible. It will save a lot of pain in the future.
4. Try out new things
Getting comfortable or complacent is one of
the worst things you can ever do. I have done that and I have suffered. Always
try to get out of your comfort zone. This stands for not just architects, but
for everyone. Learn new tools, new languages, and new approaches. There is a
lot of material out there. You just have to look for it. Read up, try out, and
never hesitate to do a test drive. Who knows? If not a current problem, it
could help you solve a future problem. Try to see gaps and possible improvements
in your domain. There is always a problem out there that you can solve. The
trick is always to formulate the right question.
5. Follow through on design
The job of the architect never ends at the
design phase. He has to act as a consultant throughout the life of a project.
It is always your baby. You have to nurture it, help it grow, correct the
wrongs and hold it on the right path. The unexpected will always happen, there
would be changes required. Some would be gradual and some would be sudden. The
gradual changes are the most dangerous. If you are not monitoring the changes,
the gradual changes would subvert the direction that you originally envisaged.
Over time they would affect the original design to make it unusable or
unsuitable for the purposes that you had in mind, when you first came up with
it. Be conscientious in the follow
through. Keep in mind that implementers are a harried lot. The pressure is on
them to fix the bugs and deliver to the customer on time. You will need to
throw your weight judiciously and pull in and convince the client and other
stakeholders too, if you think a particular fix or change may solve the short
term problem, but create a more serious long term problem. Have your arguments
ready, but know that the client may be under pressure themselves. In the end,
it is always better for everyone to know about a potential problem, than to be
blissfully unaware about it.
6. Identify and continuously measure your KPIs
As a part of the design always figure out
the Key Performance Indicators for the design. Come up with the non-functional
requirements that are clear cut and makes sense. And always have a defined,
automated approach to achieve these requirements. Again I cannot stress enough
on the importance of these numbers. You will need to have KPIs that cover all
features/requirements. Try to get these numbers as often as possible. They
should be part of your build or smoke/short test process and published whenever
collected. If it makes sense, graph it over time and see how the numbers vary
(and they do vary!). This will help you identify and rectify the problems that
directly affect your design implementation. It will also help you when
communicating effectiveness and advocating changes. After all nobody can argue
with a number.
7. Keep in mind Murphy’s law
If it can go wrong, it will, and horribly
so. That is part of life. As an architect, the only thing you can do is to
minimize the impact and try to derive positives from negatives. A key strategy
I try to follow at design stage is individualizing components. Component functionalities
and interfaces have to be defined as clearly as possible. Incorporate fail-safe
mechanisms that ensure that others who use the component know exactly what went
wrong, when everything goes south. Yes, that error code is important! So is
that exception/error handling! Try to cover as much error scenarios as
possible. If possible make sure that components can work individually as well
as in group, so that even when there are failures, they don’t become catastrophic.
Trust me, the ease in which you can diagnose and identify an error during a
demo (and fix if possible), can impress a client as much as a successful demo.
8. Learn from failures and successes
During the course of different projects and
designs, identify what worked and what didn’t. There are lessons to be learned
from failures and successes. Also what worked for one project may not
necessarily work for another. While some of this could be capture in
Retrospective or similar process in Agile methodologies, the learning differs
for an Architect from the group. The learning could be related more to
effectiveness of design, ease of implementation, what helped in that, and what
didn’t, maintainability of the design, customer feedback on that, amount of
refactoring, etc. Try to keep doing this over course of a project during
specific milestones. Always involve the implementers in this feedback, since
they would have borne the brunt of your decisions.
9. Establish good habits
Apart from being an architect, developers
who want to follow a technical path also look at Architects as role models. The
influence you have should be used to establish good habits in the developers
from the start, whether it is on maintaining code hygiene or following coding conventions.
The inputs that you give would provide the basic building blocks for their
budding careers and can give the necessary momentum and motivation for them to
excel. Practice what you preach for maximum impact.
10. Keep an open mind
The best inputs I have got are sometimes in
the context of something entirely different, sometimes from a different domain
or discipline. So do not restrict yourself to your area of specialization.
Learn from everyone. Even the least technical person would have something to
teach you, once you get a handle on how to cross co-relate learning. The
simplest things in a different area or field could give you inputs that if you
properly correlate may give rise to innovative ideas in your domain.
I hope that you gained some insights from
this post that will prove useful over the course of your career. In case you
need any further pointers, or you had some comments, or just need to discuss,
do drop me a line on my email and I will reply as my schedule allows.
