There are certain commonsense rules that are frequently ignored or forgotten. Some of these are quite obvious in themselves, but get lost in the day-to-day noise. We will also look at common reasons that get bypassed, and why they should not be.
#1 The IT applications team needs to be focused on the users and not the application
They need to spend time with the users while they are doing their regular job and in querying them, and in listening to them. This requires that they understand the business fully and in the context of the business users? needs. This usually ends up on the backseat because technology work itself is quite demanding; and focus remains on keeping the systems up and running, and in keeping them so; add to it new work that keeps coming in. Users? availability poses another challenge. However, there is value in the argument that understanding the business (all the way to customers) will reduce the pains of technology maintenance.
#2 Focus on applications that are comprehensive in scope
For example, get or build a financials application that covers all the functions instead of picking separate applications for GL, Assets, etc. This reduces the number of applications in the system, and makes for easier support. In terms of business benefit, it makes integration easier, providing smoother workflow automation. This will mean sacrificing 10-20% of the desired functionality, which is normally the ?nice-to-have? zone. And the next rule will strengthen the argument for this rule. The lack of focus on this rule comes from users? pressures, whether about timelines or just plain preference for ?their own system?. This step is the first step in understanding business, and therefore critical.
#3 Stretch the functionality of these comprehensive applications
This is not to say, customize it; but get creative. As an example, almost all the activities of an Admin department can be provisioned by creative extension (not customization) of HR and finance applications. The reasons for this one getting ignored are the same as previous one. And the reason to remember this is also the same as previous one.
#4 Eliminate or minimize ad-hoc queries on production database
As obvious as this rule is, it is regularly flouted. In a vast majority of cases, such queries on last night?s data dump are sufficient. There are exceptions where the data has to be real-time; those can run on production database (an example would be lending collection that needs to be reviewed multiple times in a day). So it is worthwhile to create an offline reporting database. This rule is harder to implement because of pressure on users to get quick answers which gets transferred to the IT Team; and of course everyone?s work is ?critical?, and cannot be ?outdated?. The reason to remember this is obvious; it however does need a lot of education of the user group.
#5 Hot backup is needed in very specific cases; usually it is not worth the cost
In most cases, if a system crashes, one can restore previous night?s cold backup and apply logs. At worst, you have the system unavailable for a few hours, during which business can continue with pencil and paper. Hot backup for business continuity without a hiccup is required rarely, for example payment processing networks. Of course, the model of cold backup-based DRP works only if there is a sturdy backup and logging strategy; something that is much cheaper than a hot backup. This ?not always necessary? tool is implemented because of its coolness factor. But the time, effort and money required eventually take away quite a bit of this ?coolness?. And many IT teams stop in their tracks on this one because of budgetary constraints, and thank God for that!
The author managed large IT organizations for global players like MasterCard and Reliance, as well as lean IT organizations for startups, with experience in financial and retail technologies
Air Jordan 1