12 June 2009

SOA Infrastructure - Back to Future, No. 2

Posted by The Progress Guys

Is anyone talking about the enterprise service bus (ESB) anymore? My Google Alerts are slow and my Google Adwords program isn't performing. Could it be that everyone already has one? Is it assumed that everyone has one? WARNING: shameless promotion...

Did you know that Progress Software introduced the industry's first ESB? Actually, independent research firm, Forrester Research, Inc., named Progress® Sonic® ESB as a leader in the enterprise service bus (ESB) market in "The Forrester Wave™: Enterprise Service Buses, Q1 2009" report. That seems like a big deal to me but yet I continue to have problems finding someone to blog or talk about it. Thankfully there's Hub Vandervoort, CTO, Progress Software. If you haven't had the opportunity to hear him speak, you are missing out. He's not only smart, he's personable, engaging, and always leaves me wanting to learn more.

This week I'd like to share a video that he did over a year ago. In this 4 minute video, Hub talks about what an ESB is, why you should deploy an ESB, and he also shares what makes the Sonic ESB unique.

Interested in more? Read Chapter 4 of Service Oriented Architecture: Getting IT Done Right. Chapter 4, entitled Enterprise Service Buses, is authored by Hub. In this chapter Hub shares his collective experience of working with over 300 ESB end-users, and summarizes the styles and applications of ESB technology.

Enjoy!

 

26 June 2008

Never the twain shall meet, eh?

Posted by Hub Vandervoort

IONA CTO, Eric Newcomer, and I had to laugh when we recalled the panels we've sat on together and (somewhat pedantically) debated the merits of IONA Artix and Progress' Sonic. We shared the religion of distributed systems, alright, but we argued about them like we belonged to different sects. That's because a matter of principle—architectural principle—was at stake. In the highly-distributed SOA environment, what's the preferred approach: smart end-points or smart networks? Like all religious arguments, this one had a lot to do with up-bringing—and the particular tool we were both holding in our hand at the time.

Eric, coming from a CORBA heritage, had a natural affinity for the smart end-point approach, which IONA had successfully commercialized. On the other hand, I saw the problem through the prism of an enterprise messaging background and argued for smart networks—the solution Sonic had chosen to build. The schism, however, proved to be as nonsensical as the RPC vs. MOM religious wars of the early 90's. In our hearts I think we both felt that the argument was a bit contrived. We always knew that both models were valid—like a hammer and a screwdriver they are tools that address different needs. Neither replaces the other and they are rarely interchangeable. When you need the flexibility to put intelligence in the network (and can't or don’t want to change your endpoints), then the smart network approach is great. And, the converse is true too: when the network (or networks, for that matter) is a given, and I'm looking to service-enable a variety of endpoints, then the smart endpoint approach is perfect. The fly in the ointment all along was the decision we baked into our respective architectures at design-time.

Like a tattoo, you had better be sure you liked it—as CTOs, our mission was to defend it at all cost. But that's all changing now that new standards like Spring and OSGi give us the flexibility we need to defer those decisions to deployment time, where they always belonged. And thus a doorway is opened—a doorway to the best of both worlds!

SOA What? Bringing IONA and Progress together means that we can dispense with the pedantic debates and truly offer our customers the best of both approaches. It's a great time to be working in this industry, and fantastic to be joining forces with IONA. But, now what will Eric and I argue over? Well, there’s always emacs vs. vi!

By the way, if you haven't had a chance to hear what Eric Newcomer, CTO of IONA, has to say about the Progress acquisition of IONA,

18 June 2008

Than a Speeding Bullet—Are You Ready for Event-Driven Business?

Posted by The Progress Guys

Progress Software sponsored webinar will examine the impact of event driven SOA

Hub Vandervoort, CTO of SOA Infrastructure products, will participate in an InfoWorld webinar titled; "Faster than a speeding bullet—are you ready for event-driven business?" on June19th, 2008. During the webinar, Mr. Vandervoort will discuss how event-driven SOA infrastructure can be used to streamline businesses' provisioning and visibility.

When: Thursday, June 19th, 2008 at 2:00 p.m. EDT
Where: To register visit: http://www.infoworld.com/5266

What: In the "Faster than a speeding bullet – are you ready for event-driven business?" webinar hosted by InfoWorld, Hub Vandervoort, CTO of SOA Infrastructure products, Progress Software, shares strategies businesses can implement today that will keep systems ahead of the increased business velocity. He will discuss how event-driven SOA infrastructure—from the enterprise service bus (ESB) and real-time data services to complex event processing (CEP)—can be used to streamline provisioning and visibility.

