Monday, April 27, 2009

10 Principles of Change Management

Bookmark and Share

Strategy and Business magazine recently posted a "Resilience Report" titled "10 Principles of Change Management". As we've discussed (What is A Software Architect?, Most Important Competencies of the Software Architect, Governance Without Goodwill Is Dead, Service Design Principles and Governance), communication and leadership are critical skills for the Architect. These skills are really put to the test as part of initiatives with a large Change Management component - the sort of transformation programs the Architect is often asked to lead.

Strategy and Business identifies the following 10 principles of Change Management. These principles articulate what you might consider to be fundamental truths and to varying degrees should inform nearly every change initiative. I'll follow up with a post about the process of managing change. A solid understanding of these principles and processes pays great dividends.

1. Address the “human side” systematically. Any significant transformation creates “people issues.” New leaders will be asked to step up, jobs will be changed, new skills and capabilities must be developed, and employees will be uncertain and resistant. Dealing with these issues on a reactive, case-by-case basis puts speed, morale, and results at risk. A formal approach for managing change — beginning with the leadership team and then engaging key stakeholders and leaders — should be developed early, and adapted often as change moves through the organization. This demands as much data collection and analysis, planning, and implementation discipline as does a redesign of strategy, systems, or processes. The change-management approach should be fully integrated into program design and decision making, both informing and enabling strategic direction. It should be based on a realistic assessment of the organization’s history, readiness, and capacity to change.

2. Start at the top. Because change is inherently unsettling for people at all levels of an organization, when it is on the horizon, all eyes will turn to the CEO and the leadership team for strength, support, and direction. The leaders themselves must embrace the new approaches first, both to challenge and to motivate the rest of the institution. They must speak with one voice and model the desired behaviors. The executive team also needs to understand that, although its public face may be one of unity, it, too, is composed of individuals who are going through stressful times and need to be supported.

Executive teams that work well together are best positioned for success. They are aligned and committed to the direction of change, understand the culture and behaviors the changes intend to introduce, and can model those changes themselves. At one large transportation company, the senior team rolled out an initiative to improve the efficiency and performance of its corporate and field staff before addressing change issues at the officer level. The initiative realized initial cost savings but stalled as employees began to question the leadership team’s vision and commitment. Only after the leadership team went through the process of aligning and committing to the change initiative was the work force able to deliver downstream results.

3. Involve every layer. As transformation programs progress from defining strategy and setting targets to design and implementation, they affect different levels of the organization. Change efforts must include plans for identifying leaders throughout the company and pushing responsibility for design and implementation down, so that change “cascades” through the organization. At each layer of the organization, the leaders who are identified and trained must be aligned to the company’s vision, equipped to execute their specific mission, and motivated to make change happen.

A major multiline insurer with consistently flat earnings decided to change performance and behavior in preparation for going public. The company followed this “cascading leadership” methodology, training and supporting teams at each stage. First, 10 officers set the strategy, vision, and targets. Next, more than 60 senior executives and managers designed the core of the change initiative. Then 500 leaders from the field drove implementation. The structure remained in place throughout the change program, which doubled the company’s earnings far ahead of schedule. This approach is also a superb way for a company to identify its next generation of leadership.

4. Make the formal case. Individuals are inherently rational and will question to what extent change is needed, whether the company is headed in the right direction, and whether they want to commit personally to making change happen. They will look to the leadership for answers. The articulation of a formal case for change and the creation of a written vision statement are invaluable opportunities to create or compel leadership-team alignment.

Three steps should be followed in developing the case: First, confront reality and articulate a convincing need for change. Second, demonstrate faith that the company has a viable future and the leadership to get there. Finally, provide a road map to guide behavior and decision making. Leaders must then customize this message for various internal audiences, describing the pending change in terms that matter to the individuals.

A consumer packaged-goods company experiencing years of steadily declining earnings determined that it needed to significantly restructure its operations — instituting, among other things, a 30 percent work force reduction — to remain competitive. In a series of offsite meetings, the executive team built a brutally honest business case that downsizing was the only way to keep the business viable, and drew on the company’s proud heritage to craft a compelling vision to lead the company forward. By confronting reality and helping employees understand the necessity for change, leaders were able to motivate the organization to follow the new direction in the midst of the largest downsizing in the company’s history. Instead of being shell-shocked and demoralized, those who stayed felt a renewed resolve to help the enterprise advance.

