The Five Year Plan

  • David.Poole (6/13/2013)


    Anyone starting today would be shocked by what their predecessors had to to to fight with the early versions of MFC. The sheer amount of code that was necessary to produce a simple Windows form was shocking. Today its drag and drop, set a few properties and fill in the bit that actually delivers value to the business. Back then it was work out how to get windows to resize and redraw correctly, controls to respond to events.

    And I have lost count how many times I've had to essentially rebuild an Access DB for some department that went ahead and used the form wizards and macros to build their database. They only came to IT when it started so acting up and slowing down.

    Then you find there is no normalization and the auto-generated code is just a huge waste of time.



    ----------------
    Jim P.

    A little bit of this and a little byte of that can cause bloatware.

  • Jim P. (6/13/2013)


    David.Poole (6/13/2013)


    Anyone starting today would be shocked by what their predecessors had to to to fight with the early versions of MFC. The sheer amount of code that was necessary to produce a simple Windows form was shocking. Today its drag and drop, set a few properties and fill in the bit that actually delivers value to the business. Back then it was work out how to get windows to resize and redraw correctly, controls to respond to events.

    And I have lost count how many times I've had to essentially rebuild an Access DB for some department that went ahead and used the form wizards and macros to build their database. They only came to IT when it started so acting up and slowing down.

    Then you find there is no normalization and the auto-generated code is just a huge waste of time.

    But the answer should not be to take away the ability of the Business to create its own technical solutions (prevent them from creating MS Access databases) but rather to prevent them from creating mission critical solutions under the radar with no long-term plan to move them "into the fold".

    I think the point of this Editorial and the article from Infoworld is that the Business needs to get things done and sometimes their need for a solution does not fit into the traditional IT solution process. It realizes that each need fits on a continuum from "Slow but Sure" for IT to "Seat of the Pants" for non-IT.

    Sometimes it needs to be done NOW (create this report for the customer by tomorrow or lose the contract) and the scope and risk are such that a quick solution in MS Access is a good fit...for now.

    I don't think traditional IT will completely go away but the companies that do not embrace the issue of Shadow IT may find themselves out of business.

  • djackson 22568 (6/13/2013)


    We need to remember that these people get paid to make predictions, not to be right. Maybe one day the C-Suites of the world will recognize that these predictions are being made by idiots.

    Other predictions made in my life that were just as bad, if not worse:

    We will run out of oil by 1980 1990 2000 2010 2020

    Code generation tools will replace programmers by 1990 2000 2010 2020

    Amnesty will end illegal immigration

    Teaching (abstinence/sex ed) will put an end to teenage pregnancy

    Hope and change

    I will be rich by age 25

    OK, the last one is true, I did meet and marry my better half, and she makes me feel rich!

    Don't forget the ever popular Social Security will run out of cash by 1975 1976 1977 1978and every year since

  • Gary Varga (6/13/2013)


    David.Poole (6/13/2013)


    In short, IT will still exist in 5 years time, 25% will have gone, 50% will stay the same, 25% will be brand new and unimagined today.

    I know that I am being pedantic but surely one 25% is replacing the other so that totals to 75%.

    I get your point though and totally agree.

    Some of us will be retired/downsized or pursuing other opportunities:w00t:

  • scott mcnitt (6/13/2013)


    Jim P. (6/13/2013)


    David.Poole (6/13/2013)


    Anyone starting today would be shocked by what their predecessors had to to to fight with the early versions of MFC. The sheer amount of code that was necessary to produce a simple Windows form was shocking. Today its drag and drop, set a few properties and fill in the bit that actually delivers value to the business. Back then it was work out how to get windows to resize and redraw correctly, controls to respond to events.

    And I have lost count how many times I've had to essentially rebuild an Access DB for some department that went ahead and used the form wizards and macros to build their database. They only came to IT when it started so acting up and slowing down.

    Then you find there is no normalization and the auto-generated code is just a huge waste of time.

    But the answer should not be to take away the ability of the Business to create its own technical solutions (prevent them from creating MS Access databases) but rather to prevent them from creating mission critical solutions under the radar with no long-term plan to move them "into the fold".

    I think the point of this Editorial and the article from Infoworld is that the Business needs to get things done and sometimes their need for a solution does not fit into the traditional IT solution process. It realizes that each need fits on a continuum from "Slow but Sure" for IT to "Seat of the Pants" for non-IT.

    Sometimes it needs to be done NOW (create this report for the customer by tomorrow or lose the contract) and the scope and risk are such that a quick solution in MS Access is a good fit...for now.

    I don't think traditional IT will completely go away but the companies that do not embrace the issue of Shadow IT may find themselves out of business.

    Departments developing their own poor (technically) but useful (business-wise) solutions is the ultimate in agility and prototyping. I just wish that they would recognise to call in their IT departments when it starts to become a problem as opposed to waiting until it no longer is viable and need the replacement from the IT department immediately.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (6/14/2013)


    scott mcnitt (6/13/2013)


    Jim P. (6/13/2013)


    David.Poole (6/13/2013)


    Anyone starting today would be shocked by what their predecessors had to to to fight with the early versions of MFC. The sheer amount of code that was necessary to produce a simple Windows form was shocking. Today its drag and drop, set a few properties and fill in the bit that actually delivers value to the business. Back then it was work out how to get windows to resize and redraw correctly, controls to respond to events.

    And I have lost count how many times I've had to essentially rebuild an Access DB for some department that went ahead and used the form wizards and macros to build their database. They only came to IT when it started so acting up and slowing down.

    Then you find there is no normalization and the auto-generated code is just a huge waste of time.

    But the answer should not be to take away the ability of the Business to create its own technical solutions (prevent them from creating MS Access databases) but rather to prevent them from creating mission critical solutions under the radar with no long-term plan to move them "into the fold".

    I think the point of this Editorial and the article from Infoworld is that the Business needs to get things done and sometimes their need for a solution does not fit into the traditional IT solution process. It realizes that each need fits on a continuum from "Slow but Sure" for IT to "Seat of the Pants" for non-IT.

    Sometimes it needs to be done NOW (create this report for the customer by tomorrow or lose the contract) and the scope and risk are such that a quick solution in MS Access is a good fit...for now.

    I don't think traditional IT will completely go away but the companies that do not embrace the issue of Shadow IT may find themselves out of business.

    Departments developing their own poor (technically) but useful (business-wise) solutions is the ultimate in agility and prototyping. I just wish that they would recognise to call in their IT departments when it starts to become a problem as opposed to waiting until it no longer is viable and need the replacement from the IT department immediately.

    And thus give rise to the fitting moniker Shadow IT.

    The IT departments that do not exist in 5 years may be at companies that go out of business because the entire Business relied on one undocumented Excel macro and nobody has the source code.

    Ban all Excel macros and Access databases you say? You later find that the Business has requested a "report" that dumps all the data for two tables which then became the input to a cloud app that supports your biggest customer.

    To empathise with the Business folks, think of Harry Tuttle from Brazil. Getting centralized IT to help you with your technology solution makes you want to "go rougue".

    http://www.youtube.com/watch?v=dht_3NziwSw

  • The other extreme is everyone get's the same increase year after year. Eventually, even the best work ethic will crumble or the hardest workers will move on. Breeding ground for mediocrity.

  • This is definitely happening to my department. Partly by a shift to outsourcing and largely due to the slow response times that we have come to be known for. (No fault of mine of course!). So I see it as a spreading out of the skills of IT into a variety of sources. My managers seem to believe that they will be able to sit back and just direct all this activity.

    I'm not opposed to this direction, but there are wrong ways to go about it. Mainly, as mentioned above, is for what we now call "users" to start believing that because they can drag a dropdownlist onto web page designer, they are programmers. I see this happening now, and it is no different from 20 years ago when I saw so-called analysts drawing pictures and pontificating about how great their system was going to be, while they were actually wasting time on the front end.

    I wish I could spend my life in the design phase too, but we all know the project gets finished at 2AM before the release date, then time that could have been better spent with prototypes and good data design is spent in maintenance. I have no solution for this, but if it means getting rid of some layers of managers, that is something that might work at my place.

  • I should be retired by then.

  • In the environment where I work, which is food manufacturing, I agree with Steve, IT departments will not go away anytime soon. We have struggled for years with "engineers" on the manufacturing side of the business going rogue and taking the initiative to either buy a bunch of hardware and software, or build their own solution, to solve some issue. Unfortunately their lack of IT skills means that they don't ask the right questions (you don't know what you don't know), or they build a system that is not maintainable (the person who wrote it leaves and nobody understands what he/she did), and sooner or later the project lands up back in the hands of IT to sort out. These are usually questions about networking, system design & security, integration with existing systems (the vendor will always say they can integrate with anything) and how the system will be maintained.

    We have gotten better at having people invite IT to early discussions of projects, so these kinds of situations can be avoided. We do encourage prototyping by the people who are closest to the issue, because they understand the problem, but not necessarily the solution. Projects that work the best allow those who know the most to apply their knowledge in productive ways.

  • I love these predictions. This one has another 18 months until it can be put to bed. My Grandfather was looking forward to flying cars.

    The fundamental flaw in predicting the demise of a centralised IT department is that not everyone wants to program computers and of the one's that do, not everyone does it well. At some point people discover that a disciplined, coordinated approach to business functions is the most efficient and cost effective way to proceed.

    Not every department does its own accountancy even though computers have made it possible.

    I'm capable of doing leak free plumbing but I still pay a plumber to do it because I'd sooner spend my time doing other things.

  • Place me on the pile of doubters. I have yet to see a non-IT implementation so good that it could not have benefited from participation by someone with knowledge of all of the organization's moving parts. I have also seen plenty of implementers come crying back when they don't have the time, the training or the interest to fix their failing workflow. Finally, a plethora of outside vendors continue to convince departments that they can break the laws of project physics and somehow deliver faster + cheaper + better than internal IT. As more and more negative experiences pile up, the core of those who don't trust vendor promises also builds.

    While a more decentralized build process is something that easily could work, the amount that most positions are stretched thin makes for bad experiences with allowing development by a staff member who's "pretty good with Access".

  • I have seen plenty of change in IT within enterprises since this editorial was first published. Yet no shrinking in IT departments. Mostly the same people with some changing roles.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • roger.plowman - Thursday, June 13, 2013 7:13 AM

    Cloud is a security disaster.Look at the NSA mess. Any large company now has to worry about where their data is stored, which country will pass what secret espionage orders (and that's what the NSA is doing, let's call a spade a freaking shovel here).Problem is, the shift to cloud is a major undertaking. Encryption is only as good as the algorithm and you're expecting your data to remain secure over hundreds, perhaps thousands of miles of geography?Encryption will only be viable IF no formula is ever discovered to factor large prime numbers easily. The instant it is--poof. ALL encryption goes bye-bye. That day will come. The cloud won't be able to handle it. At least a local server can be physically protected. A data center?Bye-bye cloud. Pity you took civilization with you...

    Interesting take on encryption.  Since how to factor large prime numbers extremely rapidly has been common knowledge ever since prime numbers were first defined, well over 2000 years ago, you must think that no encryption does anything useful at all (a prime number is a number greater than 1 whose only factor greater than 1 is itself).  But in fact no encryption ever used has depended on inability to factor large prime numbers.

    Some modern encryption techniques do depend on inability to factor a large number which is not a square and has exactly two distinct factors other than 1, which by definition is not a prime number; if we find a quick way of doing that several asymmetric encryption algorithms will become effectively broken since it will be possible to compute the private key given the public key and vice versa.  Of course if neither key is disclosed that will do no harm but it does effectively destroy some very popular asymmetric key methods in their most common use.   But no symmetric encryption algorithm will be impacted at all.

    Tom

  • As is usual for predictions of the sort  referenced by the editoral, here we see nothing but wild and inaccurate prediction which gives no grounds at all for us to believe it.  IT departments will not disappear any time soon.   They will change radically, and probably get used to taking up more software that they didn't write themselves, but they won't disppear.  Accounts departments didn't disappear as a result of Lots 1-2-3, they survived the relese of Borland Quattro Pro, and they were not abolished because the CEO could do it himself with Excel.

    Tom

Viewing 15 posts - 16 through 30 (of 33 total)

You must be logged in to reply to this topic. Login to reply