Why Point-to-Point Integration Costs More than SOA
April 26, 2011

Does your business keep expecting the same kind of ROI from SOA as they get from point-to-point integrations, even though you try to explain until you're blue in the face that SOA is anything but P2P?

Join the club. Unfortunately, P2P integration is less invasive and doesn't mess with business processes, and as a result, does not bear the up-front costs that SOA may incur. Marc Rix, a senior SOA/BPM architect, has just released this white paper that discusses describes the differences between P2P and SOA-based integration, and explains why SOA ROI is vastly different from P2P ROI. SOA is uncharted territory, "so in the absence of objective SOA performance data, the industry needs a simple model that compares the distinguishing characteristics of SOA and the P2P approach on a fundamental level so that we can make more objective judgments about the fit of SOA in our enterprises," Marc says.

Marc separates the economics of P2P and SOA this way:

Point-to-point offers short-term savings, but long-term pain.

"Point-to-point architecture carries seductively low up-front costs, resulting in little impact at the project level... However, microeconomic stability can quickly fester into macroeconomic chaos. As more and more one-off solutions are piled atop one another, IT maintenance costs swell exponentially and connection sprawl strangles the infrastructure."

The costs of individual P2P connections remain constant no matter how often the process is repeated -- therefore P2P costs grow linearly, Marc points out.

SOA means higher up-front expenditures but long-term savings.

"Higher up-front expenditures are required in order to ensure loose coupling between linked components, which inflates project budgets. This translates into initial financial losses at the microeconomic level and often catapults projects beyond conventional thresholds of risk tolerance. However... investments in SOA at the microeconomic level can blossom into colossal benefits at the macroeconomic level. By dramatically reducing the number of physical connections in the infrastructure and leveraging no-cost, virtual connections to achieve everything-to-everything connectivity, SOA’s return on investment increases exponentially as the infrastructure grows."

Unlike P2P, each physical connection in the SOA network links one node to all other nodes via virtual connections through a hub. This means that the value of the SOA network increases exponentially as its size, or number of nodes, increases, Marc relates. Thus, "the value of the SOA network is greater than the sum of its parts." A link to Marc's white paper can be found at his site here.


SOA security lesson
December 17 2011

In a recent survey, our readers reported security is the top organizational requirement for SOA. All of the agility in the world doesn’t matter if you can’t provide it in a secure fashion.

Yet traditional security isn’t sufficient to lock down a services infrastructure. Applications aren’t being housed on single servers in a static network. Changes in the application domain necessitate changes in the security domain and it is incumbent upon the application architects to plan for the different types of security that service-oriented architecture will require.

With that in mind, we’ve launched our new security lesson inside our Service Orientation for Architects School. It provides essential resources for architects looking to bake in the security that is essential for a proper SOA.

Burton Group’s Anne Thomas Manes offers up a Webcast on a holistic approach to SOA security. It deals with network options, end point intelligence and identity management practices. Steve Craggs of Lustratus Research identifies the top 5 SOA security traps in a podcast.

It is no secret SOA is creating new vulnerabilities. It will be the users who educate themselves about how to protect against those new vulnerabilities, the ones who don’t expect someone else in the organization to find the holes, who make the most successful switch to service orientation.



RIA with your SOA? Watch your business rules
January 23 2012

At the Ajax Experience in Boston last week, I caught a presentation by Joshua Gertzen, primary architect at ThinWire, called “Dodging the Pitfalls of Enterprise Ajax Applications”.

Gertzen and ThinWire came into the Ajax/RIA space through an interesting side door, working on desktop banking apps at an ISV called Custom Credit Systems Inc. So Gertzen’s perspective is that of a programmer with a business focus than one who likes to make pretty Web pages. In fact, he noted that the Web traditionally doesn’t handle data-centric applications very well, which is no small issue for those building data-heavy business apps.

Even more than that, he said that a serious financial application can have thousands of business rules attached to it (16,000 was his number of choice) and it can make for a presentation layer nightmare when it doesn’t understand a rule change. The degree of difficulty only rises when you add Ajax and Web services to the mix.

“All the new application endpoint handlers on the server could number in the hundreds,” Gertzen said.

Gertzen’s proposed solution is that logic and events should be handled on the server to allow full access to server resources and to make debugging easier. That will allow developers to create a tightly coupled Ajax/RIA interface that doesn’t get bogged down with too many rules.

Of course, since this is an SOA blog, I probably just hit a trip wire for many of you when I used the words “tightly coupled.” Aren’t we trying to get away from tight coupling? Well … yes … though obviously there comes a point where you have to implement and that may involve some tight coupling.

I caught up to Gertzen after his talk to bounce that very question off of him. What does the application architect need to consider when tying these rich interfaces to a Web service that may have shifting data sources and business rules? How do you rationalize the tight coupling of the interface with the loose coupling of the service?

Gertzen suggested having the server make a Web services call to itself to create a new, separate instance with which the interface can interact. That way state and change management don’t become rolling trouble spots.

Let’s take that ball and run with it. Say you’ve got an enterprise that runs a few hundred Web services inside its SOA and you want RIA interfaces for all of them. That would seem to be a real sweet spot for virtualization tools. You could make those new instances part of your overall SOA governance strategy (specifically in how you handle change management). It’s amazing how all of these hot, new areas in IT can potentially fit together. Whether virtualization will become the secret sauce in the RIA/Web services sandwich remains to be seen, but it certainly would seem a handy way of getting around the problem of tightly coupling an interface to a service that will not remain static.