Wednesday, June 07, 2006

A Tale of Two Models

Various names exist for the delivery model which allows companies to create software in multiple locations.
The simplest avatar of this model has work distributed across two locations, one of which is usually the client location. This model also has different versions, there is a Thin Client and a Thick Client version.

In the Thick Client version substantial development takes place at the client site whereas the Thin Client version is skewed towards majority of the development taking place at the non-client location.

In the early days of multi-location development, the prime driver was often perceived (both by service providers as well as customers) to be "Cost" more specifically reduction in costs and hence the thin client model is what most of the organization specialized in.

This I think had an impact on a couple of things,

- the choice of a delivery approach, given that the thin client model
and its inherently limited client interaction- (suprisingly having limited client interaction is still seen as one of the differentiators in the IT industry but thats another tale for another day),

the tendency was to spend a portion of the time (which was limited) to gather requirements and then be shooed away to go and magically design and create software... sound familiar?

- the 'sophistication' of services that companies (again customers and service providers) believed could be provided (with adequate certainity of delivery) using this model and approach, led to a slow but certain 'commoditization' of services being provided.

The Thick Client model was driven primarily by a belief that Software is meant to 'add value' to business and not just automate in the hope of reducing costs through increased efficiencies. This model is inherently geared towards richer customer interaction and consequently has the canvas to provide services which are increasingly sophisticated. Doing this however required a different mindset and approach to software creation, which leveraged the availability of the customer to shorten feedback cycles. In short be more Agile

Friday, June 02, 2006

I must meet Vardhan from DNA and thank him for all the rock groups he has managed to bring into Bangalore. I grew up in the 80's listening to some of these bands. It was not too easy at that time to imagine that you would see Uriah Heep live or Mark Knoffler playing live. At that time my reasoning was more to do with branding of the Indian audience to this music. My reasoning was that these bands would not even know that they had a fan base in India. Which was probably true in some cases. I guess the breaking down of walls around the world helped in getting the word out to these folks on the demand in India

Later when DNA started getting these bands into India one started to hear about the thousand ton equipment that they lug around just so they can do a show which lasted a couple of hours. I wonder how many folks listening to Knoffler croon Romeo and Juliet thought about all the effort which went in to getting the infrastructure setup so one could experience this:)

I recently read an article on Joel's - http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html)

which outlined a role 'management' needs to adopt in software companies. The article encourages 'management' to take on the responsibility of creating what they call the 'Development Abstraction Layer'. Essentially allowing project teams to concentrate on what they need to do - create excellent software solutions to business problems, and taking away all the 'noise' associated with providing them the infrastructure to do so.

Thursday, June 01, 2006

Getting by with a big 'Yelp' from my friends

For a while I have been a sniffer on various blogs. My friend Chaman (also works with me) gave me a wake up call on blogging, and consequently this is my first blog entry.

One of the many fun parts of working with the company that I work with (ThoughtWorks) is the push you get from folks around you to do stuff you have never done.

I joined this company because I had had enough of consulting at 20,000 feet above sea-level, mainly looking at the "whats" and moving on to another what while another team came in and thought about the how's. You keep doing this for a while and the lack of O2 at that height finally gets to you and you long for terra firma.

Thats all for today