Rittman Mead Consulting » Professional

Getting back into focus

Peter Scott — Wed, 17 Oct 2007 17:59:34 +0000

I have been working with my previous company for more than a dozen years – over that time the name on the sign over the office entrance has changed many times, and is indeed about to change yet again but a lot of the people have remained constant.

My role, too, has also changed a few times, but all the while reflecting my involvement with databases and Oracle in particular; I have been a developer, database architect, data warehouse designer, service delivery manager, project manager, BI consultant, practice leader, Oracle partnership manager and a host of other titles that I either can’t or won’t recall.

But the time has come to refocus myself and to spend time doing the things that I want to, things that I want to do because I love doing them. First off, I move back to being a customer facing technologist. This in effect means becoming a technical mentor to my customers, talking about their difficulties with BI and data warehousing, suggesting solutions (which may mean education or training, or actually getting down to hands-on stuff)

I will write more on this next week as plans develop, but for now I can say that I am very excited about my new role.

Honest consulting

Peter Scott — Fri, 28 Apr 2006 22:35:25 +0000

On a follow-up to my last post Beth wrote: It's been my experience that clients appreciate honest (yet tactful) discussions with the techies when making their decisions. She is absolutely right. I can remember at least two occasions where customers specifically asked to have me on a project because of my honesty.

The first time was when I was doing some work for a government agency that needed to interconnect several databases spread across a wide area. We quickly worked out a secure and inexpensive way to do what they required. After that initial engagement I was invited to a high level meeting where I was introduced ‘this is Peter, he’s not like our IT people, if he says something can’t be done it’s because it’s not safe to do it’

A more recent time was when I was requested to work on an ERP implementation project for some people that I had worked for in the past. Now, you would know from you may have read here, I am not an OLTP person so was perhaps not the natural technical choice. However the customer wanted someone who would think and tell it like it is.

In both case I was working as a trusted advisor. You can’t do that without respect from the customer, both for your technical skills and your honesty.

Oh, and take a look at Beths’ blog. I’m not saying that because she has put up a link to my blog, nor because she used to work for the same company as me; they are both facts though, but because she writes well and has something interesting to say.

I must get out and write more

Peter Scott — Tue, 11 Apr 2006 20:23:00 +0000

I had my monthly session with my business mentor today. Within my division mentors (or as some might say, coaches) are chosen to offer differing perspectives on the world. My first mentor was our former director of outsourcing; on his retirement I moved to guidance of the head of our financial services group. True, my work crosses several markets; finance, retail, utilities, and, occasionally, government but in reality my finance work is miles apart from the banking solutions my mentor delivers. Having one-to-one access to a senior manager is an amazing way to spend a significant part of the day.

Part of the session we white-boarded a few short-term career goals for me to achieve and what he needed the company to do for me to succeed. The main upshot of this is more writing. I have been given the company’s permission to submit an abstract for UK OUG – I have two possible titles in mind; one on summary performance (risky for a non-DBA such as myself) and the other an introduction to analytic functions (even more risky if Tom Kyte is in the audience). Conferences are about sharing knowledge and not every paper has to be impossible to understand by the majority. If I’m accepted to present I get free time to write the paper! But I must not spend too long on it as I also have a whitepaper to research and write on BI. This should be a challenge as it is to be vendor neutral and business (not IT) focused. There is also a longer piece of writing bouncing around my head that may see the light of day later this year, but that’s another story.

Testing times

Peter Scott — Thu, 26 Jan 2006 20:12:00 +0000

As an organisation, my employers firmly believe in working to standards; we are ISO certified, all of the technical staff in our outsourcing group have a minimum of ITIL foundation level certification. Lots of our guys also have vendor certifications in the products they use in their day-to-day working lives (OK, we also make sure we have a good headcount of certified professionals so that we enhance our partner status with various vendors; and it impresses potential customers)
So, we are strong on process. This means that some things take a while to happen. We need to test and document the test, nothing happens on a production system without the electronic equivalent of piece of paper say that somebody is happy that the change does exactly what it should and the can be applied to the production system to resolve some issue or other. Or so the theory goes.
Recently we patched a customer’s Oracle 9.2 test database to the most recent patch-set, tested and found no problems, rolled it out to live and hit a bug with star transform, found a patch on Metalink, retested and patched. And then we found problem with our statistics collection routine taking 15 hours instead of two. This one is going through Oracle’s Service Request mechanism; my guys have a bit of work to do to capture trace data and prepare a test case for support; we can see what is going wrong, we just need to have the evidence so that the problem can be fixed. But for now we have put in a work-around to put enough stats in place for the on-line day.
Neither of these problems were seen on the test system; the first because we did not run that user query; the second did occur but on a far smaller test system (less than 1 TB) it was not obvious. So do we need to revise the way we test or accept that sometimes things can get through and have the mechanisms in place to deal with it – I think the later.

Meanwhile back with Tom Kyte

Peter Scott — Fri, 30 Sep 2005 20:49:00 +0000

Eddie Awad asks: How come no one has mentioned "testing"?! A very important part of developing an application (any application) is to test it again and again until the tests produce the desired results.
Of course Eddie is right, but sadly, like good design, adequate testing often takes a backseat role to getting the job done. Reduced rigour in testing is, however, not always a deliberate ploy by the developers to cut corners, it can be that they just don't know how to test.
I expect the coders that work for me can unit test their work and to keep proper records of their tests – I even let the ISO auditor loose on them just keep them on their toes. I expect their test plans to cover both the expected and exception cases. I also expect that these guys to handle the type of regression testing we put in at deployment time to ensure old bugs don't come back. But I do not expect them to design complex testing plans – that goes down to expert test managers. Here I'm lucky in that I use one of the best freelance test managers in Europe – I've known her for years (we were at school together) and she is one scary lady. She can make both coders and customers quake at the rigour of her test plans. But we pay her to make sure the tests are fit for purpose and she delivers. She is well worth the cost of flying her in from Switzerland for a few weeks or months.