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.

CORBA is now Actional-ized!

This is really cool, and I can finally speak about it. Wow, gag orders just don't work very well for me. I mean, I can keep a secret, it's just that the really juicy ones are harder to keep than the others! And, this one's juicy. Ready...

Today we will release Orbix 6.3.4 with support for Actional.

Whoa! I bet at this point a lot of you are like SOA What? (yeah, remember that blog-ism we did here back when SOA was cool?)

Well, let me give you end-to-end visibility into the import of that sentence above.

As with all the other technologies we cover, including the recently announced SAP ABAP integration, Actional integration with Orbix gives customers:

1. End-to-end message flow visibility across an entire CORBA environment, in run-time, without any impact on performance or scalability. That same visibility extends beyond CORBA, and does so consistently to provide a unified view of message flows and business transactions in their environment.
2. The ability to centralize run-time policy creation, allow for distributed enforcement across multiple environments, and to ensure compliance with corporate and regulatory policies across the entire messaging infrastructure.
3. The same tools our current customers have that help them achieve an 80% reduction in time to resolving critical production incidents and a 20% reduction in major production incidents per year by simplifying root-cause analysis and problem resolution.

Now, you might think with all these great benefits, there would be a high cost. Nuh uh!!!

• No additional coding changes to get this up and running. Instrumentation of all CORBA services is automatic.
• No architecture changes, Actional won't impact scalability.
• No extra capacity required, Actional won't impact performance.
• No additional staff are required, dependencies are dynamically discovered and maintained to help keep the cost of ownership low. In fact, case studies independently verified by Forrester Research of our customers who are in production showed a rather quick payback of the investment due, in part, to the low cost of ownership.

Of course, if you follow Actional and Progress at all, awesome technology is old news. Actional has been working on non-SOA distributed applications since early in the development of our product and anytime we add a new technology, protocol, or platform, we've always added the same rich features, while maintaining the enterprise-class performance. Let me say that again, because I've accidentally brought up a very important point.

The single Actional Agent adds all of the functionality, across all of the protocols and platforms, and provides the same outstanding performance you've come to expect from us. In contrast, many other vendors can support all the platforms/protocols, and all the business-transaction-management features, and do so non-intrusively... but THEY CAN'T DO IT ALL AT THE SAME TIME!

Back on track, sorry for the diversion. I'm almost done here, I promise.

There are other equally interesting implications from this release that I'd like to share (in no particular order).

1. This helps to, in part, validate the strategy that lead us to acquire IONA in the first place. There are a lot of cross-product synergies.
2. This continues to prove the applicability of our technology far beyond the common understanding of SOA infrastructure (SOA and HTTP/JMS). We have successfully broken out of the "SOA management" niche, and are providing real value to customers across the entire breadth of business transaction management needs.
3. In this "recovering" economy, Progress can help customers gain more value from their legacy technology investments by upgrading the capabilities in mission critical platforms like Orbix/CORBA. Whether it's from the operational perspective of lowering their operating costs while providing higher-levels of service, or from the business perspective of preventing "revenue leakage", Actional solves real-world problems without impacting the architecture or requiring coding changes to existing applications.

In closing, I wish I could share some of the early adopter customer quotes here. I can't, but the feedback from the (former) IONA field was equally funny. The IONA field is (relatively) new to Progress and hasn't necessarily developed the instant-automatic love for each-and-every Progress product because we all share a logo color scheme. We actually had to prove ourselves to these guys and gals (a very capable team I might add). Once the engineering team was finished, they took the early software and implemented it at some rather large (and equally skeptical) customers. After running it through it's paces, people were actually smiling. When was the last time you saw beta users smiling at performance results? To quote one guy working at a large airline... "it simply worked the way it should."

Beat that!

Now That's What We Mean By Performance!

Was visiting a customer in Switzerland last week and a funny thing happened.

They presented us with where they are in their deployment... they've deployed their first "major" application early last year (Inventory Management), and this year are planning two more applications in the suite to be deployed in 2010 (E-Ticketing & Centralized Checking-in).

They're using a very old version of Actional (v6x), and I was hoping to help them understand why it was important to upgrade to the current release (v8.0). The Inventory Management application contains about 300 applications (including TIBCO BusinessWorks and Oracle/BEA WebLogic Server), and is designed for 400 million messages per month. They're currently doing about half that. (It was really cool to see the Actional console with those sorts of numbers in the dashboards!!!)

