Print

Stay tight on loose coupling



Email
January 5, 2012 —  (Page 1 of 3)
Fellow architects and designers, I fear that we as an industry are moving our applications and data into the cloud without first having mastered service-oriented architecture, the basic discipline of building distributed systems. In the process, we’re setting ourselves up for failure.

If your experiences have been anything like mine, SOA has been a disappointment. Think back to a decade ago. We were promised lower operating costs, improved business agility and reduced operational risk if we would only adopt SOA. Filled with enthusiasm, and with the encouragement of reputed vendors and analysts, we persuaded our businesses to invest generously in technology and training around service-oriented architecture.

We’re ESB-ed and Registry-ed to the gills. But now, 10 years later, when we total up the benefits we received by adopting SOA—and there have been some—they haven’t been stellar. New systems still cost a lot to build, existing ones still cost a lot to support, it still takes time to create new business capabilities, and our systems still experience unexplained outages. So the promise of SOA hasn’t been realized, if we’re thoroughly honest with ourselves. Where did we fail?

SOA itself is not at fault. The basic principle behind SOA is “loose coupling,” which is based on perfectly sound software engineering experience. Think of “loose coupling” as the absolute minimum required set of dependencies that should exist between any two systems. Too many dependencies can make it harder to change anything because a large number of related changes needs to be made (high operating cost); these changes take time (lower agility); and changing anything risks breaking something unexpectedly (high operational risk). That’s why reducing dependencies to the minimum possible makes such good sense. SOA is therefore just common sense.

Why didn’t SOA succeed then to the extent that it should have?

The IT industry has seen SOA as just a bunch of cool technology products that can reduce the tight coupling between systems, and has forgotten about an equally important source of dependency. That’s the applications themselves, or, boiled down to the essence, it’s the nature of the data that’s exchanged between systems that is responsible for much of this tight coupling.



Related Search Term(s): agile, cloud, SOA

Pages 1 2 3 


Share this link: http://sdt.bz/36237
 


Comments


02/14/2012 05:09:19 PM EST

I have been doing data exchange work since before EDI emerged. I feel SOA is going through the same thing that happened to EDI: people looked at it and decided it was too complex. If we just use SOAP stuffed with this really cool stuff called XML then we don't need all of the complicated rules that the old folks felt EDI needed. Guess what - useful data transactions are actually complex and involve complex data. It is a lot of work with a lot of complexities to create a data exchange that does more than order a DVD from Amazon. The problem has never been the media - it has always been the complex realities of the business world.

United StatesMark


02/15/2012 08:06:37 PM EST

I have been doing data exchange work since before EDI emerged. I feel SOA is going through the same thing that happened to EDI: people looked at it and decided it was too complex. If we just use SOAP stuffed with this really cool stuff called XML then we don't need all of the complicated rules that the old folks felt EDI needed. Guess what - useful data transactions are actually complex and involve complex data. It is a lot of work with a lot of complexities to create a data exchange that does more than order a DVD from Amazon. The problem has never been the media - it has always been the complex realities of the business world.

United StatesMark


close
NEXT ARTICLE
SOA (the term) is dead, but SOA (the architecture) lives on
Cloud and APIs have their roots in service architectures defined more than a decade ago Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?