Counterpoint: Vendor Practices Critical to SOA Success

Loraine Lawson

Sometimes, it takes someone from a different hemisphere to see things differently.

SOA experts here and in the UK are pretty outraged if you mention vendor-specific SOA solutions. "What," they ask, "is the point of having an architecture that frees us from vendor lock-in if you're just going to let a vendor lock you into their version of SOA? SOA needs to be standards-based, not vendor based!"

"In fact," they add with a heavy dollop of condescension, "vendor SOA isn't even really SOA."

I'm not trying to mock. And I'm not saying they're wrong. In fact, I think those are all really good points. I've shared their views on this blog previously.

I'm just saying, they're really passionate about this position. In fact, they're so passionate and so persistent, you may get the impression there isn't another opinion.

That's why, when I saw an article titled "Anarchy hits free-wheeling SOA-land" published on Australian IT today, I had to bring it to your attention.

You see, this article presents a very different viewpoint. It suggests that the lack of standards among users is creating anarchy as services grow. And this anarchy is forcing specialist software companies -- particularly SaaS companies -- to align themselves with the "best practices" of vendors such as SAP, Oracle and -- yes -- Microsoft. I'm guessing that's going to strike a nerve, since some argue Microsoft can't even grasp the concept of SOA, much less serve as a standards model.

Someone forgot to tell these consultants from Australia, it seems.

Of course, to be fair, these aren't unbiased sources -- who is these days? For instance, the man advocating for alignment with vendor best practices is Peter Still, the global vice president of strategy at RuleBurst, an SAP partner.

It's important to note, however, that Still is not voting for vendor lock-in. As I read it, he believes that SOA, by its nature, will eliminate that, forcing small software companies to compete by "investing in specific expertise." As an example, he notes that U.S. tax law is different from Australian tax law - and the providences within the countries require further expertise.

This article offers a lot of interesting observations either I haven't seen or I seldom see. Unfortunately, it starts meandering about a third of the way through, so you may be tempted to abandon it before it ends. So, here are my favorite question-raising observations from the article:

  • One person is quoted as saying "the most profound difference SOA will make to the software industry" is to end upgrades as we know them. I suspect that's true, in terms of the massive ERP upgrades seen in the past, but I wonder whether it's possible we could see endless series of mini-upgrades as services are reused and developers find unanticipated problems that need to be fixed at the service level.
  • Rudolf Chati, a Unisys systems architect, argues that implementing an ESB requires people skills as well as technical skills. Specifically, he mentions that IT is called on to negotiate between different parts of the organization. Given the long history of IT's poor communication skills and inability to relate to business users, I can't help but wonder how IT is going to work as a negotiator between business divisions. Is that even a role IT wants to take on?
  • Chait also is quoted as relating an incident where his group plugged in a tool and then uncovered several bugs in a commercial software stack in England. The programmers had an interesting reaction to this: They opposed the use of the tool. Chait says this is because it exposed badly built and tested code, adding that "programmers have to know it's not for prosecuting them but for developer productivity." Granted, it's a bit childish for programmers to react that way - feeling picked on because someone points out a problem with their code - but could this be one of the reasons some in IT are a bit cold to the idea of SOA?
  • The article talks a lot about enterprise service buses, almost to the point you'd think you can buy an ESB and have an SOA. Don't fall for this. Check out what IBM and SOA consultant David Linthicum recently had to say about this misconception.
  • Sun Microsystems' head of software practice Rob Erskine raises an interesting future dilemma for services. Erskine points out that two services may both be called "weight" and look the same - but their calculations and purposes could be completely different if one uses net weight in pounds and the other is gross weight in kilograms. That's something you'll want to avoid.


Add Comment      Leave a comment on this blog post

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.