In a post to his Infoworld weblog, Bridgewerx CEO David Linthicum suggests there's a huge difference between "the traditional enterprise architecture crowd" and those who assess the value of SOA. He recommends a company might be in need of a new Enterprise Architect if the answer to any of the following questions is "no":
- Has somebody compared the current architecture with best practices in you industry, looking to spot issues that need correcting, such as the architectures inability to align and keep us with the business?
- Has somebody done a ROI analysis of the value of SOA, or other approaches for that matter, for the current architecture and reported it to management?
- Do you have a complete service-, semantic-, and process-level understanding of your enterprise?
- Do you have a common abstract model for key elements, such as customers, sales, inventory, transactions, etc?
- Are systems well integrated and communicate in real time where needed?
- Can you change your architecture to accommodate business changes at the speed required by management and the marketplace?
Predictably, this has led to a large number of reactions, for example from XML guru Uche Ogbuji and Mark Nottingham. Mark, who used to chair the W3C's WS-Addressing working group while working for BEA and is now at Yahoo!, expressed his opinion as follows:
I think that most “enterprises” (whatever that means) do need a shake-up, and maybe some new blood. But not to buy into an ever-more-complex stack spoon-fed to them by the big vendors…
SOA consultant Richard Veryard disagrees all the blame can be put on the vendors:
I think David Linthicum raises some good points in his post, but I don't agree with his conclusion that you should fire enterprise architects who don't appreciate SOA. It is probably true that some enterprise architects don't deserve that job title - but it's not because they don't appreciate SOA but because they actually aren't very good enterprise architects in the first place.
Community comments
I always get a little scared when the phrase "best practices" is used
by Bruce Rennie,
Re: I always get a little scared when the phrase "best practices&a
by Eric Roch,
Re: I always get a little scared when the phrase "best practices&a
by Ozawa Hitoshi,
I always get a little scared when the phrase "best practices" is used
by Bruce Rennie,
Your message is awaiting moderation. Thank you for participating in the discussion.
I totally agree that every company should understand SOA and evaluate what it might mean to them. Where I get nervous, very nervous, is when someone implies that you are doing something wrong if you're not actually using SOA.
Sometimes I really wonder how we, as an industry, can actually talk about this sort of thing with a straight face. I mean, how many times in the past have we screamed "the sky is falling" whenever something new comes on the scene. Is it so difficult to face the idea that there might actually be companies out there who can still succeed with Cobol applications?
I dunno. It just seems to me that if you find yourself in a position where you actually believe technology alone is going to save you, you're already dead.
Re: I always get a little scared when the phrase "best practices&a
by Eric Roch,
Your message is awaiting moderation. Thank you for participating in the discussion.
I am a big proponent of SOA but this post is purposely inflammatory. No one can answer yes to all these questions and David knows it or should know it. My comments:
blogs.ittoolbox.com/eai/business/archives/fire-...
Re: I always get a little scared when the phrase "best practices&a
by Ozawa Hitoshi,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree that an enterprise architect should be doing an
ongoing analysis.
As any new technology, I also think SOA should be evaluated.
However, I've heard the phrase, "that's you're not doing
your job if you're not doing xxx" just too many times.
During the .com era we were all "suppose" to be doing the Internet. What happened to it now?
We should carefully evaluate it, but only implement it
iff it provides a real value to the business.