5. Create ownership. Leaders of large change programs must overperform during the transformation and be the zealots who create a critical mass among the work force in favor of change. This requires more than mere buy-in or passive agreement that the direction of change is acceptable. It demands ownership by leaders willing to accept responsibility for making change happen in all of the areas they influence or control. Ownership is often best created by involving people in identifying problems and crafting solutions. It is reinforced by incentives and rewards. These can be tangible (for example, financial compensation) or psychological (for example, camaraderie and a sense of shared destiny).

At a large health-care organization that was moving to a shared-services model for administrative support, the first department to create detailed designs for the new organization was human resources. Its personnel worked with advisors in cross-functional teams for more than six months. But as the designs were being finalized, top departmental executives began to resist the move to implementation. While agreeing that the work was top-notch, the executives realized they hadn’t invested enough individual time in the design process to feel the ownership required to begin implementation. On the basis of their feedback, the process was modified to include a “deep dive.” The departmental executives worked with the design teams to learn more, and get further exposure to changes that would occur. This was the turning point; the transition then happened quickly. It also created a forum for top executives to work as a team, creating a sense of alignment and unity that the group hadn’t felt before.

6. Communicate the message. Too often, change leaders make the mistake of believing that others understand the issues, feel the need to change, and see the new direction as clearly as they do. The best change programs reinforce core messages through regular, timely advice that is both inspirational and practicable. Communications flow in from the bottom and out from the top, and are targeted to provide employees the right information at the right time and to solicit their input and feedback. Often this will require overcommunication through multiple, redundant channels.

In the late 1990s, the commissioner of the Internal Revenue Service, Charles O. Rossotti, had a vision: The IRS could treat taxpayers as customers and turn a feared bureaucracy into a world-class service organization. Getting more than 100,000 employees to think and act differently required more than just systems redesign and process change. IRS leadership designed and executed an ambitious communications program including daily voice mails from the commissioner and his top staff, training sessions, videotapes, newsletters, and town hall meetings that continued through the transformation. Timely, constant, practical communication was at the heart of the program, which brought the IRS’s customer ratings from the lowest in various surveys to its current ranking above the likes of McDonald’s and most airlines.

7. Assess the cultural landscape. Successful change programs pick up speed and intensity as they cascade down, making it critically important that leaders understand and account for culture and behaviors at each level of the organization. Companies often make the mistake of assessing culture either too late or not at all. Thorough cultural diagnostics can assess organizational readiness to change, bring major problems to the surface, identify conflicts, and define factors that can recognize and influence sources of leadership and resistance. These diagnostics identify the core values, beliefs, behaviors, and perceptions that must be taken into account for successful change to occur. They serve as the common baseline for designing essential change elements, such as the new corporate vision, and building the infrastructure and programs needed to drive change.

8. Address culture explicitly. Once the culture is understood, it should be addressed as thoroughly as any other area in a change program. Leaders should be explicit about the culture and underlying behaviors that will best support the new way of doing business, and find opportunities to model and reward those behaviors. This requires developing a baseline, defining an explicit end-state or desired culture, and devising detailed plans to make the transition.

Company culture is an amalgam of shared history, explicit values and beliefs, and common attitudes and behaviors. Change programs can involve creating a culture (in new companies or those built through multiple acquisitions), combining cultures (in mergers or acquisitions of large companies), or reinforcing cultures (in, say, long-established consumer goods or manufacturing companies). Understanding that all companies have a cultural center — the locus of thought, activity, influence, or personal identification — is often an effective way to jump-start culture change.

A consumer goods company with a suite of premium brands determined that business realities demanded a greater focus on profitability and bottom-line accountability. In addition to redesigning metrics and incentives, it developed a plan to systematically change the company’s culture, beginning with marketing, the company’s historical center. It brought the marketing staff into the process early to create enthusiasts for the new philosophy who adapted marketing campaigns, spending plans, and incentive programs to be more accountable. Seeing these culture leaders grab onto the new program, the rest of the company quickly fell in line.

9. Prepare for the unexpected. No change program goes completely according to plan. People react in unexpected ways; areas of anticipated resistance fall away; and the external environment shifts. Effectively managing change requires continual reassessment of its impact and the organization’s willingness and ability to adopt the next wave of transformation. Fed by real data from the field and supported by information and solid decision-making processes, change leaders can then make the adjustments necessary to maintain momentum and drive results.

