SOA is a Means - Not an End in Itself
Here's a news flash for you: SOA is sometimes oversold. Hard to believe, I know, but it's true.
Now, I'm personally a big fan of Service-Oriented Architecture. It can - and has - delivered tangible, positive results for numerous organizations. The problem is that it's often overhyped. This is not unusual for a relatively new technology as it makes its way into the mainstream. Amidst all the bluster and pumped-up promises, keep one very important thing in mind: SOA is a means to and end, not an end in itself.
How many times has an organization failed in an attempt to harness the benefits of an emerging technology because the technology itself became the focus of its efforts, rather than the enablement of important business initiatives by way of the new technology? I don't know, but I suspect that (borrowing a line from the movie "Top Gun") "the list is long and distinguished" (which is to day, this is a trap into which even the best and the brightest can fall). People who lead the way to these IT train wrecks might sing a siren song with an appealing refrain: "The technology will solve our problems." Though I hate to be a burster of bubbles, I'll tell it to you straight: NO, IT WON'T.
In talking about SOA, plenty of people like to mention that it will improve an organization's agility (i.e., the ability of the organization to quickly develop new application functionality in response to marketplace changes). This assertion really isn't true because it's missing an important word: help, as in, "SOA can HELP to improve an organization's agility." You can see why this is so, right? I mean, sure, aspects of an SOA such as code modularization, abstraction of application implementation details, and the use of standard interfaces do ENABLE greater agility, but if the enterprise is going to be more agile then the BUSINESS side of the business is going to have to do its job: it's going to have to recognize new marketplace threats and opportunities and devise effective strategies to deal with them. No mere application architecture is going to do that. When a change in the organization's environment has been identified and an associated strategy has been devised, new application functionality needed to execute the strategy can probably be developed in less time if the organization utilizes service-oriented architecture.
It's like owning an exercise bicycle. The bicycle won't reduce your weight unless you ride it. The bicycle can HELP you to lose weight, and in that sense it's a good thing. You just need to do your part to make the purchase of the bike worthwhile.
Look, you can't let yourself be intimidated by technology. It is a tool of the modern enterprise, and the sooner you start thinking of it as such, the sooner you can get IT to work for YOU, as opposed to vice versa.
I could go on and on, and in fact I will, on May 18. That's the day on which I'll be teaching a full-day seminar, "SOA in the Real DB2 World," at the 2008 North American Conference of the International DB2 Users Group (IDUG) in Dallas, Texas. If you register for the conference, I hope that you'll register for my seminar. It would be great to see you in "Big D."
Now, I'm personally a big fan of Service-Oriented Architecture. It can - and has - delivered tangible, positive results for numerous organizations. The problem is that it's often overhyped. This is not unusual for a relatively new technology as it makes its way into the mainstream. Amidst all the bluster and pumped-up promises, keep one very important thing in mind: SOA is a means to and end, not an end in itself.
How many times has an organization failed in an attempt to harness the benefits of an emerging technology because the technology itself became the focus of its efforts, rather than the enablement of important business initiatives by way of the new technology? I don't know, but I suspect that (borrowing a line from the movie "Top Gun") "the list is long and distinguished" (which is to day, this is a trap into which even the best and the brightest can fall). People who lead the way to these IT train wrecks might sing a siren song with an appealing refrain: "The technology will solve our problems." Though I hate to be a burster of bubbles, I'll tell it to you straight: NO, IT WON'T.
In talking about SOA, plenty of people like to mention that it will improve an organization's agility (i.e., the ability of the organization to quickly develop new application functionality in response to marketplace changes). This assertion really isn't true because it's missing an important word: help, as in, "SOA can HELP to improve an organization's agility." You can see why this is so, right? I mean, sure, aspects of an SOA such as code modularization, abstraction of application implementation details, and the use of standard interfaces do ENABLE greater agility, but if the enterprise is going to be more agile then the BUSINESS side of the business is going to have to do its job: it's going to have to recognize new marketplace threats and opportunities and devise effective strategies to deal with them. No mere application architecture is going to do that. When a change in the organization's environment has been identified and an associated strategy has been devised, new application functionality needed to execute the strategy can probably be developed in less time if the organization utilizes service-oriented architecture.
It's like owning an exercise bicycle. The bicycle won't reduce your weight unless you ride it. The bicycle can HELP you to lose weight, and in that sense it's a good thing. You just need to do your part to make the purchase of the bike worthwhile.
Look, you can't let yourself be intimidated by technology. It is a tool of the modern enterprise, and the sooner you start thinking of it as such, the sooner you can get IT to work for YOU, as opposed to vice versa.
I could go on and on, and in fact I will, on May 18. That's the day on which I'll be teaching a full-day seminar, "SOA in the Real DB2 World," at the 2008 North American Conference of the International DB2 Users Group (IDUG) in Dallas, Texas. If you register for the conference, I hope that you'll register for my seminar. It would be great to see you in "Big D."
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home