Who Has the Power?

Today's post over at The Heart of Innovation is titled "Managers Need to Become Innovation Coaches" and offers guidance that good architects will do well to apply. While the article (and the short extract below) focuses on the role of the "manager", these principles are more aptly described as characteristics of good leadership in nearly any role - especially that of the architect.

Most managers, unfortunately, perceive new ideas as problems. [Instead] they foist their ideas on others and can't figure out why things aren't happening faster.

That's not how change happens. If people are only acting out somebody else's ideas, it's only a matter of time before they feel discounted, disempowered and... well...just plain dissed. People are more than hired hands; they are hired minds and hearts, as well.

If you want to empower people, honor their ideas. Give them room to challenge the status quo. Give them room to move -- and, by extension, move mountains.

Who has the power in an organization? The people who are allowed to think for themselves and then act on their ideas! Who doesn't have power? The people who have to continually check-in with others.

The idea of empowerment is essential. No matter how smart and capable the architect, the true "brilliance" of a team or an organization lies in the collective mind (Leadership - The Secret Sauce). This brilliance can be tapped only through legitimate empowerment, and that means we all should ask ourselves "who has the power" in an organization, on a team, or on a project. Good things happen when the architect provides leadership - and the team provides power.

Progressive Refinement of Estimates (aka The Transmission Repair)

Not too long ago, I had to have the transmission in my vehicle rebuilt. While car troubles are never a pleasant experience, this one created an experience that I think we can apply to many of our software development initiatives. You see, when I walked in to my friendly neighborhood repair shop, I was a bit anxious and really "needed" to know right there on the spot what was wrong with my car and how much it would cost to get it fixed. Oh, and when I would get it back. As you can imagine, it didn't quite play out that way. You see, the transmission guy, being the experienced professional that he is, knew he wasn't in a position to reliably answer those questions - yet. But he also knew how to work with me through a series of activities that would progressively refine our collective awareness of the answers - and ultimately be mutually beneficial. Here's how the story played out.

The Transmission Repair Story

Day 1 - 10AM - The Contact
Transmission's been slipping for a few days, so I head up to see "Ray" the transmission doctor. Walked in the front door and was greeted cheerfully. Explained the symptoms to Ray and asked the obvious questions: 1) What's wrong?, 2) How much will it cost?, and 3) When will it be done? Of course, Ray's been through this with hundreds of customers, and he knows he's not in a position to answer those "ever-so-important" questions. But he knows just what to do, so he explains how the process will work - and how it will meet my needs and get my car back on the road in a jiffy. Ray tells me the next step is to allow him to do a road inspection. He'll drive the car and observe the behavior himself. He'll even do some investigation with the car up on the rack in his shop. He says once he's completed that assessment, he'll give me a call and let me know where we stand.

At my prompting, he lets me know that the trouble could be something simple like contaminated fluid or mechanical adjustments, or it could be a more complicated problem requiring more extensive repair. On the lower end, Ray says it might cost as little as a few hundred dollars. He cautiously points out, however, that major repairs can be well over two thousand.

I anxiously awaited his call.

Day 1 - 3PM - The Engagement
At about 3 that afternoon, Ray calls to give me the update. It's a little bit of bad news, as the early indication is that there is indeed damage in the transmission, and it will need to be repaired. Ray gives me a bit of confidence by explaining what he observed and what that might mean. He is able to correlate his observations to many past experiences and makes me feel good that I'm on a path that many have successfully gone down before. According to Ray, repairs are going to cost between $1100 and $1800, and the correlation to previous work makes me feel confident with this range.

Ray goes on to explain that the next step is for him to get the transmission off the vehicle and onto the bench so he can open it up and look inside. Once on the inside, he'll be able to determine more clearly which parts need to be replaced and what work needs to be done. With that new information, he'll be in a position to give me a more reliable estimate.

Ray says that it's a lot of work to pull the transmission out to take it apart and do the detailed diagnosis. For this work, there will be a charge of $600. If I choose to follow through with the repair, that charge is simply part of the $1100-$1800 estimate. However, after Ray does the diagnosis and comes up with the updated price, if I choose not to proceed with the work (because, for example, cousin Charlie says he'll do it for a couple six-packs), then I'll owe Ray the $600 for his work.

While I'm not too crazy about this idea (it limits my options and makes me commit), I really can't argue against it. It only seems fair. I give the go ahead, and Ray promises to call me with an update within 48 hours.

Day 3 - 11AM - The Commitment
A little less than two days later, Ray has completed the detailed assessment and calls with the news. Along with several other parts, Ray will need to replace the governor pressure solenoid, the servo piston, and the boost valve. I have no idea what any of those things do, but Ray offers to explain in as much detail as I'd like. He wants me to be comfortable and confident in the estimate. With these new parts, his labor, and a couple pieces he has to send out to the machine shop for reconditioning, the revised total estimate is $1700 - $1850 and I can have the car back within 3 days. I give Ray the authorization, and he gets to work.

Day 4 - 2PM - The Change Request
Ray called to tell me he was making good progress on the transmission. It'll be ready for me to pick up tomorrow. That's good news!

