1 2 Previous Next 16 Replies Latest reply: Nov 16, 2012 12:44 PM by jgarry Go to original post RSS
      • 15. Re: Database walk-through - What to look for ??
        EdStevens
        Billy  Verreynne  wrote:
        SBhaumik_DBA wrote:

        As I said in my original post, I would kindly request you/all to imagine yourself in a situation wherein "you" have visited a client-site environment, and you are requested to "investigate" the platform as a DBA in whatsoever respect possible, and finally "_provide improvement suggestions_" to client.
        You do that by starting to ask questions to management. What are the real and perceived problems? What is the architecture? What are the policies ito security? Auditing? Vendor support and maintenance? What are the critical business requirements that the platform and database need to address? Etc.

        I would not start out by running "scripts" pretending to be an all-knowing Oracle database guru.

        I would start by applying fundamental software engineering principles. User requirements and expectations. Defining that and defining the real or perceived problems. Before doing anything else.
        Here, here!

        It seems to be more and more common that people want to approach these problems with some piece of automation, some set of scripts, some intelligent tool. But they ignore/don't realize/don't want to admit that a big aspect of being an analyst is to bring some real world intelligence to the job and do the hard work of actually asking difficult questions of humans, and doing some reflective thinking about those results. We see it in the typical help desk interaction, when the 'analyst' has his script and flow chart of questions and doesn't know how to deal with information that is not accounted for in his script.

        Ed's Rule One of Analysis and Design: Never overlook the human element.
        And the human element includes business line managers, end users, and maintenance programmers.
        • 16. Re: Database walk-through - What to look for ??
          jgarry
          Billy  Verreynne  wrote:
          SBhaumik_DBA wrote:

          As I said in my original post, I would kindly request you/all to imagine yourself in a situation wherein "you" have visited a client-site environment, and you are requested to "investigate" the platform as a DBA in whatsoever respect possible, and finally "_provide improvement suggestions_" to client.
          You do that by starting to ask questions to management. What are the real and perceived problems? What is the architecture? What are the policies ito security? Auditing? Vendor support and maintenance? What are the critical business requirements that the platform and database need to address? Etc.
          +1 to this. When I used to do stuff like this, I would often find quite a disparity between what management called me in for (normally some specific issue), what management shows me when I get there (at his point I would have a poker face, silently collecting data points), and what the users say is wrong (which of course would be very strange ideas, but additional data points). People are happy to informatively complain if they think something will finally get fixed.

          >
          I would not start out by running "scripts" pretending to be an all-knowing Oracle database guru.
          I wouldn't pretend to be an all-knowing guru, but this would be the excuse to gather configuration and some operational data. Usually grumpy IS managers would be happy to have someone poking about by this point, if you can show one key improvement. Some back-and-forth about "you are doing this, most places would do that..." would give additional data points. Putting all this information together with a plan to fix the original problem plus some observations about other problems noted in passing would often lead to actually being able to fix a lot of problems, sometimes with "you can do that! Wow!" as a user reaction.

          >
          I would start by applying fundamental software engineering principles. User requirements and expectations. Defining that and defining the real or perceived problems. Before doing anything else.
          Expectation management is the key.
          1 2 Previous Next