A good day today. I was privileged enough to be at the paper selection day for the UKOUG conference in December 2008. For those who don't know what happens, and perhaps suspect some sort of elite giving themselves presentation slots, here is roughly how it works. 

Firstly a reasonably large group of reviewers from around the world, though naturally UK biased,  score your abstract on a scale from 1 (very poor) to 6 (excellent). They also have an opportunity to comment. These scores are then collated and a small team review the scores and allocate presentations to available slots. The purpose of the 2nd review is twofold - first it allows the team to review the agenda for balance of both topics and target audience - this year for example you will be especially well-served if you are a relatively new dba - and secondly it allows for the moderation of some of the scores - where for example only a very few people have scored a particular abstract. Finally, because some presenters get consistently high scores (Jonathan Lewis being the obvious prime example)  then there is the opportunity to ensure that other, maybe lesser known, presenters also get a look-in as well.

So what did this mean this year, well we had 212 submissions for the Server Technology arena (apps dba submissions are separate). We needed to fill 64 slots. So that means we needed to eliminate 7 out of 10 submissions. The average score for  this stream was 4.5 (that's halfway between good and very good.)  and on average over 18 reviewers would have scored your submission. To get into the Top Quartile (more or less to be guaranteed a place) then you needed to score 4.93 (Very Good) on average. To restate - to stand a good chance of getting in, your abstract needed to show a group of nearly 20 Server Technology specialists that it was either very good or excellent. The bar to present at UKOUG is extremely high. Those who will be receiving congratulations communications should feel justly proud. Those who are planning to go, well you should be spoiled for choice. You can register your interest (and maybe win a laptop) here.  

Richard Foote updated his blog today with a description of the 3 step process for troubleshooting technical problems with business systems. Briefly his 3 steps are

1.  Identify an actual problem that needs addressing, one that’s problematic to the business, not one that only exists in some statistic or in one’s imagination
2.  Determine what’s actually causing the problem as identified in Step 1.
3.  Address the specific issue as identified in Step 2.

This started as a comment, but grew a bit. I suspect that most of the time the 'difficulty' lies in step 1. Identifying a problem that is causing drag on your employers business. This requires at least: 

1. understanding the business in the first place.
2. specifying to a high degree of certainty the issue.
3. quantifying the impact.

IT staff are notoriously bad at 1) and 3) and business staff are notoriously bad at 2) and 3). For example some colleagues of mine went to a meeting with business users of a core system that has historically suffered significant downtime. We identified and made some infrastructure changes that have reduced the downtime by approximately 40 days a year (that's right this system was running at circa 80% availability).  The system has been running in it's new configuration at over 99% availability, and helpdesk calls have all but vanished. The meeting was quite difficult since the business users wanted to complain about the stability of the system. In particular they were upset with the 99% availability statistics because they felt that the stats did not reflect reality, which was that occasionally data was 'lost' or application sessions were apparently hung. The fact that other users could continue to work did not mean that the service was available.

This illustrates particularly well my point 2, the technologists involved had understood a problem statement "the system is often unavailable" in terms of the uptime of the application - i.e Can I log on? The business users on the other hand interpreted the exact same statement as meaning "we often encounter unexpected errors when using the application". 

The ICT division at my employer has just announced a number of Job Vacancies including one in my team. You can read about all of the vacancies here. I am particularly looking for people from a SQL Server background (since we are taking on responsibility for that technology) with an exposure to, or looking for exposure to, Oracle technologies. The job ad for for the DBA position reads as follows

Our DBA/Developer team support the technology that underpins some of the council’s key business applications, including housing services, social care and internal finance, HR and procurement, across Oracle and MS SQL platforms. As well as supporting packaged ‘off the shelf’ solutions, you will also be responsible for developing and supporting some of the key integrations that enable us to deliver services that are genuinely joined-up and customer focused.

We are particularly looking to build the SQL Server skill set within this important team. You will need to demonstrate a comprehensive knowledge of SQL Server databases and the tools which are used to develop and support database technologies. You will have experience in using these skills to provide appropriate support, advice and guidance to business users as well as delivering solutions for complex business requirements

The closing date is March 17th.  You can apply online and see the full details here