Taking a New Tack With SOAs

 
 
By Peter Coffee  |  Posted 2004-10-18 Email Print this article Print
 
 
 
 
 
 
 

Few phrases have seized enterprise mind share to the same degree as "service-oriented architecture". Buyers want to spend money building SOAs, and vendors want to position themselves as being part of those plans. And it's the enterprise develo

Few phrases have seized enterprise mind share to the same degree as "service-oriented architecture," or SOA. Buyers want to spend money building SOAs, and vendors want to position themselves as being part of those plans. As is so often the case, its enterprise developers who are on the grinding edge of the resulting phenomenon: Its the application development managers and teams that must find the sweet spot where enterprise desire intersects with vendor reality.

Impelled by the combination of technology push and management pull to "do services," developers must be wary of the common pitfall of using new tools to do old tasks. The high-buzz enabling technologies of SOA—Web services, XML and multiple middleware initiatives—can be used to liberate enterprise IT from sluggish, brittle, costly systems. They can also be used to build the next generation of ... brittle, slow and costly systems.

Its far from a novel idea to visualize enterprise IT as a dynamic confederacy of services rather than a welded-together structure of tightly coupled IT assets. The "blackboard" systems of artificial intelligence researchers in the 1980s and the distributed object protocols such as CORBA that were hot topics for enterprise IT in the 90s all had the common goal of building systems that revolved around what was done rather than what was doing it.

Major recording company uses SOAs as part of its Web strategy. Click here to read more. What gets the SOA pot perking now is the confluence of cheap bandwidth, commodity processing power and violent agreement on nonproprietary standards on the technology side, combined with newly vigorous demand for an IT strategy that serves the business mission rather than forcing the business into the mold of the technology.

But if business wants to drive the definition of future IT direction, then business-unit managers must be looking through the windshield as well as seizing hold of the steering wheel. The price of using SOA technologies without an overall SOA buy-in from business units may not be apparent in the short run, but it will become painfully clear down the road when expected payoffs of business flexibility and money-saving code reuse do not live up to expectations.

To follow the forward path to liberation—rather than the circular path that repeats past mistakes—its certainly useful to master new standards, skills and tools. But its essential to develop and maintain a clear understanding of the difference between the parts (that is, the component technologies of SOA) and the whole (that is, the mission-driven and highly adaptable IT architecture that they can be used to create).

Its an error, in particular, to think that an SOA can be built only with the Web services technology portfolio, despite the similarity of terms. The most successful SOA deployment is most likely to combine Web services pilot projects with the simplest possible interfaces to mature legacy systems.

Its an even bigger error, though, to think that an IT architecture based on Web services will be, by definition, an SOA.

Next Page: What SOA is not



 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel