Feeds

back to article Hey, IT department! Sick of vendor shaftings? Why not DO IT, yourself

Enterprise IT departments have been reduced to personal shoppers at best and checkout clerks at worst. You want extra lock-in on those chips, sir? I say this because IT departments just don’t make anything anymore. When was the last time you were required to actually make a new thing as part of an IT project? As the …

COMMENTS

This topic is closed for new posts.

Page:

Anonymous Coward

You actually have to have a large, competent, IT department to do it yourself. We used to do it and had loads of inhouse built applications, custom designed to our needs, that had much more functionality than others in the industry who bought in. They were getting a bit long in the tooth though and needed some investment in bringing them up to date.

Over the past 5+ years though, there has been a shift to buying things off the shelf, and a corresponding decimation of the IT departments, along with farming the remaining work out to India.

Our costs are up, and functionality is down, but it's a "Success!" by some strange definition of the word. And our remaining IT guys now no longer have any investment as they aren't working with stuff they created, to make it perfect, instead they are tweaking a few config options on something they see as inferior. If they see problems they can't fix them, they have to just raise it to the vendor and hope for the best...

26
0

It's not true everywhere - luckily for me

I'm the lone IT bod in a more-medium-than-small enterprise, and I am lucky enough to be able to build things that actually solve problems.

We've been hectoring one of our main IT suppliers to add a not-mission-critical-but-extremely-useful function into one of our systems for ages. Unfortunately they're a useless set of ballbags and they've never managed to get started on it. Bored of this delay, a few weeks ago I went on GitHub, found someone had already done exactly what was needed. The code was a bit mucky, so I contributed a little, fired it up in a VM and we're rolling it out next week.

I know that nearly finished code off GitHub isn't the same as building something from the ground up, but you do come across the thought of "how many times has this wheel been reinvented elsewhere?" and then you look on GitHub and it turns out they've got not just the wheel but another wheel and an axle between them. Hurrah for open source software and the internet for making it so easily accessible.

13
0
Silver badge

"Our costs are up, and functionality is down, but it's a "Success!" by some strange definition of the word"

The success part comes from the fact that the IT manager/director no longer has to take direct responsibility for any cock-ups. He can just wave the contract around a bit, point the finger at the vendor and head off to the golf course knowing he's done all he can and the board can't take him to task over it.

16
0
Anonymous Coward

Heading downhill one tax dollar at a time

"Our costs are up, and functionality is down, but it's a "Success!" by some strange definition of the word."

Such a pattern gets (regretfully) labeled as a "success!" because you are thinking like an IT guy and not like a [modern] CIO / CFO / CEO...where it's all about the MONEY.

An outsourced app, an outsourced consultation, an outsourced infrastructure designer, etc. becomes a capital improvement investment - in other words, deductible. The salaries paid to in-house IT specialists are...not. So to the CFO, who reports such information to the CEO who then proclaims policy to the CIO, reminds them all that any outsourced expenditures can be depreciated as a capital investment whilst doing business and therefore makes said outsourcing "good policy!".

We're all caught in the same trap which allowed big business to export call centers, construction contracts, IT development and just about all other job skills to 'somewhere else'. Our corporate tax codes, written oh-so-lovingly whilst the lobbyists are staring right over the shoulder of our legislators, allow this. The tax code can still be 'repaired' - "fixed" - by granting a "home benefit" for all capital expenditures when the money stays within the borders of the home country as locally-fulfilled contracts, but that would cause the foreign lobbyists to say "Unfair!" and would mean any headway into the process would have to start all over again.

TL;DR: In other words, as a worker, you're screwed. Welcome to the 21st Century, here's your spot of tea.

4
0
Anonymous Coward

Devolved Responsibility

By not making it yourself (which few CIO's and no CEO's understand) you can buy it from someone who buys you lunch and tells you how great you are. Added benefit: the decision maker doesn't have to let on that he doesn't actually understand IT or applications or application development or how to define business requirements and can devolve responsibility to the supplier if/when it goes wrong. Same argument for Outsourcing and Facilities Management. I know of a very large manufacturer who devolved responsibility for the recovery of their business critical 25 year old VAX system (essential to their production process) to an unproven 3rd party who would magic up failed HDDs, motherboards, processors, IO cards. "We have offloaded that responsibilty to a specialist provider and are therefore not running at risk" - Naive at best "Business-Intelligence" stoopid at worst. Meanwhile the (old) guys that had written and maintained that system were retiring / dying / leaving...

