Slashdot Mirror
Survey: SOA Prominent On 2005 budgets
Michael S. Mimoso writes "A Yankee Group survey of 473 enterprise decision makers reveals that companies have put aside money for service-oriented architectures for 2005." This is a bigger deal than it sounds - if companies keep moving this away, it will mean a sea change in corporate technology usage - and change the way/why development is done. We're talking everything from SOAP stuff (ITMJ is part of OSTG) to wholesale ASP adoption like Salesforce.com.
I think the key indicator in the article that this is the latest in buzz phrase compliance was the recommendation that "Vendors have to get on the pulpit." It's all about getting the customers over the hump into buying all of the application servers and services that will give them true SOA.
The biggest hurdle is that "executives do not understand Web services or loosely coupled architectures" (per the Yankee Group's Philip Fersht). There's the rub, and the value, of the thing. The executives don't understand the value of separation of applications (what Roger Sessions calls Software Fortresses), but are beginning to be taught. If they can loosely couple, they begin to get choice of vendor at a finer scale. They can choose different vendors for differents parts of their critical systems. So the strategy of the large, integrated solution vendors will have to be to sell the buzzphrase while continuing to delivery monolithic messes.
I will listen to what they have to say when they stop employing SCO shill Laura Didio.
--
E_NOSIG
May I be the first to say "WTF".
SOA may be something useful. Unfortunately (?), this article does nothing to explain what it is, only that you need it, your business needs it, and if you don't you are going to be left behind all those other companies that allready have it.
I gotta invent me something like this, make it cool, and make a mint flogging it.
However, posting it to slashdot WILL NOT be my preferred manner of drumming up business.
Norman Cook's Ode to Sl
If you haven't tried bullfighter (from the guys at deloitte) and are use word/powerpoint at the office, you'll love it.
According the the bullfighter Index, the article gets:
Bull Composite Index of 5.9 (not horrible)
Bull index of 94 (good)
Average sentence length (good)
Syllables/word (ok).
And the part I love.. the Flesh score.. 36:
Diagnosis: Teetering on the edge of unclear. The overall meaning remains discernible, but it becomes possible to lose oneself in corollary thoughts, which may be worth exploration, but which can also detract from the core point of the written article.
Anyway.. off topic but fun.
JD
The problem is that it isn't the jargon of techies. It's the jargon of people-trying-to-market-new-buzzwords.
The article is pimping ASPs. For those of you who have managed to avoid this particular bit of buzzwordspeke, it refers to "application service providers" (not the more common usage). Basically, the idea is that some vendor runs the backend of your applications on a remote server and admins them there, and you get the front end. It has the obvious appeal to vendors -- it lets you use a neat loophole in the GPL -- since you don't distribute code, you don't have to hand source out to anyone. It also provides basically impervious copy protection -- since you don't own the back end of the application, the vendor can cut you off at any time. It also gives the vendor tons of customer info, the ability to sell tiered service (i.e. price discriminate) and lots of control over the product. Oh, and a subscription-based sales moels, which is alway spossible. It falls prey to the obvious problems -- on the face of things, ASPs are generally a big loss for customers. The customer suddenly runs the risk of losing his apps if the service provider goes under, gives his vendors much more leverage over him, has to consume bandwidth, makes the not-very-reliable Internet a point of failure for his apps, etc.
May we never see th
As someone who is on a team developing a large scale Service Oriented App I can tell you all I hear around here is buzz words. This technology is ripe with it! On the plus side it has been a _lot_ of fun. But then again, I get to develop it and don't have to admin it. I can tell you these things are hell for the admins since they generate so much network traffic.
http://www.ebpml.org/indigo.htm
? pull=/msdnmag/issues/04/01/indigo/default.aspx
http://msdn.microsoft.com/events/pdc/default.aspx
I think this push for SOA is going to be the beginning of the end for OO:
Object-oriented development focuses on applications that are built from interdependent class libraries. Service-oriented development focuses on systems that are built from a set of autonomous services. This difference has a profound impact on the assumptions one makes about the development experience.
SOA makes outsourcing easier:
The notion that boundaries are explicit applies not only to inter-service communication but also to inter-developer communication. Even in scenarios in which all services are deployed in a single location, it is commonplace for the developers of each service to be spread across geographical, cultural, and/or organizational boundaries.
- - - -
Object-oriented programs tend to be deployed as a unit. Despite the Herculean efforts made in the 1990s to enable classes to be independently deployed, the discipline required to enable object-oriented interaction with a component proved to be impractical for most development organizations.
Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy.
Every service advertises its capabilities and requirements in the form of a machine-readable policy expression. Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service.