He also wanted to let me know about something he'd learned during the repair. Once he had the transmission all apart and cleaned, he noticed that the #4 gear had some pitting on the inner surface of the teeth. He explains that this isn't something that will cause trouble any time soon, but he wanted to present me with the option of taking care of it now while everything is already out on the bench, potentially avoiding a second, more expensive repair at a later date. The part would cost an extra $75 plus $50 for labor. If I opt for the additional work, my revised total grows to $1825 - $1975.

After careful consideration, I decline the additional repair.

Day 5 - 4PM - The Delivery
The car's ready. The total came to $1797, and I can pick it up anytime before 6.

The Lesson

Before getting into the lessons learned in this experience, it might be a good idea to review Ray's process:

1. The Contact - Customer explains the trouble. Ray agrees to spend a couple hours investigating. This investigation will result in an understanding of scope and constraints and provide both Ray and the customer the information they need to make decisions about how to move forward.

2. The Engagement - Ray explains the results of the initial investigation and provides options. Customer agrees to a minimal investment to conduct the more in-depth assessment that will include removing and disassembling the transmission in order to generate a detailed work plan.

3. The Commitment - Ray explains what he learned during the in-depth assessment and provides a reliable estimate for the repair along with details about when he can deliver. Customer agrees to the terms of Ray's plan.

4. The Delivery - Ray completes the work and delivers on-time and on-budget. Customer is satisfied.

It seems Ray has this process nailed down. He avoided making a commitment (or asking me to) before there was a reasonable level of understanding of the work that would be required, and he walked me through each step of the process right up to the final successful delivery. While there were steps in that process that I really wish could have worked differently, I knew I had to be reasonable. For example, in that first interaction ("The Contact"), it wouldn't have done a bit of good for me to pitch a fit and throw a temper tantrum in an attempt to get Ray to cave and tell me exactly what was wrong and what it would cost. Likewise, Ray knew it would be just as unreasonable to avoid giving me a cost estimate as early in the process as possible. If he couldn't (or wouldn't) give me an estimate (even a wide range) at "The Engagement" stage, I surely wouldn't enter into the arrangement, and I'd have to take my business elsewhere. Throughout the process, we agreed to collaboratively work through a series of well-specified milestones. Each step resulted in the addition of new information and yielded an increasing ability for each of us to understand what we were getting ourselves into - and what we could each expect to receive in return.

Applying the Lesson

Let's be encouraged to apply the same reasonable and responsible sort of process to software delivery. Our customers can understand why precise estimates are not possible when there is little or no data, and we can understand that it is absolutely essential that we provide estimates that can be used for coarse-grained business planning as early as possible. All too often, this devolves into an emotional tug-of-war where nobody wins.

We all come out ahead when we design processes like Ray's and work collaboratively to step through a progression of estimates that become more and more reliable as a project unfolds and new data becomes available.

One last thing. You may be interested in comparing Ray's process to the Rational Unified Process, in which you'll immediately be able to draw simple parallels:

"The Engagement" = The Life Cycle Objective Milestone (LCO)
"The Commitment" = The Life Cycle Architecture Milestone (LCA)
"The Delivery" = The Initial Operational Capability Milestone (IOC)

These milestones give us a good framework for the reasonable and responsible collaboration that makes Ray's process a success.

Service Design Principles And Governance

A good architecture governance capability has at it's heart a focus on developing people and encouraging excellence (see Governance Without Goodwill is Dead). I like to think of it in terms of a leadership capability of the sort alluded to in this Dwight Eisenhower quote:

"Leadership is the art of getting someone else to do something you want done because he wants to do it."

With that backdrop, and as part of an emerging governance program, I've recently had the need to introduce or reinforce a set of service design principles to a large audience and begin developing a shared and actionable understanding of these practices. The goal is to increase community awareness and support for good design and to further develop good design skills throughout the community.

A good source for this material is Thomas Erl's SOA Principles of Service Design, and many in the community have been encouraged to buy the book. In fact, we've given away a couple dozen of them. To further jump-start the process, it has been helpful to create a high-level representation of these principles that can be used in introductory sessions and training. Doing so has begun to instill a common language and frame of reference.

You can download a copy of the design principles document. It's a bit large due to the graphics. Following is a quick preview.



Standardized Contract - Implement a standardized contract

Services within the same service inventory are in compliance with the same contract design standards

Loose Coupling - Minimize dependencies

Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment

Abstraction - Minimize the availability of meta information

Service contracts only contain essential information and information about services is limited to what is published in service contracts

Reusability - Implement generic and reusable logic and contract

Services contain and express agnostic logic and can be positioned as reusable enterprise resources

Autonomy - Implement independent functional boundary and runtime environment

Services exercise a high level of control over their underlying runtime execution environment

Composability - Maximize composability

Services are effective composition participants, regardless of the size and complexity of the composition

Statelessness - Implement adaptive and state management-free logic

Services minimize resource consumption by deferring the management of state information when necessary

Discoverability - Implement communicative meta information

Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted

Hope you find this useful. To learn more about these principles, be sure to get a copy of SOA Principles of Service Design and download a copy of the design principles document.