Why: "Faster than a speeding bullet" doesn't just refer to superheroes anymore; it's the velocity businesses need to compete. Financial trade settlement has accelerated from three days to two hours in just a few years. This trend is repeating itself in almost every industry. The result: current systems can't keep up with the ever-increasing velocity of business processes.

12 June 2008

Why should you deploy an ESB?

Posted by The Progress Guys

An enterprise service bus (ESB) provides you with interoperability across many distributed, heterogeneous services and systems. Watch the video below and hear Hub Vandervoort tell you more about the power of an ESB and the industry's 1st ESB - Sonic ESB.

25 January 2008

Multiple ESBs: SOA Reality in a Federated Environment

Posted by The Progress Guys

There has already been some hype about the audio interview between Hub Vandervoort, CTO, Progress Software, and an industry expert from Gartner, but in case you haven't listened, listen to it.

During the interview, Hub discusses how companies that are working in federated environments need to approach the governance of their SOAs in both run-time and design-time contexts. If you listen, you might gain important insights into how to isolate and manage multiple SOA domains, determine which aspects of your SOA you should control at the edge, the importance of semantic control, and how event-driven ESBs can ensure loose coupling between SOA stacks.

Download the audio file entitled, Multiple ESBs: SOA Reality in a Federated Environment .

17 December 2007

WSOA: 7 Points of SOA Mediation

Posted by The Progress Guys

Last month we introduced our first WSOA interview, SOA: Time to Value of IT. Here is another interview on a more technical topic which explains in detail, but yet understandable terms, how SOA project leads and architects should be thinking about mediation. SOA mediation is a critical and broad area of functionality in your SOA infrastructure.  Listen to the podcast, 7 Points of SOA Mediation, and hear Hub Vandervoort, CTO, Progress Software, outline what he believes are seven descrete points that will help bring business agility and alignment to your SOA project.

We intend to produce our "WSOA" interviews on a regular basis and to include a broad range of speakers and topics. If you have any feedback or recommendations on future topics, please make sure to post a comment.

04 December 2007

SOA Measures on the Rebound

Posted by Hub Vandervoort

by Hub Vandervoort

Last Thursday night I was treated to two pleasures simultaneously: seeing the Celtics trounce the Knicks 104 to 59 and being vindicated for a blog entry by David Linthicum. What better place than a skybox full of SOA analysts and reporters to discuss "measures for improvement"—given the Celts' amazing, measured improvement? Among others, Dennis Gaughan of AMR Research kindly acknowledged my point was taken out of context and was sound.

This all started when Joe McKendrick interviewed me (MP3) for an InfoWorld SOA Executive Forum supplement (PDF) and podcast about how Progress customers had realized ROI through their SOAs. In each of my examples, which Joe referenced in a recent blog post, the measured change in business performance was objective and illustrated by before and after measures.

Some examples used cost savings; others, regulatory, revenue, risk mitigation, customer satisfaction, competitive advantage, or key IT performance metrics. The IT backlog example simply illustrated one way a customer of ours had discovered to measure agility—a hard concept to quantify. In this case it was measured, benchmarked, and tied to activities that would bring clear improvement over earlier measurements. The point was: genuine models for assessing ROI and SOA success must be contextual and concretely comparative—not an abstract equation masquerading as a universal silver bullet.

Unfortunately, Linthicum singled out one example for his [mis]interpretation, and in labeling it 'too rudimentary' implied Progress is so naive it would view IT backlog as a single measure for use in all circumstances, or that this is the definitive measure of SOA success. Tony Baer (OnStrategies) clearly interpreted me correctly, blogging that this "can be a sure indicator of success (assuming…"—not the only or best indicator, just, given certain assumptions, it may be ideal.

While I agree with David that "the rubber meets the road in determining the ROI before you fund your SOA" and "most business leaders are going to demand a business plan," the formulation of those makes a difference. A plan must show how change will occur in an unambiguous, quantified way, using measures that are institutionally accepted as meaningful and which can be practically obtained. Then it must show how improvement will be realized by stating the current benchmark and the measure of beneficial change that will come to it by executing the plan—which Linthicum calls a "rear-view mirror approach." But the alternatives are less effective.

