It's Automatic, That's What!

During the first year of our (Actional) acquisition by Progress, I logged some 150,000+ air miles and worked with customers and Progress sales teams in over 30 different countries. During that time I had the opportunity to really feel the SOA market and understand customers' frustrations with their SOA implementations. Expectations weren't being met on important metrics used to justify SOA such as developer efficiency or business agility.

As I took the Actional message into the wilds, I gained confidence that our product was on the right track. I heard all sorts of challenges we could meet... customers just needed to get started. But, they weren't - at least not in the way I was hoping when I packed my bags and gave up my life for a year while I peddled my wares on the road.

In my jet-lagged-and-airline-stressed state, my brain couldn't adapt. Like an American speaking to non-English speakers, I just talked louder and slower, expecting everyone to "get it".

After some time, reports from the field started to trickle in. The exact message (and language!) varied, but the theme was the same. "We convinced the customer to let us install it, and they love it." Once they saw it for themselves, customers were inspired - actually, awestruck. Customers could finally see what their SOA infrastructure was about. Developers and QA staff were increasing testing efficiencies and operations staff were more rapidly pinpointing SOA hot spots.

Wasn't this what I spent the whole year saying? Wasn't anyone listening?

What had been missing from my message? After all, if I was that far off, it must have been me, right?

Well, for someone who's supposed to be smart, I let some people down. It took me until yesterday to realize just what was missing...

It's automatic, that's what!

Let me give you a slightly tangential example, if I may. We have a partner in Argentina who needed the product to do something it didn't. They took our Interceptor SDK, read the java docs, and wrote the piece they needed. Impressed (very impressed!), we wondered where they got the documentation to do what they needed. The response, "We took the javadocs, you know, the documentation that's automatically generated from the code."

These guys were good. We didn't need to write detailed documentation. The documentation was automatically derived from the code. That means there were no errors in the docs as they were translated from "engineering" to "documentation". It also means that as the code changes, these guys will have new docs, and will be able to react the moment each new release is available. And this is all because the information they needed was generated automatically.

SOA What? What does it mean to that audience who listened to me all last year without hearing me? Bascially, the only way the knowledge of your SOA will be true (which I'll define as "accurate and complete") in real time is if it done automatically.

• For SOA Architects. Automatically track transactions through the SOA without any pre-configuration or application modifications. It's not unusual to see tens-of-thousands of service dependencies as SOA uptake grows in an organization. Manually tracking a SOA of that size is, to put it nicely, impractical. As our Argentinian friends know first hand, the best information comes directly from the source... automatically.
• For SOA Developers. Automatically know who is using which services. You'll be amazed by what you find. I still believe SOA's main benefits are sharing and reuse. As one financial customer has said... "Our problem now is that integration has become too easy. Excuse me, I need to find out why we don't have the capacity we expected. " OK, I added the second sentence in that quote, but the first part was true. And, the challenge is properly planning capacity and application behavior when anyone can use a service.
• For SOA Operators. Automatically see the SOA in the moment. Know the players as the drama of a SOA meltdown occurs. Know this information in real time, not as of the last time the documentation was updated. What providers exist? What consumers are using them? What dependencies exist end-to-end that might be implicated by a root-cause analysis of the current failure.

And, since I like to ask questions as well as talk, I'll leave you with a last thought... How can you be certain your services are secure if you don't even have a true understanding of consumers, providers, and the dependencies between them available in real-time? Remember, if it's not real-time, it's history.