John Crupi's Weblog

A few days ago, Dave Brillhart commented on my earlier blog on the SOA Shift for aligning IT and the business unit. This is a response/explanation to my thinking...

So what's the big deal with making the business unit so prominent when talking about SOA. It's not about being one big happy family.  It's about the organizational structure which needs to support what we really want to do; have business drive the requirements for SOA. That's what we mean when we say SOA is a business-driven architecture, not a IT driven architecture.  If the business unit and the IT team don't work together to achieve a SOA, you will be very hard pressed to get the requirements necessary to drive the proper service granularity and process definitions.

What does this really mean? It means that for SOA to be successful, it must be a "top-down" approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure.

This isn't just me thinking aloud. This is based on many discussions with customers citing why their initial attempts to use webservices and create SOA solutions failed. Many of our customers cite the "just wrap it in a web service" approach as a simple and natural way to create a the SOA service layer.  So simple (from a tools perspective), and natural (wrap what's there),  they thought it was worth a try. The problem, is taking an existing asset/system and making it a web service is a completely bottom-up approach and creates an immediate mismatch between the new web service interaction style and the existing system.  More about this in future blogs.,,

Below is a page from one of my presentations to help visualize these thoughts.

Gesture Muting

One of my favorite comics is the one where two dogs are sitting at the computer and the tag line reads "On the Internet, no one knows you're a dog."  But, I think we need a comic relevant to "generation flex" who like the flexibility of working from anywhere and doing conference calls at home, in the car, on the treadmill, while feeding the kids, going to the bathroom and even while changing poopie diapers. Not that I do any of these ;>, but I know others do. How? I can hear them. How can I hear them? Because, today's cell phone mute button technology sucks! That's right, let's start innovating in the least addressed feature of the cell phone; the mute button.

I have a nokia 82xx phone and it requires me to press a button, toggle down to "mute" and then select it. That's three steps! Plus, pressing a button is not conducive to how we mute. We mute out of necessity and we mute quickly and often. Pressing a button, let alone one which requires three steps is all wrong. So, here is what I propose: Gesture-based cellphone muting. Here's a few ideas:


1. The High-speed Wave gesture:


Basically, I wave the phone to the right and then to the left and it goes to mute.  I reverse the process to turn off mute. Note: this is best suited for headsets and not hand-holders.

2. The Pressure gesture:


This method works for both headsets and hand-holders. Very simply, you squeeze the phone to place it in mute. You press again to turn off mute. This works best for the headset-ers who hold the phone. Of course, there is a pleasant audible to tell you if you're in mute mode.

3. The Scream gesture:


This is my favorite and very consistent with what happens right before you need to mute.  Your daughter walks in the room and says; "Daddy, mommy says you need to stop working or she's leaving you...". Since, this is not something new and you know its dinner time, your 6th sense detects  your daughter coming and right before she says a word, you yell out; "MUTE!". Instantly, your phone goes into mute mode. Maybe you can program in something better than "MUTE", such as "LOVE", "YOU LOOK GREAT", "I DON'T DESERVE YOU" or  "HAVE YOU LOST WEIGHT". Your choice, but any of these will have the same muting effect, but can also help relationships at the same time. I'd call this a double win!

Hopefully, someone from Motorola, Nokia or Ericsson will read this blog and grant my wish. If you have other ideas, please comment!

SOA means a lot of things to a lot of people. And, now that the money is flowing to SOA, even more of us are interested. The reality is that SOA is much more than just a buzzword. It is an architectural style which tends to be best realized using Web Service and open standards. It's not the only way to implement SOA, but sure does seem to be the most popular lately.

We're finding that there are some key "shifts" that have to take place in an organization to be successful with SOA. Today, I'll talk about the first of these "SOA Shifts".

• Shift #1 - SOA requires a combined effort between IT and the Business Unit

The point of this shift is that we cannot do SOA without a mutual effort between IT and the BU. Gone are the days of throwing the requirements over the fence and hoping it hits. Not only do these two groups have to work together, they have distinct roles and responsibilities. Basically, the BU runs the show and owns the business drivers, use-cases and processes. IT implements the BU requirements and owns the service definitions.  It's unfortunate that we really do have to refer to this as a "shift", because we should be doing this anyway. But, the reality is that IT and BU typical function as disparate groups and rarely work together to have the business use-cases drive the process and service definition. More about this later, but if you get the gist of this shift, I think we can begin the journey to SOA....