WHITE PAPERS SPONSORED PROFILES JOB BOARD WEBINAR CENTER FREE SOFTWARE BZ RESEARCH ALMSHAREPOINT EVENTS CALENDAR PRINT/PDF EDITION PRINT/PDF BACK ISSUES

SUBSCRIBE TODAY CUSTOMER SERVICE EDITORIAL BEATS GUEST VIEW GUIDE SD TIMES 100 GUIDE EVENTS CALENDAR ADVERTISING ARTICLE REPRINTS REPORT A BUG SITE MAP

ABOUT US BZ MEDIA NEWS BZ RESEARCH NEWS ON MONDAY SPTECHREPORT SPTECHWEB SPTECHCON IPHONE/IPAD DEVCON ANDROID DEVCON PRIVACY POLICY CONTACT US

HOME >> OPINIONS

Stay tight on loose coupling

By Ganesh Prasad

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

Most Read Latest News Blog Resources

Virtualization: Not just for machines anymore
Network virtualization allows multi-tiered applications to behave as though they were in a physical network

Zeichick’s Take: The handheld and the tablet, circa 1976
Texas Instruments' and Hewlett-Packard's calculators were doing things decades ago we take for granted today

Google talks tools at AnDevCon III
New 3D debugging tool and recent ADK changes are detailed by Google developers at the third Android Developer Conference

Android is the focus of two new design tools
Anywhere Software and Xamarin provide ways for developers to create and test their applications on PCs

Virtualization: Not just for machines anymore
Network virtualization allows multi-tiered applications to behave as though they were in a physical network

Achievements and learning: Gamification comes to businesses and schools
Startup takes page from gamers by offering achievement marks to get developers more engaged in their projects

Google talks tools at AnDevCon III
New 3D debugging tool and recent ADK changes are detailed by Google developers at the third Android Developer Conference

SmartBear rolls out new quality solution: API Complete
Software gives organizations ability to write test scripts and monitor APIs by bridging the DevOps divide

Creation
To write better software, cultivate your ability to be creative.

Slick...but who needs it?
compilr.com is a well-designed site and the folks behind it seem to have their heart in the right place. But...who needs it?

How to be a better software developer
Want to be a better developer? You won't get there by mastering an interesting language or learning a new set of APIs.

Wooing Galatea
Do yourself a favor and check out Galatea 2.2, a wonderful book by novelist Richard Powers.

Five SCM Best Practices Two-thirds of all software projects fail, according to the Standish Group’s CHAOS study. Improper usage of software configuration management...

Best Practices for Branching and Merging Patterns

Development teams often create a branching pattern, usually drawn out on a white board or in a Visio document, that is used as a model to...

Automated Error Reporting We invite you to read a short e-zine that tells you all about automated error reporting for .NET applications. This 8-page e-zine is packed...

The End of Application Redeploys Imagine that every time you wanted to write, send or receive an email, you needed to restart your computer. How much time would this take, a...

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

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

Open Cloud Initiative envisions an open cloud future Vendor lock-in is a hidden danger, so principles must be established to protect users

The cloud's place in a SOA world Experts suggest viewing the cloud as a deployment option for SOAP- and REST-based services

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

United StatesMark

Add comment

Name*
Email*
Country

Comment

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>>
SharePoint Tech Report
more>>

Download Current Issue
MAY 2012 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?

Creation
To write better software, cultivate your ability to be creative.
05/19/2012 07:40 PM EST

Slick...but who needs it?
compilr.com is a well-designed site and the folks behind it seem to have their heart in the right place. But...who needs it?
05/16/2012 12:45 PM EST

How to be a better software developer
Want to be a better developer? You won't get there by mastering an interesting language or learning a new set of APIs.
05/14/2012 12:18 PM EST

Wooing Galatea
Do yourself a favor and check out Galatea 2.2, a wonderful book by novelist Richard Powers.
05/12/2012 07:05 PM EST

The world as story
An artificial-intelligence system at Carnegie Mellon seeks to understand the world by making statements about it.
05/10/2012 06:39 AM EST

The Rise of the Brogrammer, or the Rise of the Sexist Programmer?
Women in Silicon Valley get vocal about sexist ads and campaigns that contribute to a tense work environment.
05/09/2012 03:14 PM EST