Posts

Showing posts from November, 2014

Why Software Architecture Matters

I was reflecting on various software systems I had opportunities to work on in last 20 years, initially as a VC++ programmer, then as a project manager, and now as CEO of an offshore IT Services company, Harrier Information Systems. I feel, regardless of the technology, team, project manager or business domain, the single most important factor that separates a system that nobody uses from the one that nobody realizes exists while using it daily; is the software architecture of the system. We have delivered several software systems that customers use daily like Air without realizing those exist till they require an enhancement once in a while. We also had a couple of those that failed to ever go ‘live’. First, a few successes... We developed a custom ETL tool that processes millions of records every month, and it just works! There is a process automation system and another one for equity research that are working smoothly for years! Another web-based reporting tool h

Everywhere banking… Almost!

Banking is moving towards making ATMs almost like a branch where most of the basic banking transactions can be done using technology. This encourages banks to avoid opening branches in general, and particularly in rural areas where there is a huge less-literate population that is unable to use an ATM and requires someone to talk to for banking. I am wondering, when we can use ATM of any bank irrespective of where we have our account, how about allowing customers to use the branch of any bank irrespective of the bank where one has the account? Imagine the impact of this on inclusive banking in rural areas where bank branches are far and few in between. This may provide more reasons to have a bank account for huge rural population that avoids banking and prefers cash for lack of easy access to bank branches in smaller villages. This may also encourage banks for have more branches for opportunities to cross sell products, apart from additional revenue from potential service ch

To Respond, or to Wait? That's the question!

I like responding to emails immediately unless I am waiting for some information or am dependent on something for a decision. Some friends suggested I should wait for a few hours or a couple of days before replying to an email, as an indication of being busy to avoid being perceived as unoccupied or desperate. Having lived and worked in the US and India; and now working with clients in developed nations as well as in India, I see some marked work-cultural differences in perception about ones promptness. (With the risk of generalization) If you respond to emails immediately to someone in the US, it is 'generally' taken positively as a sign of your respect for the person and her/his time, your eagerness to work with the person or the project, and your professionalism (with 'auto-response' about potential delay in response). In India, immediate response may be seen as a sign of you being less occupied or being desperate to move ahead with a project or an orde

Customer Service benchmark

Here is a real customer service episode we had recently. I was in a meeting with a client when she told me that she will be traveling overseas next week and would like to show a demo of the web-based application we just developed for them. She was unsure about having Internet access while abroad and she could not carry a heavy laptop for health reasons. I carry a Sony Vaio Ultrabook (about 1 Kg. in weight) as a Windows based alternative to Macbook Air. I suggested we'll deploy the web-app on the ultrabook and she could demo it from 'localhost' without needing Internet access. We agreed on the solution and the deployment started. As soon as we deployed the app on the Ultrabook, Murphy made his first mark! We realized the charting library we used in the system only works when the user is connected to the Net. This is OK in most cases as user would typically access the system over the Web, but we were preparing for a 'standalone' scenario. Thankfully we