April 21, 2017 at 10:28 pm
Comments posted to this topic are about the item It's all about Customer Service
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 22, 2017 at 7:04 am
Great post. I am going to generalise and say this is not just with DBAs but with IT in big companies. Look I get it sometimes business don't know what they want or are not able to articulate it well enough. I have seen IT departs become the stumbling block for anything new because they just could not be bothered. The rules are on their side. This is why so many business people resort to creating full blown applications in Excel.
April 22, 2017 at 4:15 pm
Mpumelelo - Saturday, April 22, 2017 7:04 AMGreat post. I am going to generalise and say this is not just with DBAs but with IT in big companies. Look I get it sometimes business don't know what they want or are not able to articulate it well enough. I have seen IT departs become the stumbling block for anything new because they just could not be bothered. The rules are on their side. This is why so many business people resort to creating full blown applications in Excel.
I fully got into SQL Server because the company policy was DB2 and an audit revealed 100+ SQL Server instances running on machines outside the Datacentre with no IT involvement. We never tried to check Access and Excel
April 23, 2017 at 11:41 pm
If the developers want to introduce the likes of MongoDB, someone will have to support and maintain it. We don't know MongoDB, but I would happy to put time into learning it and until I get up to speed on it (or unless someone is hired to support it), it will remain *unsupported* or, at best, not well supported.
If that is OK with management, then it is not my problem. It is somebody else's.
April 24, 2017 at 1:34 am
One company I worked for had its HQ overseas. There they hired consultants, who came up with ever more restrictive 'standards' which were not subject to peer review and which we were all expected to enforce without questioning. Then they brought in scripted installations which removed any leeway we had to relax those standards where it would be in the interests of the customers to do so.
That was one of the developments which led to me leaving that company after more than a decade. The standards were not always in the interests of the customers and I realised I was not prepared to defend what I believed to be indefensible.
April 24, 2017 at 2:27 am
If the developers want to introduce the likes of MongoDB, someone will have to support and maintain it. We don't know MongoDB, but I would happy to put time into learning it and until I get up to speed on it (or unless someone is hired to support it), it will remain *unsupported* or, at best, not well supported.
If that is OK with management, then it is not my problem. It is somebody else's.
This is one of those situations where both sides are a little correct and also a little wrong. The truth is somewhere in the middle. Backend staff don't have to face the business and tend to stick to the rules. Developers don't have to make sure things are running 24/7 so they come up with cowboy solutions that appear to work on their PC but will not scale. The solution off course is simple, we need to talk to each other. Easier said than done.
Philosophically, the inability of big organisations to move quickly leaves an opportunity for smaller more nimble organisations to fill in the gaps.
April 24, 2017 at 7:05 am
Sometimes, 'the book' gives you the right to say no. However, the fourth or fifth time you say no, aren't people going to start to bypass you? If I were a developer, I sure would.
I would never call down management on someone to get my way. However, I certainly WILL protest if the developers won't even listen to my reasons for why something should be done a certain way and not another way. I've had more than a few experiences where I've been called in to rescue a database that is in distress, only to find out that the whole problem could have been avoided if they had just taken five minutes to run the code by me. I want to keep things moving too, and part of that process is making sure the team doesn't implement something that is going to cause problems down the road.
I've often felt that developers should be required to do a regular "rotation" on the administrative / client support side of their applications so that they can see the real-world consequences of the design decisions they make. This would go a long way towards showing them that we usually don't say "no" to be difficult.
April 24, 2017 at 7:20 am
.. When developers ask about adopting MongoDB for certain applications, or for help setting up a CI process, is your stock answer to say "no", and to quote corporate policy at them? ..
DBAs don't get awarded for playing by the book (at least not in the better IT organizations). It's successful implementation of great ideas and consistently avoiding disaster that brings praise and reward. So, a DBA should never robotically say "No" but rather consider every proposal as a potential opportunity. Some of these ideas, like adopting MongoDB purely as a means of persisting session state for a web application, don't necessarily fall within the realm of the DBA anyhow. So, the response should be something like: "Sure, I have no objection to you guys spinning up a MongoDB database, and I'll back you up when you propose it to management, because it could potentially reduce the load on SQL Server. However, your development team will build, own, and maintain it.".
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
April 24, 2017 at 1:48 pm
WRT to the United situation, it was entirely United's fault. United failed to follow the law, which doesn't give them the right to remove passengers on a flight that isn't overbooked(and that flight was not actually overbooked), even if they need to get crew to a different location. Even if the flight was overbooked, United stopped offering compensation at a level below the legally required amounts for overbooking, simply because the gate agent didn't have the authority to offer more, and apparently didn't feel like bothering management for more authority for that specific flight. United called police to resolve a civil dispute. The passenger was not breaking any law by refusing to leave(according to multiple attorneys who have commented and made reference to the relevant laws). The police should have said "this is a civil dispute, work it out", and left.
In our environment, we say no when necessary, and refer whoever is asking to the relevant governance group that controls the purse strings for that sort of thing. Anyone who implements unauthorized applications is subject to termination. That's made clear to everyone. If a business case can be made for an app, it will be acquired, tested, and a support plan developed. In large organizations, you cannot allow rogue users to buy and implement whatever they choose. The pitfalls can be huge, especially when a user does something with "open source" software that has a license that makes everything done with the application open source, including the proprietary stuff. If more companies made their policies clear, there would be less conflict and more productivity.
April 25, 2017 at 1:20 pm
Great editorial.
Falling back on policy always feels like a cop out (whether at work, or when dealing with the customer service of other companies).
If you agree with the policy, then say so without relying on the policy. If you don't agree with the policy, then be more helpful than just saying no.
That said, I also understand that circumstances can be challenging. When you're blindsided by a situation you've never had to handle before, and when the pressure is on to make a decision quickly, I can see how individuals fall back on policy as a first line of defense. In some ways, that's what policy is there for - so you know what you're supposed to do when you don't have all the time in the world to make the best decision. Certainly, at work, I try not to surprise people if I know what I'm proposing is brand new and a change to how we've done things before.
Leonard
Madison, WI
April 25, 2017 at 7:36 pm
My policy is simple. Prove the ROI, maintainability, safety, security, and long term cost of ownership of the new method along with an explanation as to why it can't be done as easily with the tools already present and you're golden. If you can't do that, then don't bother asking because you've not done your homework.
If you've come up with a new method to use existing tools, then ROI and maintainability are pretty easy to prove with a Proof-of-Principle and if you can present the need and the new method, I'll help you prove it. Whatever you do, don't be like the idiot that wanted me to deploy a CLR that did a Modulo in SQL Server. 😉 And I'll tell you right up front, nothing in this world will make me accept centralized backup control. Every machine has to be autonomous in that area or I'm simply not going to let it happen and there will be no negotiation. Invent a different way to make autonomous code easier to deploy to new machines and I'm all ears.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 23, 2017 at 10:21 am
The customer is not always right, but the customer (whether internal or external) is the reason we are in business. Forgetting that is what causes things like the United incident to occur.
That doesn't mean I think I should always do what the customer says; it does mean that I treat the customer as a valuable person.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply