Thoughts from the trench - by Prakash Muralidharan

August 30, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Emerging technologies.

Filed under: Technology, Corporate IT — Prakash Muralidharan @ 4:16 pm
Tom Foydel over at Sightlines writes about the next wave of technologies that will hit the SME sector. The regular suspects are all there : RFID, Open Source, SAAS, Clouds and stuff. There are a couple of surprises as well because you don't hear so much about these yet: Alternate energy, Cell Technology. Tom's list seems comprehensive but I'd like to know what you think? Are there any emerging technologies that are not in the list?

Linking and Sharing

del.icio.us:Emerging technologies.  digg:Emerging technologies.  fark:Emerging technologies.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/30/emerging-technologies/trackback/

August 29, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Break in the hills.

Filed under: Life — Prakash Muralidharan @ 11:33 pm

We took off for a short break in the hills a while back and the impending long weekend brought back those memories. Here are some pics. No, that's not a bison burger but a venison burger. It's amazing what being in touch with nature can do!

Farming 

Venison burger

Country roads


Linking and Sharing

del.icio.us:Break in the hills.  digg:Break in the hills.  fark:Break in the hills.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/29/break-in-the-hills/trackback/

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Myriad sourcing flavours - Will they merge ?

Filed under: Software Services, Outsourcing, IT strategy — Prakash Muralidharan @ 7:38 pm

Peter Allen over at TPI argues that vendors need to know where they stand on the sourcing continuum (What type of a provider am I ?) and buyers need to know what type of sourcing they need (Should I go for a transformational partner or stick with a commodity player).

"It’s important for outsourcing buyers to know what sort of relationship they need, and equally important for service providers to know how they will be slotted into the hierarchy within the service portfolio. 
If you want a strategic partner, don’t select a provider that has built a business on being a leader in a commodity category.  Similarly, don’t hire a transformational expert if all you really want from the relationship is cost-benchmarked services delivered just like many other providers. "

Very true. The "Big five" started with solid relationships with the business, primarily around finance, auditing and business process. This allowed solid board level relationships and well as a good understanding of industry business processes and pain points. They branded themselves as transformation partners and charged clients hundreds of dollars an hour for providing 'thought leadership'.

The Indian giants started out as pure body shops. Learning to effectively 'package' resumes on the front end and while doing that, drove decent operating margins through operational efficiencies. The Y2K opportunity was the poster boy of this model at it's best. Vendors grew like weeds and life was good. The norm was that the big five would come in and produce a word document that would lead to downstream implementation business that would be cherry picked and handed out either to the big five -  the turn key, high end stuff or to the traditional offshore players- the repeatable, commodity work.

This state represented the three sourcing flavours very distinctly with firms occupying one of the three tiers that Peter brings up. With a high volume, high margin business and a booming Indian stock market, traditional IT players started investing in areas outside their comfort zone of commodity technologies. Companies got verticalized, technology practices lead by centres of excellence got formed, project management capabilities got matured and the list goes on and suddenly, the Big five's started getting their business models exposed. Clients started realizing that there was a value gap. They were leaving money on the table and a lot of work being done by highly experienced onshore Big Five consultants could be done offshore.

The Big Five reacted by aggressively building offshore capabilities - even at the cost of commoditizing their existing business with all the political ramifications. They had no other option. This lead to accelerating commoditization of the backend, while at the same time shifting the battle to the front end. Traditional offshore players reacted by strengthening their front end, sometimes organically, but mostly inorganically. You can see that playing out currently.

What does all this mean and where will it leave us ?

The dividing lines are clearly merging. The best of traditional offshoring players and the best of the multinationals will form a unified high end Tier-1 sourcing layer. These vendors that will have the capability to conceptualize quality business solutions and execute them virtually and globally in a truly 'flat' sense with the ability to exploit local geographic strengths while enjoying global scale. They will straddle IT and business seamlessly and across industries and will be able to offset margin pressures with a combination of high end value and unique flat execution efficiencies.

What of the rest ? They will either need to find niches in which to survive or will get acquired. With factors like the long term appreciation of the rupee, escalating infrastructure and wage costs, the so called tier-3 and tier-4 vendors will find the going tough. They will not be able to play the cost game in the commodity space and neither will they be able to retain the kind of talent needed to play the high end game. We could see some of these players moving towards a localized onshore and near shore model, cherry picking leftovers from the tier-1 players. Others could consolidate and merge between themselves in an attempt to squeeze maximum scale in a commodity business. This is likely in areas like testing where there is a case for independent validation and given the pace of growth in the testing market, an attractive scale proposition.

Linking and Sharing

del.icio.us:Myriad sourcing flavours - Will they merge ?  digg:Myriad sourcing flavours - Will they merge ?  fark:Myriad sourcing flavours - Will they merge ?
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/29/myriad-sourcing-flavours-will-they-merge/trackback/

August 26, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Web 2.0 bubble bursting ?

Filed under: Web2.0 — Prakash Muralidharan @ 11:06 am

 

