Off the critical path

Off the critical path

Summary: It's obviously no fun to have to worry about having your IT job offshored or outsourced. But now you have something else to worry about: the possibility that you may be removed from the critical path.


It's obviously no fun to have to worry about having your IT job offshored or outsourced. But now you have something else to worry about: the possibility that you may be removed from the critical path.  That was sort of the suggestion in a email subject line I came across today. Actually, it read: "Removing IT from the Critical Path with Service Oriented Architectures." troll

It was for an upcoming webinar sponsored by Solcorp. (an EDS subsidiary) and Insurance and Technology Magazine. As the piece explained, "Flexibility, speed-to-market, process transparency and revenue growth are consistently identified as top priorities within the insurance industry, but many carriers still lack the capabilities to achieve these goals. They continue to be bogged down by disconnected and inefficient processes and systems limitations that not only impede effective and efficient product development, but also can impede regulatory compliance, sales/marketing initiatives and competitive analysis. In fact, often IT itself is an impediment to an improved product development process, due to siloed legacy systems and outdated methodologies. To perform in today's more intensely regulated and competitive financial services environment, insurers must be able to rapidly define new product characteristics with minimal time and expense -- which means overcoming traditional systems limitations."

There you go. That's one reason there is so much resistance and teeth-gnashing in the Talkback section of this blog. Who wants to be thought of as a mere impediment on the critical path to revenue growth?

Fortunately, this free, one hour webcast promises a way to escape these trolls, particularly the nasty ones who make life so very unpleasant for insurance companies. "[Y]ou will learn how adoption of a component-based architecture can help insurers shift from the traditional disconnected and inefficient approach to product development to a more integrated, collaborative and reliable strategy that can be deployed in increments to achieve immediate results. Hear how leading insurance companies that have committed to component architectures are gaining accelerated time to market (including pricing, calculations and testing), systems transparency, more effective project discipline, and improved collaboration and internal communications between business units and IT."

Check it out if you are interested in improving processes, increasing governance and introducing more flexibility.  Sit in on the event if you are interested in reducing cost, complexity and risk in the product development process. As for all you IT trolls, you have been warned. You come out from under that bridge again and you are dead.  

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Holy crap

    I don't think I've ever seen so many buzzwords crammed in so little space.
  • SOA - Snake Oil Anyone?

    The reason for resistance to SOA is that the methods it proposes will not work to solve these problems and have been shown not to work in the past.

    The SOA position seems to be that in addition to having large unintegrated systems you add literally hundreds of small additional systems (services). Presumably all these small additional systems integrate themselves by magic or is it actually the configuration management nightmare that it appears to be at first sight?

    The big software suppliers are all for keeping their software separated and only letting you in through "services" that they supply, presumably at additional cost.

    I confess I misunderstood SOA for a long time. I thought it was to do with being orientated towards providing service to customers. However it seems to be about implementing web services (whatever they might be, I can find no coherent definition). I am fairly clear that implementing web services will provide no service to customers whatsoever and indeed will probably make the situation worse than it is at present.
  • No reasonable arguement, here come the threats

    "You come out from under that bridge again and you are dead."

    I think the "trolls" have won the argument. SOA has only the threat of violence left to defend it. I didn't think there was an SOA mafia, but maybe it does exist.
  • What a load of tripe

    Can you say bamboozle?
  • What a great racket!

    Where can I get on this bandwagon? Find out what the industry's greatest fears are - and then promise to fix them all. I would LOVE to be there when companies start lobbing money at you out of sheer desperation. I hope you are smart enough to TAKE THE MONEY AND RUN! I hear Brazil has no extradition treaty with the USA . . .
    Roger Ramjet
    • I think I understand it now

      First all this talk about "insurance" ;-).

      Then the death threats.

      I am implementing web services now before I end up doing aerobics in the river wearing concrete leg warmers.

      Accidents can after all happen.
  • Technology was supposed to help, not hinder...

    Too often it just gets in the way.

    Words that need to be removed from the software lexicon:


    Things just need to work right. From the beginning. And solve problems, not create them. I can't tell you many times "programming" fixes one things and breaks about 30 others.

    Get out of my way.

    Talk amongst yourselves.
    • Great idea

      but you can never eliminate bugs completely (but that doesn't mean they the bug level can't be substantially reduced).

      I would agree that if software is of fundamentally good quality then there should be no need for patches (well only very occasionally and the supplier has to pay you if they have to release a patch).

      Updates are fine, provided they don't disrupt what you already have. The trouble is, as you say, usually they do.

      Any practical suggestions for how we achieve all of this?