If you're a decision-maker with limited technical understanding, it is much easier to *trust* a 3rd party who can be blamed (they lied to me!!!) than be blamed for an in-house foul up (I made a bad decision!!)

As for success criteria - well thats easy - its a sucess if I say its a success, if I'm the decision-maker; who's to argue? Increased costs, lost functionality, decreased reliability can all be explained away.

3
0
Silver badge

Not sure where you work...

...but we have 50 devs "making" our own stuff, sometime we take a vendors products, and customise the hell out of it, or we start from the ground up. Yes we still buy a lot of the off the shelf stuff, but why invent the wheel?

The other issue, is when it's custom made, if the guy that wrote it buggers off, and there is little or know documentation, it leaves a whole load of shit behind....just look at the banks for a classic example of this.

5
1
Meh

Re: Not sure where you work...

In our large pharmaceutical company, the home-grown applications have been systematically replaced over the last 25 years by configuable standards, the residual home-grown applications will have disappeared in the next few years. When they go, the get replaced with some standard with reduced functionality, some were even sold to external IT specialists to turn them into "standards".

The driving force is the need for full, up-to-date documentation and control of changes.

The creative programmers who stayed either moved to the internet side, or became business analysts joining extracts (mostly in excel).

3
0
Silver badge

Re: Not sure where you work...

The other issue, is when it's custom made, if the guy that wrote it buggers off, and there is little or know documentation, it leaves a whole load of shit behind....just look at the banks for a classic example of this.

That's why you beat them about the head with the Big Book of SSADM before letting 'em near a compiler.

Okay, so you could probably pronounce it as "sadism", and probably compress the entire methodology down to "anal retentive attention to detail and documentation", but hey, if you want everything documented, you document everything. Before writing a bunch of undocumented code.

Or at least encourage them to use Doxygen and heavy use of remarks. Owt's better than nowt.

7
0
gv

Re: Not sure where you work...

SSADM? Michael A. Jackson would be turning in his grave if he were dead.

0
0
Silver badge

Re: Not sure where you work...

"Or at least encourage them to use Doxygen and heavy use of remarks. Owt's better than nowt."

Of course the downside of heavy use of in code comments whether doxygen style or not, is that yes they're great for the initial version, but then along come half a dozen maintenance coders who all modify the code, but not a single one of them change the comments. So 5 years later the comments are merely of archeological interest and don't match the code at all. So which is worse - no comments at all, or comments that are eventually useless or even misleading? I don't have an answer to that.

2
0
Silver badge

Re: Not sure where you work...

The other issue, is when it's custom made, if the guy that wrote it buggers off, and there is little or know documentation, it leaves a whole load of shit behind....just look at the banks for a classic example of this.

That's why you beat them about the head with the Big Book of SSADM before letting 'em near a compiler.

That's why they start taking months instead of days to deliver anything, and the CIO starts looking favorably at off-the-shelf again.

8
1
Silver badge

Re: alf a dozen maintenance coders

Why aren't your maintenance coders required to update the comments when they change the functionality?

6
0
Silver badge

Re: alf a dozen maintenance coders

>Why aren't your maintenance coders required to update the comments when they change the >functionality?

I've worked in over a dozen companies in my career , and not one mandated maintenance of code comments.

1
0
Anonymous Coward

Re: alf a dozen maintenance coders

I've worked in investment banks and they were all seriously winging it from minute to minute. Very poor quality code with nothing thought through and misleading comments (if there was any commenting).

I also worked at an asset management company which ensured that everything was documented, coding standards (including comments & history) were adhered to and procedures were followed for UAT and PROD releases (with sign-off & responsibility resting with a peer). They even had peer reviews of code and documentation. It was a huge shock to me after years of the cowboy approach while working at the banks, but it's made me a significantly better coder as a result.

