Sluggish economy may spur more, but smaller, SOA projects

Sluggish economy may spur more, but smaller, SOA projects

Summary: SOA doesn't have to be done exactly right the first time


Will 2008 be a year of retrenchment of our expectations of SOA, or will things really take off?

There's a debate as to whether a slow economy would help or hurt SOA. It's worth noting that the case for SOA, in tandem with Web services, was forged during the worst IT spending slump in a generation -- the 2000-2002 time period. Companies and IT professionals were attracted to the SOA/Web services concepts because they offered the attractive advantage of building or exposing existing applications at minimal cost and disruption. As the economy went into growth mode, SOA was increasingly pitched as a growth agent. If things slow down again, we may see SOA return to its roots -- the cost-savings/economies-of-scale mode of thinking.

Tony Baer, for one, says SOA expectations may be entering a bear market. He posits that economic sluggishness may temporarily turn off more grandiose visions of enterprise SOA and foster more of the incremental, low-expectation route:

"Recessions tend to discourage the kind of long-term thinking that grand enterprise architectural exercises are supposed to support. In that sense, SOA has been caught up in the middle – roughly six years after the current incarnation of the concept emerged with Web services, there remains considerable debate as to whether it makes sense to take a project or architectural approach."

Not that adoption of SOA itself will diminish anytime soon. In fact, a new survey out of Forrester Research (reported by Rich Seeley) finds more companies than ever are on the SOA bandwagon. As the study finds:

In 2005, the survey found 53 percent of enterprises were "using or planning to use SOA." By 2006, that number had grown to 62 percent, and in 2007 it reached 66 percent. More importantly for the theme of the latest survey, enterprises with an "enterprise level strategy and commitment to SOA" went from 18 percent in 2005, to 22 percent in 2006, and 26 percent in 2007.

What will happen in 2008 if companies feel a need to scale back spending? As Tony suggests, a sluggish economy may cause companies to be less willing to pony up funds for big-time SOA projects. In such an environment, the best route to SOA may be through lower-visibility service-oriented islands spawned through grassroots movements.

Actually, this realization has been building for some time. Even in the best of times, organizations need to see the ROI (or a reasonable facsimile thereof), and this is much easier to find on a project-by-project basis. 'Business agility' is a ghost of a goal that is almost impossible to benchmark and measure, but 'x hours of development time saved' is self-evident.

Tony reports on a conversation on this topic he just had with Progress Actional's Dan Foody, often a good source of wisdom of all things SOA. Dan said it's time to dispell "the notion that SOA had to be done exactly right, the first time.... The trap we got caught in was that you have to be perfect from day one,” he says.

In his own recent post, Dan recommends avoiding the terms 'agility' and 'reuse' when discussing SOA. Instead, focus on SOA's cost-savings abilities. "Consistency, avoiding duplication, and consolidation are all instrumental to managing costs. And SOA gives you these," he said.

Randy Heffner, the author of the Forrester study, feels that if IT budgets were to tighten, this may actually spur SOA development, for the same reasons:

"There are conditions under budget stress that actually encourage the use of SOA," he said. "For example, one benefit of SOA is that it extends the life of legacy applications. Say we were going to rewrite this application and spend $X millions, but we figured out we didn't have to because with a fourth of the money we could get where we needed to by SOA-enabling a legacy application."

Dan sees more movement toward an iterative approach as a result of a spending pinch, "which is to model only as much as you need to build services now while still providing freedom to act when circumstances change." Again, spot on. And isn't that what SOA is all about anyway?

