Thursday, July 16, 2009

Strategic Short-Cuts!

Thanks to my friend and fellow Architect, Naren for influencing me to write this blog post. I was so impressed with the concept that I felt I had to write this post.

Are you managing an IT shop that consistenly spends on Operate & Maintain Budget?
How much of your annual IT budget goes to 'sustain' your existing systems?
How much of it goes to 'extend' your existing landscape with new business capabilities?
If your spending is more inclined more towards 'sustain' mode, there are chances that you are carrying quite a lot of debts.

Yes, the subject of this blog post is about 'Technical Debts'. Here is a short article by Martin Fowler on Technical Debts. In this note, Martin defines Technical Debt as something that is accrued over quick and dirty ways of doing things.

In this note, as well as other articles that I read, Technical Debt is defined in the context of Application Development projects, where the Dev team is forced to pay the interest payments in the later phases of the release cycles. When I mention interest payments,it is the additional cost incurred in future development activities due to bad design/technical decisions that were made earlier in the cycle.

It was quite interesting to correlate this debt with Financial Debt! More than defining Technical Debts in a Project context, I was curious to understand how the idea is applicable in enterprise IT context, especially in the legacy application maintenance/support space. In typical IT spending, lions share of the budget goes for maintenance/support/operations and Technical Platform Refresh/Upgrade, etc. The question is - Does the lion's share goes to keep just the lights on? or extend those legacy apps with new capabilities?. Typically it goes for lights on operations and the organization depends largely on Heroes (be it people or IT Service Companies).If the company wants to get an insight on why the maintenance spending just stays flat on legacy apps or every single fix takes a huge amount of time, Its time to assess the Technical Debt that it carries. Once the company becomes aware of the Debt, it acquires the capability to manage it effectively.

The good thing that I liked about this idea is that it makes the bad decisions/short-cuts 'explicit' and 'quantifiable'. It is also an effective mechanism to communicate the risks to business/General management forum in non-technical language. I see a lot of relevance for this concept in the Architecture space, where I can defend the spending on Architecture/Design phase by stating the future costs on 'interest' payments.

In matured companies, you will not only report out how much of Technical Debts that you have created out of a project, You will also track and manage the Debt on a periodic basis. The companies can decide to payoff the debt once for all or pay it in increments, depending on the nature of the risk.

To thrive on this concept and make it actionable, the key pre-requisite that I see is the open culture. In a culture, where people will not get penalized for reporting the problems and there is an open atmosphere for discussing/debating the risks and mitigation options, those would be the places Technical Debts will fly.

Here is a plug-in from Codehaus for Technical Debt. The plug-in gives an indication on effort/cost required to reimburse the debt and the kind of debts detected in the code. (e.g. Code Duplication, Complexity, Violations)

Wednesday, July 01, 2009

Big Software Plans for Amazon Kindle?

In february 2009, I wrote about Amazon's kindle evolving into an application platform.

Looks like its becoming true. This Businessweek's article confirms my speculation.

Some of the possible directions that the article indicates:
- New applications that run on Amazon's kindle e-Book reader
- An Online App store like iPhone/BlackBerry application store
- Kindle evolving into a delivery channel for content. example - Blog Publishing
Amazon already provisions selected internet blogs thru the device
What else could be delivered to the device directly?
- Email applications/Web Browsing.

Once Amazon provisions an SDK for application development, I am sure there would be interesting possibilities!.

Digitize Your Wallet!

Citibank is introducing mobile based credit card payments in India. It is an integrated solution that Citibank is piloting along with other vendors such as Nokia (Handset provider), Vodafone (Telecom service provider), VivoTech (Technology provider) and Mastercard (Credit Card & Secure Payments Authority) and with selected merchants in the city.

Using this technology, the customers will be able to make contactless payments in the Point-of-Sale locations.

The customer downloads the credit card into the mobile application and protects the same with a password. When the customer makes a purchase in a retail store, he taps the mobile against a special reader device which performs the transaction. As I understand, a Java application installed on the mobile phone communicates with the card reader using Near-Field communications technology (elder brother of Bluetooth?) and communicates with the reader.

The reader & the application are from the technology company Vivotech. From technology perspective, Vivotech empowers the Bank to provision the credit card information securely to the mobile phone over the network provided by the Telecom Vendor. Vivotech also empowers the merchants with contactless readers.

It looks more convinient than pure-play mobile payments, where the mobile application sends an SMS or instructions to the bank directly to make payments. Here the idea looks more of digitizing your wallet and carrying it along the way. And there are no additional costs involved in data services consumption for payments as there is no need to send an SMS or connect to Internet.

The interesting perspective is that Citibank believes that it is not just a technology trial. But, a business model trail. Just imagine, if the mobile application can accept information from the card reader device at the merchant location - the possiblities are many - individualized discounts, gift vouchers/coupons download, personalized marketing. And all of these will result in additional revenue to the companies!.

We will have to wait and see how the technology picks momentum in Bangalore!.

I would be willing to sign-up but the catch is that I need to have a specific NFC-enabled Nokia handset.