Each of the new applications will probably add a similar amount of traffic. 1.2 Billion messages per month. Surely, there's my in.

I started talking about how we've made major improvements to auditing performance, user-interface usability in large scale environments, and CPU and memory utilization, along with general performance improvements you'd expect in two years of development. I was sure this was a certain driver for them to upgrade to a recent version, when the lead architect from Progress leaned over, and whispered in my ear...

The current architecture's not even breathing hard. Even with that traffic growth, we'd probably only be at 30-40% of design capacity.

What can I say? We have a really fantastic engineering team.

And, I'll have to work with the customer on building a business case for upgrading using a different angle.

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 >

Meaningful Measurements

At our annual sales kickoff in Miami last week, I heard a story about one of the Regional Sales Managers that put a smile on my face, and it made me like Progress a little more. When asked by the CFO how he did last year, the regional sales manager responded "six cents".

Six cents. Huh?

Well, apparently there is a culture here at Progress that you look at regional profitability, and then each sales manager knows how their deals affect the company's bottom line. Being a numbers geek, and one who likes to measure things properly, I think it's cool.

SOA What? Well, I also heard a story about a new Actional customer who had over 98% up-time for their IT systems last year - a number they were proud to report. (Realizing, of course, that each industry has its own benchmark for up-time.)

They were proud to report it but it was meaningless to do so...

Why? Because as it turned out, while they had this brilliant up-time of their underlying infrastructure, something was preventing their largest customer from receiving any information for over three weeks. Do the math, 52 weeks in a year - down for 3, that's almost 6% downtime.

Where was the discrepancy?

The IT team was not tied into the business and was assuring system up time but NOT assuring their business transactions. So now, in order to gain credibility with the business and to make more insightful technology decisions in support of the business, the team chose Progress Actional as the management solution for their SOA and distributed applications (links to good article on what this is about by Anne Thomas Manes). Hopefully, they'll do better next year.

Have you ever had a situation, even in your personal life, dealing with a company's technology where they say all the systems are up but still, it's not working? Create a comment here and share your stories...

"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?

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.

9-Reasons to Use Sonic for Your Next IBM Websphere MQ Project

You have to simply stand back and admire a crisp and clear expression of a product's differentiators in a complex and competitive market. Working with some of our recently-delighted customers, erstwhile subscribers to IBM blah-blah-blah, our Sonic team developed this crisp expression of Sonic's advantages over IBM -- and where in an IBM Websphere MQ deployment you are likely to find them. Hat's off to the Sonic team!

Nine Reasons to Consider SonicMQ for Your Next Websphere MQ Project

• Because… when a broker fails, SonicMQ provides a hot mirrored backup broker so that:

  1) No messages are trapped in the failed broker.
  2) There is no need for specialized disk devices or expensive hardware.
  3) There is less error handling code needed in your applications.

• Because… when a network connection fails, SonicMQ provides automatic reconnection to the hot mirrored backup broker so that:

  4) There is no loss in state associated with the message exchange.
  5) There are no lost messages between your application and the broker.
  6) There are no duplicate messages or out-of-order conditions as a result of restarting the application.

• Because… when anything changes in your broker or client deployment, SonicMQ provides distributed configuration management so that:

  7) You don’t have to spend time assessing the impact to your topology
  8) You don’t have to find and update dozens or even hundreds of configuration files across multiple possibly remotely located machines.
  9) You don’t waste time debugging all those manual configuration changes or rolling back your changes.

If these nine reasons aren’t enough to convince you that your next WebSphere MQ application isn’t better served by SonicMQ, then we’ll have to give you the names of our capital markets clients, airport operations clients, medical device clients, ERP vendor clients, and the guys who run the large hadron collider in Cern, Switzerland. Maybe they can convince you.

Progress SonicMQ—when you and your application can’t tolerate non-sense anymore.

SOA What? Best-in-Class independent vendors have to sharpen their knives as the saskwatch-footprinted stack vendors begin to tread on their space.  Only by finding crisp and specific, and deadly, points of vulnerability can the smaller upstart continue to thwart the giants.