The Ultimate Business Machine - Archives
List of Categories : Commentary * Database * Singapore * Technology * Travel *
Sun 06 Nov 2005
Doing IT right
Category : Commentary/ITtransformsIndustry.txt
I'd hate to tinge these pages with any hint of negativity, so instead of simply ranting about how inept corporate IT departments can be, maybe I owe it to the reader to describe an alternative vision as to how IT could be used to transform an entire industry.
I'm going to return to the example of the general insurance industry and see if I can describe how information technology can be made to work to the users' benefit, and explain that all in the users' own terms.
Bear with me, because I've not tried to lay this out in any coherent sense before, but I feel that if we can pin-point what has gone wrong with traditional MIS/IT manager mindset, maybe we can work towards improving its effectiveness.
So, here it goes. Imagine you're insuring a ship. The key idea is to make sure you're not putting too many eggs in one basket. For example, you could be insuring several freight forwarders, some of whom could be putting stuff on the same ship. Without a computerised database, it would be hard to keep track of all these. Because, in the physical world, once you've filed the policies in one order, say by freight forwarders or by the insured's name, you can't file them by ship. But with a relational database, you can store the data in one arbitrary physical order, and yet retrieve them in an almost infinite number of ways. And the best thing is that the computer "remembers" long after our mind has lost the battle to keep track of the details.
So, how has the system to be designed? First, once you've entered the period of insurance and the name of the ship, the system's got to pull out all the policies in effect across the same period, for the same ship, and accumulate those risks to see if it goes beyond a pre-set limit. A lot of factors come into play - the start and end dates of the policy, the quantity and nature of the items being insured, and the insurance cover being sought.
So, in terms of what is required at the user interface, there's a sort of dance where you change the dates of the insurance, tab out of the field, and you want immediate feedback as to whether that's still okay. Or you add new lines of items to be covered by the policy, etc, and you want to know if it's worth going ahead with the policy and what options you can take to re-insure the policy and spread out the risks.
There's a lot more of such details but what's fascinating here is the design of the database that will allow the user to get at the information, and the design of the user interface that will allow him to focus on the risks that's been taken and the wordings on the agreement - all these without even being aware that he's working on a computer.
So, you're thinking about data structures and user interface navigation. This - the desire to help the user focus on the meaning behind the data so that he can price the product to make a profit - provides the context around which you map the available technologies to pick the ones that will serve these needs.
That's why we'll look at relational databases, like Oracle and MySQL. The way we'll use the technology determines how we'll judge the relative merits of the competing vendor offerings. For example, for our purposes, MySQL offers almost everything that Oracle does except that Oracle offers "views" - automated support for the creation and optimisation of views, which are descriptions of what the data needs to look like to an end user, no matter how they're actually stored in the database. Since we use this so often in our design, Oracle has an edge, for the moment. But the important point is that we have a context to base our choice, rather than simply making an assertion that it has to be Oracle just because they're huge or to it has to be MySQL just because it's free.
Notice that we've spent a lot of time thinking about what the business needs and trying to map out the data structures. So why do IT managers waste no time in shouting out the slogans - "Windows, VB, .Net, or Java"?
Take Java, for instance. Java is just a programming language. The relevant question to ask is what follows next : what kind of application are we using Java to build - a browser-based application or a window-based client-server application?
If it's a browser-based application, you rapidly run into problems. Traditional web applications work by having a user submit a form to a web server, and if there is a data entry inconsistency or a transgression of the business rules, the server sends the whole page back to be refilled. So in our marine cargo example, it rapidly becomes unwieldy. With a window-based client-server application, you can trigger a check through all the business rules every time a user tabs out of one field onto the next. But with a browser-based application, you're plodding through one form after another.
And that creates another problem - session-management. Because a single business transaction occurs aross a series of form submissions, and many people could be transacting business at the same time, it's quite possible to mix up the sessions and get one person's data crossed over to another's. On top of that, you get concurrency and deadlock issues when more than one session accesses the same set of data - especially when users are quite likely to exit to a totally different site altogether in the middle of a transaction!
So, the point is : web browser-based applications could take at least four times longer to build than native, window-based, client-server applications, and when they do get built they're unwieldy, insecure and hard to maintain. So, you can hire any number of Java programmers off the street but you may not get your system built. That's what happened to the company we saw. Their Java development went nowhere even after two years. Their IT guys blamed it on their lack of domain knowledge about the insurance industry. That's about all they're willing for us to be hired. But they still insist that the development has to be in Java and I can only presume that their resumes will look good with them as Java programmers.
Java can be used to build client-server applications, using Swing as the Java equivalent of Cocoa. Now that we're comparing apples to Apples, it is possible to demonstrate that using Cocoa is many times more productive than using Swing, as the many Java programmers who took our Java-Cocoa courses will attest. But this is the corporation, and they've got to run Windows. 4th Dimension (4D) is cross-platform, will run on Windows, and is still significantly faster to develop for than using Java with Swing.
So, kick out Java and 4D. Just use Visual Basic. But here's one other consideration. What do you do when you have fifty users and you need to make frequent updates to the system? Do you go to every desktop and copy over a new version of the application each time or leave it to the users to mess things up? With 4D, there is a very neat feature where you only need to update the application server and all fifty users immediately get the latest version. That ought to count for something, I believe.
So I think the problem with Microsoft-centric IT managers is that they're secure in the domination of Microsoft, where might means right, that they've never bothered to train their minds to see the big picture, to focus on the near term as well as the long term, to see the business as it grows, and to imagine how the system will work as it scales. Somehow Microsoft will provide.
It's a waste because there's a more dynamic way of integrating the business for the end users so that the information flows like a well-designed waterway. I see fifty users and, while they have titles like underwriters, claims managers, marketeers and financial controllers, they're doing no better than a clerk's work pushing paper. You could make the system push the paper, or eliminate it altogether. Instead of sherperding deals through the system, the underwriters could concentrate on the nuances of an agreement. Instead of being data entry clerks, they should be developing a more legalistic mind. And claims managers could work like actuaries, using the patterns they find among the payments they're making to help the underwriters fine-tune the pricing of the products.
We've built a system that made the information flow like that - that can propel the users towards higher-value work - and I know that it can be done. But we've done that by being open to variety of influences, including Apple's, insofar as there's such a thing as style in information design.
A better world awaits and IT managers can help if they concentrate on acquiring domain knowledge and adding value, rather than acting as policemen and selfishly acquiring the means to reach higher paying jobs.
Now, how do we bring all these to bear? I don't know and it may to be too slow, our old way, changing the world one person at a time. But if one person reading this could see that it makes sense, and use these ideas to achieve a significant improvement in using IT in his or her own company, then this could be a start. Eventually we may all succeed in making a dent in the universe.