Business Making Progress

Business Transactions, Exciting Stuff!

Last week, I had an opportunity to listen to some of our top solution spokespeople here at Progress Software present, watch the audience respond, and then drink with the sales people who are tasked to sell our solutions in what could be the worst economy in recent history. I made a note to myself about a topic to blog on and am really excited that Jason Bloombergat Zapthink beat me to it!!

My note was simply:

"Process Mashup = Business Transaction"

In the Zapthink post, they talk about "data mashups" solving the "swivel-chair integration problem." They make a whole lot of talk about SOBA this and SOBA that, but at the very end, say something pretty interesting:

"From a business perspective processes always involve information, and there's no way to get value out of information without doing something with it, and when the business does something, that activity constitutes a business process." (Run on sentence is theirs, not mine.)

I think an important generalization can be made...

From a business perspective, there's no value in infrastructure unless it directly relates to what the business is doing. And, measuring the value requires the ability to directly relate it to the business.

Earlier this week, I mentioneda customer of ours who had 98% up-time but their largest customer was without data for over 3 weeks. Another example is a customer of ours - a large cable company. They have business owners of their "products" -- including cable, Internet phone, cable-Internet.

They use Actional to monitor the provisioning process for these services, and then share it with the appropriate business owners through browser-based dashboards. The first thing these managers do in the morning is bring up our console and look at how their business process is doing.

The important thing is that even though there is a mesh of underlying support systems for each of these products, as well as the famed "triple-play", they don't care about the infrastructure. They care about the results to their business.

Underlying this all is a Process Mashup which, is just a fancy way of saying "multi-product, multi-vendor integration to implement a solution." They've taken the component processes (provisioning, ordering, credit-checking) and made it into a single Process Mashup that helps them understand and deliver an outstanding customer experience. Importantly, the person responsible for the process doesn't really care about how it happens, as long as it does. But from an IT perspective, it's important to know when it's not happening and why.

For example, take FedEx (not a customer). They ship me a package and it arrives on time. I get an email and all is good. If it doesn't arrive on time, I call for help, and someone drills into the step-by-step tracking of where it's been to figure out where it is. At that point, they see which distribution center it shipped from, how it got routed, what the weather conditions are, and so on. Of course, ideally, they'd tell me (rather than have me call them) there's a problem, but... the important thing is that there are many steps in the process. We can police the end-result and use policies to warn us (ahead of time or after the fact) when things don't go as planned. We can also get all the detail we need to assure those important business processes (or Process Mashups as Jason and I like to think of them) keep the business optimized.

SOA What? Well, I find this exciting because we can start to really talk directly to the business in a way that shows hat we (as IT people) understand what's happening. We can talk about results the business cares about (the customer can watch cable tv in two hours from the time they sign up) and speak to results no one cares about, except when they have to ("There it is, the request to provision them got stuck in the queue. Yeah, that happens sometimes. Why were you waiting for it to finish?").

I'm very aware, that in addition to being a brilliant technologist, I'm also the check-out guy at Home Depot (where I always choose to self check-out), I'm a travel agent (book online, don't call the airline, they charge you more), and even a bank teller (using an ATM - just today I found out I don't need to fill out a slip to make a withdrawal from a teller... it's been that long since I've spoken to one!). In all those cases, it's quite easy for me to switch providers and completely opaque to companies as to why I would. And, I will switch if service is promised and not delivered. If a service provider doesn't communicate in terms customers can relate to, and then assure those processes using the benchmark the customers understand, customers will go to service providers who do.

One data model, many approaches to integration

The use of a common data model in SOA has been recommended in definitive posts - from the viewpoints of integration and of governance.  The common model architecture facilitates integration by providing a common ground for data transformation, and supports governance by bridging the business and implementation views of enterprise information.  When a common model is properly used, these principles generally apply regardless of the runtime environment.  But a common model supports several quite different styles of integration.  We could look at those integration styles as a kind of spectrum, with extremes at each end and a blend in between.

One end of the integration style spectrum is represented by what I call the common interface style.  OSS/J and MTOSI are examples of this style in the communications sector, and there are comparable examples in other sectors.  The common interface style promotes a universal, standard interface between applications.  It requires that all participating applications use the standard interface, reducing some common integration problems and costs.  The level of adoption of standardized interfaces varies among domains and among application vendors.  A common model can be used to implement adapters over non-compliant applications in order to conform to the standard interface.  Although the common model and its mappings may resemble a hub and spoke model at design time, the runtime view of this style typically requires that the adapters be highly distributed.

In contrast to the common interface style, the other end of the spectrum is what I call the data integration layer style.  Several OSS transformation projects are examples of this style.  It starts with each application as-is, and adapts their existing interfaces to a set of "canonical" interfaces based on a common data model that supports mapping between all participating applications.  It also adapts canonical interfaces back into application-specific ones.  This allows process management infrastructure to intercept and redirect canonical requests, providing access to business process that would otherwise have been hidden in (and locked into) the "wiring" between applications.  For this style, in contrast to the hub and spoke design view, the runtime view depends largely on the location of the mapping services, but it usually inserts process management between requesters and responders.

Other integration projects fall somewhere between the ends of the integration style spectrum, with a mix of adapters, canonical interfaces, and direct translation between applications.  It will be interesting to see how these and other styles evolve, as SOA best practices and SOA-supporting technology improve.

Goldilocks Governance

An article in the Wall Street Journal today on approaches to IT Outsourcing (The Goldilocks Strategy) has definite parallels to what I've seen with SOA Governance.

The article talks about an organization which first moves to outsourcing with a very loose contract, and ends up failing (poor service, mistrust, etc.).  Then, they move to an airtight contract that lays out every last detail.  But as their business changes, the rigid contract creates issues that result in... you guessed it: poor service and mistrust.  So, they finally switch their approach to one that's much more hand's on to build trust between their organization and the outsourcer, allowing them to more easily adapt to changing business climate... and they end up with a very successful IT outsourcing strategy.

The same parallel hold true for most SOA Governance initiatives.  Either there's none, or it's too overbearing (automated, rigid, and inflexible) - creating the exact problems that governance is intended to fix.  Moving from web services to REST?  "Sorry, our governance approach doesn't allow for that."

The right solution is often one that has little to do with tools, technologies, contracts, or mandates but instead is heavily based on the enterprise architecture team building a strong personal relationship with the rest of the organization.

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...

Sometimes It's Just Too Late

Down in Florida for Progress' annual sales kickoff meeting and using the opportunity to visit my grandparents. Needing a car to get around, I rented a low-end model from Dollar/Thrifty, an Actional customer. Normally, the car is full featured but this time, I got a car without power locks. No big deal, right?

Saturday morning, I went to the mall, parked, had breakfast, sat in Starbucks and caught up on email. When it was time to go, I realized the problem with not having electronic locks.

I couldn't find the car.

You see, I didn't really pay attention to where I left it. I figured I could walk around, punch the alarm, and move towards the beep. I ended up having to walk the aisles looking for a red Dodge.

This weakness in my plan would never have occurred to me until I experienced it... at which point it was too late to do anything about.

SOA what? You've got similar challenges with SOA management tools. You don't really know what you need until you need it and it's not there. Unfortunately, once you've put the SOA infrastructure in place, it's too late to compensate and you must do without (or find a work-around).

It's important to think things through carefully, but realize that you're going to miss something. This assumption makes your decisions about architecture way more critical than individual features when it comes to product selection. Features can be changed (quite easily in fact) but they are limited by the capabilities, performance and scalability of the underlying architecture of the solution.

Evaluating software for managing your distributed applications? Then this is a must read.

At least, I think it is. Just because I'm the author of the recently released Software Buyer's Guide, doesn't mean my opinion on its relevance is biased, really. If you follow me on Twitter, you've already been notified of the Buyer's Guide. And, as I said before, if you join the conversation and direct message me on Twitter, I'll send you a copy without requiring you to register.

Personally, I get quite frustrated by the vendor-initiated confusion around the problem that Progress® Actional® solves. It's not really a management problem. I mean, you can say a pilot uses his instrument console to manage his airplane, but what he's really doing is flying the beast. Well, Actional and other competitive solutions are the equivalent to the pilot's instrument console. And, the pilot is... Well, I think the pilot is anyone who drives business and the technology on which it runs. But, the right persona is a bit more organization-structure dependent and a bit less obvious than the "pilot" analogy.

While this guide talks explicitly about managing distributed/composite applications in a mission critical environment, it was written in a way that starts by proposing a framework for evaluating enterprise class software. I define enterprise class applications as being:

• Scalable
• Performant
• Resilient

Software that does not have the right enterprise architecture, should be disqualified before a feature-by-feature evaluation begins. I realize that's a strong statement, but I believe:

Architecture deficiencies are mortal. Feature omissions are easily corrected.

I think this simple rule is often overlooked by the whiz-bang of a pretty UI, or the easy sale-ability of a specific feature that touches the purchaser's hot button.

The guide goes on to discuss a few areas that are often part of "managing" a distributed application and tests for each that can be used in a POC. I've said it before, and I'll say it again... DO A PROOF OF CONCEPT BEFORE BUYING SOFTWARE. I've worked in the enterprise "plumbing" business since 1995 and the only consistency is that vendors try to avoid POCs. If we're trying to avoid them, you should be trying to do them. And, when you do them, take the time to do them properly. Little upsets me more than doing something so you can check it off a list somewhere. </rant>

We've also put out a brief teaser release highlighting the buyers guide. You can see it on our site, or over at SOA World Magazine (thanks to BusinessWire).

EDS AirlineSOA Goes Public

I'm a bad blogger. I've been very quiet lately. It's that time of year, after our fiscal year ends, but before we announce our results, and so I've obviously been busy with customers (remember them?) but can't really share the excitement.

I was trying to find the recording from last month's online eBizQ conference and ran across a blog entry by Joe McKendrick (one of my "must-read" industry analysts) talking about EDS' AirlineSOA initiative, and in particular the Lufthansa Airlines project.

SOA What?

Well, which SOA management vendor do you think underlies AirlineSOA?

I'd also point you to a recent post by Anne Thomas Manes that highlights the single most important "new product" that should be budgeted for in SOA implementations... that of a management solution.

It's interesting that both Anne and Joe blog about the same thing... Anne in the abstract, and Joe in the specific. I know AirlineSOA and Lufthansa in particular, use a host of different technologies from various vendors including TIBCO BusinessWorks. But, the only "fashionable" product used differently from the past (when it was just "airline" not "airlineSOA") is Actional.

What do you think of that? (I think it's pretty cool; but clearly I'm biased.)

And, there's more. Why do you think EDS selected Actional?

Performance.

For those of you reading this evaluating your own solutions, I'll share that EDS put a big effort on behalf of Lufthansa to make sure the performance was what they needed. This wasn't a simple "show us what you got, we're going to dump on the vendor" POC. They knew their environment and they invested the time in understanding our architecture, how it mapped to their environment, and how to optimize it all together. If you're serious about evaluating an enterprise tool, you need to make a serious investment in understanding it.

Of course, I still haven't found that recording (in part because I wrote this post). EbizQ has a new face on their site, and it's a big improvement, but old recordings are still hard to find (or, I'm just an idiot).