Design for Upgrade

While this blog is more inclined towards the Agile software implementation, one of the incident happened last month has forced me to pen in a few thoughts on software architecture. We developed an application with Microsoft Office SharePoint and InfoPath. The development started a year back with Office 2003 and now it’s migrated to MOSS 2007. The application has been simply architected, keeping in mind the customer requirements. As mentioned in one of my previous post, the “tale of never ending requirements” hit us in the middle of migration. A new product release always carries additional/ improved features for addressing business problems. During the migration, it makes sense to evaluate new features and analyze the possibility of leveraging them for addressing business problems (in better way). Having said this, the solution architecture must support the up-gradation scenario with reasonable amount of time and effort.

Design decisions while architecting a software solution are derived from various sources like availability of resources, customer needs and preferences, business domain etc. However, the basics remains unchallenged for every implementation scenario. One of such fundamental is explained in this great quote from “Software Architecture in Practice, Bass, Clements, Kazman”

"Architects make design decisions because of the downstream effects they will have on the system(s) they are building and these effects are known and predictable. If they were not, the process of crafting an architecture would be no better than throwing dice. "

No architecture can be perfect, in-fact you do a tradeoff between software systems attributes to come with the best possible solution for specific business requirements. Thinking of an architecture generally brings into mind the concepts of layers and tiers (layers are logical separation of components while tiers are physical). Each layer will add an additional message call which will hit the response time. Then why architects still model the system in separate layers and takes the performance hit? The answer is “to make complex things simple”. More complex the system requirement is, more are the number of layers that are generally included in the solution architecture.


Coming back to our scenario, how would an architecture can support the technology up-gradation process? I believe there can not be a complete answer to this; unless you understand the vision of the technology/ product company, it’s difficult to handle this 100% with architecture. However, there are some basic principles that remains unchallenged. XML functional calls, loosely coupled layers, different tiers for application and database etc. are few checks to handle the situation .

One important point to consider: If requirements are simple then it’s not recommended to take the performance hit by including layers. Trying to over simplify the system will make it complex .

Clear Business Goals

This post is in continuation of project success series। We will discuss the point number 3 i.e. clear scope and business objectives.

Any software project, based on it’s outcome falls into 3 categories। 1) Successful, 2) Failed & 3) Hanged project. Hanged projects are the most (in)famous and interesting ones. The beauty of hanged project is the fact that they get’s accepted by customer but still it’s of no use to end user.

Software is developed to meet some business goals and if the goals are not clear and measurable, you will get a hanged software. I would like to mention here the key difference between failed and hanged software; Failed software doesn’t meets software requirements (specifications) and is never accepted by customer, while hanged one meets documented requirements but doesn’t helps reaching business/individual goals.

Individuals either opt to use the software or they are forced to do so; Individual goals makes sense, only when they are inline with business goals of an organization they work for। Complexity begins when individuals start considering these goals as the solution of their functional problems. So we have business goals and business problems and the difference between them is the ability to measure. For example, the “customer wants to increase the production” is a business problem. This business goal is that “customer wants to increase the production by 50%”.

Arnold H. Glasgow says: “In life, as in football, you won't go far unless you know where the goalposts are.” During the software development, it’s important to check and measure the progress towards business goals। The iterative model of agile development helps in this context. I remember the control theory of Feedback Control Systems (taught in B.E, Elec. & Telecom) which defines “feedback” as a process whereby some proportion of the output signal of a system is passed (fed back) to the input. This is often used to control the dynamic behavior of the system. Example is the missile guidance system which measure the position at regular intervals and send it back to control device. The theory fits well in agile development scenario where we take user feedback at regular intervals and adjust the output accordingly.

Coming back to hanged projects; they are derived by specifications that states business problems (most of the times) and not the measurable goals. Though these goals are defined from customer, the project analyst must help transforming business problem statements to measurable goals. This way I believe a customer will have the value for money she has spent to build a software. For us, the software is successful when it’s used by end users and not just delivered and signed off.

The Art of Software Development

Hello and welcome to my blog. My name is Abhishek Kaushik and I strongly believe that software development is an art as well as science (I've realized during eight years of software development). Internet has lot of references on technology (from basic programming, oops, patterns etc.) and IT processes (CMMI, Analysis, Estimation etc.) that makes a software implementation successful. However, you seldom find places that aims towards providing information on the common sense we need have for developing a software system that WORKS (Agile development is a great effort in this direction).

Software that really works is the system that is used with ease by end users. No-matter what latest/best technology or process you follow at backend, the bottom line is that system must WORK for the end user. I’ll share what I’ve learned from practical situations that I’ve faced during these years of software carrier.

I must tell you that I’m great supporter of technology (working as .Net Solution Architect; I love my job ) and got opportunities to work upon wide range of technologies including - Assembly, C++, PHP, ASP/ VB/ COM, .Net (Beta 1 - 3.0), SharePoint, BizTalk, Commerce Server, Office InfoPath and so on… Also I understand the importance of software process that we must follow to deliver successful and profitable projects. At the same time I believe that if you lack or deviate from the common sense required, you will end up loosing.