Tag Archives: Joe McKendrick

SOA Summit Wrap Up

by Miko Posted on May 11, 2009

In the spirit of saving you a few bucks, I’ll provide a summary of the Software AG SOA Summit event in Scottsdale, AZ.

First off, we have a bit of coverage of the event…

* Joe McKendrick blogged about “Stepping out of your Silo”
* Jignesh blogged about “…a turning point in the SOA Movement”
* Jason Bloomberg picked up on “Evolution is about Survival”

If I were to echo a sentiment from the packed-to-capacity event in Scottsdale Arizona, SOA has become vital… This observation was made by Forrester analyst John R Rymer.

SOA Practitioners are now asking the hard questions–and coming up with the pragmatic answers. I proposed that SOA itself could be seen as the answer to a simple question:

“How do you maximize the business value of the existing and ongoing investment in IT?”

Asked in this form, many architectural principles naturally emerge out of the “primordial soup” of technical services that clutter every large Enterprise. Business Process is a common answer to the “business value” component, while leave-and-layer, loose coupling, reusability and core SOA principles emerge as logical ways to refactor existing and ongoing investment.

But part of the paradigm shift was in understanding the shift from what SOA is to how to achieve it.

Sean Valcamp from Avnet demonstrated this kind of pragmatism by showing how a complete system of measurement can accelerate and ensure adoption of SOA… Measurements spanning Financial, Operation and Behavioral areas, including both strategic and tactical components.

By establishing such a robust program of measurement, SOA adopters can ensure both Approval and Adoption–two distinct facets of the SOA Success pattern.

We talk a good bit about how measurement must be connected with behavioral incentives in our free eBook, SOA Adoption for Dummies.

Another very helpful case showing powerful dynamics around both Approval and Adoption was Kevin Flowers and his presentation on the amazing SOA results coming from Coca Cola Enterprises (CCE).

The lightbulb that went off for me during Kevin’s presentation was that if SOA is about human behavior, that we all could benefit from taking a page from the marketing handbook. As you all know, Coca Cola is a genius at marketing…

Kevin showed how geographic mash-ups showing sales data superimposed on maps can provide a powerful “economic stimulus” for SOA projects. He also demonstrated how using GPS and delivering services to mobile devices creates powerful connections previously unavailable.

In one case he cited that the headquarters noticed one delivery person moving back and forth within a store. When they called this person they discovered that they were moving hundreds of cases of Coca Cola products using a grocery cart–because the store did not have a pallet loader (which their service-level agreement required them to have!)

By providing mobile devices to Coca Cola Enterprises employees, the company saved millions of dollars and avoided significant costs incurred by support of larger devices like laptops as well as over 2M dollars in pure toll charges (reps calling the 800 number from payphones).

The roster of speakers was a bit dense to go over one by one, but Leo Shuster, Bjoern Brauel, Ron and Jason from ZapThink, Susan Cramm and many others shared their insights.

For me, it was a reflection of a deeper turnaround in the SOA market–a newly found sense of optimism tinged with practicality. Architects rolling up their sleeves, taking measure of their adoption plans and getting their SOA programs under way with an eye to proving the value of their approaches.

Given the global reduction in travel budgets and the specter of swine flu, I was amazed to see packed-to-capacity rooms and very active participation in our program. If you have any other questions about SOA Summit, please feel free to contact me.

My 2 cents,
Miko

Posted in Cloud | Tagged , , , , , , | Comments Off

Stop talking SOA and start digging it

by Miko Posted on February 5, 2009

Joe McKendrick of ZDNet invented the phrase “Shovel ready SOA”

I too like this metaphor… I see a lot of digging going on.

I spent yesterday talking to a large enterprise doing SOA and there was a joke that you had to pay a dollar every time you said “SOA”. It’s no longer cool to talk about SOA!

But it was all we talked about all day for four hours, in a meeting with about twenty people. It’s pretty funny. People were “digging it.”

Rebranding SOA
A good friend of mine back in the early days of SOA told me “SOA is like sex in High School… everyone TALKS about it but nobody is actually DOING IT!” It seems like that trend has completely reversed. Nobody talks about it anymore but it seems like everywhere I turn someone is doing it! SOA is so uncool that Enterprise Architecture is now considered uncool. Tony Baer suggests in his blog that we “lose the name”. I suggest that Enterprise Architecture needs REBRANDING. The Daily Show had an excellent example video of how rebranding can help.

Shovel-ready SOA
Like the “Shovel ready” infrastructure projects like the national road system, the “business justification” is slightly limited on a case by case basis. How can I justify the cost of a highway system if I’m only thinking about going to the store today and willing to spend $1 to get there and back?

But if you add up all of the utilization of the road system, it becomes obvious that without our roads, our economy would be a lot less effective and that having them enables whole new economic opportunities to exist that didn’t before.

So the question becomes–when do you invest in infrastructure? Ask Warren Buffett who says “be bold when others are fearful and be fearful when others are bold”. Or ask Franklin Delano Roosevelt about the New Deal.

It’s 2009, become the change we need.

Stop talking and start digging.