6
0

Re: Not sure where you work...

"In our large pharmaceutical company, the home-grown applications have been systematically replaced over the last 25 years by configuable standards, the residual home-grown applications will have disappeared in the next few years. When they go, the get replaced with some standard with reduced functionality, some were even sold to external IT specialists to turn them into "standards"."

Same at the biopharm company I work at. 10 years ago there were hand built programs to do time off, expenses, data management. The company was split and my bit sold to a VC company and the majority of the IS people stayed with the old company. New software tools were no longer developed but at least the old ones were updated. The company was sold on a couple of years ago and all of the internal webpages have gone along with the perfectly functional software tools to be replaced by a fricken SAP "portal" and internet that seems to be dialup.

2
0

Re: Not sure where you work...

No comments please, appropriately named methods, variable and classes will do just nicely thank you.

0
5
Silver badge

Re: Not sure where you work...

That and automated test cases made by a separate team of test fiends wired to a "programmer, you are fired" light once a settable number of failures occur in the daily test run.

0
0
Anonymous Coward

Re: Not sure where you work...

I think the answer to that comes down to two things - management and code review.

I've worked in shops where code didn't get to touch a repository until it was reviewed by another engineer. Each engineer had checklists of what they were to check for in a code review, and any public methods without up to date doc-strings would have been things to flag up in a code review.

4
0
Bronze badge

Re: Not sure where you work...

SSADM? Surely you adhere to ITIL?

0
1

Re: alf a dozen maintenance coders

>Why aren't your maintenance coders required to update the comments when they change the functionality?

In my (albeit limited) experience, when working at a company with a small development team (often just me), the management tend to prefer immediate results over a properly documented and tested solution. When someone asks me to make a change I usually ask "do you want it done properly or do you want it done now?". No prizes for guessing which answer I get.

3
1

Re: Not sure where you work...

Having left (presumably a different but similarly managed) pharmaceutical company IT department a year ago, it is such a relief to not have to deal with the depressing nature of knowing how to make something work really well but being told to implement some closed-source "solution" from elsewhere.

I'm now working on the "internet side" (within the Drupal community) now and the feeling of collaboration and inspiration is fab. Looking back at what is happening where I left, I think I made one of the best decisions of my life...

0
0
Silver badge
Stop

Re: Steve Knox Re: Not sure where you work...

".....That's why they start taking months instead of days to deliver anything....." Lazy-arsed male bovine manure. If you code right from the word go (proper structure, syntax, etc., AND GOOD COMMENTING/DOCUMENTATION) then you will usually complete the project faster and more accurately. Only the WYSIWYG editor generation knock SSADM and similar techniques because they slept through the design modules on their CompSci degrees. Yes, managing coders is like herding cats, which is why you need experienced team leaders and project managers willing to tell them to start over if the coders try submitting anything a green graduate can't decipher from the comments and documentation. Edits, additions and re-use all are so much easier when you have whipped the cats into shape.

1
1
Silver badge
Facepalm

Re: Roland6 Re: Not sure where you work...

" SSADM? Surely you adhere to ITIL?" SSADM is how you make sure what you design is going to work - ITIL is what you use to bamboozle the board into paying for your design.

Actually, you can throw a large chunk of blame for the current COTS fad at ITIL. One of the things it allowed the board to do was understand risk, something business people really want to know about. I used to do a lot of risk assessments for companies, and I'd point out to them the biggest risk to their business operations wasn't servers failing or corruption of data, it was often that only one or two people in the company actually knew how the systems worked, and if they fell under a bus the company would be screwed. This drove a heightened increase for process and systems documentation (which we, as consultants, charged extra for) and "knowledge sharing" (guilty, we charged for helping them do that too), and produced an unfortunate side effect of "dumbing down" IT to remove the risk of relying on one or two gurus.

1
0
Anonymous Coward

Re: Not sure where you work...

@Lost all faith