The bubble has burst or what ?  Max Bleyleben over at Technofile Europe feels the party is over. "As I have commented before, most of the $1.5bn VCs have thrown at Web 2.0 startups went into cutesy but useless Web services.  Some went into infrastructure and enterprise services, but most of these didn't have defensible technology and were too easy to replicate"

Eric Schonfeld seems to 
concur"But did Web 2.0 deals peak last year? Take out the $300 million raised by Facebook, and the amount invested was up only 46 percent, a marked slowdown from the 132 percent dollar growth the year before. "

Martin Lamonica of Cnet
says "Silicon Valley remains the hotbed of Web 2.0 activity, but the hipness of start-ups with goofy names is starting to cool in the face of economic reality. "

It's amazing how much money chases hype only to have the bubble burst. Yet again. Even the 17'th century had it's own bubble. The Tulip bubble. According to the Wiki "Tulip mania or tulipomania was a period in the Dutch Golden Age during which contract prices for bulbs of the newly introduced tulip reached extraordinarily high levels and then suddenly collapsed." You can read about it here.


Linking and Sharing

del.icio.us:Web 2.0 bubble bursting ?  digg:Web 2.0 bubble bursting ?  fark:Web 2.0 bubble bursting ?
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/26/web-20-bubble-bursting/trackback/

August 25, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Of Information technology and Burgers.

Filed under: Software Services, Project Management, Corporate IT — Prakash Muralidharan @ 9:09 pm

Ramshankar laments about the lack of visibility when it comes to the services that IT departments support and expose to the business. "There are very few organizations where one gets a sense of what IT truly delivers to its customers at what cost, at what performance level, conditions and so on….What about “make your own Service menu” like “make your own pasta”! Is there flexibility within IT Services to accomplish this?" He goes on to suggest ITIL V3, a standard that recommends dynamic catalogs as a possible solution that can help end users and business see IT like a burger. Log in to an intranet portal or something and 'order' IT. Essentially hide away complexity and expose a very simple front end to business.

Renjith blogs about ITIL V3…"the Service Catalog concept have been enhanced and coupled with Demand Management, Portfolio Management and Request fulfillment."  

Interesting. Now, where's the burger?



IT plays multiple hats when it comes to business. I briefly touched upon the two broad types of IT demand in a previous post. Basically, there is the transformational 'change the business' part, and then you have the keep-the-lights-on 'run the business' aspect. 


Certain portions of 'run the business' are definitely like a burger. Desktop software installations come to mind. You have limited complexity, a fixed set of ingredients (read skills sets), a mature and repeatable execution model, resources are interchangable and not too many unknowns. When was the last time an IT engineer failed to install Office on your desktop ? Surely you can, given the right tools, adopt sophisticated demand forecasting with integrated resource fullfillment and maybe even aggregate demand across customers and have a portfolio level approach. The benefits are clear and easy to quantify.

'Change the business' is an entirely different game altogether and so will any aspect of 'run the business' that requires close integration with 'change the business'. This is more complex stuff that requires a more strategic approach both from business and from IT. 'Change the business' is more like a full course meal in a gourmet restaurant, replete with all the bells and whistles. 

Burgers are cool and have their place. So do gourmet dinners. The trick is to know what to serve to which customer.


Linking and Sharing

del.icio.us:Of Information technology and Burgers.  digg:Of Information technology and Burgers.  fark:Of Information technology and Burgers.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/25/of-information-technology-and-burgers/trackback/

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Rounding errors and WW-III

Filed under: Software Services, programming — Prakash Muralidharan @ 1:47 pm

Amit Ranjan at Webyantra points to the enormous leverage that software has on our day to day lives. The consequences of bugs are usually thought of in terms of customer dissatisfaction, schedule slippages and maybe at worst a bunch of pink slips. Next time someone trivializes testing or defect fixing, make them read this:

Explosion of Ariane 5, 1996 due to “…conversion of a 64 bit integer into a 16 bit signed integer lead to an overflow…”

Loss of Mars Climate Orbiter, 1999 due to “…mix-up between pounds and kilogram….”

Mars Polar Lander, 1998 due to “…software error that mistakenly identified the vibration caused by the deployment of the lander’s legs as being caused by the vehicle touching down on the Martian surface….”

Loss of Mariner 1, 1962 due to “..period instead of comma in FORTRAN DO-Loop…”

Breakdown of AT&T’s long-distance telephone network, 1990 due to “…a single line of buggy code in a complex software upgrade implemented to speed up calling caused a ripple effect that shut down the network….”

USS Yorktown dead in the water, 1998 due to “….input and Division by ‘0’. „ X / 0 = undefined…”

MIM-104 Patriot Missile Failure, 1991 due to “…rounding error”

Shutdown of 5 nuclear reactors, 1985 due to “..use of arithmetic sum of variables instead of the square root of the sum of the squares of the variables….”

Denver International Airport, 1994 due to “…baggage handling system broke down because of numerous bugs….”

Reading this definitely made me more reverent about my own beginnings- doing Y2K fixes. I used to resent the work and thought it as 'dumb' and spent a lot of time writing automation tools instead. :-)


Linking and Sharing