my 2 cents.
Miko

Posted in Cloud | Tagged , , , , , , , , | Comments Off

ESB Hate Storm

by Miko Posted on July 24, 2008

Lots of hate for the ESB lately.

Everything from Joe McKendrick’s E-s-Busted to Dave Linthicum’s ESB Hurting SOA, we are in the midst of a full-fledged backlash.

I’m certainly sympathetic to these views. The SOA “patient” is already pretty sick. Years of Tribal IT battles, “quick fix” technology solutions that dont interoperate and create more hassles than they fix, project funded IT driven by inconsistent objectives and just plain years of abuse. This after years of “waxy IT buildup” leaving the communications “arteries” of the company rigid and atherosclerotic. Business units are demanding solutions to Business Process problems and quick fixes that existing IT infrastructure can’t support.

Any “expensive cures” for this patient steals valuable money from proven technologies that might have a chance to save the patient. So if some vendors have exploited the pain of this sick patient, I can see why there’s so much anger in the blogosphere for this approach.

The big problem with ESB isnt that it’s of no use. as Lori MacVittie pointed out, ESB exists for good reasons.

The big lie:

The problem is that ESB by itself was sold as a “magic cure” for:

1) Silos, and

2) BPM (Business Process Management)

So along comes this “doctor” called Enterprise Service Bus. All you have to do is take the magic ESB treatment and years of architectural degeneration will be cured… right? Wrong! And the backlash against the ESB “quack doctor” begins.

The “Magic Cure for Silos” Enterprise Architects Rejoice!

Why are people so angry about this? Well, first of all, the ESB “doctor” is guilty of some amount of malpractice. The word “Enterprise” as applied to Enterprise Service Bus is really as descriptive as adding the word “Enterprise” to any piece of software that isnt Enterprise just to make it sound more serious. See, the problem is that this “Bus” wont take you downtown. It wont take you out to the suburbs. You have to change busses 10 times just to go down the street! Proponents of the ESB originally sold the “bus” as a single conduit that ran all the way across your enterprise. Frankly, this just never happened. Getting business units to “standardize” on a single vendor for ESB just hasnt been realistic. Why is this? Because every vendor has an “ESB” and some vendors have 3 or more ESBs (!) So you have an ESB slabbed on top of your Enterprise Apps from Oracle or SAP. You have an ESB from your app server vendor. You have ESBs from your integration vendor. So you end up with a half dozen different brands of ESB all over the place. So people are angry because the “Enterprise” in ESB never happened. This basically means that business unit silos are unaffected by ESB for the most part. All sales teams look for the “Enterprise License” for the products, so why not try to sell your product as a solution for an “Enterprise-wide problem”.

The “Magic Cure for BPM” Business analysts Rejoice!

The second expectation that really wigged people out was the concept of Business Processes orchestrated on top of an ESB. People had this great concept that you could take an ESB product to a business person and some standards based orchestration language like BPEL. BPEL was oversold, I think it must have been the “Business Process” in “Business Process Execution Language” that fooled people. Setting the expectation than an ESB by itself can solve the BPM problem is just naive. If you peel back the onion and look at “orchestration” flows within the ESB, you are looking at integration-logic, not the kind of logic that business people use to solve business problems.

So what’s the reality here? Reality is that you need to accept the fact that, while useful, the ESB was never designed to solve either of those problems. If you were conviced those problems would dissappear when you bought your ESB, sorry guy, you should have read the fine print. ESBs are actually pretty handy for solving integration problems. Should we throw out our ESB? No–just because an ESB is a poor environment inside of which to do BPM and a poor environment to eliminate Enterprise Silos, it happens to be a good environment within which to implement “Business Services”. Don’t think of an ESB as the thing ABOVE the services playing any kind of architectural role: think of the ESB as another kind of app server, and therefore a place inside of which you create and implement a service. Is BPEL a reasonable choice for implementing a service? It’s a little functionally limited, but sure, you could do it. So if you put the ESB in its proper place BELOW the business service interface, you can be made happy again. Leave the Enterprise Architecture and BPM to the other systems please.

So how do we go forward from here? Well, first of all give up on solving Enterprise Silo problems by either forcing a single brand of ESB across all silos or trying to program BPM in your ESB. There is no magic cure.

The (non magical) Solution

If you want to solve the problems of Enterprise Silos, you need a way to federate policy and enforce it across silos. This is what SOA Governance solutions ought to do. Get a SOA Governance solution. Is this enough? No! You also need Enterprise Architecture competency. You need a SOA Competency Center. You need to actually do the work.

If you want to solve the problem of BPM, get a BPMS. Will that please the business by itself? No! You also need to align processes with IT capabilities (services anyone?). You need to ensure that process models can be monitored with a Business Activity Monitoring (BAM) solution and you need to make adjustments (process optimization) over time. You need to do the work.

Sorry, like heart disease, you may need to make lifestyle changes. The shiny ESB you bought unfortunately wont get you all the way there. No wonder you’re mad.

My 2 cents,

Miko

Posted in Enterprise | Tagged , , , , , , , , , , , , | Comments Off