March 12, 2012 at 10:15 am
Eugene Elutin (3/12/2012)
Elliott Whitlow (3/12/2012)
I have a question.. Why do they get to decide technology as a requirement?I used to deal with this sillyness in a previous job, until IT finally took the position that technology is OUR choice, the business gets to define what they need done but how we get from point A to point G is not open to a business requirement..
This is a case where I would push back and challenge the requirement. SSIS IS almost certainly the best tool for this job and a requirement to use something like linked servers shows a fundamental lack of understanding.
Short answer, no, we will use any tech that makes sense, this includes SSIS and we won't accept a requirement that says otherwise.
CEWII
I don't thing that the requirement went from business...
I think it was "advised" by OP manager or team-lead...
Also, depends who you call "business". If the requester is paying for technology, it's quite valid in some case for him to request some technical implementation - at the end you cannot base your solution simply on the fact that one tool is better than another. What about if the manager who request this stuff posses inside info that Microsoft is about to sell-in to Apple, so all MS related technology will disappear, therefore, he want everything to be runable of iPad :hehe:
If this came form my manager I would make every effort to dissuade him from the path..
I agree a little about the people paying, however I would take the approach that in 99.9% of the cases they lack sufficient information and knowledge to make such choices. And I would agree that the decision about whether one tool or another was better. But as an example if the business is saying buy Essbase but based on their needs and projected (and likely) future needs, SSAS fits the bill nicely we are going to push back, HARD and ask why exactly Essbase should be used. As it happens they had used Essbase before, a much older version and they were used to it, the fact that the licensing was like 5x SQL and we weren't getting much for that differential made the decision for us.
A specification about technology would typically be a suggestion, but would not be binding. If they felt the need for a particular technology it would have to be something like we need an iPhone app or an Android app, but exactly how that app WORKED would not be up to them. I would tend to cal these edge cases. What we would not accept: we need to get Oracle for this app we are building in-house.. As a primarily MS shop I would ask why (I've been in this situation before) and I would expect an answer along the lines of "we hear it is faster".. I had a case where at a former employer the business was starting to push a move from SQL to Oracle because the app was slow. The problem was the app was slow because they spec'd a severely under-powered machine and then did a poor job of design and index selection. They added a couple indexes and went from 4GB to 8GB of RAM and the thing really picked up. When I left they were talking about some re-writes of some problem areas in SQL..
We went to a model where the business did not get to decide toolset, they got to decide feature/functionality. They were not permitted to corcumvent IT as they had in the past, they couldn't go out and buy what they (thought) they wanted and then say please put this server in the NOC. This worked very well and projects were prioritzed and there were projects that didn't get done because in the scheme of things they weren't all that important. A good example of one I remember and was not surprised it didn't get done. It was a project that would have saved 1-2 people a total of up to 10 hours (total) a month, but it was going to take something like 200 hours to code it and test it. The ROI just didn't work when a 300 hour project would save 6 people about 1 hour each day. And even that project wasn't high on the list due to some REALLY big projects. It still got done but not for a month or two.
CEWII
March 12, 2012 at 10:32 am
Ok,
Product A. vs Product B.
Having: Product B cost as twice as Product A, require twice as many people and hours to achieve exactly same requirements
I can easily show that selection process is really based on a position:
Owner: less cost - more profit. Select Product A.
Senior Manager: Ask for kick-back and/or other non-material benefits, most likely Product B wins
Manager: I want more budget and more subordinates, looks like Product B again...
Perm. developer with skills in Product A: I want myself secured in a job: Product A
Perm. developer with skills in Product B: I want myself secured in a job: Product B
Consultant (honest one, no skills in Product A or B): It is simple. Product A (have you seen many consultants like me?)
Consultant (honest but realist, no skills as per above, but huge experience in live): Ask the managers what they want. Product B
3:4 Product A lost to Product B
:hehe:
March 15, 2012 at 10:01 pm
You could also use the Import export wizard to export data either to a flat file or excel sheet. This is a easier option for limited amount of data. SSIS is a more structured way to doing it. Other than that you could use BCP tool as the previous posts suggests
March 20, 2012 at 11:06 am
I'm with Elliott 100%. experts should speak on what they know. I do not know the business as well as the business people, so they should tell me what I need to know. Business people are not experts on tech, so they should leave it to tech people.
A well-run company will hire good people and let them do what they do best. Having an excellent bean counter decide technical direction is not going to result in a well-run company. Let him decide the feasibility, cost vs benefit of spending X to get Y which shoudl result in Z. but don't let him pick your database engine!
I have also been in the "business decides everything" arena and it is a nightmare. everyone ends up looking bad after piles of time and money are wasted.
All that said, use the tool that suits the problem. I have landed in hot water before by doing the right thing and I'm sure I will again. I do generally stay with a "so long as the task got done, it's nobody's business How" to keep from being accused of insubordination as many times as I should have been by now.
Now if you just want to challenge yourself by tying the top 2 tools behind your back, feel free. But if you don't speak up about how somethign should really be done, you're as guilty of bad decision making as they are.
I must cop to having done that as well, just to keep the peace and do the task and move on. Only you know which battles are worth taking on.
So, good luck!
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply