Integrated Infrastructure Blog

SOA Upgrade to British Airways

British Airways (BA) is turning to service-oriented architecture (SOA) and Progress Software to connect over 600 different electronic systems and processes involved in getting BA passengers in the air.

BA has more than 250 key applications distributed over 300 locations around the globe, which explains why they chose Progress. From an integration perspective, Progress® Sonic ESB® excels in those scenarios that require the integration and management of hundreds or even thousands of systems. One Progress customer was able to deploy its integration backbone out to 25 locations a day (and can update them in a fraction of that time).

One can only guess how many of those 250 systems are touched when you travel BA. Everything from choosing your seat assignment to charging your credit card (once only please), to selecting a vegan meal is managed via systems. And let's hope those systems succeed in keeping track of your luggage.

The real-time data synchronization of Progress® DataXtend® Semantic Integrator (SI) allows BA to significantly improves information quality while reducing costs associated with data replication. And Progress® Actional® SOA Management provides BA with the visibility they need to make sure your reservation gets booked and you make it to your destination in a timely manner. Weather permitting, of course. ;)

Thanks to SOA, BA is able to extend the features of its e-commerce site right through to its airports, allowing greater self-service functionality and 'plug and play' capability to over 25,000 users.

"Moving this to a highly automated environment is a challenge, but SOA quickly proved itself to be the right approach to achieving our goal of a fully agile environment."

So the next time you take your family to London (or Disney - that's my family's destination of choice at the moment), think about how many transactions went right along the way, automatically.

I love when technology makes a tangible difference. Pretty cool stuff.

British Airways Selects Progress SOA to Upgrade the Travel Experience

British Airways announced yesterday that they had selected Progress Software for a revolutionary project that is integrating more than 600 different electronic systems and processes which are involved in getting BA passengers in the air.  This new highly automated infrastructure will bring increased agility to the airline. Rollouts will be easier, and associated cost and time will be reduced.

As is often the case with these kinds of announcements, however, it wasn’t really news to an “insider” like me.  I had visited BA earlier in the year and met with numerous people in the organization from the CTO to Architects and Developers on a number of the projects where they are implementing our technologies.  The thing that was most gratifying to me in those meetings wasn’t the scope of this cutting edge project or even that they were implementing using nearly our entire portfolio of SOA infrastructure products, namely Progress® Sonic® ESB, Progress® Actional® for SOA Management and Progress® DataXtend® Semantic Integrator (SI).  It was that, at every level in the organization, they expressed how pleased they were in the selection of Progress.  

At the senior executive level, they were discussing the partnership that they had developed with Progress and the vision we had provided to address real business challenges, for example, improving customer service by extending the features of BA’s e-commerce website into airports.  At the architecture level, there was a great sense of partnership on how the products we provided could be brought together in a coherent SOA based approach to their infrastructure that increases agility and operational responsiveness.  The developers were just happy that it really was “best of breed” technology that “just works”.  

At a time when most airlines are cutting back, it’s great to see British Airways taking advantage of what SOA has to offer and at every level of the organization they can count on Progress as a trusted partner to help.

Have you deployed your NGMP yet?

WIN has! After doing a review of their technology, WIN and their technology partner, Tech Mahindra, selected Progress® Sonic® ESB as their Next Generation Messaging Platform (NGMP). Because rapid change in the mobile sector is driving consumer demand for innovative multimedia and high-bandwidth services, they needed to look at a service-based infrastructure (or SOA) for its new platform. Here’s a quote from our recent press release:

“As mobile services evolve into widgets, applications and mobile video on-demand, much of the integration work we do to meet our customers’ service requirements is custom-built,” Graham Rivers, CEO at WIN, explained. “But to create an efficient and agile model that allows providers to roll out new services quickly, service re-use is key. SOA brings that flexibility to our platform.”

For many companies today, SOA is a significant part of improving infrastructure response. But superior operational responsiveness and SOA deployment require innovative technology to be effective. WIN knew that in order to remain competitive and deliver the best solutions and services to their customers, including Vodafone, T-Mobile, and Sony Ericsson, their NGMP needed to deliver high performance and reliable communications. Sonic ESB gives WIN the power they need to meet customer demands and deploy an event-driven architecture that will scale with technology and innovation.

Alphameric Beats the Odds with Progress Software

It’s always great when a company is willing to talk publicly about your products and services, even when the public statement incorporates a bad pun. In this case, Alphameric Solutions Ltd., the leading technology provider to the bookmaking marketplace in the UK and Ireland, wasn’t holding their cards close to their chest when they decided to collaborate with us on a press release. Alphameric selected the Progress® Sonic® ESB to revolutionize the way they handle content and messages across their network because they couldn’t roll the dice with unreliable infrastructure. Sonic’s continuous availability architecture made this a sure bet.

With new virtual games such as poker and fantasy football being released every day, Alphameric was struggling to manually keep all the feeds and databases up to date. The new SOA-based approach makes accomplishing those tasks a lead pipe lock. Alphameric can now change data more quickly, easily bring new feeds online, without gambling with the accuracy through automation.

Using Progress, Alphameric is achieving operational responsiveness, increasing revenue and improving customer service to finish in the money. You can’t beat that. I’d add that this decision puts them clearly ahead of the game, but Matt Smith, our Senior Enterprise Architect quoted in the press release, beat me to the finish on that one.

OK, I think I got that out of my system now. Sorry about that...

Smart Integration Infrastructure for Insurance Industry

Those of us who have been entrenched in middleware and SOA infrastructure technologies over the years know the importance of having a smart integration infrastructure. Well, today we released a press release announcing that West Bend Mutual Insurance, a property and casualty insurance carrier, chose Progress Sonic ESB and Progress Actional as core applications for their service-oriented architecture. West Bend Mutual Insurance will use Sonic ESB and Actional to supplement its existing policy administration system, so its insurance agents can conduct business more easily and effectively via a single integrated portal. The insurance portal will also be a critical tool to help them improve their customer retention and acquisition. The best part is that West Bend Mutual will finally be able to enjoy operational responsiveness by being able to respond to changing conditions and react more quickly to business opportunities.

For industries like insurance that need to constantly offer new products and services to remain competitive, creating an infrastructure that is agile and scalable, and one that delivers end-to-end visibility of back-end systems, is essential. SOA is a great fit. Read the complete release.

Book Reveals How to Create SOA the Right Way

The book, An Implementor’s Guide to Service Oriented Architecture: Getting it Right, explores SOA related topics ranging from design services, registries and repositories, to runtime management, and organizing for success. The book includes insight offered by AmberPoint, BearingPoint, Composite Software, MomentumSI, and Progress Software. Purchase your copy from Amazon.com.

If you are interested in a preview of the book, download Chapter 4 entitled, Enterprise Service Buses. This chapter was written by Hub Vandervoort, CTO, Progress Software. In this chapter, Hub talks about the ESB, a messaging-based communications backbone for SOA infrastructure. He also shares his collective experience of working with over 300 ESB end-users, and summarizes the styles and applications of ESB technology. More importantly, the secret to ESB success—captured in the synopsis he has dubbed the "seven points of mediation"—is revealed to illuminate why all ESBs are not created equal, and provides practical advice about how to be successful using an ESB in your SOA initiatives.

Download Chapter 4 of SOA: Getting It Right >
Podcast Seven Points of Mediation >

Don't Forget ESB-CON 8. It starts today.

Thursday, Aug 20th
10 am PT // 1 pm ET // 1700 GMT
Register now: http://bit.ly/h6fO6

Join and listen in as 3 of the industry's top CTO's talk about the ESB, SOA and software integration. Presenters include Jerry Cuomo, IBM Fellow, Vice President, CTO WebSphere, Ross Altman, Sun Microsystems CTO, Software Infrastructure, and Hub Vandervoort - Progress Software CTO, SOA Infrastructure Products.

Learn more >

Secret No. 2 - The Myth of Five Nines

Lets continue to pull back the covers on highly available integration infrastructure.

Listen now to Part 2 of the Five Dirty Little Secrets of Highly Available Integration Infrastructure podcast series: The Myth of Five Nines.

Presented by Hub Vandervoort, CTO, and Ken Rugg, VP and General Manager, Integration Infrastructure, Progress Software, this is the second of five new interview-style podcasts that reveal the software industry’s five "dirty little secrets" or misconceptions of a so-called highly available integration infrastructure.

Three minutes of downtime may not seem detrimental now but if that failure occurs during peak transaction times, it will result in lost revenue and poor customer service. In this podcast, Hub and Ken present ideas on how to deliver a highly available enterprise infrastructure.

> Secret No. 2 - The Myth of Five Nines

Tune in next time for Secret No. 3 - Recovery Time.

Simple SOA. Not-so-simple SOA.

Open Source SOA has arrived! On a single day we have one platform announce that they have simplified basic SOA, and another has announced that SOA is never simple - and if it is simple, just use web services. The question is... is there really a simple SOA and a not-so-simple SOA?

As I look at it, there is a very fine line between simple SOA and the more complex ones that require an enterprise service bus (ESB). Lines are blurred today. Now, ESB itself can be in a single container or more massively distributed ESBs with a strong messaging backbone (like Sonic ESB). But messaging backbone or not is more about the underlying integration infrastructure. So, what does it mean for the application itself? Is the model/paradigm different for the two cases? This is what gets lost out in the melee - the application models and the underlying infrastructure are quite decoupled. From an application standpoint many of the ESB mediation requirements may always be needed functionally. Can one access services without getting the data in the right format? To get it in the right format, won't we need data transformation? And security is a given in all cases. Sometimes one can look at business rules based routing to services. All of these regardless of whether it is a simple SOA or not-so-simple (more distributed multi-data-center) SOA. 

This (common treatment of all SOA use cases regardless of complexity) is very evident with the way our open source platform, FUSE, works because it has an embeddable transport layer. One could use the containers with or without Active MQ. But with or without distribution, the same functionality is available. Simple SOA? Or not?

Actional for IONA Orbix & DB

I've been on the road since the end of May and I have also moved, so needless to say, I'm behind on my blogging and tweeting responsibilities. I mean, you know you're busy when you don't have time to tweet!

My colleagues have been out there though, doing some great things. We've got some early trials going on with Actional being evaluated at a few IONA Orbix (CORBA) customers. Since the team has tweeted this, I thought I'd blog about it!

As Frank Lynch said, "CORBA users will be mighty pleased to have Actional visibility, an no performance penalty to boot." Yep, couldn't a' said it better myself.

Why is Actional/Orbix integration important?

1. It demonstrates a key differentiator between Actional and all other solutions out there... we're not designed specifically for web services. Never were. Extending Actional beyond web services started in late 2003, and continues with the work we're doing with the Orbix team.
   
2. CORBA customers are "interesting" in that they are typical enterprise class deployments. They have high message rates, are deployed in critical infrastructure, and are sophisticated deployments due to their maturity. Right in Actional's sweet spot.
   
3. In this down economy, Progress has a key advantage over our smaller competitors, so much so that it's hard to actually view these customers as competitors. Where these small guys have to go and develop new customer relationships, we can continue to delight our existing customer base (in over 100 countries) with innovative integrations between the products in the Progress portfolio. This continued innovation enables us to drive market adoption while delivering products that meet real enterprise customer needs.

On that last point, I've got a bit of a new role here. Or, better said, my role is being further formalized as Actional Product Evangelist. I'm very pleased to have the responsibility for socially-marketing some of the new integrations we are delivering to market. In particular, those integrations between products in the Progress portfolio and Actional, and between Actional and some partners. I'm hoping I can have a real impact with this formalization to my role, as well as some fun introducing Actional to some new technologies.

That said, my initial focus is going to be on IONA's Orbix, Progress OpenEdge, and Sun Glassfish. Glassfish support has been released, and both IONA and OpenEdge are in early trials (pre-beta). As I get organized around communicating these solutions, feel free to drop me a line with questions if you are interested in seeing what we've got!

Any existing Orbix customers interested in the Actional integration should contact your sales rep... or me. You're required to have Orbix 6 or later for Java (for now... we're working on the C++ and Java/C++ for Orbix 3, but they're not ready to trial yet).

PS Why not follow Maneesh Sahu (Sr. Solution Architect, Partners), Dion Picco (Engineering) , Frank Lynch (Sr. Solution Architect, East), or Marcelo Jabali (Sr. Solution Architect, West)?

SOA Infrastructure - Back to Future, No. 2

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!

 

SOA Infrastructure - Back to Future, No. 1

The New SOA Maturity Model

Originally introduced in 2005, the SOA Maturity Model white paper and the Quick Reference diagram were co-authored by business partners Systinet, Amberpoint, BearingPoint and Sonic Software. During a 2005 live webinar an audience poll noted that 40% of the webinar participants were “currently developing a SOA project,” and 37% noted that they would “begin a SOA project within the year”. That same year, Gartner, Inc. predicted that by 2008, "SOA will provide the basis for 80 percent of new development projects." (1) But over the past few years, there has been much skepticism about the ROI and business value of SOA. That doesn't mean that SOA is dead or that companies should abandon their SOA initiatives, it means that it might be worth stepping back to review your original goals and best practices, and move forward to seek the right solutions that will help streamline and cut costs.

The players have changed—Systinet was acquired by HP, Sonic Software was brought back under the Progress Software umbrella, and Progress Software acquired Actional whose product offerings align with Amberpoint—but the goals of any SOA technology provider or practitioner are the same; software reuse, agility and the improved alignment of business and IT. (I like Miko Matsumura’s 2005 post, The Rise of the Software Architect in an SOA World.)

With that, I’d like share the New SOA Maturity Model white paper and quick reference diagram which were updated in 2007. The tone may have changed slightly but it still provides a framework for discussion between IT and business users about the applicability and benefits of SOA in an organization across five levels of SOA maturity, including: Functionality, Cost Effectiveness, Responsiveness of Business and Collaborative Services, Transformation, and Optimization. The benefit of these resources also remains the same… to not only to provide a means for organizations to benchmark current implementations, but to offer a source of inspiration as IT leaders successfully advance the value of SOA within their organizations.

Enjoy!

White Paper: The New SOA Maturity Model >

Quick Reference: The New SOA Maturity Model >

1 Hayward, S. "Positions 2005: Service-Oriented Architecture Adds Flexibility to Business Processes," Gartner, Inc. Feb. 2005.

Welcoming Scottish Widows to the Family

For the record, I think I've had three hours of horizontal sleep in the last 48 hours or so, and that was on a hard wood floor - though I did have a pillow and blanket.

That said, the title of this post makes perfect sense to me... See, we've just announced (this past Tuesday) a new customer relationship for Progress - Scottish Widows. Scottish Widows is a part of Lloyds TSB Group, and is a well known provider in the life, pensions and investment industry in the UK.

The press release is typical - you can read it - but it essentially says:

Scottish Widows performed a 20 month selection of an integration platform and selected Progress' offerings because they perform better than other offerings. Scottish Widows hope to

1. launch new products faster
2. integrate easier (probably why they hope to launch new products faster)
3. lower their IT costs overall

In fact, it's this last point that's very interesting. I was only involved with the deal on the periphery but from the beginning the deployment team of both Scottish Widows and Progress are integrating metrics into determining the success of the deployment. Among other things, they will be measuring their cost savings by using Progress Software. From an Actional perspective, this means diagnosing issues faster and reducing support costs, as well as improving customer (and end-user) satisfaction.

We've done a similar case study with a Financial Services institution, validated by Forrester Research. Email me if you'd like a copy of the case study or watch the on-demand webinar with Forrester that explains the results (as a special perk to readers... you don't have to register). The case study provides real numbers about the Total Economic Impact (TEI) and measurable results achieved by this institution.

The press release also mentions that Sonic ESB and DataDirect Shadow (mainframe integration) were also selected. Congratulations to those teams, they're great products. We're starting to see some really interesting dynamics driven by customers selecting multiple products from the Progress SOA infrastructure portfolio, but more on that after I've gotten some more sleep.

Five Dirty Little Secrets of Highly Available Integration Infrastructure

Even some of the world’s largest, most demanding companies suffer from a hardware, software, or network failure. Learn more about how a continuous availability solution will protect you from lost transactions, and guarantees in-order delivery without the cost and management complexity of the 3rd party hardware or software add-ons.

Register to download our new white paper, Five Dirty Little Secrets of Highly Available Integration Infrastructure. Topics presented in the white paper include:

• Recovery Time
• Data Corruption
• Hidden Cost and Complexity

... and those are just three secrets. Download the paper >

Embedded Not-so-lightweight ESBs

David Linthicum touched upon a very prevalent problem of technology not living up to its expectations set during the hype curve! He says, "With cloud computing, SOA, or whatever we come up with next, we still need to figure out core issues within our enterprises that no set of technologies or emerging trends can solve." In the service-oriented architecture (SOA) case, we all know that the widely professed use cases of systems "automatically" looking up service registries on the web/intranet, locating the required services, getting the interfaces, picking the right one, and actually making a service request is just a pipe dream! The reality is nowhere close! It is difficult to even find enterprise wide service buses, much less the dynamic on-the-fly service-look up-and-use!

I recently came across a scenario where even a large international bank has SOA infrastructure solving regional problems - and not necessarily as a corporate backbone! I was at this tech discussion with the regional technology head of a large bank, exploring how Apama (Progress' Complex Event Processing (CEP) engine) fits into a biz requirement they have. Specifically, he wanted to understand how Apama works and how it is a good fit for their biz problem. They were trying to build a business performance tracking solution (a la GRC) that involves tracking key biz activities, ensure due process is followed, and then proactively detect potential service-level agreement (SLA) failures so they can be averted. A classic use case for Apama!

Now, when we started to see where the business events information came from and how they could be "wired" to emit the required events into Apama, we suggested that they could just tie into their enterprise service bus (ESB)—we knew they had standardized on one. As we dwell further, it turns out they are using an ESB to solve departmental integration requirements, and there are multiple instances and no central ESB that can help integrate these "departmental integrations".

Now that was a revelation. (I am not complaining because suddenly our opportunity now included Sonic ESB, along with Apama). While we have been reading (and I myself have been blogging and talking) about how SOA failed to live up to its expectations, I still expected at least a large number of banks to have standardized backbones. But not to be! I guess, like in many large enterprises, even here SOA adoption has started purely to solve departmental integration problems—more as localized islands of "integration". And its nothing like the enterprise-wide integration platforms or service bus that we have so much noise about since 2004. This reality check at this bank was a clear validation of this failure! It seemed clear that the technology promise was something, and the actual on the ground realization was something totally different!

Come to think of it, it does seem like a good model for use cases such as BAM or GRC - to have a complete platform that in addition to the CEP engine and dashboard, it also includes a "local/embedded" ESB. Now, embedded is not about being lightweight or smallas it is about being available out of the box when you get the platform. In this case, the ESB is available along with CEP, well integrated - so no surprises as you start using it. And the purpose is to "wire" exchanges from existing ESBs or applications in the enterprise to the CEP environment.

Not a bad idea at all! Embedded ESBs!

Rage against the term 'ESB' not the need for Integration

In my opinion the rage against ESBs is directed more at the term "Enterprise Service Bus" than at the need for integration within an enterprise SOA. Few bloggers would publicly discredit integration infrastructure in the same way that they rebuke the term ESB.  Corporate IT portfolios are ripe with IT systems needing to be integrated and line-of-business executives who remain disgruntled with the lack of agility shown by IT in response to their demand for business change.  So, if you replace the label "ESB" with the word "integration", I expect that the vitriol would turn to sweet loving respect if not desire.

Integration infrastructure buyers ("ESB" buyers) are learning that most ESBs that come packaged with a platform are really unadorned web service brokers – allowing simple transformations of SOAP messages but little more.  If they've done their homework, these same buyers have learned that many vendors re-label security appliances, EAI suites and even application servers as ESBs.  So there is little surprise that the term "ESB" itself has become the object of such animosity. 

Furthermore, most new SOA infrastructure applications don't need an ESB.  ESBs are designed to provide integration between applications and are often overkill when put between services within a single development team. And when real integration projects do arise the complex nature of legacy IT infrastructure makes exceeds the capabilities of these one-size-fits-all service brokers.

Many of the clients with whom I've spoken about integration recognize the vitality of this solution and are on record with their satisfaction:

• Andy Edwardson, Vice President of information technology at FAMI, commented: "In addition to tackling internal integration challenges, our goal is to create a highly available environment in which we can more easily interact with business partners over the Web. Our desire is to develop an enterprise architecture that is less 'hard-wired' and more service-oriented, allowing us to create reusable business objects resulting in a more agile business environment. The Sonic ESB will facilitate such an environment."
• Bruce Hogg, Enterprise Architect for Pacific Blue Cross, commented: "Sonic ESB allows us to leave existing processes in place while layering new business functionality on top, and it allows us to implement a messaging-based distributed infrastructure for migrating to an SOA, step-by-step."

These supporting quotes suggest that some customers have come to draw their own conclusions about what an "ESB" is and as such, support the term - provided that the solution meets their needs (and perhaps is implemented in the right way). It's frustrating that the market has put them in a position where they have to go to such lengths – it makes their job of rationalizing the options available to them that much more difficult. Perhaps in the end, we should admit that the battle of defining ESB properly is a lost cause; rather vendors like Progress focus on SOA integration in general and the value of a robust solution to this age old IT challenge.

The past will predict the future

As you have probably read in today's press and blogs, Progress is going to acquire IONA.  This is great news and I welcome my new colleagues from IONA.  But what does this mean to our combined customers?  While I am not going to directly comment on what the Progress and IONA products will look like going forward; I will review some of the past acquisitions to understand the benefits for everyone involved.

If you look at the Actional acquisition, you will see how these products have evolved over the last couple of years to not only stand on their own and compliment other vendors' stacks, but also how they have enhanced products like the Progress ESB.  The same also goes for products from Pantero, now DataXtend SI, where we support full life-cycle of canonical models and the transformations in and out to save our ESB customers many hours of work, but again also provide the same to the application server vendors out there to ensure that we never have to go into XSLT hell again.

As I said earlier I am not going to comment on combining roadmaps, etc., but you can see from the past that not only is Progress Software adding more capability to our SOA infrastructure portfolio by allowing us to help our customers solve larger and more complex problems, but we can equally play as well in combined vendor solutions.

Why should you deploy an ESB?

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.

Gain Better Enterprise Visibility of Your SOA

What if you could gain better visibility of business systems and services across your SOA infrastructure? At Progress Software, we believe that you can achieve the promise of SOA without compromising your architecture or getting locked into a single-vendor approach. Listen as Giles Nelson, Director of Technology at Progress Software, presents his observations on the challenges that you and other enterprises face when trying to identify business requirements, deploy smart solutions that will support these requirements, and how - at the end of the day - you'll be able to monitor and analyze operations so that you can make smart decisions that will improve ROI and reduce risk.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.

Learn more about SOA Infrastructure products from Progress...

• Enterprise Service Bus - Sonic ESB
• SOA Management - Actional
• Complex Event Processing - Apama
• Data Interoperability - DataXtend
• Mainframe Integration - Shadow

Loose coupling versus decoupling ...

Last week Jeremy Suratt made an interesting point on the Infor Tech Talk blog.  He says that event-driven architecture (EDA) is different from traditional service-oriented architecture (SOA) in the manner in which applications are related - or not related.  In particular he says "key to event-driven SOA is the ability for decoupled, asynchronous operations."  I agree wholeheartedly with Jeremy and think this point is one of the least well understood aspects of modern enterprise architectures and the complexity inherent in large integration projects. 

There is a great book on this topic entitled "Software Fortresses" by Roger Sessions.  Though the book doesn't mention the term SOA (it largely predates SOA and the current hype), it does point to the fundamental need for decoupling of systems through asynchronous messaging.  In the book, one of the golden rules is "never let transactions cross software fortresses."  I may be misquoting this a bit ... but the essential point is that between application domains, which are referred to as fortresses, you should allow for no dependencies which might block a transaction's completion.  This rule flies in the face of what most SOA infrastructure advocates today suggest is the very purpose of this new architecture.  Aren't we to just make a Web Service call when we want to leverage components in other systems?  Roger says - just because you can doesn't mean you should.  Once you grok these simple architectural best practices and the power it brings through "isolation", you're fast on the road to understanding the difference between traditional SOA and event-driven SOA.  The latter abides by the golden rule by inverting the control of intra fortress communications - using an event publishing rather than a service invocation model.  The former decouples the applications and the latter couples them - albeit loosely through Web services. 

Perhaps this is a long winded "dah" moment for you, but for many organizations it's still something they wrestle with daily.   Progress chose this decoupled model for the design of our integration backbone, Sonic ESB.   As a result, applications integrated with Sonic ESB are naturally decoupled.  This means you can shut down any application without impact to the overall operation of the other applications.  Unlike systems that link through traditional SOA request/reply invocation... Sonic ensures that messages get through when the application comes back online.  Now this is very different from other ESBs on the market or available through open source today.  These ESBs employ a "traditional SOA" architecture - meaning that applications connected through them are coupled via service-proxy rather being decoupled through asynchronous message forwarding.  I don't want to belabor the point, but a loose coupling of Web services is an insufficient architecture for large integration projects.   If you're not familiar with this type of ESB, I encourage you to download our latest Sonic ESB 7.6 version and go through the tutorial on "batch to real-time" processing - which shows the power of event-driven integration in the form of a continuous pipeline processing example. 

Before you start writing you own ESB ...

Vincent Partington recently wrote on his blog "before you start writing your own services and your own ESB, have a look at what's available."  Vincent point out the challenges of migrating from a home-brew ESBs and recommends against a "not invented here" attidute.  Reminds me of a dinner conversation in Winnipeg, Manitoba several years ago following my presentation of a new SOA Maturity Model to a group of local IT directors and executives.  The gentleman next to me asked a simple question - of all the services in the world (SOA) which ones are the most important to do first?  I was a bit set back by the question since I'd never had someone ask such a straight forward and obvious question.  After chewing a bit on my dinner I admitted how profound it was and then suggested - file parsing, transformation, routing, and file writing were probably the services that everyone should invest in first.  These are precicely the same set of services now offered out of the box - in both commerical and open source ESB (enterprise service bus) implementations. 

At Progress we've gone a step further to document larger enterprise integration patterns such as "batch to real-time" and "remote data distribution" on our developers network, and we also offer public code share libraries for users of Sonic ESB.  So, long and short - consider downloading Sonic 7.6 and leveraging some of these prebuild integration services, code shares and higher level EAI patterns.  I think you'll see that Vincent was right on the money with his advice, "...have a look at what's available." 

Optimizing the SOA Assembly Line

We have all been there, performing the same task over and over again - this is no different when implementing a SOA.  There are many patterns, see www.integrationpatterns.com, that can be implemented plus many techniques to develop the particular functionality that is required, and as sure as god made green apples you will have to do it again.

In the latest version of Sonic ESB 7.6 (being formally announced soon) we've incorporated templates that any developer can create by simply copying any assembly/service that has been used before and dragging it into the templates palette.  Now any time that I want to use that pattern, it just needs to be dragged onto the canvas and all the dependent files will be generated, e.g. stylesheets, etc., and you are ready to go on knowing that the pattern is good.  Note you can export from one developer to another to rapidly build up a set of templates in a team very quickly.

The cool thing is that anyone can do this, no knowledge of Eclipse is required, no programming knowledge ,etc.  With features like this we can really start to increase productivity and solve the simple very quickly, the complicated may still take a little longer.

SOA What?  Now is the time that the business is going to start viewing all SOA infrastructure projects with a fine toothcomb, so providing the ability to deliver more functionality can only be good.  Solve once repeat many, is now truly realized by the developer.

The Fat Double-Headed Arrow

We were excited to see Philip Howard's piece on the importance of a common data model. It was heartening to read our convictions about IT architecture espoused by someone with no overt commercial agenda. Though he mentions our favorite product at the end of it, we did not solicit or contribute to the piece. So we interpret his research as reporting on an industry trend where we are at the vanguard.

That bit of bragging aside, being ahead of the trend means we'd like to see a common data model become more common. To many IT folks "Enterprise SOA" still only equates to normalized interfaces and messaging.

For many years we've seen diagrams with squares, cylinders and computers on either side of and connected to a fat double-headed arrow. The squares, cylinders and computers represent processes, databases and applications. The fat double-headed arrow is labeled as some kind of bus or backplane. Ten-plus years ago it might've been labeled "Object Bus" and the underlying technology might have been CORBA. Five-plus years ago it might've said JMS or other messaging protocol. More recently the fat double-headed arrow just says ESB.

Common messaging protocols (e.g. JMS) and interface definitions (e.g. WSDL) are critical to Enterprise SOA. But messaging and interfaces focus on normalizing business processes and do little to normalize the other half of computing: the data. That is where the common data model comes in.

SOA What? A common data model (sometimes called a common information model) is the data complement of an enterprise service bus. It is a critical component of the fat double-headed arrow.

Distributed SOA

Last week I attended the Forrester Enterprise Architect forum and heard a pretty consistent cry from people walking around and stopping at the booth; "How do I implement SOA in a distributed environment?"   This question is being raised by people talking about 3 or 4 locations distributed worldwide to 500 locations in the US.  Most of the people have evaluated the competition and realize their service orchestration engines are great in a hub and spoke model but do not really support global processing.  More to the point, even if they supported the idea of distributed applications, they do not support the idea of management/control of that environment, i.e. I can deploy the application to a remote location for version 1 of the solution, but version 2 will require me to re-deploy a whole new application.  Worse than this, there is management overhead that I must place in the remote location, e.g. someone to start/stop and monitor the application server or similar.

Well now I can see these problems are solved and have been for a number of years with Progress Sonic ESB.  The enterprise service bus (ESB) provides the ability to not only distribute the service/event processing to where it makes sense - e.g. if I am a retailer and need to allow my in store POS devices to communicate - but at the same time allows them to communicate through firewalls with the various applications distributed in other stores and the corporate headquarters.

This whole SOA deployment can be managed from a central location to ensure that no IT resources are required within the distributed locations - other than to turn the hardware on/off occasionally.  Metrics and Notifications are fed up to existing management software, and I can view log files of remote applications from the central console.  Also, new versions of the services can be deployed centrally so updates can be deployed to 500+ sites at the speed of the network, and if the network is down, the ESB will hold the request until the network returns.

SOA What? If you have a distributed SOA/event-based requirement, look no further than Progress Sonic ESB. OK, so as a principle architect, I'm probably not supposed to be "marketing" on this blog, but not only will Sonic ESB allow you to create your application with minimal code in a distributed environment, but you will also be able to manage it, and reduce the time and cost it takes to make your SOA a success.

We're Running Out of Words II

It's interesting when you have a shared blog... sometimes coordinating posts with others so there is no talking over each other leads to no one posting. It's especially hard for me, as I'm a "mood poster" - meaning, I post when I'm in the mood. Fortunately, I'm usually in the mood to talk about something I profess to know something about, so there's no shortage of material.

Which of course, leads to a brief apology. I've been quiet lately, even though there is a ton of good stuff going on (not all of it in my head). I just find it hard to be creative when I'm busy, and it's been a busy few weeks (in-and-outside of Progress) for me. Probably will be for another three weeks or so... so to all my fans, my apologies!

Back in November, I jokingly titled a post that "We're Running Out of Words." Something you could, of course, never tell by how much I talk.

The idea is that we "overload" words with meaning and often don't even realize the assumptions we make (and more importantly, others hear) when we use overloaded words. The most overloaded word in our space (IMO) is discovery. Another, management.

When I first started at Actional, our mission was to educate the market. I started presentations with a slide that said "Web Services Management" -- what the market was calling our space at the time. I then went on to put big red X's through Web and Management. What we were doing had little to do with the associations that come up when people think "[World Wide] Web" or "Management." It was a challenge then, and it's a challenge now.

SOA What? Well, today, you should be asking "SOA Why Now?" - I mean, I talked about this back in November.

My brain works weird. I read Dana's post, Progress Software adds cross-process visibility with Actional 7.1, over at ZDNet, and one thing stuck in my head. Knowing that I haven't been around for a while, I thought I'd comment on how we've overloaded the phrase "Business Process" (and the associated "Business Process Management"), and as a result might be missing the really interesting point.

Let me share an customer situation: very large telco in the mid-east - actually an Oracle customer. It was about 20 months ago, so that gives you an idea of where Oracle's BPM solution was in terms of maturity. This customer needed visibility into their business processes. Oracle told them (as would most anyone out there, I'm singling out Oracle, but picking on everyone) if they wanted to track business processes, they needed to implement them in a BPM engine. Long story short, they took their existing processes and implemented them in Oracle BPM. It was hard to do... so they only implemented their most important processes. Once implemented, they realized they had only 1/12th of the performance they had before - all in exchange for knowing where a process fails and being able to track it from end-to-end.

So, let me summarize:

1. They reimplemented processes that were already working just fine. BPM offered no process-value-add.
2. They were limited to their most important processes because of the difficulty they had implementing their processes in a BPM engine.
3. They suffered performance and scalability in exchange for visibility; visibility that was limited to what was going through their BPM engine.

This is the key point that Dana, and I think everyone else, misses when they look at Actional. Processes don't need to be orchestrated to be managed. Ad-hoc processes can be managed just as easily as anything else. And, perhaps, that means in some cases (not nearly the majority - but some) BPM isn't needed. I'd argue that most processes are actually informal... and only become formal so they can be orchestrated and controlled. What if you could gain all the visibility and control you need, without the overhead of orchestration?

Instrumenting an SOA infrastructure with Progress® Actional® means they get all the visibility they need, into ALL their processes, whether those processes are orchestrated or not, without impacting performance or scalability, and they get it cross-platform and protocol:

• All the visibility they need; anything on the platform is automatically displayed and correlated across the entire infrastructure.
• All their processes; since there is no need to change code or re-implement a process that already works, every process (ad-hoc or orchestrated) can be tracked in real-time and, more importantly, in the business context in which it is executing [that telco I was telling you about had a provisioning service - we were able to track it for landline vs mobile separately with just a few configuration steps. Then, we enhanced tracking by separating mobile provisioning into pre-paid and post-paid just as easily, and without affecting performance].
• Without impacting performance or scalability; if Oracle slowed things down to 1/12 with just some processes orchestrated, then we can be said to have been more than 12x faster than Oracle!!! And, Actional has no single point of failure like a BPM engine (and many other service management solutions) does.
• Cross platform and protocol; Do I even need to explain this? Gosh, we have customers using TIBCO BusinessWorks alongside Sonic ESB, and exposing everything as web services over SOAP, and we can track everything end-to-end from the HTTP call to the portal, to the service, to the "bus", to the BPM engine, out to the database, and back - synchronously or asynchronously. A mouthful, I know, but cool nevertheless.

There's a reason Forrester ranked us #1. But, to know what they know, I need to ask you to listen to what we mean, at least until we can make new words.

By the way, if you want to see this end-to-end visibility yourself, apply to evaluate the solution. It won't include the business process "stuff" we do, but will give you an idea of how easy it is to discover and correlate across platforms and protocols.

Multiple ESBs: SOA Reality in a Federated Environment

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 .

"But, what do you DO?"

My grandfather's curiosity makes him seem younger than his 90 years. After the war, he, an immigrant in NY, became, among other things, a tailor. For the past 10 years or so, each time I've visited, at some point the conversation would turn to my job, and he would pointedly ask, "But, what do you DO?" I didn't quite understand his emphasis on "do." So, I'd respond that I travel, talk to people, listen a lot, and ultimately advise customers and our field on ways to move opportunities forward. I'd give examples. In return, I would get a confused look and a repeat of the question, "but what do you DO?"

Finally, one day in exasperation he says, "When I went to work, I made clothes. When you go to work, what do you DO?" Now, that was awkward... you see, I don't really DO anything. I'm an enabler. I'm more like a carrier of a disease than a tailor. I travel around picking up experiences in one place and leaving them in another.

I know... fascinating. But, SOA What?

Well, we just had our annual sales meeting here at Progress. And, coming off a great year, we Actional people were pretty popular. I was delivering the Actional message to a group of new employees - which I consider the 2nd most fun thing I get to do all year - and they kept asking, "what's the business benefit of Actional?"

What's the business benefit of Actional?

I'm not going to answer that here. Suffice it to say that my answers left the people in the room last Sunday somewhat unsatisfied. They wanted something tangible to take to their prospects--something that would quickly and dramatically get their attention and priority. I gave them talking points that they could use to start conversations, but nothing that would turn people's heads. The whole thing got me thinking...

Can an enabling technology have a direct business benefit?

Notice the word direct. I think an enabling technology enables business benefits. But, it requires some deeper understanding of the business situation, and then the application of technology expertise to that situation in order to achieve some tangible benefit.

An example will help. Actional has a large number of travel and hospitality customers. We help them optimize their delivery of product across various channels. Using Actional, these companies are able to differentiate service levels by customer, channel, and dynamically based upon, among other things, immediate local market conditions. In one case, a company has saved millions of dollars on hardware investment by better utilizing their shared infrastructure. They optimize their SOA infrastructure based upon "business level SLA," rather than blindly adding capacity. In short, they more closely coupled their "business" with their "infrastructure." These benefits apply equally well to any services business, and in my opinion will be a critical differentiator in the coming years.

If you look at the benefits I just described, you might think we compete with a highly customized point-of-sale system, or some reservation system, and probably a bunch of other things, however, as much as people want the "soundbyte", it's simply not the case. We don't really do anything tangible for these companies, though we are a key part of their enterprise infrastructure for delivering a highly differentiating service. I think there was a Dupont commercial that summed it up quite well... "we don't make your business systems, we make your business systems better."

Once my grandfather realized I didn't actually "DO" anything, he was able to start to understand what I accomplished. Perhaps we need to look at enabling software the same way?

Business visibility should be a driver for SOA

I've just read a Gartner research note by Massimo Pezzini published on the 16 November. It's titled Greater Business Process Insight Is an Unexpected Benefit of SOA. It argues that an unexpected and unplanned consequence of SOA projects is that organisations gain better visibility of their business processes and business data. It recommends that organisations think and plan about things like Business Activity Monitoring (BAM) from the outset.

I was surprised by this and also disappointed. Not because I don't agree that better business visibility is a consequence of SOA – it is. What surprises me is that this is still seen as noteworthy. It shows how far the industry still has to go toward understanding the merits of enterprise architectures which give them more open, simpler, more flexible access to real-time business information. service-Oriented Architecture (SOA) is about service reuse, open standards, etc. etc. But you're doing this for a reason, not for its own sake. Surely one of the benefits of a more open, flexible architecture is that you can get at your business information better so you can drive efficiencies in your processes, identify threats and opportunities more quickly, and better communicate with customers, etc?

Some organisations do recognise this. Only last week we responded to an RFI which not only included "usual suspect" SOA requirements satisfied by such things as an Enterprise Service Bus (ESB), but also requirements for event processing and BAM. The organisation recognised that the building of a SOA infrastructure gives them access to business event streams that they can obtain value from immediately. They had indeed expected this consequence and were planning for it.

SOA What? These kinds of requirements will become the norm. Real-time access to enterprise information is becoming more relevant in a whole range of industries – we're seeing this directly in some of the engagements we're involved in. Furthermore, event processing and BAM are at the more business end of the SOA universe. One of the things that the industry harps on about is that the business rarely sees the relevance of a SOA initiative. By taking the advice of the article and thinking about these things apriori then perhaps not only can organisations get more out of their initiatives but also CIOs can gain a little more credit from the wider organisation.

Buying and Driving your SOA

When I get around to buying a new car, I know what is important to me. Being 6 feet 4 inches tall the first criteria is whether or not I can sit comfortably and see myself driving many miles, and then small things become important, like whether I can see the lights at an intersection. The comfort criteria is independent of the car and must be applied to all cars that I try, although I do like the image of relatively fast cars. When you look at what I drive, it might surprise you, I have a Ford Focus SVT which is good for 140 mph and 0-60 in about 6-7 seconds I am told. Many people have asked why I do not drive a SUV or similar and the reason in many cases for me is that they typically have less room for a driver of my proportions than my Focus.

When I bought my car, there was a lot I already knew. Having driven many cars, I knew where the steering wheel, radio, rearview mirror, etc. were and I knew that I could drive the car without a specific driving course, although to push the limit and understand how it would go 140 mph on a sweeping right hander would probably require a day at some race track. My wife on the other hand has to transport kids to the school and to soccer practice so her vehicle of choice is a minivan.

Now that I have shared with you some of the reasons how my family chooses cars, you may be wondering how this relates to SOA. Well, last week in a meeting with customers and prospects alike, I was getting questioned on selection criteria for ESBs and SOA infrastructure technologies.  And in nearly every conversation, the same criteria was clear - how many messages per second, how much memory, etc. etc., and only a few really came up with a statement such as "We are facing challenge X and would like to solve it?" This is the most important question because just like my car challenge of "sitting comfortably for long periods of time" outweighs the need to do 140 mph (which I have yet to do), if I bought a car that does over 150mph, it would probably be gone by now as it might not meet my primary needs. And lets face it, how fast do any of us really need to drive? Even the cheapest car on the market will do 80mph all day.

Using standards such as Web-Services, JMS, etc. also means that developers can apply the same disciplines to one technology as another - in much the same way that most drivers can switch cars. If it did not, Hertz and other companies would not be in business. Which brings me to the second theme of questions and comments I was getting, "What do my developers have to learn to be successful?" They have to learn to transition from one environment to another but still be able to apply the same core software engineering practices. For instance, you would not write all your business logic in one Java class so don't do the same in one ESB process. In CORBA you would not make every object accessible, so why do you try to make every Java object a web-service?

SOA What? Buy the technology that makes sense for you and your business, e.g. if you are a distributed manufacturing organization build/buy a SOA that can be deployed and managed in a distributed manner.  If you are dealing in high volume transactions or events, you will, like a racing driver, need to look into performance. Once you have chosen your SOA technology, remember to still stop at red lights, and not to redline the engine at every gearshift. The speed limits may have increased, and you can break them later, but they still exist. And just like I would get special tuition to drive safely at 140 mph, remember to call on the experts of your SOA to drive at the limits.

Progress Sonic Extends Lead in Distributed SOA

Today, Progress Software announced the release of Progress® Sonic™ Deployment Manager (SDM). The Sonic Deployment Manager is an installation and configuration tool that helps project teams streamline incremental development and rollout of large-scale Sonic product deployments. By automating the installation of Sonic products (including Sonic ESB and SonicMQ) and tailoring the configuration to suit each host, Sonic Deployment Manager reduces the time and cost of project development, delivery and maintenance.

Two of the key use cases for the Sonic Deployment Manager product are lifecycle management and large scale deployments. In both of these use cases SDM delivers on the critical need to have consistent, repeatable deployments both between lifecycle stages and also across a widely distributed environment. Unique to SDM is its ability to create a completely reproducible package of all components and configurations of a given deployment instance. This capability allows precise rollback and re-creation of any given environment, enabling configuration management, auditing and regulatory compliance.

Learn more about the SDM >
Read the Press Release >
See What's New in Sonic ESB 7.5 >

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

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.

Understand your organization before you architect your SOA

John Radko of GXS had an interesting blog entry about SOA versus ESB - Conflict or Collaboration where he talks about whether ESB and SOA should always be put together.  Since SOA is an architecture but an ESB is a product, deciding whether your architecture should depend on a specific product is an important question to ask yourself.

The interesting thing about this question is that answering it has little to do with technology.  In fact, the right approach has to do with the existing power structure of your organization (whether "organization" for you means project, division, or even enterprise).

Drive Operational Excellence with an ESB - SOA Success

A few months back Progress Software hosted an online event called, Drive Operational Excellence with SOA. The webinar featured a guest speaker, and customer, from Pacific Blue Cross who discussed the challenges of moving from a legacy batch and manual processing architecture to a leave-and-layer approach with an Enterprise Service Bus (ESB). Deploying the messaging-based ESB in their SOA infrastructure gave Pacific Blue Cross the ability to wrap new services around existing services. The benefits that Pacific Blue Cross and other ESB customers gain by this approach include: Reduced business process cycle time; improved consistency and visibility of in-process data; reduced cost of errors from manual intervention; cut costs of processing peak transaction loads; and improved flexibility to handle future business change.

The Approach to a Successful SOA

As an ESB practitioner for the past 4-5 years I am often asked what is the best way to make a SOA project successful, my response 'An initial win, followed up by small successful iterations,' the main thing that people are taken back about in this statement is the lack of technology and standards in the response. Yes, technology and the supported standards will help dramatically with achieving this, but it is an aid to the vision of the business, architect, or other that is pursuing the SOA vision - without that vision the project will not be successful regardless of technology.

The initial win might in fact be the easiest part of this statement, as in many projects this might be a Proof of Concept or initial pilot that is built with little regard for the challenges that are about to hit the project. However, with a bit of planning and some guidelines for the development and layering of SOA applications, it is possible to achieve the statement 'followed up by small successful iterations.' To achieve successful iterations each subsequenet iteration in the project should build directly on services built in the prevoius revisions.

To prove reuse and agility I recently created a simple demo for a distributed query across four databases, this was created in top down approach allowing the quick win to be achieved in which the sample end user portal could simulate requests within minutes of starting the project and before the databases were even defined. Then the data aggregation and connection level services were created in about another 2 hours, allowing essentially 3 phases in 21/2 hours. And now the unexpected benefits; for the next use case which was Remote Information Data, or given a document entering the ESB route it to the appropriate back-end datasources. This was done in about an hour as I not only reused some of the service instances, but the associated artifacts such as Integration Workbench projects etc.

For both use-cases I used 3 service types, 5 projects and 21 ESB Processes and not a single line of code (Java or .NET) and have the ability to reuse most of these as my demo is extended.

Serving Justice Better with an Enterprise Service Bus (ESB) - Tarrant County, Texas

As law enforcement and prosecution agencies across America seek better ways to share information on criminals and case files, it becomes apparent that there needs to be a faster way to reach the truth. For Tarrant County, Texas, real-time availability of information is crucial to expediting and improving its criminal justice system. With 41 incorporated communities and more than one million citizens, Tarrant County is the one of the fastest growing urban counties. But also growing are the difficulties, expense, and latency of circulating paper case files and sharing electronic information among county entities. Tarrant Country wanted real-time access. Being able to move beyond old-school methods and workarounds for information retrieval to a comprehensive, real-time justice search-and-find engine was just what Tarrant County wanted. After researching technologies and potential vendors, their IT team selected a service-oriented architecture (SOA) framework from Progress Software. Their enterprise service bus, Progress Sonic ESB provides a federated approach to alignment and automation of critical data applications for greater visibility and flexibility across distributed environments. Sonic ESB simplifies and mediates connectivity of existing and new applications. With Sonic ESB now a significant part of the enterprise architecture, Tarrant County is able to facilitate its ambitious integrated justice program and enable the IT department to operate an information utility service. Sonic ESB simplifies and mediates connectivity of existing and new applications - which function independently on existing platforms but gain full participation in the bus topology - to orchestrate and control end-to-end business processes, without recoding requirements. The result is immediate, seamless, cost-effective integration and communication. Read the Progress Software case study.

Business imitates baseball *

If you follow Major League Baseball, you know that below the surface of the run-of-the-mill baseball "news" is the story regarding Barry Bonds' pursuit of Henry Aaron's career home run record.  As I write this blog post, Bonds has five home runs between him and outright leadership in this important category.

The discussion around the validity of Bonds' achievement is rich and emotional.  Fans in ballparks where Bonds plays bring poster boards with large asterisks on them, indicating support for a broadly held view that under the influence of performance-enhancing drugs (steroids and the like), this and other achievements in various categories should be considered dubious.

Sometimes business imitates baseball.  In recent market share research, a funny thing happened.  Like athletes on performance-enhancing drugs, vendors who were nowhere in the pursuit of leadership and market share in the Enterprise Service Bus category are now share leaders.  From zero in 2004 to 20+ percent market share in 2006.  Further evidence of how performance has been enhanced: the share positions of IBM, Oracle, TIBCO and BEA in 2005 suddenly changed -- that's right, the results for 2005 also went from zero to 20+ percent share -- during 2006!!  Miraculous!!  *******

SOA What? Sure, analyst firms like Gartner group can change their definitions and as a result numbers can shift.  But just like baseball fans need to look closely at Bonds' achievement and assess its relevance when considering the conditions under which it was achieved, so should enterprise infrastructure buyers look closely at the claims the bulked-up software giants are making.  You know the SOA opportunity is great when it causes this kind of behavior on the part of very large industry players.  Like baseball purists, SOA infrastructure purists need to stick to their principles.

I see events. They’re everywhere.

After having been involved in the study and implementation of advance event processing techniques and technology since the mid 1990s, it’s gratifying to see this field getting much deserved attention. In a recent presentation, Yefim Natis of Gartner, predicted that Complex Event Processing (CEP) will be one of the five most significant IT trends over the next few years. Yefim also noted that CEP will increasingly become the foundation for the next generation of Business Activity Monitoring (BAM) applications. This is very good to hear as this is a conclusion that we have also reached.

One reason the market is getting excited about CEP is that event-capable middleware—most significantly the Enterprise Service Bus (ESB)—is now becoming mainstream in corporate IT. ESBs, most popularly regarded as the critical messaging-based backbone for SOA implementations, are just as capable for event-driven architecture (EDA) implementations because of their messaging heritage. EDA takes the SOA principle of loosely coupled services one step further – to decoupled services. Whilst the interaction model is a little different, the underlying technology remains the same so ESBs provide an important driver for CEP adoption. Along with the adoption of these technologies also comes familiarity with the whole event processing model, and the technical skill and best practices that go with it. The result—in short—is the sudden availability of business event on a much more pervasive scale. Here, the event processing version of Metcalfe's law kicks in—the value of CEP is increases exponentially as more events become available to process. That is, as long as your event processing infrastructure can handle it.

Another reason interest in CEP is rising is the proven success of the technology within capital markets. Not only have most of the leading investment banks adopted CEP to implement their algorithmic trading and risk management systems but now the financial markets and regulators are adopting the technology to monitor the market in real time to detect compliance violations or patterns of fraud, like insider trading. For example, the Financial Services Authority (FSA) is adopting CEP technology to help monitor the UK markets and enforce MiFID compliance in an increasingly fragmented trading environment. The system called SABRE II is being developed by Detica. You can read about it here.

But it’s not just capital markets that will benefit from CEP. It is also being adopted on the manufacturing floor for process control and improvement, in logistics applications for early detection of supply chain issues, in retail RFID for inventory management and security, by military branches for situational awareness of the battlefield, and even by casinos to help their monitoring of suspicious gaming behaviour. It seems events are everywhere these days.

I was recently at an academically hosted event in Germany. Many vendors and practitioners attended and many themes in software were discussed – BPM, BAM, SOA, CEP amongst others. What came over loud and clear in the sessions was that CEP was increasingly seen as a major new and important capability that fitted well into the SOA world. An ESB for example was important in giving the foundation for the gathering and analysis of events from around the enterprise.

As more and more organizations embrace SOA infrastructure that supports event processing—and the event processing skill set that goes with it, the value of CEP technology will continue to rise. In fact, expect interest in CEP-powered applications (BAM and otherwise) to be a real driver in infrastructure investment over the next few years. Soon you’ll hear many more CIOs saying: “I see events. They’re everywhere.”

Reduce Business Process Cycle (BPC) Time with an ESB

A few months ago Progress Software hosted an online event called, Drive Operational Excellence with SOA. The webinar featured a guest speaker, and customer, from Pacific Blue Cross who discussed the challenges of moving from a legacy batch and manual processing architecture to a leave-and-layer approach with an Enterprise Service Bus (ESB). Deploying the messaging-based ESB in their SOA infrastructure gave Pacific Blue Cross the ability to wrap new services around existing services. The benefits that Pacific Blue Cross and other ESB customers gain by this approach include: Reduced business process cycle time; improved consistency and visibility of in-process data; reduced cost of errors from manual intervention; cut costs of processing peak transaction loads; and improved flexibility to handle future business change.

A Rose by Any Other Name...

Jason Stamper posted recently about Progress and the organization changes "to make its Sonic division less autonomous."  Read his post.

So why would the corporation make such a decision?  I think it is eminently clear.  Look at how acquisitive the traditional platform suppliers have become in recent years: IBM, SAP, BEA, Oracle.  What have they acquired?  Technologies like Progress has in Sonic's ESB, the Apama event processing product, Actional's SOA management.  Why?  Because those market spaces are incredibly exciting, growing rapidly, and threaten the franchises IBM, SAP, BEA and Oracle (among others) have built over the past decade(s).

As a result, Progress has elected to assemble a portfolio of products to expand the value proposition we can bring to customers and prospects -- and the affinities across the Sonic, Actional, DataXtend and Apama product lines are obvious -- even to industry analysts (;-).  I recently published a white paper -- The Right Infrastructure for SOA, which goes into greater detail.

But unlike the millstone-necklace-laden platform vendors, we have chosen not to pour more wet concrete around our installed base footprint.  We take a different approach deliberately because we believe each of our products should be able to stand and deliver value on its own—be it our industry-leading ESB, Actional for SOA visibility and management, Apama for complex event processing or DataXtend for dealing with the challenges disparate data models in an SOA environment. Not only do we believe it, but we can prove it. Actional is deployed as often along side competitors' ESBs or application servers as our own; IBM Global Services endorses DataXtend Semantic Integrator for use in telecom integration; and Sonic is often called upon to connect disparate platform stacks. It’s this fierce product independence that frees us from protecting a franchise.

That said, customers, especially large enterprise customers, need to buy from a vendor they can trust and one that’s not going anywhere – Progress has been in business for 25 years and demonstrates rock-solid performance year after year. While it’s not always easy to convince customers (or the press) that we’re committed to the independence (yet interoperability) of our product lines—it’s certainly difficult to imagine a vendor making a bigger commitment to product autonomy in this age of the super-size-me platform.

SOA What? Customers and prospects have lots of vendor choices for SOA infrastructure.  We believe there is an important difference in our approach from those of the gargantuan platform vendors' offerings. We believe the platform vendors are uniquely unqualified to address the mediation, management and communication issues that occur amongst and between platform environments in your SOA.