Topics: Enterprise Software, Browser, Software, 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
  • Frontline VRT Windows or Bust Out with MySQL a la Web 2.0

    Accurately VPN has been changed to something new for the field. Web focus is a great long term coupler with online My SQL. As seen here on ZDNet.
  • So the economy does

    What years of focus on being profitable and productive failed to do.

    SoA can be profitable and productive, if it's implemented properly. Otherwise it's a giant money-sucking black hole that provides no value to your business bottom line.

    And it takes the economy tanking to make that apparent.

  • Message has been deleted.

  • SOA makes even more sense with open source

    If the economy is turning down, as most signals indicate, then free and open source tools to help build and run an SOA make more and more sense. Open source tools like XAware for data services, ActiveEndpoints for orchestration, Mule or ServiceMix for ESB, are quite mature (disclamier: I'm with the XAware data services project).

    Aside from saving money in a downturn, open source tools make even greater sense for "project level SOA", where a company can build an SOA in the small before committing to an expensive enterprise-level SOA.
  • RE: Sluggish economy may spur more, but smaller, SOA projects

    The term "build an SOA" still triggers my gag reflex.

    Why assume that "enterprise SOA" is expensive? Why assume that new tools are needed? Why would an architecture that follows service oriented principles care about a downturn? Why would following SO principles be something that is to be done only in good economic times? Is it a fair-weather architecutural style that is to be abandoned at the first hint of economic trouble?

    If open source tools can do the job, why only consider them in a down economy? Either they are a fit for the job or they are not--tight purses don't make them more of a fit and "settling" for one of them because you can't afford the "right" one would seem to be taking a path in the wrong direction.
    • RE: Sluggish economy may spur more, but smaller, SOA projects

      Good points and good questions, reamon! I think enterprise-level SOA is expensive in people costs as well as tooling. You've got to have governance (policy, design time, run-time), at a minimum an SOA Bouncer to keep the development groups in line, if you listen to Dave Linthicum. Other big costs may not be mandatory, but the platform vendors like IBM, BEA, and Oracle seem to be successful convincing large enterprises that they need a platform to do SOA. Vendor lock-in and large continuing costs are common in this scenario. Platforms aside, the companies I've worked with building and running an enterprise SOA have all spent a lot of money on tools to help manage their SOA.

      Of course, I believe that open source alternatives are completely viable alternatives regardless of economic conditions, but even more so when budgets tighten. Many companies will absolutely have to "settle" for less expensive tooling when budgets are tight. But the idea is to get 80% of the functionality for 20% or less of the cost. This is a compelling value proposition for many companies.
      • Enterprise level architecture costs don't change because of SOA

        "I think enterprise-level SOA is expensive in people costs as well as tooling."

        This assumes that enterprise level architecture (SO or otherwise) is new to the company. If so, then yes it is expensive but not because of SOA--it is because one is introducing architectural planning and activities. If EA is already in place, then taking an SO approach doesn't mean more costs. It simply refocuses efforts.

        Governance is not prerequisite to SOA any more than any other architectural style. If you didn't have policy, design time, run-time governance before, you may not need them now either. If you did have them before, they now take on an SO focus (which doesn't require tooling/re-tooling).

        One does need a platform to host solutions. Everyone typically already has one (more than one, usually). SO doesn't require new hardware and software. It is highly likely that existing facilities can be leveraged.

        My point isn't that new software and hardware isn't useful. Just that it isn't necessarily required. Did you do business architecture before? Awesome (and atypical!). View business components through a services lens. Did you do EA before? Great. Apply SO principles now. Did you do software development before? Cool. Now design components as services, decouple interface from implementation and cut the coders loose. Design and code reviews still exist (you were doing those before, right?) but now review things with an SO slant.

        If you didn't do BA, EA, AA, etc. before, doing them now will cost more than what was spent before--but this is due to introducing architecture not because you're "doing SOA."
        • Re: Enterprise level architecture costs don't change because of SOA

          Reamon, I see your point, and I do agree to a certain extent. If you're doing BA, EA, AA well already, you have most of the people and processes in place, and only need to refocus towards service orientation. That takes care of most of the people costs. Of course, we're talking about a company already "doing things right", probably not the average case.

          On the software side, I still maintain a company will need to bring in new software (much of this could be open source) focused on SOA. I say this both because I'm regularly exposed to companies building out an SOA, and I know what they are buying (outside of any influence from me), plus there are technologies that just make it easier to build and manage an SOA, including the tooling I mentioned earlier. It just makes sense to use the right tools if you're building out an SOA. My apologies if this "SOA building" talk makes you gag ;-)