December, 2007

Is SOA about the business?

Recently I ran into this post from Arnon of DDJ fame which is in response to another response by Sam Gentile :-). I wrote about this in related posts a while back and this seems to be a recurring theme in many discussions. Seems like both are trying to say the same thing that “SOA is all about the business”. but I can’t help but add my 2 cents to this discussion

This (SOA) has nothing to do with business drivers. It has to do with defining components, relations, attributes on relations and components as well as constraints.
By the way, SOA has nothing to do with technology either. You can implement SOA using WS-*, Atompub, MSMQ, CORBA just as much as you can implement REST with quite a few technologies.

Putting those two statements together means SOA has nothing to do with technology nor business!!!

On a serious note tho’, its my opinion that the “relations, attributes on relations and components and constraints” are all business level components, relations between them, attributes on relations and components and constraints. SOA is a way of thinking about (read architecting)  your applications and how they interact with and compose with each other to provide business value. How this SOA is “applied” has nothing to with the business… well yes it does, but not in a direct way.

To take an analogy of building a house. The notion that the house needs to have a certain set of properties like good ventilation, good sun light, access to different rooms etc is akin to what an SOA lays a blue print for. Now which wood/ paint/ nails etc to use to build (read appling SOA); i.e. achieve that vision is only material to the builder (read solution architect/developer) not the home owner (read business stake holder). The home owner only cares about the “business” constraints/attributes. I’d say SOA s all about the business!

A walk in the clouds…

Many internet-years ago Microsoft released an experimental service in the cloud called BizTalk Connectivity Services. Pretty neat stuff. It consists of the following pieces… (to quote the description on the site.)

• Identity Services are hosted services that enable organizations to more easily manage their users and help developers create more secure applications that support user identities from many different organizations.
• Connectivity Services are hosted services that make application messaging between organizations easier.

The identity services are pretty basic at the moment and allow just enough fine grained control over resources. It has the notion of

1. Resources - which act as boundaries/scope of controlling access
2. Operations - which give a finer grain of control, as to who gets to do ‘what’ within the scope of a resource. Operations represent the logical actions that are allowed within the resource
3. Rules - which tie users/groups to operations

The connectivity services are just fantastic. The SDK thats ship with the service makes connectivity such a simple task.

This year has seen the mushrooming of many cloud-services not to mention the number of web 2.0 applications that expose their APIs for external consumption. There’s a bunch of very interesting services available in the cloud today and its my guess (oh well, prediction! ) that in 2008 these cloud based services will capture the mindshare of folks (of folksonomy fame), helping them create applications that will connect people/applications using the internet as a service bus. We’ll try and explore some of these cloud services in the following weeks

Crumbs from week ending 30-12-2007

• Dave Chappell has great whitepaper on configuring WCF and some great .net 3.5 introductory topics aswell
• Jon Udell has an interesting conversation with Richard Wallis about the Talis semantic web platform
• Another post triggering the ever entertaining REST vs WS-* debate thread
• Arnon from DDJ continues  his series on defining SOA

Technorati claim post

Technorati Profile

Crumbs from week ending 23-12-2007

• Dependency injection in WCF
  • http://weblogs.asp.net/cibrax/archive/2007/12/13/wcf-dependency-injection-behavior.aspx
  • http://orand.blogspot.com/2006/10/wcf-service-dependency-injection.html
• New blogger resource for microsoft Biztalk blogs - http://www.biztalkblogs.com/
• Seeking nominations for SearchSOA.com 2007 products of the year
• Larry Ellison says SOA Uptake is Slow
• The Authorization Continuum - exploring authorization across services

Active syndication

Came across a very interesting (and as always, a very insightful Jon Udell) conversation about syndication-oriented architecture. Not, to deemphasize the benefits of the “information flow within the enterprise” via syndication; but, its really an amazing observation that “The line us blurring between personal information management and publishing“; and recent developments in the syndication space might just be the right technology to see that happen.

James Snell from IBM has an interesting comment on the FeedSync service

“For search engine indexing, we assume that the search engine indexer is acting just like the first offline client example above. For the most part, all the search engine will be interested in are significant changes to content and the tombstones so that deleted content can be removed from the index.”

This might really change the way web sites open up their content for search and make content more relevant and accurate, more specifically, tying it back to information flow in the enterprise, it will make enterprise search that more efficient. Good stuff!

