David Chappell

  • September 2020
  • November 2017
  • April 2017
  • October 2016
  • March 2016
  • February 2016
  • August 2015
  • April 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003

Opinari

Get the Feed! Subscribe

Responses to SOA and the Reality of Reuse  
# Friday, September 29, 2006
 
I've been surprised by the responses I've seen to my latest Opinari. I expected more people to disagree with me, defending the promise of service reuse. What I've seen instead is general (and sometimes enthusiastic) agreement. Even the comments on Joe McKendrick's ZDNet entry were largely in agreement, although I'm not sure Joe himself shares my perspective.

Microsoft's Harry Pierson wrote an interesting response on the importance of context in reuse, something I fully agree with. His observation that reuse with services might well be more difficult to achieve than it was with objects also rings true, since the requirement for remote access to services does raise the bar. David Ing also wrote a useful response, raising some excellent points about why reuse is valuable primarily for services that expose data.

For a view from the other side, I had a chance to talk recently with the author Thomas Erl. We both presented at Gartner's Application Development Summit this week, and Thomas is significantly more bullish on the potential for reuse. As I understand it, his view (based on experience gained from his firm's consulting work) is that if an organization does an appropriate top-down analysis of a well-defined business domain, it's quite possible to discover and implement reusable services. This is a good argument, and I'm willing to believe that there are cases where this kind of analysis-led reuse can work.

What's harder for me to believe is that a majority of organizations will be able to do this. Instead, I've come to expect most efforts to take a more technically oriented bottom-up approach. Given that the coming wave of vendor platforms will all but force us to build service-oriented applications, it will be hard to avoid at least this much SOA.

Will this simpler, less ambitious approach offer all of the benefits claimed for SOA? Certainly not. But is it an improvement over the world we live in today? Just as certainly, the answer is yes. Like objects, services won't provide everything promised by their most fervent exponents. Nonetheless, this shift counts as a step forward.


3 comments :: Post a Comment

 


Comments:

When I read the opinar I didn't understand your point talking about reuse and SOA in the same sentense so I responded with this.

In my world SOA comes from the frustration with applications built up as a silos of data and hard coupled parts. IMHO the goal with SOA is to break down the silos into compositions of services.

Compositions uses services not for the sake of reuse, but from the possibility to virtualize on functionality and be able to reconstruct the application from one point to another without rebuilding and deploying a new version of the application.

Rebuilding classic non-SOA applications comes with development costs, consultant costs, migration costs, long time frame, etc.

I would say reusability is the opposite to agility since reuse results in coupling, which agility tries to oppose.

Also, I would like to ask you how agility is "just another form of reuse" (as you write in your opinar)?

-Jonas
 

True: "the reuse of business objects failed."

False: "the barriers to pervasive reuse of business logic remain high."

Discussion (or click through my name above for the 16/10/2006 post):

http://weblogs.asp.net/erobillard/archive/2006/10/16/Object-Reuse_2C00_-David-Chappell_2C00_-and-the-Rule-of-the-Least-Common-Denominator.aspx
 

All these young turks fretting over reuse. (sigh)
If you have worked in computer science as long as I have (35 years) you will have seen that "reuse" has been a holy grail in every era and always comes up short. Subroutines, functions, libraries, modules, classes, components, distributed versions of all of the previous, and now "services".

The problems are always the same:
* knowing how to make something reusable (which only happens with feedback from multiple attempts to reuse each particular component)
* knowing where to find components which are reusable, and knowing
what those components do (which means doing the detailed clear type
of documentation that never seems to get done)
* and most importantly, it is simply more easy (dare I say fun) to
develop from scratch than to find, learn, debug, refactor, existing
"reusable" components written/controlled by someone else.
* OH, and dont let me forget! People have the whole notion of "components" (aka services) backwards...FRAMEWORKS are what must be reusable and reused. Components dont exist! In the same way that donut holes dont exist. Frameworks are the donuts which define the holes/components. As long as people think about components in isolation, all of the above problems are made worse
 

Post a Comment


<< Home