Pages

Saturday, February 18, 2012

Developers usually tend to prefer development projects over production
support projects. Developers always want new challenges in terms of technology
and would like to be using the latest tech tools and platforms. As most
development projects offer them this advantage, they usually prefer to get away
from production support projects. But in
reality, the production support projects do offer them certain key benefits,
which are very much required as they move up in their career path. Let us examine
some of these here.

The real life business scenarios

A software project begins with perceived business
requirements as drafted by the Business Analysts and approved by customers. In
most cases, the requirements are far from complete and that leads the
developers to live with ambiguity giving room for more defects in the product
that they develop. How much ever the software is tested, when it hits the
production use, the real life business scenarios will for sure throw the
software out of gear and makes it fail. Thus, those involved in the support
projects get the opportunity to deal with production business scenarios which
will sharpen their business / domain knowledge. Given that the world has
started embracing the cloud and SaaS applications, there will be less of
development and more of customization and managing the configurations. That
means that the need for domain skills with the developers will rank very high
amongst the SaaS providers and consumers.

Better product / domain knowledge

In product development, it is quite possible that a
developer or a team of developers would be working on just a small part of a
product. That means, the developers associated with development projects have
very little opportunity to have complete understanding of the product. Whereas
the developers involved in the production support would get opportunities to work
with all parts of the product and some times across other products too. They get better visibility on the operating processes / practices associated with a use case, there by getting a better product / domain
knowledge.

Solution design skill

Developers tend to believe that support projects do not have
much opportunity in the solution design space, which is a myth. A production
defect is far more difficult to deal with than a defect identified during the
development life cycle. Resolution of a production defect involves at a high
level the following steps:

Quickly come up with a data fix to maintain the data
integrity if impacted by the defect.

Perform a root-cause analysis and come up with the real
life scenarios that could lead to this defect being encountered.

Come up with an interim work around if any available to prevent
it from recurring in the shorter term.

Identify a best solution to prevent it from recurring – This
is rather challenging as the solution has to be designed within the existing
product architecture, with lesser efforts and least impact to the already
working software.

Each of the steps when done well in combination with the
real life scenarios add tremendous value to the abilities of the developers and
that will lead them towards software or solution architects. Solutions in support project see production quicker than the development projects and as such high appreciation from business teams.

Code Re-factoring

Learning from one’s own mistake is a good way of learning.
But, learning from other’s mistake is a smart way of learning. Every time a
developer attempts to resolve a production defect, he might be looking into the
code written by someone else and may come across many different ways of
achieving a result. Taking it positively, a support developer may enjoy reading
through the code written by others and pick up some better algorithms and at
the same time, how not to write codes. This will for sure better their coding
abilities.

The developers in the supporting a production instance of a
software product will realize how important the readability of the code is and
hopefully they will be making it their habits to write readable code with
appropriate comments and indents.

Trouble shooting expertise

Usually software products are moved to production
environment after atleast three levels of testing. A defect in production means
that it has slipped through all the testing phases during development. So the
scenario under which this comes to surface is not something that has been visualized
during the development phases. Some of such defects would be very difficult to
reproduce without which resolving it would be a nightmare. Those involved in
support projects would quite often exposed to such scenarios and they will over
a period gain good trouble shooting expertise. Read one of my other blog on
Debugging performance problems.

Collaboration with other teams

During development phase, a software developer would be
looking up to his lead for any clarifications on the work that is assigned to
him and would not get exposed to other teams. Whereas, those involved in
production support get to work with various other teams like the infrastructure,
IT security, subject matter experts, quality assurance, business analysts, end
users, third party vendors when any of their components are used, etc. This collaboration
and interaction brings room for acquiring some additional skills both in
technical space and also on the soft skill space.

Conclusion

Being in production, support projects facilitates the enterprise
to perform its operations and earn profits on an ongoing basis. They play a
vital part in the business continuity of the enterprise. As long as a
production software is well supported and maintained, the IT heads would not
think of replacing it unless a major technology overhaul is expected.

Of course, there are certain downsides of being support
projects too. For instance, one may have to be on call to support any emergency
and some times, a hard to crack defect could result in tremendous pressure and stress.

Saturday, February 4, 2012

One of a typical question that an aspiring architect has to
answer in the hiring interview is “how in your opinion an architect is
different from an IT Manager?” Even I have been in the asking side, on many
occasions and have not been getting convincing answers from many. This is very
typical as in most organizations, even if one is titled as Architect, he or she
end up managing IT as against Architecting IT. Let us attempt to compare and
contrast the skills that these roles demand. Please note this is not
an attempt to make out a complete list of skills of these roles.

1.The Engagement

The Architect’s engagement starts with
identification of a business pain point. At times, it would be the Architect
who should spot the pain points and propose remedies. On the other hand the IT
Manager is engaged the moment a project has been scoped and is ready for execution
and implementation. The engagement of an
Architect starts with the challenge of making a business case (of course with
the help of fellow architects specializing on specific areas) to the stake
holders with appropriate quantified projections that lead to a positive RoI.
When this task is done well, the projects that get shelved mid course would
come down considerably.

2.Big Picture thinking

The Architect has to be the one who can visualize
the big picture of any given problem or a possible solution in line with the
enterprise’s long and short term goals, the anticipated business growth and the
technology trends in the related area. This visualization would help the
Architects to appropriately prioritize the various initiatives and to draw out
the short term and long term road maps. The big picture visualization is an
integral part of the IT strategy lifecycle of the enterprise to determine the
future state and plan for the transformations from current state to future
state. On the other hand, the IT Manager is engaged only in the transformation tasks
and there by leading the organization to the future state.

Some of the aspiring architects, when asked
how would they do the capacity planning, their response was based on a pinned
down Statement of Work, which in case of architect engagement would not exist
and they could not think of a situation where they would be designing a
solution with absolutely no requirements on hand.

3.Project Execution

The IT managers will have teams to execute,
implement and manage various projects, whereas, the Architect would be playing an
independent and in most cases individual contributors. The Architects have to
be with the project execution teams and help the teams by bringing in course
corrections whenever they deviate from the intended plan. This role requires the
Architect to possess hands on ability in the related technology, so as to hand
hold the project teams during execution. The IT Managers on the other hand may
not be required to do this and instead he would simply co-ordinate the
engagement of Architects with the teams.

4.Risk Management

While Risk management is essential in IT management
life cycle, performing it early on adds huge value to the solution execution as
it helps better decision making in terms of resource planning, training needs
and of course will bring in the ability to remedy the risk. That is the
challenge an Architect has to face in identifying all potential risks that the
solution may lead to. IT managers also face challenges in risk management, but
it will be a lot easier as many things would have gained concrete shape with
less ambiguity.

5.Staying on top of the trends

The IT Managers are not normally pressed to
stay on top of the technology trends and it would be enough for them to stay on
top of the technology that is mature enough and has good industry adoption. The
Architect on the other hand has to stay on top of the trends and that would
help him in measuring the longevity of the proposed initiative or solution. It
also important for the Architect to have a good grasp of industry predictions
and analysis and should have the ability to choose the less risky path to lead
the enterprise to the future state.