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

The Three Faces of SOA  
# Monday, January 23, 2006
 
Among software people, the word “architecture” is commonly used in three distinct contexts: application architecture, infrastructure architecture, and enterprise architecture. The notion of service-oriented architecture spans all three of these areas. Yet whenever somebody talks about SOA, he or she is often implicitly thinking about only one of them. Developers are mostly interested in the challenges of building service-oriented applications, for instance, and so their focus tends to be on the application architecture aspects of SOA. A vendor of web services management tools commonly thinks of SOA primarily in the infrastructure sense, while an enterprise architect at a user organization is likely to be concerned mainly with SOA’s enterprise aspects.

All three perspectives have value. Here are simple descriptions of each one:

- Service-oriented application architecture: Guidelines, patterns, and practices for creating service-oriented applications. People who focus on platforms for service-oriented software and on the architecture of individual applications tend to emphasize this perspective. Technologies such as Microsoft’s Windows Communication Foundation (WCF) and the recently-announced Service Component Architecture (SCA) are directly relevant here.

- Service-oriented infrastructure architecture: Guidelines, patterns, and practices for managing and operating service-oriented applications. Big thinkers about SOA sometimes give this perspective short shrift, but anybody who’s actually trying to make it real knows how important these issues are. Vendors like AmberPoint and Actional are focused here.

- Service-oriented enterprise architecture: Guidelines, patterns, and practices for using and getting business value from service-oriented applications. Technical issues still appear here, but many of the biggest concerns revolve around people. (In fact, I’d argue that this view of SOA encompasses the most difficult challenges--people are usually more problematic than technology.) Advice on SOA from analyst firms such as ZapThink often emphasizes these aspects.

I’ve seen people argue about the meaning (and even the value) of SOA when their real difference was that one took an application-focused view while the other took an enterprise view. Words are only useful when we can agree on what they mean, and so having a clearer sense of what we’re talking about when we use this overloaded term would be a step in the right direction.


10 comments :: Post a Comment

 


Comments:

One comment ... An application gives one trust for the software in use. Applications are opaque and absolute units of work. The former is good, and the latter is bad (in a SOA). A SOA should not make a distinction between units of work, only between units of trust. Applications, enterprise or cross-enterprise are all trust boundaries. That's why I think applications and enterprises are the same architectural piece, where the infrastructure adds the feeling of trust. Application as a concept is old and should not be part of the SOA paradigm. One could call it meta-application instead?
 

I agree that deciding exactly what qualifies as an "application" in an SOA world is challenging. Trust boundaries are part of it, but pragmatically, somebody actually owns each particular chunk of code. This person, either an IT manager or a manager in a business group, probably paid for the software's development--it was created to solve a particular set of problems--and he pays for its ongoing maintenance. To him, this certainly is a discrete application.

From a purely technical point of view, one might argue that trust boundaries are all that matter. One of the signal truths of SOA, however, is that technical issues are the easy part. My experience suggests that the human and organizational challenges are much more important.
 

It's funny because there are a lot of trust boundaries around us (classes, components, processes, frameworks, machines, applications, etc). They will all be your friends, if you stay on the right side of the border. IT managers like their friends, because they make them able to sleep at night.

But if you open the black box of trust, you'll find duplicates of both data, business logic and flow. How much is trust worth? Why isn't the IT manager sleepless over the problems with duplicates?

If too many early and misguided SOA project fails, the trust will be lost. Monolithics and non-transparency will rule.
 

IT managers certainly are sleepless over the problems with duplicate data and business logic. I spoke with the CTO of a large US firm about this recently, and he told me that his new policy was to fire anybody who created a duplicate database. This is perhaps a little extreme, but rampant duplication is widely seen as a bad thing. SOA has the potential to help with this problem, although it's not without its own challenges.
 

You're right, duplicates is a huge and expensive problem for a company. SOA might be a solution, but there's a flip side to that coin.
Some say EAI and EII are symptoms of a disease and that application boundaries are evil and un-healthy. Some say SOA is the perfect way for organising an EA. But they take little attention to the fact humans are involved.
Humans want to be in control. An application is under the control of the IT manager. An architect is human too and likes to design a system inside-out to retain control. Same goes for developers who want to stay in control.
But SOA paradigm aims high and backs it up with a lot of standards, service governance tools and market attention. But the result of a service network will not be easy to picture and even harder to control.
Do you agree that an application oriented EA with EAI and EII is a threat to SOA from a control/trust perspective?
 

Is it possible to create an enterprise architecture that isn't "application oriented"? I'm inclined to doubt it. People typically rely on and pay for specific applications, and I don't think this will change in a service-oriented world. If real SOAs can't find a way to succeed in spite of this, I question whether they'll succeed at all.
 

In my world service orientation is the opposite to application orientation, in terms of the enterprise architecure. Eventhough we put services in the middle, I agree that something like an application has got to be part of it all. But I see applications as trust boundaries, not part of the architecture itself and definitively not part of the architectural design (as it is today). I believe that applications (as trust boundaries) in a SOA also can be the way you package and go to market with your services. Then companies will buy your services to fit seemlessly into their excisting network of services. That's never been possible to achieve in the application oriented world. In the ideal situation, companies could build new composite applications on top of your services. Reconnect the service choreography in your app to their own enterprise data-, access-, process- and interactive-services. I believe that's the architecture that will align to the business in the best possible way, don't you?
 

While an enterprise architect might prefer to think primarily about trust boundaries, the people who own applications--IT and business managers--are more likely to think about boundaries based on money and control. I'm skeptical of any approach that doesn't take this reality into account. In most firms that I'm aware of, when architects and the guys who control the money disagree, the architects lose. So while I'm sympathetic to the trust-based picture you paint, and I agree that it's a big part of the promised SOA vision, I'm worried about how well this approach will fit into the way organizations really function.
 

This comment has been removed by a blog administrator.
 

A lot of groups agree upon SOA, but they all picture it differently. Business people have a vision where the software is organized similar to their business. When the business turns right, IT should follow. Enterprise Architects relates to SOA as ‘standardized integration’ (EAI + WS). System Architects picture it as just another abstraction layer in their architecture, while developers are still struggling with and banging their heads over the 4 SO-tenets. Finally we got IT who only read the white papers from ESB vendors (repackaged EAI products) to be enlightened. SOA comes on a broad front, which is good. All the points of intersection between the groups will finally make SOA fly.
 

Post a Comment


<< Home