John Brady's Weblog

Oracle and System Performance

All | General | Oracle | Performance
« Introduction & Hello | Main | Performance is like... »
20050630 Thursday June 30, 2005

Performance is like ...

I am a big believer in what I call "Proactive Performance Management". In other words, doing something about performance of an application on a computer system before it becomes a problem. By which point, of course, it is too late.

One of the problems I have is persuading people that this is something worth spending time, effort and money on today. Most people take the approach of "If it ain't broke, don't fix it", and so do not see the benefit of spending money on addressing a problem that doesn't yet exist. So I am always on the lookout for any good descriptions of the dangers of not addressing performance properly, and of the benefits when you do.

I also like analogies, as they stop us getting stuck in a set of specialised terminology related to computers. And a good analogy will get the point over, and show that the principle applies to other scenarios too. Which should increase the strength of the argument being put forward.

So, while reading Adrian Cockcroft's blog I came across a posting comparing fighting house fires to managing performance ( Playing with Fire ). And this made a lot of sense to me. No one would prefer to live in a building that was not well designed, and had taken the consequences of fire into account. Otherwise, you would end up spending a lot of of your time dealing with spontaneous fires. Given the choice most people would choose a well designed, safe building.

So why do we not design performance into the environments in which we deploy software applications? Why do we continue to presume that nothing needs to be done about performance, and end up spending significant amounts of time and effort "fighting fires" when some system or other starts behaving badly?

The analogy to avoiding fires brings out another point. You do not add performance or performance management in at the end, when the system has been built and deployed. Performance is not something you can just bolt on to an existing system. Just like you cannot bolt on fire safety to an inadequately designed building after it has been built. Good performance management needs to be designed in from the very start of the system.

( Jun 30 2005, 10:37:14 AM BST ) Permalink Comments [1]

Trackback URL: http://blogs.sun.com/johnbrady/entry/performance_is_like
Comments:

Hello John, having been in IT management and support side for many years could I observe that consumers and deliverers of information technology have a relationship that is driven by some (generally) unspoken forces. The obvious relationship is 'I want a reliable system that meets my needs', and 'I can build you a reliable system that meets your needs." Then things get interesting. Before I continue I'd better make it clear that I am an advocate of the 'computing people are always to blame' approach - on the basis that in 60,000 support calls I've looked at recently I could only pick out five or six where the system user was responsible for the fault. The next relationship is time and money. IT folk may underestimate time due to (a) inexperience generally or with the particular technology or business scenario (b) desire to 'get the job' (c) lack of clarity (that might not initially be apparent) in the system users specification. IT folk (particularly corporations) may make deliberate decisions to offer unrealistic build prices on the basis that maintenance contracts will 'make up the shortfall'. That is not to say that they will 'build in' errors, but their budget for build will only allow minimal quality control. On the consumer side, there is sometimes a perception that (a) it ought to be inexpensive because some staff member did something similar with a spreadsheet, or (b) it's not possible to check with anyone else whether they thought these IT contractors did a good job because they've been told that 'every job is unique', and (c) the people who want the solution are not 'trusted' by the people who control the funds (who have observed 'blow-outs' in IT projects in the past), , so they are given half of what they really need which guarantees that when the solution-seekers engage the IT contractor there will be a 'blow-out' (and everyone who has played a 'part' in the game is satisfied - particularly the budget controllers who believe that they have restrained costs and yet again proven how improvident purchasers if IT services really are). Money isn't exactly 'unspoken', but discussion on it are often 'left till last', or diverted to another channel in the organisation purchasing the service, dominated by Finance Budgetting folk who don't really understand the business needs of the area contracting the service, or the IT industry. Against the preference on the consumer side to squeeze on time and money is the consideration (gained after getting their fingers burnt) of 'pay more now, pay less later'. But, some organisations think that pay less now, pay more later is a 'fair deal', particularly where purchasing costs have to be 'justified' to Executive (or the shareholder), while maintenance costs are 'buried' deep in the budget and possibly come out of someone else's bucket. Against the squeeze on money and time on the IT contractor side is the consideration of 'reputation', and how much past performance influences future new or repeat business. A couple of things diminish this consideration, (a) the degree to which organisations 'collude' with the contractor for all the reasons that benefit the organisation (detailed above), (b) some IT contractors work on the basis that there's always enough new business to make repeat business 'expendable', and the new business is generally not well informed enought to 'check' previous work, and (c) the conviction in the mind of the IT contractor that all of the 'fault' in previous work was due to the organisation buying in their services - and a willingness to tell the next customer that this is the case (a message that goes down surprising well with customers when accompanied by an aside from the IT contractor, "but you're not like that, you are obviously a professional organisation.") Then there is another angle on reputation, on the purchasers side, and that is that IT projects are seen as 'forward looking' and 'cost saving' and are often sponsored by ambitious Executives who are 'going places'. Literally. By the time the true cost of the project has been revealed the Executive sponsor has received their bonus, the shareprice has risen, and the 'guilty parties' have moved on to bigger and better things; somehow (.. there are strategies) keeping a distance from the 'bad smell' of a IT project gone bad. Then we get on to a discussion about promises and expectations, how the IT contractor really believes that 'they can do the job better and faster than last time', and how the consumer is already convinced 'we don't understand the technology so we'd better just do whatever he/she says and trust them'. And particularly how the latter is reinforced in large organisations which have a 'punishment' culture. The thinking goes like this.. "If I question what's being proposed here I will either upset some powerful sponsor, or become responsible for it somehow, better just to 'let it happen' and keep my head down - if it's a success I'll have plenty of chance to claim credit for it (or get some 'left-overs' from my boss..), and if it's a failure I can say I was 'never involved'. If all that sounds cynical, I don't mean it to be. But to operate without some awareness of the 'other factors' is to operate with only (say)) 80% of the information. The advantage of putting that other 20% 'out in the open' (because I am not suggesting that most of us don't know it 'in our hearts') is that it opens up the possibility of a discussion about 'what to do about it'. If you were to ask me if there was a single (reasonably achievable) thing that would make the IT world 'better' I'd probably nominate 'creating an awareness amongst consumers of the value of checking with previous customers of any IT contractor to get a picture of their work, and to focus on purchasers about 12 months back (not recent ones). This opens up a question about 'uniqueness' of systems, reluctance of commercial organisations often in competing territory) to tell you that they've purchased a 'dud' (in fact they might like to tell you that their 'dud' is a great success (which maintains their 'face', while lumbering you with the same sort of handicap they are struggling with), and questions of defamation. So even the 'reasonably achievable' improvements are going to be hard work. But we are all optimists.

Posted by John McCann on October 23, 2005 at 12:45 AM BST #

Post a Comment:

Name:
E-Mail:
URL:

Your Comment:

HTML Syntax: NOT allowed

Calendar

RSS Feeds

Navigation

Links

Referers

Search

Recent Posts