A leading U.S. health-care company was facing competitive and financial pressures from its inability to react to changes in the marketplace. A diagnosis revealed shortcomings in its organizational structure and governance, and the company decided to implement a new operating model. In the midst of detailed design, a new CEO and leadership team took over. The new team was initially skeptical, but was ultimately convinced that a solid case for change, grounded in facts and supported by the organization at large, existed. Some adjustments were made to the speed and sequence of implementation, but the fundamentals of the new operating model remained unchanged.

10. Speak to the individual. Change is both an institutional journey and a very personal one. People spend many hours each week at work; many think of their colleagues as a second family. Individuals (or teams of individuals) need to know how their work will change, what is expected of them during and after the change program, how they will be measured, and what success or failure will mean for them and those around them. Team leaders should be as honest and explicit as possible. People will react to what they see and hear around them, and need to be involved in the change process. Highly visible rewards, such as promotion, recognition, and bonuses, should be provided as dramatic reinforcement for embracing change. Sanction or removal of people standing in the way of change will reinforce the institution’s commitment.

Most leaders contemplating change know that people matter. It is all too tempting, however, to dwell on the plans and processes, which don’t talk back and don’t respond emotionally, rather than face up to the more difficult and more critical human issues. But mastering the “soft” side of change management needn’t be a mystery."


Watch for the follow up on the process of change and look for every opportunity to learn more about Change Management principles. Great Architects are distinguished by practical skills in this area.

Monday, January 5, 2009

Hottest Posts in 2008

Bookmark and Share

2008 was a good year for the practice of software architecture. Good progress is being made throughout the industry in recognition of Architecture as a distinct discipline, and the maturity of the discipline was advanced by the excellent writings of a host of passionate practitioners. Looking back at the year on SoftwareArchitecture.com, I found it interesting to note the most popular posts of 2008. People are clearly interested in understanding the profession and reinforcing their practice. Let's keep it up!

The top 10 most popular posts of 2008:

  1. What Is Software Architecture?
  2. Good Architecture Descriptions are Explosive
  3. Service Design Principles (the Contract Story Continues)
  4. Most Important Competencies of the Software Architect
  5. What is a Software Architect?
  6. The Architect is Accountable!
  7. Progressive Refinement of Estimates (aka The Transmission Repair)
  8. The Proactive Architect
  9. Governance Without Goodwill is Dead
  10. The Making of a Governance Anti-Pattern?
I hope you have found something thought-provoking. As always, I love hearing from you.

Thursday, August 14, 2008

Organize Around the Architecture (#1)

Bookmark and Share

In a post titled “Contracts and Integration Tests for Component Interfaces” at Object Mentor, Dean Wampler discussed agile development and the communications between teams. As usual, Dean makes a number of good observations, and I’d like to pick up and expound on a couple of his thoughts.

For many years I led teams that had fully adopted agile practices. We had refined our development approach (and continually did so) to be extremely productive. Our responsibilities were almost exclusively for common services that were used at the enterprise level, which included everything from Credit Card Processing and Campaign Management to Subscriber Identity Verification. In those days, the overwhelming majority of the teams we worked with were still fully rooted in traditional/waterfall methods, and just like the teams Dean described, these teams were very reliant on BDUF.

Working with those teams, we were very quickly able to get ourselves into a position where we stayed barely ahead of them. We performed independent analysis in the business domain and consistently developed the services that would ultimately be needed. Of course, we always made sure not to get too far out in front where we might run too high a risk of disconnecting from or misunderstanding the true business objectives, needs, and priorities. Operating in this mode, there was at least a theoretical danger of building things we didn’t need, but in practice, over more than five years, that didn’t happen a single time. By maintaining close relationships with the “customers” (which included both the true business customer and the other development teams that would consume the services) and constantly communicating about their needs, we consistently blazed the trail just in front of where they wanted to go and made it possible for them to keep marching unencumbered towards their goals.

From a technology standpoint, we did something pretty similar to what Dean suggests. Though they’re absolutely a prerequisite, static definitions of contracts are not sufficient for reliable communications and assurance of unified expectations (see also Contracts are the Thing and Service Design Principles (The Contract Story Continues)). In our case, we delivered in four steps and provided the following in rapid succession to each team: 1) static definition of the contract, 2) client-side mock, 3) server-side mock, and 4) operational service. Sometimes this would all happen within just a sprint or two, and it always allowed the teams to actively participate in the evolving understanding of the dependency and how it could be incorporated into their design and delivery.

