Business Making Progress

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.

Try to Stick to the Problem and Describe it Well…

So far I have been sitting on the sidelines and following my blogger colleagues fairly regularly in an effort to understand (and agree or not) with their mindset, which blogging is ultimately meant to do.

However, I could not pass up the opportunity that my esteemed colleague and prolific blogger David Bressler has extended me in his post “On Roadmaps and Future Product Features…” (thanks for introducing me David!).

David’s stance on the question he raises, “What problem does a product strategy solve?”, is fundamental and one which I would like to build upon in my debut into blogging. 

What drove me was a very interesting experience I personally had last year during a seminar I was attending from Pragmatic Marketing Research; There was a small workshop-type exercise in the seminar whereby each attendee was invited to describe a customer problem situation that they had or were currently facing, which would have ultimately resulted in formalizing a requirement. Like many product managers, most of them (including me) came from an engineering background, with a very technologically driven perspective on problem-solving, especially in software.

As the exercise proceeded, most attendees took turns describing their customer situations with technologically rich details with a lot of insight on how to solve them. More often than not, I kept on hearing the instructor’s comment after each presenter:

"…but what is the problem that you are solving, never mind what technology you will use? ... don’t tell me how to solve the problem… describe me the problem you expect to have solved…"

This went on for several iterations. The one that stuck on my brain up to this point was:

"…describe the problem in such a way that your grandmother would understand…"

Although, in my opinion, it might be pushing it a bit for my grandma to understand problems that SOA is expected to solve, since then I have come to develop a true appreciation to simply and properly describing a problem. Once it is clearly understood, then technology (SOA or otherwise) can readily be applied in solving it and solving it well.

SOA What? In listening and hearing myriads of so-called requirements from the people in the field (customers, prospects and sales folks) all greatly in tune with SOA infrastructure themselves, it makes a lot of sense to take a step back--albeit for a minute--and examine what problem are we solving and describe it in a technology-agnostic way, as much as possible. Believe me, it not as easy as you might think…

What type of CIO do you need for SOA?

There's been a lot of talk over the last week around Burton group's report on SOA adoption.  Most recently I read Dave Linthicum's Should you Fire your CIO blog entry and I totally agree.  Not that I mean you should fire your CIO, but there are definitely different styles of CIO's - and if you have the wrong kind maybe you need a change.

What I find most valuable about the Burton report is that, unlike many of the other recent SOA surveys, it doesn't rely on self evaluation.  After all, if I'm asked whether I'm ugly and smell bad, my answer would be "no" (whether it's accurate or not) - this is what people smarter than me would call "cognitive dissonance". So self evaluation isn't a very reliable way to measure SOA success.

That said, back to the topic of CIOs.  There's a pattern I've seen: the "change and go" CIO.  Certain CIOs make their living coming into an organization to shake it up, change it, get it going... and then they leave onto the next company that needs their help.  In a number of cases, I've seen SOA infrastructure initiatives kick started by a "change and go" CIO.

Why does this work?  These CIOs only go to companies that recognize they need to change - so you've got a fundamental ingredient for success: a mandate for change, driven from the top - and someone to make that change happen, with no desire to carry sentimental baggage forward if it doesn't make sense.  Now, I don't have data to support this, but I'd hazard to guess that more than a few of the (small number) of success cases that Burton found were a result of one of these "change and go" CIOs.

If your organization is looking for a change, it may make sense to look for one of these unique breeds of CIOs.  The one thing you'll want to do, however, is interview the CIOs that came after the "change and go" CIO to make sure that they didn't achieve their short term results at the expense of long term pain (which only the next CIO will be able to tell you!).

SOA: The New Tower of Babel

The Tower of Babel was an engineering marvel that failed nonetheless. Like the great tower, SOA represents a revolution in “infrastructure,” the very scope of which threatens its success.

According to the biblical account, before the Tower of Babel was built, to glorify the city of Babylon, everyone spoke the same language. The architect’s vision was to have the tower reach the heavens as a way to make a name for the citizens of Babylon. Unhappy with the motivation for the construction, or so the story goes, the entity upstairs decided to “confuse their language” and make it impossible for the people of Babylon to communicate successfully to complete the tower.

Without the ability to communicate the people were unable to take advantage of the great infrastructure and they were ultimately scattered far and wide, losing not only their tower, but their community.

Like the Tower of Babel, SOA infrastructure projects begin with a vision predicated on successful communication. It seems reasonable to try to get all the applications and services to speak the same language; just wrap components in well defined service interfaces using industry standard WSDL and all the pieces will be able to talk to one another.

Unfortunately, as with the Tower of Babel, things change. In SOA projects, however, it isn’t “divine intervention” that causes this change, but more mundane concerns. Systems are added to the integration project, new understanding is gained about the systems that are included, and existing systems are modified to accommodate new requirements. Before you know it, the systems no longer speak the same language.

I recently had a conversation with the CIO of a major telecommunications service provider. When presented with the idea of a common model-based approach to integration, he said that they had been trying for years to get everyone to speak the same language. The problem was that every time a system was added, it brought along new requirements, and they essentially had to create a new “common model” to accommodate it. The old systems couldn’t speak the new dialect and they had no tools to find the dependencies and integration code in their systems that would be impacted by enhancements they made to the model to support the new systems.

Because of this, the old common models and technologies used to transform in and out of these models needed to be maintained. They used multiple versions of the “standard” messages to communicate between services, thereby ensuring that there were no standard messages. The integrations were effectively “scattered throughout the earth.”

SOA What? If you don’t want your SOA infrastructure to end up like the Tower of Babel, you not only need to have a common language to communicate between your systems; you also need tools that will allow you to accommodate change to that model over time.

On Roadmaps and Future Product Features...

As some of you know, I'm more than just a pretty face. In fact, more years ago than I care to think about, I got my MBA because I was more interested in how and why technology got used in the enterprise way more than how it was implemented or what technology it was.

Of course, as with everything in life, the parts that I got out of the experience had nothing to do with what I expected. I've learned to keep an open mind (stop laughing and let me finish), and let things happen - when I do that - I usually have a much richer experience that I could have imagined.

At Progress Software, we're a technology company but, like any other public company, we are also a business. A business subject to rules... some obvious, others not so obvious. Assuming that the readers of our blog are made up of primarily, (1) customers, and (2) Progress employees, I'd like to point out one of those "less than obvious" rules we have to deal with. You see, we're pretty fiscally disciplined here at Progress; disciplined and conservative.

I've become a bit of an Apple fanboy and was reading an analyst article, when I came across the following paragraph discussing the iPhone:

Apple's management cautioned in its Q2 conference call that it will not be recognizing the revenue for any iPhones sold between March 6 and July 11 until after iPhone 2.0 is released. Peter Oppenheimer, Apple's CFO, notes in Apple's Q2 Conference Call, "Because we announced the specific new features to be included in the iPhone 2.0 release and plan to provide them to iPhone customers as a free upgrade in late June, we will delay the start of revenue recognition for all iPhones sold on or after our March 6th announcement date until the iPhone 2.0 software is delivered."

I recognized that necessity. You see, we have the same restrictions with regards to revenue recognition. If we tell you about a product future and you buy the product to use the future feature, we can't recognize the revenue. And, as a conservative company, we are very careful about our financials. Our investors appreciate that but I know first hand that our field staff doesn't, and our prospects question our direction when they feel we are being evasive.

SOA What? What does this have to do with SOA infrastructure? Well, if you're buying our SOA technology, you need to know where we're going - but, we can't always give you specifics AS MUCH AS WE MIGHT WANT TO! You need a feature and you wonder why we can't just commit to a date and get over with it. This is why. It's about revenue recognition, and rules that are placed on us to protect customers and investors alike.

Instead, why not use a different approach? Knowing that these are the restrictions that vendors with integrity are under, how can you get what you need without compromising the integrity of the process?

Let me ask you another question - before I answer that to get you thinking about how successful the current approach is - regardless of the legal restrictions we're under. How many times have you worked with a vendor who successfully delivered a POC with some custom feature (often integration with some other product I would bet), gone and purchased the product only to find that the feature delivered during the POC wasn't quite up to enterprise class? And further, what has your experience been trying to get the vendor to add the feature to the roadmap in a way that addresses your concerns?

So, how do you get what you need without compromising the integrity of those involved?

Talk therapy.

One interesting thing about our space is that we're deep in infrastructure, and purchases of our product, both large and small, tend to be strategic in nature. We're going to be together for a while. Why not get to know us?

I suggest the following sorts of questions:

1. What is the product direction and strategy? What problems does it solve and what does it do best? What won't it do?
2. What use cases do partner integrations satisfy, and where do those use cases fall in the product adoption life cycle? Why not get multiple vendors in a room together and have a mini-summit? A four hour brain dump? I find those informative for all involved.
3. What references can be shared by customers who needed features and worked with product management to get them appropriately prioritized and delivered?
4. What is the vendor's product delivery strategy? How many releases annually? What is the delivery/release strategy? For example, if you look at our minor-releases, they are often driven by customer enhancements. We use the rapid cycle of minor-releases to quickly address customer concerns as they start their implementations rather than forcing them to wait six months or longer for a major release. As part of our process, these minor releases are fully supported and part of the product in a disciplined manner.
5. How flexible is the product architecture to allow for enhancements? What is a typical timeframe for an integration of type X?

I know, talking about strategy is high-level, but... isn't it better to learn how we make decisions rather than to get an answer to the questions you have now? I think so. Remember, we're going to treat you really nicely when we're dating. What you really want to know is how we'll treat you once we're married.

That said, you know Dan and I from this blog. We spend more of our time talking to prospects than customers. There are two people on the team who are the reverse - though they talk to prospects, they spend more of their time working with customers. They are Vasco Kollokian, our Product Manager, and Julianna Cammarano, our Product Marketing Manager. I've learned tons by working with them. Why don't you try some of the questions above on the four of us, and see what happens?

If One is Good, Five Must Be Great!

Rob Hailstone, an analyst over at The Butler Group, just wrote an article talking about our IONA acquisition. It's one of the better articles I've read, and it shows that he knows quite a bit about IONA's products and the overall market.

He makes two points in relation to Progress® Actional® which I'd like to address. He suggests that IONA partners with Amberpoint which will have a conflict with our Actional products. Then he goes on to say:

"Progress partners with the HP Systinet registry/repository for service and metadata management, but Iona has its own registry/repository within the Artix suite."

Well, the Amberpoint issue has been addressed below both by Dan and myself. But, I'd like to clarify the Actional registry/repository positioning for Rob's audience, since I couldn't comment directly on Rob's post.

Actional currently supports registry/repository integration with:

1. Standard UDDI registries
2. HP Systinet (and the Governance Interoperability Framework)
3. Software AG
4. Fujitsu
5. BEA AquaLogic Registry Repository

Each of these is currently supported and available.

SOA What? This actually speaks quite well to the Progress SOA "portfolio" concept (in contrast to "stack" vendor solutions). The idea behind our SOA portfolio is that customers are free to choose bits and pieces that work for them, and be assured that the bits they choose work well with the rest of their enterprise infrastructure choices. Actional supports Sonic ESB and SonicMQ, as well as IONA Artix and other ESB solutions. Customers have a choice, and our partner organization works very hard to make sure that we have the relationships to back-up product integrations we deliver to the market.

SOA How? Actional is sold with an optional module called the "Governance Integration Module." For integration beyond standard UDDI integration, the Governance Integration Module is required. This module abstracts out the various repositories so that we can publish all sorts of cool things beyond service endpoints, like real-time service statistics, dependencies, and policy information. It also make is architecturally-easy to add new registries as circumstances demand. As for integration with IONA's registry... for that, you'll have to wait until we announce and further discuss roadmaps. I can't talk about roadmaps, but I hope I've addressed Rob's concern about partner ecosystem implications.

Oracle Makes the Right Choice for their Customers

As I write this, I wonder if Joe will wonder why one of his (very loyal, and loved by many) employees (me) would promote Oracle on the company blog! Hear me out Joe... this is good news, for us, and for Oracle (and BEA) customers.

Just back from vacation (I know, y'all missed me), and adjusting to the market's reaction to our acquisitions of IONA and Mindreef, and I came across this bit...

Oracle drops Amberpoint for SOA Management.

I mean, it's on the Internet, so it must be true, right?

I can't say this is a surprise, except that I am surprised that they are correcting their mistaken relationship in the first place. I mean, look at the history of Amberpoint's partners once they make the time to find out about Progress® Actional®:

1. Microsoft. Amberpoint's got a great relationship with them, and certainly much better than we do since the Progress acquisition. But... Microsoft has always viewed them as a tool vendor, shipping Amberpoint Express with Visual Studio. A testing tool for developers that doesn't integrate seamlessly with their enterprise offerings. And, we continue to enhance our support for .NET SOA infrastructure, including more protocol support for Microsoft protocols (like ADO.NET and WCF) than any other SOA management vendor.
2. Progress. Progress originally had a "best practice" offering with Amberpoint, until Hub met Dan. Hub, one of Progress' technical gods, got it immediately, and not only did they drop Amberpoint, they acquired us!
3. IONA. Our Actional customers won't talk in public but not only have we been partnering with IONA (with an Actional Agent for Artix ESB), but we've been replacing Amberpoint in several accounts because of the impact they have on production performance and scalability. Oh, and it turns out that Amberpoint modifies one telco's messages in order to track them end-to-end... a big no-no.
4. Software AG. A relationship growing quite well, combining Software AG's registry and repository solution with Actional's SOA management and security offerings. Like chocolate ice cream and whipped cream - it's ecstasy.

And, there are many others, large and small.

By the way, with respect to Oracle/BEA, we support Oracle Application Server and WebLogic Server, and BEA Aqualogic Enterprise Repository, and have for some time.

SOA What? I know the above is a bit sales-y but it's an important part of who we are. And, when customers make a decision to work with a vendor like Progress Actional, they want to know they're in good company and that we'll work with the rest of the enterprise tools already in place. We are, we will, and we'll do it in a way that easy, fast, and scalable. I promise.