Hard as it is to believe, some managers don't give a hoot about SOA

Hard as it is to believe, some managers don't give a hoot about SOA

Summary: Don't just hope for best practices -- act and measure


Go to any conference or read any white paper or any blog (including yours truly), and the message is clear: you need business buy-in to make SOA work. But suppose your management doesn't care or is oblivious, or just doesn't give a (fill in expletive) about SOA?  (I'm sure it happens occassionally here or there...)

Don't just hope for best practices -- act and measure

(Remember my theorem: those companies that could use SOA principles the most are the least likely to be implementing or supporting SOA.)

Loraine Lawson recently spoke to Dan Diephouse, chief software architect on the Mule Galaxy SOA governance platform and creator of Xfire, an open source SOAP framework, about this very issue.

Diephouse said that one of the mistakes SOA proponents make is "hoping for best practices," meaning an initiative is set into motion (or at least verbalized), but then managers don't check back or measure what took place. "Then they wonder why a year later, they didn’t manage to do this. Why didn’t this magically happen? Well, you didn’t really check and encourage people to do that and set some benchmark points along the way." It's not enough to set goals; it's important to put policies and metrics around SOA activities.

This measurement should also extend to the reuse of SOA-enabled services, he says.

So what happens if you are in an organization that doesn't support -- or even care -- about such efforts? Where your management may be say, less-than-forward thinking? Diephouse says many of these processes can be launched by SOA proponents under the radar, to help build such an effort from the ground up:

"You may not get the cross-project or cross-organizational funding that you’re looking for but you can still think about, okay, how can I enable reuse of this service? Maybe there are ways I can actually bring in another group. Even though there isn’t some top-down vision, I can say let’s collaborate on this and figure out funding. Let’s start thinking about how we can share schemas and gather requirements from other consumers. Let’s think about what the QA process of our service is going to be. What our end-to-end process is going to be from build to deployment to run time."

SOA often ends up being an initiative that springs from the network, versus any command-and-control scenario. As Diephouse also says, collaboration between groups is key.

"If you have six people or six services that use different schemas for the purchase order, you end up with this problem where you need to translate in between all of them and it’s a giant maintainability hassle. I think it is very important for people to come together and collaborate and say, 'Okay, who else is doing this type of thing? Can we share our requirements and come up with a shared definition for what a purchase order is across our organization?' The same thing at the service level - you don’t want to have all these different service definitions. You want to have a shared contract that is as universal as possible because it’s going to reduce maintenance for you. You aren’t going to have to maintain all of these different versions. You aren’t going to have to maintain all of these different services. You’re going to be able to create some shared funding and come up with a common service for everybody."

I have a feeling that the issues and approaches Diephouse talks about are very widespread, and probably more pervasive than enlightened enterprises that encourage and have embedded enterprise-wide innovation into their cultures. We've talked frequently at this blogsite about Guerilla SOA, making it work at the grassroots level and percolate upward. Ultimately, the end result of these efforts is to fuse them into a more holistic process, Diephouse points out. In some companies, executives may not be helping out that much, but teams can still collaborate to work these things through.

Topics: Software Development, Browser, Enterprise Software, Software

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
  • You can keep trying to squeeze...

    some type of positive spin on SOA and its benefit to business. But doing so only underscores your lack of a grasp on the reality of best business practices. This becomes even more appearent by your distancing SOA from ROI. Business is all about and only about positive return in resources invested. It is the ONLY way a business can prosper. There is no other way. Investments that fail to produce positive results are eliminated. For some reason you continue to act like investments in SOA are or should be immune to this most basic of business concepts. You really should find something else to blog about before the only thing you seem to have an interest in ends up where it belongs - a faint memory.
    • Measurement is the key

      Thanks for your comments. I am familiar with the challenge many organizations are having binding SOA to ROI; that's one of the most frequent topics I discuss at this blogsite.

      I have documented many SOA success stories on a site more targeted to that purpose, called "SOA in Action":

      Many of the successes documented to date with SOA have been around consolidation and streamlining of siloed systems. One of the clearest ROI cases seen is very simply, reduction of data entry requirements -- data is brought in from multiple back-end legacy systems through a composite application, versus querying and processing multiple systems and databases. The other is decreased development effort required once services are put into the catalog and made available to other parts of the enterprise. These are measurable and quantifiable.

      The challenge is driving SOA to the next level, which is so-called business agility and flexibility. The vendors and analysts keep talking about this wonderful nirvana, but few CIOs or SOA proponents I have spoken to acknowledge that they have comprehensive ways to effectively track and measure the metrics and impact of SOA on "agility," and tie that agility to corporate performance. They need measurable key performance indicators tied directly to SOA.

      Another point is that SOA often is an enabler that supports more visible initiatives, such as green IT or business intelligence. And perhaps SOA should be more of a behind-the-scenes enabler -- a company is not going to demand "SOA" alone to increase next year's revenues. Some enlightened organizations have a lot of forward-looking initiatives within their space; what is the contribution of SOA to these successes? These are issues or questions we'll continue to explore.
      • I guess time will tell.

        IT's ROI is hard to quantify. IT's biggest feat is in increasing efficiency. It will take some time before business and myself in particular will be convinced that SOA achieves this.
  • Why is it hard to believe?

    Managers are not trained to share. They are trained (implicitly) to build fiefdoms and prouduce the results that the bosses want to advance. Why would you expect anything else?

    If SOA isn't about sharing, what is it about?
    • Spot on!

      Couldn't agree more, Ron! The title of the post is actually meant to be tongue in cheek irony. But one of the greatest obstacles to successful SOA (and resulting ROI, as bjbrock says is lacking) is the political and organizational culture which resists streamlining approaches such as SOA. The organizations that could really use SOA are the ones not likely to be implementing it.
  • Executives don't even know what SOA is

    The technical knowledge of most people running companies has steadily declined in the past 5 - 7 years. I'm convinced even the ones that have heard of SOA, do not know what it does or what it can help. The marketing of SOA is all buzz words that mean nothing. Confusion reigns!!! I love it.
  • I put SOA and Consultants in the same category

    When I was running a publicly-held electronics
    manufacturing company, I found that all the consultants I
    tried didn't know enough about what we were doing to
    justify retaining their services. Since then my experiences
    as a customer of current larger businesses, particularly
    those in the Medical Care sector, indicates that many of
    them don't have a good enough handle on their internal
    processes and IT systems to function by themselves
    reliably without manual intervention from time to time.
    This a management problem, not an IT problem, that
    should be remedied before any kind of SOA "improvement"
    is attempted. Unfortunately, it still seems to be a very
    common problem with many businesses that the simplest
    kind of a manual system in the operation was not
    completely bug-free before some kind of an automated
    computer-based process was implemented. The taxicab
    franchise that my son drives for is a classic example of
    management not knowing how dispatching ought to work
    before the they bought a computer system to further
    confuse everyone. The result has not been fun for those
    attempting to best serve their customers.
  • RE: Hard as it is to believe, some managers don't give a hoot about SOA

    I think we overestimate the amount of "buy-in" needed for SOA style of architecture. Everyone doesn't have to understand it or get it. Just the key players. With the correct governance in place and the key architects buying in, SOA can be realized.

    Yes you have to have some management involvement but the big bang approach is not needed to make SOA successful. If fact I would argue it's more likely to fail with the big bang.

    • Who should buy in to SOA...

      There is even a line of thinking that suggests that maybe SOA only needs the support of IT developers or architects directly involved. But IT people alone can't force business transformation on the organization.