February 11, 2009 at 10:22 pm
Comments posted to this topic are about the item Low Hanging Fruit
Semper in excretia, suus solum profundum variat
February 12, 2009 at 6:48 am
I agree that these thought processes are an excellent way of considering our databases, but with experience often these ideas will always be just that. I have often had ideas within our organisation, for example the new user trigger which could create an AD account and scripts etc.
Our network guy reminded me of the redundancy and dependability of systems on other systems. If the database server goes offline for any specific period of time (which it rarely does of course!) how would these processes be executed without it? In the end I thought this was a completely useless argument to get involved in. He was partly right, but the amount of time processes like these would save our technicians and the network admin himself would surely account for any extra work which may be needed due to a system being down which is rarely offline for more than 5 minutes a year!
...this said, i'm completely in favour of DBAs to think like this, i think it's a great idea. As DBAs we see a lot of the business processes, but probably for most of us any adaptations to these processes are (as stated) out of our scope. Which is completely unfortunate and a great loss for the organisations we work for!
{/rant}
February 12, 2009 at 7:27 am
daniel.thompson (2/12/2009)
I agree that these thought processes are an excellent way of considering our databases, but with experience often these ideas will always be just that. I have often had ideas within our organisation, for example the new user trigger which could create an AD account and scripts etc.Our network guy reminded me of the redundancy and dependability of systems on other systems. If the database server goes offline for any specific period of time (which it rarely does of course!) how would these processes be executed without it? In the end I thought this was a completely useless argument to get involved in. He was partly right, but the amount of time processes like these would save our technicians and the network admin himself would surely account for any extra work which may be needed due to a system being down which is rarely offline for more than 5 minutes a year!
...this said, i'm completely in favour of DBAs to think like this, i think it's a great idea. As DBAs we see a lot of the business processes, but probably for most of us any adaptations to these processes are (as stated) out of our scope. Which is completely unfortunate and a great loss for the organisations we work for!
{/rant}
Daniel, my suggestion here would be to 1) document the time savings and therefore the monetary impact of the efficiency (it's always about the money) and 2) get the end users involved, and let them fight for the change on their end too.
Every day users sit at their PC and say "If only . . . who designed this thing anyway?", and if IT can work with the end user, and both sides can show how it will improve their efficiency, resulting in more business/better business, resulting in more impact to the bottom line, then change can be made.
Sometimes it's a long haul, and there's always the need to pick your battles, but even the futile exercise of arguing for a change that never happens can bring benefits in terms of networking within your organization, and allow end users to reach out to you in the future, as well as representing yourself to your management as someone who is concerned with process improvement.
My $0.02, anyway.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
February 12, 2009 at 7:37 am
It's not just that DBAs have to think of other solutions, but that the entire organization has to want to work to achieve such solutions as well.
As an example, I am one of 2 DBA/programmers at our bank, and every year we go to each department and talk about how they work and how we can help increase their productivity. Well, our commercial sales people requested a database of "soft" customer information -- so they could give a more personable face to the customer and also see potential sales opportunities.
We looked into it, and found that our core database already has the structures in place to record this information -- the information just had to be entered in. So we brought that to the table and got 2 responses:
1. The sales people (who had the information) didn't want to "waste" their time with data entry,
2. The back-end people (who do data entry) didn't want the sales people touching the core at all, and didn't have the extra time to do it themselves.
So while database-wise, this was the lowest-hanging fruit possible (i.e, a system that meets the requirements already up and fully integrated), people-wise, it was poison.
You also have situations where people are afraid of efficiency (i.e, they think the computers will take away their jobs.) While this is true for some basic data-entry-only positions, we take the approach that our job is to program the repetitive/mathematical tasks so humans can get on with the thinking and decision-making.
daniel.thompson (2/12/2009)
I agree that these thought processes are an excellent way of considering our databases, but with experience often these ideas will always be just that. I have often had ideas within our organisation, for example the new user trigger which could create an AD account and scripts etc.Our network guy reminded me of the redundancy and dependability of systems on other systems. If the database server goes offline for any specific period of time (which it rarely does of course!) how would these processes be executed without it? In the end I thought this was a completely useless argument to get involved in. He was partly right, but the amount of time processes like these would save our technicians and the network admin himself would surely account for any extra work which may be needed due to a system being down which is rarely offline for more than 5 minutes a year!
Daniel, this sounds like a very good argument for a backup database server. Perhaps a simple database mirroring setup?
February 12, 2009 at 8:00 am
Thanks jcrawf02, that is very good advice. I will be sure to do that. I try my best to work with the 'little people'. If i can fix the issues they have on a day-to-day basis i'm sure i can make the system better as a whole. Most users encounter the same bugs daily but don't say anything, so i have reached out to some of the users in my organisation, and they know they can email me directly if they have problems. Once i fix it for one person, it fixes it for 100s of users. Documenting these ideas I think is the way forward, you're absolutely right! Your post has inspired me a fair amount! Thanks!
jcrawf02 (2/12/2009)
Daniel, my suggestion here would be to 1) document the time savings and therefore the monetary impact of the efficiency (it's always about the money) and 2) get the end users involved, and let them fight for the change on their end too.
Every day users sit at their PC and say "If only . . . who designed this thing anyway?", and if IT can work with the end user, and both sides can show how it will improve their efficiency, resulting in more business/better business, resulting in more impact to the bottom line, then change can be made.
Sometimes it's a long haul, and there's always the need to pick your battles, but even the futile exercise of arguing for a change that never happens can bring benefits in terms of networking within your organization, and allow end users to reach out to you in the future, as well as representing yourself to your management as someone who is concerned with process improvement.
My $0.02, anyway.
February 12, 2009 at 8:03 am
Yes, you're absolutely right sknox. We're in the process of virtualising our data servers with a SAN (over iSCSI, not the expensive ones!) so we will be able to use 'thin' clients in a cluster as the power behind the one instance of the data on the SAN. Therefore if a DB dies, another one takes over using the same data. This was an idea thought up by the Network guy, which i was quite impressed by.
I guess it's all just give and take in the end...
sknox (2/12/2009)
It's not just that DBAs have to think of other solutions, but that the entire organization has to want to work to achieve such solutions as well.As an example, I am one of 2 DBA/programmers at our bank, and every year we go to each department and talk about how they work and how we can help increase their productivity. Well, our commercial sales people requested a database of "soft" customer information -- so they could give a more personable face to the customer and also see potential sales opportunities.
We looked into it, and found that our core database already has the structures in place to record this information -- the information just had to be entered in. So we brought that to the table and got 2 responses:
1. The sales people (who had the information) didn't want to "waste" their time with data entry,
2. The back-end people (who do data entry) didn't want the sales people touching the core at all, and didn't have the extra time to do it themselves.
So while database-wise, this was the lowest-hanging fruit possible (i.e, a system that meets the requirements already up and fully integrated), people-wise, it was poison.
You also have situations where people are afraid of efficiency (i.e, they think the computers will take away their jobs.) While this is true for some basic data-entry-only positions, we take the approach that our job is to program the repetitive/mathematical tasks so humans can get on with the thinking and decision-making.
February 12, 2009 at 8:53 am
daniel.thompson (2/12/2009)
Thanks jcrawf02, that is very good advice. I will be sure to do that. I try my best to work with the 'little people'. If i can fix the issues they have on a day-to-day basis i'm sure i can make the system better as a whole. Most users encounter the same bugs daily but don't say anything, so i have reached out to some of the users in my organisation, and they know they can email me directly if they have problems. Once i fix it for one person, it fixes it for 100s of users. Documenting these ideas I think is the way forward, you're absolutely right! Your post has inspired me a fair amount! Thanks!
I'm humbled by the thought that I have inspired you, and tempted to sign off for the day, so I don't ruin my high. 😀
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
February 12, 2009 at 9:16 am
Thanks for the responses so far.
@daniel-2, you're right that quite a few of the ideas we have may well often fall by the wayside. However, it costs nothing to have an idea, and only a minute or two to run it by someone, so even a small hit rate is still hugely cost effective.
@sknox, I agree. It's not just DBAs who need to think like this, but everyone in the organisation. The only reasons I focussed on DBAs were firstly that they and programmers provide most of the target audience here and secondly because the databases we deal with are often at the heart of a lot of important business processes. However, if I'm honest, the ideal should be that the whole culture associated with this kind of attitude is fostered right from the top of the management tree, and that would have put quite a different spin, I suspect, on the situation you described.
And @jcrawf02, I couldn't agree more. Talking with people gets you known, and once you're known people tell you incidental things. Sooner or later you start making connections between throw away comments from separate people and put them in touch with each other, and you get a reputation as someone who can get things done. Good for the company, good for the people you help and great for you.
Semper in excretia, suus solum profundum variat
February 12, 2009 at 11:58 am
I LOVED this article, both the general content and the specific examples.
I try to build these types of ideas into my applications all the time and have another example to share. One of the more successful strategies has been to automate inter-staff communications (where communication is the final purpose, *not* an e-mail to initiate some mundane task that could be handled automatically as discussed in the article). For example, suppose every time a user adds an "abuse referral" to our database, the client's worker needs to be kept informed. My application checks to see if the "reported victim" is a client and has a worker at all. If so, the database or front-end (it depends) automatically sends the e-mail containing the pertinent information.
This kind of feature does several GREAT things, including:
. 1) saves a great deal of time for the user who is suppose to initiate the communication, (even short e-mails take time to type out and the time on even short e-mails adds up over time)
. 2) improves moral because the user who initiates the communication is saved from having to do a tedious, mundane task. Also improves moral because users feel happy when they have software that actually helps them with their work,
. 3) greatly increases communication compliance and consistency since often these types of communications get forgotten accidentally,
. 4) provides a written record of the communication. In lieu of the auto-e-mail feature, staff instead are known to leave a quick voice message or post-it note or talk in the hallway.
Adding auto e-mails is easy for me as the developer/DBA. It is low-hanging fruit with great returns. Of course, when creating a new project, users do not often think to ask for such a feature. They don't think about how time-intensive and inefficient their current processes are. Thus, it is up to me to look for these opportunities and provide them. When I do, boy do our staff get happy!
I agree whole-heartedly that many small projects or features provide huge gains and should be actively looked for. Thanks for the article.
February 12, 2009 at 1:24 pm
Thanks for the kind comments, JJ B. Good example, too; it's exactly the kind of thing I was thinking about. A little bit of initiative to provide a benefit far outweighing the effort needed to implement.
Semper in excretia, suus solum profundum variat
February 15, 2009 at 7:51 am
Very short but very firm and strong articles. Very true words have been written in the article. We each of us can make a difference in our work place...
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply