Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

Pure Play Maintenance Costs Consuming IT Budgets? 39

Posted by Cliff from the is-your-IT-budget-being-eaten-away dept.
ContractualObligatio asks: "The Register asks the question of whether businesses are at risk of having no budget to develop code, from maintaining too many 'pure play' applications. What has the experience been among Slashdot readers? Are people spending too much time maintaining code and integrations because the business is adopting too many applications? Do IT teams have the time and money to actually improve and innovate the way their companies do business?"
This discussion has been archived. No new comments can be posted.

Pure Play Maintenance Costs Consuming IT Budgets? More

Pure Play Maintenance Costs Consuming IT Budgets?

Comments Filter:
  • Are you seriously asking if management has too many in-house applications to make more? I think that situation will pretty much take care of itself. If you never get anything new done, they'll KNOW. And they'll want to know why. And since you have a good reason, they'll know they either need more tech team, or they need to slim down their stuff.

    No, sorry, I think this is just 'slownewsday' stuff.
    • If such a thing does happen to a company, it's their own fault. If the software was written right the first time, they shouldn't have to mess with it again. Unlike an engine, software doesn't "wear out". You write it once, you write it well, and it works, and keeps working.

      • Re:Too much to do to get work done? What? (Score:4, Insightful)

        by afidel ( 530433 ) on Tuesday October 24, 2006 @08:39PM (#16570280)
        Only true if you can make an application design that can scale arbitrarily with the business and can meet all current and future business needs. Since that's impossible there will always be some level of maintenance and replacement of software systems. Then there's the hardware platform on which the application runs, and unless it's something basic like OS/360 nee Z/OS then you might have to redisign the app every so often to keep up with the changing OS platform. The goal of IT is to meet the businesses needs at the minimal cost necessary to maintain that position and meet ongoing business growth.
        • But even us zOS based devs have to deal with people who insist on putting the source management tools on CMS, or doing plenty of other stupid things that cause internal tools to fail to deliver business needs after a few years.

          Even worse for zOS is the complete luddism of most develeopers. DTL, PDSE, and FTP have been around for years, and still they code panels the hard way, compress PDS datasets weekly, and use IND$FILE to move data about.

          Grrrrr.

      • Re: (Score:3, Insightful)

        by eschasi ( 252157 )
        You write it once, you write it well, and it works, and keeps working.

        ...giggle...

        ...snort...

        hahahahahahahahHAHAHAHAHAHAHAHAHAHAHhahahahaha . . .

        Go on, pull the other one.

        OK, ok, I'll be serious for a second. What about:

        • OS patches that break things
        • new feature requests from users
        • new browsers that have to be accomodated
        • the code just being slapped together in the first place (yeah, I know you said you write it well. Given the circumstances under which most non-programming IT shops build apps, it

        • Re: (Score:1)

          by Gr8Apes ( 679165 )
          Here - have fun:
          1. Don't patch - if your system is working, why patch?
          2. New features in a well designed system are either minor enhancements or new modules
          3. browsers at this point (provided it's a web app) should maintain backwards compatibility
          4. "code being slapped together" - this is a contradiction to the initial stated case.
          5. If the interacting applications change - it should be their problem. If you doubt this, try to get someone like PaymenTech to change their app because you changed yours... It's not going to h

      • Re: (Score:1)

        by SurturZ ( 54334 )

        Unlike an engine, software doesn't "wear out". You write it once, you write it well, and it works, and keeps working.

        Let me take the opportunity to welcome you to planet Earth. Things work a bit different here.

        As a programmer that is still supporting MSDOS programs I "wrote well" in the early 90s, I feel I am entitled to comment.

        You've forgotten that things change. Business needs change. The third party apps you integrate with change. The programming languages change. Hell, even the operating system changes

      • what they are refering to in the article is "boxed" software. PHBs are always getting marketed the next "big thing" and swamping the budget and admin's time with disconnected "fashionable" programs that don't really get the work done. It's like how Microsoft advertizes how a few cheap MCSEs can buy Microsoft servers and make the "dinosaurs" go away with magic electronic access everywhere. What's not in the pitch is that it takes admins to glue all the pieces together in a MEANINGFUL way! in my own compa

  • pure play? (Score:5, Interesting)

    by tepples ( 727027 ) <tepples.gmail@com> on Tuesday October 24, 2006 @07:34PM (#16569424) Homepage Journal

    The article doesn't define "pure play" applications. Is this a common term of art in IT? Google shows "pure play" defined on investing sites as a firm that concentrates on one type of product.

    • I'm guessing that this means an application that does only one thing. Seemingly with a limited API or hooks to link it with other apps. From TFA:

      But in practice, the level to which any pure play application integrates with an infrastructure management suite can be a significant variable, and there is always the possibility that adding something like lifecycle management means adding yet more pure play applications to the maintenance list.

      So, kind of a limited version of the old *nix ethic. Do one thing, but

      • Yeah, so a search on Google yeilded this:

        Pure-Play Application Service Providers

        Market analysts created the term "pure-play" to designate those providers that focus solely on the real application services delivered to their customers online, and if possible, on a rental basic. Pure-play ASP's business models, marketing strategies, research, and operations focus mostly on business applications: value chain activities, data processing, or analyticals (see application taxonomy). In their purest form, the

        • Market analysts created the term "pure-play"

          Who let market analysts on slashdot? The quoted definition, while worth the attempt to find it, makes even less sense. I'm still trying to get my head around "application taxonomy." Someone obviously got a new thesaurus this week.

          • I'm still trying to get my head around "application taxonomy."

            Sounds awfully Web 1.0 to me!

            The only thing worse than this is some crappy quote from Tim O'Reilly (I think?) trying to define "Web 2.0":

            "Folksonomy, not taxonomy."

            WTF is that?

      • Didn't that used to be called "Silo" application, meaning it had its own data formats, build tools, language, etc, and sharing data with other apps was like pulling teeth? So instead of using capability from the system down the hall we'll just rewrite the parts we need in our own app.

      • Re: (Score:2)

        by elrous0 ( 869638 ) *
        It's an old journalistic principle that, unless you're addressing a very specific trade audience, you can't use jargon. And if you do use it, you must, at least, define it.

        -Eric

  • If businesses buy lots of applications, each of which narrowly applies to its own small niche, eventually the small expenditures use up the whole budget. While this was always possible, the existence of so many "web services" and other such things makes it easier than it used to be to do this. Oh, and if you spend *all* your money, you can't pay people to do things, and one of the things they could've been doing is coding.

    I think that's what it's saying.
  • The revolutionary new networking technology from Valve that will give dialup players LAN speeds.

    http://en.wikipedia.org/wiki/PowerPlay_(technology ) [wikipedia.org]

    I'm not surprised so many IT departments are having trouble implementing it - the bleeding edge technology is probably conflicting with their DMAs and compromising their cookies.
    • I assume your jesting, but while you're on the subject, let's be glad Valve gave up on the technology back in 2001:

      The ISPs are going to need to spend a fair amount of money to be compliant with PowerPlay. But how they get that back is up to them. Some will have a tiered service, and some will just try to recoup their investment through reduced customer churn and customer acquisition.

      That's the last thing we need - to give the ISPs another incentive to go after tiered services.

      Dan East
  • You could spend all your budget on hardware, leaving none for software. Or you could spend it all on software, or consultants, or staplers. So what? The number of ways to screw up your business is infinite. After reading the article, I do not feel any smarter.

    BTW, I thought it was called "best of breed", not "pure play".

  • "Pure play"? (Score:3, Funny)

    by illuminatedwax ( 537131 ) <stdrange@nOsPAm.alumni.uchicago.edu> on Tuesday October 24, 2006 @08:04PM (#16569854) Journal
    Yes, I would prefer to have "virtual work" or "hybrid play" in my IT office! See I can make up words too!
    • I think my CS degree in progress has already imparted me with the correct IT skills to be an excellent "virtual worker"

      while(time < fiveoclock)
      {
        something = new makesomething();
        assemblyline.push(something);
      }

      Job's done!

      • Re: (Score:3, Funny)

        by schematix ( 533634 ) *
        while(time < fiveoclock)

        Ahem. Not to be too anal about your code, but this would certainly cause some issues (most notably with disgruntled workers at the office at odd hours.) Perhaps you should add some additional logic such as (time > eightam), (time <> lunchtime), etc.
  • "OMG, I was thinking the other day: what if we spent the total petty cash budget on sugar? Would that leave enough money to buy the coffee needed to Synergise the Enterprise Customer Service Orientation Systems Matrix Method?"

    Wow, an inane hypothetical. How is this news for nerds?
    • Because it affects a good chunk of us at work. At least, from my experience, it does.

      I work at a pretty decent sized hedge fund. We have been growing since before I arrived, and continue to do so at what I feel is a fairly rapid pace. In order to seem "current" and keep up with the market, our trading desk has been expanding into unholy amounts of new investment strategies. Lots of fun OTC derivatives, energy markets, weather, pollution trading, etc.

      This is all well and good on the face of it, but i
  • We need to get the boss to spring for more bandwidth. I would have totally got the guy in the warthog with a headshot, but the NWN2 torrent is causing me to lag. Wait? It's not near month-end is it. Are they using the net to transfer those business files again? Sheesh!
  • My head hurts from the ambiguity and acronyms.
  • Let's not worry whether Service-Oriented Architecture is Service Hierarchies for Information Technology. Bring this down the the level of working developers, and you'll find a pretty old trend.

    It's not enough to know C++; you have to know ACE. It's not enough to know Ruby; you have to know Rails. It's not enough to know Java; you have to know Struts and Tapestry and Spring and Hibernate and JDO and POJOs and Tomcat and JBoss (or some other application server) and SOAP and REST and JMS and JNI and JNDI and .
    • How is this a bad thing though, if said components are written well? While well-written external components are often a gamble as to how well they integrate with existing systems, or how well they work, sufficiently stable and generic components can be leveraged to create systems in much less time than writing from the ground up. Isn't this what the last 20-30 years of the push towards software engineering has been emphasising - encapsulation, reuse and lack of rework?

      The one problem with this, as mentioned
    • developers are spending more time than ever learning third party components, and spending time on their care and feeding. (How much time did you spend last week futzing with Log4j configuration files?)

      Was it more or less time than I would have spent designing and developing my own Log4j work-alike?
  • I'm sure I could get four corners and a line out of that article, it's a just a little light on the bull for the full house though.

  • Oh yes (Score:4, Interesting)

    by mwvdlee ( 775178 ) on Wednesday October 25, 2006 @03:58AM (#16573706) Homepage
    As somebody who has worked on a multi-million dollar project that would bring in about $20,000 each year for a product that would be phased out in about 10 years and could have just as easily been replaced by a paper form... yes, too many "pure play" applications.

    • Re: (Score:1)

      by Gr8Apes ( 679165 )
      You gotta love those. I wonder how they're pitched?

      "See, I've got this idea to create this product that will guarantee delivery of your message to your intended deliveree using the internet by the mere click of a button and you'll see that confirmation of said delivery 'immediately'. It will cost $20M to produce and $2M/year on enhancements (maintenance), and it will be rock solid."

      Current costs of sending a memo to secretary? $20/year.
  • FTA:
    A simple observation was put to me recently by HP software pre-sales manager Dave Clarke


    A sales rep for a software company says rolling your own software is a bad idea. Big surprise.
  • We work for many of HPs Outsourced businesses in their datacentre teams (now Global Outsourcing). We see a number of the day to day failures and I can tell you right now that for the majority of the issues we have with software comes from our larger suppliers like SAP, Backup providers, and soft/hardware control issues for industial equipment like automated tape drives. While Dave Clarke might be correct in that Pure Play applications do incur significant costs in IT, a great deal of that is because many p

    • Re: (Score:2)

      by Asgard ( 60200 ) *
      How many of these 'pure-play' applications make rash assumptions about Apache configurations, system configuration, and directory structures? One reason virtulization came about was because so many applications cannot be trusted to play well with others on the same host.
  • I work for a medium sized non-technological global company in an Analyst Programmer/Systems Analyst position. At present we're re-doing the websites which should be completely re-written. Unfortunately we are sticking with this "polish the turd hard enough and you've got gold" philosophy.

    The problem is because IT development is seen as needless expense (besides the fact that it holds the company together). We are the "plumbers" of the company, just fixing the "internets tubes" and computers which "dump st

Slashdot Top Deals

No man is an island if he's on at least one mailing list.

Close