Feedsync makes rss/atom syndication two way and I’d like to call this Active Syndication!

SOA and the technology agnost

Like I opined in an earlier post; it cannot be stressed enought that web-services is only an technology enabler not a panacea to all the worlds business problems!

 In a recent article in http://www.itbusinessedge.com titled “One Technology Does Not Fit All SOAs“

This may not be easy to do – you may need to hire additional help, either by finding a consultant or creating a staff enterprise architecture position, if you don’t have one.

In November, I asked Linthicum how companies can find qualified SOA consultants. He suggested you find a qualified architect who can guide your SOA implementation.

Now what role is such a person supposed to play? In most cases, its someone who suggests appropriate strategies/solutions that are best of breed, capable of solving the existing problem domain.

In reality, companies invest a lot of money in technology choices they make; either going J2EE route or the .net route for the most part. more than likely a that its a “solution architect” thats hired to fit the business initiatives within the confines of the existing technology investments or within the expectations of technology investments in the future.  

Can these be the same person? I think an enterprise architect would not suggest anything different from whats mentioned earlier in the same article,  and wouldn’t be wrong in doing so!

Donald Rippert outlined four phases of implementing service-oriented architecture:

1. Using XML as an interface.
2. Making legacy systems available as Web services.
3. Using an ESB (enterprise service bus) to connect Web services and use composite processes.
4. Using BPEL (Business Process Execution Language), which he notes will make it possible to change a business application by changing the process model rather than the code.

Its the “solutions architect”, responsible for each application that needs to integrate, who needs to map the proposed technology direction to the most effective implementation within his respective business domain. At the end of the day its all a matter of opinion but SOA will only succeed if its a middle-out SOA with grass roots adoption.

Time for seasons greetings!!

Yes its that time of the year and these posts make sure you dont forget!!

Master data management and SOA

Joe McKendrick has an interesting post “SOA’s role in master data management explained“

Pfizer first launched an SOA effort in 2001, but had to retrench its efforts when it didn’t provide access to stovepiped systems. “One of the things we learned is you can’t do SOA without data, and you can’t do it within silos,” Brodbeck said. “It’s more about farming than fishing.”

MDM and SOA have another thing in common — both require enterprise governance to succeed. Pfizer’s MDM governance structure strongly resembles one assembled for SOA, led by a business sponsor. “Master data management is much more about governance than it is about technology,” Brodbeck said.

While that works for enterprises like Pfizer, that have financial muscle and the ability to “govern” all of the IT assets, its impractical to expect at some level because getting consensus on what the “one-true” customer is can be a lot more expensive than having two systems integrate with each other. More importantly, IMHO, if the SOA is not able to bring together processes so as to alleviate the need for a formal MDM, then the business processes need to be re-engineered.

For an MDM implementation effort to succeed, it should be an outcome of business process (re)engineering. It needs to be grown organically while discovering needs to integrate business functions using SOA. After all, its better to engineer your business for efficiency than your data!

Contract-First or Code-First service design; does anybody care?

The advantages of going with contract-first is certainly evident when it comes to interoperability. I remember reading an interesting article about the Contract-first vs Code-first debate a while ago. At the time it was published, I remember thinking to myself that both sides seem to have very valid points, but, Ted Neward, whom I have great regard for, an evangelist for interoperability, was dissing the idea of contract first. Why?

Now, After a couple of years effort in spearheading the contract-first approach to SOA, it behooves me to wonder about the practicality of such an endeavor, for a couple of reasons

1. Change management is more intuitive for a code-first approach; and this may very well be just the tooling support around managing changes across schemas and services isn’t as mature.
2. The development processes in most places today don’t know how to slot the task of managing contracts in the schema/wsdl form. Who is the person responsible for rationalizing and implementing the changes. Is there a formal process to do this? Can developers do this on their own, without thinking big picture?

In a homogeneous SOA environment its code-first is easily the more practical of the two (which is not to say it doesnt involve an equal amount of thought and architecting). That said, in my opinion, given a service interoperability scenario, there is no clearer winner than contract first. I say this on the strength of one fact. If one were to design code-first interfaces and have them generate the contracts; who is to say that the way the platform renders these contracts would not change in future versions of the platform. All of a sudden service consumers fail because the contract has changed implicitly!!!