David Chappell

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