del.icio.us:Rounding errors and WW-III  digg:Rounding errors and WW-III  fark:Rounding errors and WW-III
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/25/rounding-errors-and-ww-iii/trackback/

August 23, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Gartner does not need to provide SLAs.

Filed under: Consumer Internet — Prakash Muralidharan @ 10:52 pm
Vinnie blogs about Gartner bringing down their site for scheduled maintenance with a cookie cutter "apology" page and asks "Does Gartner provide a SLA ?". For a second the post took me back to 1996, when the web was in it's infancy. Penetration and thus user volumes were low. Application servers were still not properly clusterable and outages were frequent. A quick search revealed that Amazon does have an amazing uptime. According to Webmetrics the Amazon uptimes are:

Web ServiceAverage UptimeAverage Response Time
Amazon S3 REST API99.9915% 1.63 sec
Amazon S3 SOAP API99.9912%1.55 sec

 


Does all this mean Gartner has to have an SLA when Amazon does ? I think the key is the source of value. Gartner draws it's value almost entirely from proprietary content and from a strong brand built on the idea of proprietary content. Content is king.

Amazon's value is based on transactive sophistication (just check out their
one click ordering). and amazing customer service. They don't sell anything 'unique'. They make the buying process somewhat a pleasure and yes the prices are great. Context and service is king.

Now, what happens if Gartner is down and you wanted an article desparately ? You'd have no option but to wait. Even if you find the exact same content freely availaible on the web you still can't use it like you would be able to use Gartner content. To know the difference, just try quoting from Gartner to a client and make the same quote like you are saying it yourself.

If Amazon is down or even slow, a good proportion of customers would simply go elsewhere. With Amazon becoming a cloud player, performance has become even more critical. It's not only Amazon that looses money, but also the folks who rely on their infrastructure.  


Linking and Sharing

del.icio.us:Gartner does not need to provide SLAs.  digg:Gartner does not need to provide SLAs.  fark:Gartner does not need to provide SLAs.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/23/gartner-does-not-need-to-provide-slas/trackback/

August 19, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Weakest link in software development ?

Filed under: Software Services, Project Management, Program Management — Prakash Muralidharan @ 1:53 am

Abhijit writes about estimation as being the weakest link in software development. He says:

"Most of the times the people who estimate and people who develop are different, their skillsets are different, and most importantly the business needs and constraints change at a higher frequency. "

Estimation is surely a weak link. Often, sales guys try to sell the project through an estimate. From a management perspective, if you can get the three edges (scope, time, cost) of the 'golden' triangle to meet then you have a successful development project. What do you think is the weakest link ?

View Results


Linking and Sharing

del.icio.us:Weakest link in software development ?  digg:Weakest link in software development ?  fark:Weakest link in software development ?
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/19/weakest-link-in-software-development/trackback/

August 17, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Buy versus build.

Filed under: Software Services, Outsourcing — Prakash Muralidharan @ 2:01 pm

JP proposes the following mantra for buy versus build technology decisions (building something inhouse versus buying a commercial product:

"If the problem is generic use opensource
If the problem is specific to a market segment use commercial
If the problem is unique to your organisation use your own resources"

Buy versus build decisions are often complex with political ramifications.

If you make a build decision, you often need to decide on whether to outsource and if so, what to outsource. When it comes to outsourcing, I use the following broad pattern of thought:
-Think deeply about the role IT is playing in your business today, and where you see it going tommorrow.
-Look at your application portfolio and your people capabilities in relation to the role you see IT playing.
That will tell you where your crown jewels are and also point out your capability gaps.
-Use outsourcing to fill capability gaps in such a manner that your own people can polish your crown jewels.

Enough said for a Sunday afternoon!


Linking and Sharing

del.icio.us:Buy versus build.  digg:Buy versus build.  fark:Buy versus build.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/17/buy-versus-build/trackback/

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

The importance of being the first to give value

Filed under: Client Management, Account Management — Prakash Muralidharan @ 1:31 pm

Account management is all about relationships. You can deliver all you want, but if relationships are messed up, it's time to polish the resume- guaranteed. You will get big time escalations over little things. Well ? Did someone say that the little things are the big things when it comes to relationships ?

In some ways it is funny. Relationships, something essentially emotional, should play such an important part in selling something that is thought to be a product of logic. In any type of a complex sale, relationships play a key factor. In account management; it's everything.

OK. Relationships are everything. So how does one go about building them ? One of the keys to building lasting customer relationships is to be the first to give value and to keep giving value without expecting anything in return. Find out what matters to your customer and think of small, incremental and creative ways to deliver the same. Your delivery style should be open, friendly and engaging. Do this, and you are well on your way to building lasting relationships.


Linking and Sharing

del.icio.us:The importance of being the first to give value  digg:The importance of being the first to give value  fark:The importance of being the first to give value
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/08/17/the-importance-of-being-the-first-to-give-value/trackback/

Next Page »

Creative Commons LicenseDisclaimer : This blog site is published by and reflects the personal views of Prakash Muralidharan,in his individual capacity. It does not necessarily represent the views of any of his employers, past or present, and is not sponsored or endorsed by any of them. No representation is made about the accuracy of the information contained in this blog.