The classic example of the banks is not a good one - those jobs were offshored to people who do not understand/care/have responsibility for what they do. The offshored teams churn every few months so even if you did a good technical handover initially, it is diluted in a matter of months as semi-competent guys leave for better money and do minimal handover (because they are no longer trusted to touch the IT and because they no longer care anyway because they're leaving).

I don't bank with any bank that offshores its IT any more (and neither should you) because they are a ticking bomb and the Business-Geniuses that made those decisions don't even have the wit to know it...

2
0
Bronze badge
Meh

Re: not one mandated maintenance of code comments

They were run by incompetents then.

2
0

So I'm not the only experiencing this?

I had a meeting with "the business" earlier this week. Several departments were there who had previously gone off and done their own thing but were now being hit by vendor lock-in, price rises, failure to stick to contracts... All the time we had been providing nuts and bolts IT services in house that kept chuggling along around 99% uptime.

The various business departments wanted to bring their IT needs back in house for IT to design, build and support. It was a very enjoyable meeting, means I'm going to be doing a lot more work soon but in this climate I was fist pumping all the way back to my desk.

12
0
Silver badge

Re: So I'm not the only experiencing this?

Just don't forget this...

"...what they didn’t do was give the finance department a thing to play with whilst they got the project off the ground."

2
0
Silver badge

once they are finished they zip back up the mouthpiece of their latex suit and climb back into the gimp box with (insert service provider's name here) on it.

You misspelled "Oracle's".

4
0
Anonymous Coward

The IT industry is like the maturing Industrial Revolution

At first everything was handmade, crafted by people who had learned their trade over many years. Gradually factories were built so that a product could be made by cheaper labour. Those factories were made possible by large bespoke machinery made specifically for that one job, but it needed people based at the factory who could maintain, fix and update the machines as required. Over time entrepreneurs started making standardised machinery to sell to the factories. This meant the factories no longer needed their own people to build and maintain the machines - they simply bought them in and paid for repairs or changes when needed. The next step in the process was for manufacturing to be pushed to other countries to reduce labour costs and this is where we find ourselves today - very few people able to build or fix machines and manufacturing was decimated.

This seems a direct parallel with the IT industry; At first a company wrote its own software using self taught people or people who deliberately wanted to get into that trade. But over time it became cheaper to buy standard tools for the job and the in-house IT departments dwindled away in favour of service management teams who managed contracts and project managers who managed system rollouts. Gradually the remaining high cost was salary and that meant that the remaining jobs flowed out to other countries who could provide it cheaper.

We are at the tail end of the IT revolution where there remains little knowledge or expertise in the larger companies, and increasingly in the smaller ones. But like manufacturing the only real option left is to specialise and own the IP even if the actual manufacturing is performed elsewhere.

Whether this is a good or bad thing is hard to say but we can learn a lot of lessons in IT from the decimation of the manufacturing industustry.

12
0
Anonymous Coward

Use experience

I was the IT lead in an educational service. Once we were able to get a local authority IT person to help us choose, modify or even build for us the stuff we needed. And we could also draw upon our contact in the IT team to help us select hardware to meet our needs, which I could source myself, and they'd set it up for us.

Then all of a sudden it became corporate. We had to use software packages that didn't quite fit our needs. The corporate IT people introduced all sorts of overcomplicated, big, expensive, often incomprehensible outsourced designs that didn't quite work and, in one example, relied on an obsolete version of IE to keep working.

Meanwhile we had to order our hardware through a nominated person who never seemed to be able to help us to select stuff, (I don't think he'd even heard of TCO let alone being able to match our usage profile), only used what was available through authorised suppliers, always took 5 times as long as we could have done it, even from the same suppliers- we had to join the queue- (if he did it at all) and ended up costing more to buy than I could have got it myself ( I tested this a few times) then added his costs on top.

And stuff we needed sorting out didn't happen unless everyone else in the council had identified the same need ( which was seldom the case).

If it wasn't for the fact that we hadf really good IT guys working with us on the day to day stuff we'd have opted out ( which we could have done).

4
0

This post has been deleted by its author

I wish our IT department would google stuff, generally I have to tell them exactly what I want by looking at their vendor's catalogue, then they charge me 10% more that that & I have to help them install & configure it. The idea of IT being able to actually help me do my job better seems frankly laughable from here...

2
1
Bronze badge

Erm ok

Do you have an inhouse department, sounds like an outsourced reseller

2
0
Anonymous Coward

I was dealing with an infrastructure team recently, using industry standard software packages.

In the aftermath I asked them 'did you google it (as you are trying to do a standard thing with the most prevalent tool that does this sort of thing)'.

The answer - we don't Google stuff, we have been doing this for years and we do things our way.

The top five developers in the IT organisation are consultants, and they are ten times faster, produce code with less bugs and far less technical debt.

The idea of moving development back in house is laughable - COTS all the way!

1
0
Silver badge

Don't blame the IT department. That was a management decision.

0
0

It could be as simple as a 4-point "charter"

Very elegantly written article: "Sharepoint has never been an answer to any question ever asked by a business person" :-)

The choice is too often reduced to a bipolar distinction between smooth commercial COTS and in-house development that is never documented, and has one socially dysfunctional developer as the only source of knowledge. It isn't that single-dimensional.

It seems reasonable that ALL commercial software vendors should: (1) provide source code available licenses to their customers; (2) use applicable open source software that clearly out-performs where development resources and adoption are concerned; (3) always choose an open standard over proprietary alternatives; and (4) create an API that expects the customer to add functionality (and makes it clear such derivative works belong to the customer).

Software vendors will find themselves at different levels of maturity when measured against these criteria, but that's fine.

Until IT buyers start asking for this from their suppliers, lock-in and frustration will be the norm.

5
1

Re: It could be as simple as a 4-point "charter"

With my vendors hat back on --- although I have built stuff along your suggested lines, there ain't no money in it. My problem has always been getting enough licence and support revenue in to keep a decent development team and a decent support team together. If I am a vendor with thousands (or millions!) of customers, it works, but if I am, say, a specialist supplier providing applications to local government (total market 433 or maybe less depending) then I am going to struggle.

If I am going to have to expose an API, then that will increase my support burden and cost.

Now the freetards on here will express no sympathy but consider this. There's no value to you in putting the vendor of your business critical application out of business.

But I agree there's no point in your vendor just taking the p**s either.

5
1

Horses for courses

The key word in there is 'competent' and that's the piece in short supply (no shorter supply now that 15 years ago but rarer as a proportion of the IT community). I started out working with first generation COTS packages and making them work, sometimes with a hammer. I've come to the view that modelling the business requirements and processes first is key, then slotting in reliable packages to do the 80% that's common and needs to just work and get supported and upgraded regularly leaving the remaining 20% of functional gaps to be filled by bespoke elements adding business benefit.

4
0

Lovely writing. The "possessed multi function device on the 8th floor"...

I'd especially advise not working on that one after hours; the lights will start flickering, and it won't go well for you.

0
0

10 years ago...

When I started doing this 10 years ago, it was expected that the in-house guys knew what they were doing. They build infrastructure, wrote code, did some development work.

Now though, it seems these basic skills of building say, a web server, or a mysql database, or a webpage with a bit of java on it to do something simple has disappeared from IT teams.

Everything is spoon fed to them by vendors. The IT teams go out into the market place, get bombarded with information about the particular task they want to achieve, and are then forced to choose one, based on no knowledge at all, just the scales of cost the individual vendors are pushing at them.

You wonder why places buy the cheapest, or the most functional (but not necessarily the most functioning) bit of software? You wonder why businesses are so confused they seem to buy the nearest bit of crap to what they want without thinking about the environment they need?

There is very little skill left in the IT sector now. If you're wondering where its gone, look at the smallest, sweat filled cupboard with no air-con or adequate ventilation at any vendors office. Thats the place where our best developers and system architects are. Stuck in pre-sales designing overly complex systems for generic solutions for people who don't understand what they are buying, or buying into.

7
0
Anonymous Coward

Re: 10 years ago...

Absolutely, you only have to look at the prices of the IT contracts signed by Government departments to see it. Want a new Intranet page? Thats £100,000 please. The problem is that people see these contracts as safe when in reality they can be just as, if not far more risky. It really annoys me when an Organisation like the NHS outsources absolutely everything, its not like they are too small to support a permanent Software team. At least where I work if I find a bug in one of the tools I am using I can either A: Fix said bug (although I admit as we grow I do this much less) or B: Walk over to the software team who will then be able to see the exact issue and resolve it quickly. Also as I have direct vision / control over the systems (in the main anyway) and don't have stuff hidden from me because it is not part of my contract I can generally fix or work around problems quickly. Much better than raising a "severity 1" case with Company A who will blame Company B until Company C hears and realises one of their services has crashed so restarting a service takes 8 hours instead of 10 minutes.

1
0

Smart kids in the UK are making better career decisions too

In the 90's kids in the UK who were good with computers were steered into IT jobs, today their equivalents view IT as just another skill set to help them in their chosen careers.

I don't think that it was so true in the USA, though my experience was limited to New York. There I met plenty of users with a very poor opinion of their IT dept's because they viewed them as second best.

2
0
Bronze badge

Re: Smart kids in the UK are making better career decisions too

This.

The careers teacher in the 90s sold me a pig in a poke.

I ran SimCity on their 386s, suddenly I was some sort of whizzkid.

Ended up with a BSc Comp Sci, was sold some sort of golden path, ended up in App. Support fixing other people's messes.

If I had to do it all over again - I wouldn't.

3
0
Bronze badge
Devil

Re: Smart kids in the UK are making better career decisions too

Yeah, most are actually avoiding a career in IT - now that's a smart move!

0
0
Silver badge

Re: Smart kids in the UK are making better career decisions too

Same here.

As I get more experience I get less pay and more trouble.

Yet the whole world would literally collapse tomorrow without IT.

What's wrong with this picture?

1
0

Re: Smart kids in the UK are making better career decisions too

That is a great point - I should have made that in the article! :-)