ROI assertions often lack objectivity in either of two ways: They establish a theoretical model that looks sound but there's no way to make an objective, quantitative measure; or they compare outcomes to a hypothetical approach that will never be followed. Thus, the comparative results will never be manifest and always be open to subjective interpretation. You must use numerical data, sensibly obtained, and measure before and-after to see if predicted results were achieved. Otherwise, the exercise is simply academic.

In his Real World SOA blog, Linthicum lays out his 'more sophisticated' model. It requires accounting for: degree of change over time, ability to adapt to change, and relative value of change, in order to compute the value of agility to a business. However, I believe that beyond classrooms (or high-level consulting gigs), this isn't practical for three reasons, it:

  1. Speculates about future events like degree of change, introducing comparisons to pathways a business may never follow.
  2. Introduces factors beyond SOA, like skills or training necessary for change.
  3. Necessitates metrics that cannot be easily obtained or don't exist. How do you measure ability to change?

After deep involvement in delivering over 400 "real-world" SOA infrastructure projects using Progress technology, I can safely say not one would have been cost-justified or approved this way. And if they had, I can think of no way to reasonably measure the implementation after go-live to prove if results were achieved.

SOA What? Don’t think there's a silver bullet for ROI assessment. Don’t waste time implementing some theoretical model. For a practical approach:

  1. Define ROI and success in metrics the business lives by, not a theoretical model. If IT backlog is an accepted measure and improvement in it has value, use it. If not, find an accepted measure you can unambiguously obtain and work with it to define the next step-value for improvement.
  2. Define the measure of success against a credible benchmark; the best are actual current measures or industry benchmarks. Wasting time comparing to hypothetical approaches proves uninspiring to investors, boards, and executive management. In my experience funding is only approved for "the road ahead" when both before and after measures can be evaluated in the rear-view mirror.
  3. Be disciplined: measure and regularly review. Without present-state benchmarks for comparison, improvement can never be objectively assessed. Make the first measure; then routinely measure and compare. Only then will you begin to see improvement (or not).

Last Thursday night no one doubted the Celtics' improvement. Everyone knew--not through theoretical comparison to what would have been had the Celtics drafted different players. Nor did anyone conclude the improvement resulted from subjective estimates of their ability to change. We knew because they won by 45 points, and we could explain their improvement over last season using field-goal, free-throw, 3-point, and rebound measures—stats that no one would argue, and everyone agreed were the appropriate measures for this context.

06 November 2007

WSOA: Talk Radio with our Lead Technologists

Posted by Tim Dempsey

Today we are launching a new series of interviews with Progress technologists.  Today's series features Hub Vandervoort, our CTO -- and will address topics he has found rich ground for discussion with the customers he has been visiting with in recent months.  First - SOA: Time to Value of IT, an interactive dialog capturing how Hub has counseled architects and SOA project leaders to help evangelize SOA infrastructure value with corporate business leaders.  In his inimitable fashion, he "connects the dots" in a way I believe you will find very interesting, and useful in helping build the business case for SOA initiatives.

On the heels of "SOA: Time to Value of IT" is an interview on a more technical topic which explains in detailed yet understandable terms how SOA project leads and architects should be thinking about mediation -- an overloaded term, but a critical and broad area of functionality in your SOA.  We call this "The 7 Points of Mediation," and it most certainly is intended to make you "highly effective people."

We intend to produce our "WSOA" interviews on a regular basis -- and to include a broad range of speakers, including our customers.  So post your comments with feedback and recommendations for future topics and speakers.

WSOA - Progress' Guide to SOA - Listen to insightful interviews by Tim Dempsey



06 Nov 2007
SOA: TIME TO VALUE OF IT
Featuring Hub Vandervoort, CTO

More news, podcasts, events and webinars >

02 October 2007

The fog may be clearing but SOA has always been in the clouds

Posted by Hub Vandervoort

Last week's InfoWorld article, SOA meets open b-to-b integration by Brad Shimmin, couldn’t escape my attention for several reasons. Brad makes the observation that ESB offerings seem to be appearing "in the clouds" of SaaS vendors, commercial ISVs, and now open source providers. He goes on to coin the term 'IaaS' to mean Integration as a Service, and suggests its success will be driven by the 'sudden realization' that SOA has as much to do with B2B as it does enterprise integration. Finally, from all this he asserts that ESBs in the cloud, IaaS, and SOA for B2B will all become the spoils of the Open Source community because of its cost relationship to ISV solutions. While I will enthusiastically agree with much of what this article observes, I'd like to offer a slightly different perspective that leads me to very different conclusions.

Continue reading "The fog may be clearing but SOA has always been in the clouds" »

Progress Software