By the way, in those days (for calibrated reasons) we were exposing these capabilities as J2EE services, so part of our practice was to deliver a simple client library that encapsulated all the details about communicating with the service. This design was something we first delivered in 2001. It was in this thin library that the client-side mock was implemented. It allowed developers on those teams to start calling the service very early on, when they were ready, even if we were not. That mock remained available in the client library for future testing and development purposes and was typically activated by qualifying the service endpoint. With barely sufficient richness in the communication with the mock (e.g., the type of responses available), the dependent team was able to recognize potential integration pitfalls very early. This led to much greater accuracy, reliability, and validation of the interfaces.

You’ll notice that this approach heavily emphasizes the principle of “Organizing Around the Architecture,” which promotes segmenting a project or program into manageable sub-parts (and corresponding sub-teams) with clear and defined roles and responsibilities that in aggregate accomplish the goals of the overall initiative. Specifically, the dependency between each team should be in alignment with the architecture and in some fashion documented by the “contract” for the services being provided by those teams. For large-scale development programs, I consider this sort of organization to be essential. In fact, I think we all understand the importance of subdividing any large effort into manageable structures (and accountabilities).

Which brings me to my last point. Dean mentions the use of “virtual feature teams.” While that's a common approach and is often used successfully (especially for small to medium efforts where scope and scale are more easily managed), there’s an inherent risk in any approach that doesn’t respect the natural correlation between the structure of the organization (the people) and the structure of the architecture (the product). It’s been proven time and time again that the architecture of a product will tend to follow the organization of the people designing and delivering that product. I’ll talk more about this in a future post, but for now, as we think about the relationships between teams, how they’re structured, and how they communicate, let’s be sure to take the “Organize Around the Architecture” principle into account.

Thursday, April 17, 2008

My First Computer or Two

Bookmark and Share

Why I'd want to share this is beyond me. Why date myself?!? Inspired by a post today from Todd Bliske (My First Computer(s)), I thought I'd follow suit and reminisce about my early computers. A few fun memories.

While there were a few steps along the way, I really think of two worth mentioning. As a teenager, there were many hours of coding pleasure at the keyboard of a Tandy TRS-80 Model I. The one I had was quite similar to this one described very nicely by the good folks over at "Vintage Computer".


I hate to think how much time I spent hacking at Basic programs on that thing. See the device under the monitor? The one that's about the size of a dvd player or something like that? That was an expansion interface that enabled the connection of a floppy disk. Before adding that brilliant upgrade, all the persistent storage was handled via cassette!

Fast forward a few years to good times in the U.S. Air Force, and things got a little bigger - but marginally more capable. For several years, I had the distinct pleasure of developing on a TI-980B. Check out this awesome front panel.


This was a beast, but what a lot of fun. Featuring a switch-initiated ROM bootstrap loader, one would walk up to the machine and execute a flurry of load instructions via those toggle switches, and voila! The beast stirs to life, completing its load from good ole 9-track tape. Armed with a 4 mhz clock and a whopping 16k of dynamic MOS/LSI semiconductor memory (spanning two full-size circuit boards), almost anything was possible. One of the things I remember most was a single DMA port with 6 full circuit boards for I/O expansion. As I recall, there were literally 26 cards in the disk controller. Oh, and that disk. You know the one. Remember these?


If memory serves, that whirlpool-sized "mass" storage device provided 100mb of storage and involved a pack with 10 platters and 406 cylinders. It looked something like this one at Wikipedia: Removable Disk Pack. In those days (relatively speaking, it's really not that long ago), head crashes were a notable risk. And what a mess that was. Metal shavings everywhere! It wasn't pretty.

Not too long after that, things got a little simpler, and I remember going through a Commodore 64 and a Commodore 128 before landing on a machine that was a lot of fun for a number of years. The Amiga was a system truly ahead of its time. Both my kids learned how to use a computer (and fling floppies all over the room) on a proud Amiga 1000. It brings a smile to my face even now to think about my 2 year old selecting and inserting floppies to play his "First Shapes from First Byte" game. I can even still hear the robot voice... "First Shapes from First Byte."

Anyone remember the game "Tower Toppler?" Fun times.

How about you? What did those early days look like for you?

Saturday, March 29, 2008

Who Has the Power?

Bookmark and Share

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.

Tuesday, March 25, 2008

Progressive Refinement of Estimates (aka The Transmission Repair)

Bookmark and Share

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.

Wednesday, March 19, 2008

Service Design Principles And Governance

Bookmark and Share


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.