0
0
Silver badge

It's actually what many businesses do when they switch to Linux

Such switches usually aren't "out with the Windows box, in with the Linux one", but also switches from foreign IT products to self made ones.

One of the problems with doing things that way is that you need people who look at a problem and see the core of it. There's plenty of software developers who, when given a simple task will add layer upon layer of complexity.

There seems to be a correlation between such skills and people who prefer something unixoid as their operating system. One of the basics of the Unix philosophy is, in fact, the "Rule of Optimization" which states that you should build a prototype first.

http://catb.org/esr/writings/taoup/html/ch01s06.html#rule_of_optimization

In fact you typical unixoid environment comes with lots of useful tools for prototyping. Everything you can do on a tabulator can be done trivially with standard console tools in the time it takes to install even the simplest SQL server. It probably will be slow and buggy, but it's a prototype.

4
0
Bronze badge
Flame

DIY

Yes DIY basically explains the mess most IT departments are in and it's usually driven by the IT managers masturbating over the latest product to come out of Redmond. Why the fsck are these managers always going on about change management and adapting when they are the last bastards that want to change anything?

Thankfully, there are some good guys about that are willing to take the plunge and change the way they do things in the name of progress and lower TCO.

2
0
Anonymous Coward

Missing the competative advantage

Putting togther a decent IT dev team is not cheap or easy to maintain, so it should be used for competative avantage.

If your service or product is sold using the same software as all your competitors, where's the market differenitation. Why buy yours or stay with your company when you get the same vanilla online sales and service.

Companies that use their IT to build unquie customer service get to keep customers and poach their competitors, i've seen multi-million pound deals signed purely because our company could offer an BI service to our corporate clients that the other players didn't have.

4
0
Silver badge

Re: Missing the competative advantage

Actually it doesn't need to be expensive. Treat your IT dev team the right way. Give them decent amounts of money (actually give them what those bad IT guys get), but give them freedom.

Free them from clerical work. Get them an assistant who takes care about company bureaucracy. Give them a small "experimental" budget on which they can try out new technologies.

Then also identify the normal staff members who can program. Include them in technical decisions about your IT. Maybe they can act as a sort of interpreter between the needs of the department and the capabilities of IT.

2
0

Page:

This topic is closed for new posts.