Todd Biske: Outside the Box

Archive for June, 2008

Roy Schulte is delivering the opening keynote. Right now, he’s presenting a good slide on integrating applications from outside of your domain and emphasizing the role of metadata and policies in formalizing the agreement between service consumers and service providers, all because of the need to build applications that cross the boundaries of different domains, whether inside the enterprise or outside the enterprise. I agree!

Roy’s now presenting what he feels will be the major improvements in business computing over the next 5 years. They are:

1. SOA, EDA, REST, BPM, and SaaS will improve the long-term business agility while reducing the life cycle cost of application systems.
2. BAM is IT’s biggest near-term opportunity to shine.
3. End users will have more direct control over the applications they use, and IT solutions will be more customized.
4. IT systems will become better able to handle data in the form of documents.
5. End users will participate more actively in information capture, information sharing and collaboration.

Raf Cammarano posted a great response to my last two blogs (here and here) on his blog. The title of his entry says it all: “No More Groups, Committees, Centres or Offices.” He asks the question whether a center of excellence or competency is even necessary at all. The risks he calls out are (with quotes from his blog):

1. Staffing: “Who is going to look after the other things when the best architects are poached by another group?”
2. Overlapping Responsibilities: “There will be huge overlap between the functions of the new group and the existing EA Group.”
3. Cross-functional teams are usually temporary: “The simple reason cross-functional groups are temporary is because the best people are reluctant to get off their career path within the business and move into a ‘special project’ permanently. SOA is not a ‘project’ and it’s certainly not ‘short term’.”

His recommendation is simple: “If your EA Group can’t deliver on everything that a Centre of Excellence would be expected to – then fix your EA Group!”

I really enjoyed this post as Raf raises many good comments that you should think about before you decide to go down the path. My posts were intended to offer some advice once you’ve made that decision, but it’s absolutely critical that you first look at whether it’s even needed. Addressing Raf’s concerns one at a time, let’s start with staffing. He’s absolutely right that staffing is a concern, as most groups aren’t willing to let someone go and live within some other virtual organization that controls their day to day activities. I’ve seen an organization where the top people, the ones who should have been driving the effort, specifically weren’t chosen due to the “hero” culture that existed and the dependency the organizations had created on them. I’d be willing to bet that these organizations may struggle to establish an EA team for the same reason. The successful COEs and Competency Centers I’ve seen had sponsorship from a very high level, typically the CIO or one management level beneath them. This helps prevent people from hanging on to resources that should be contributed at an enterprise level.

As for overlapping responsibilities, again this is certainly a risk. I’ve seen this resolved by actually assigning staff from EA to the COE, as well as having sponsorship from the Chief Architect. One thing to note, though. I think any COE or CC will have overlapping responsibilities with one or more organizations. It’s important that the COE is seen as an authority (just as EA must be seen as an authority) to help mediate when it occurs. The one thing you do want to avoid is complete overlap of responsibilities with another team. A COE or CC makes sense when there may be partial overlap and focus on the effort is needed. When there’s complete overlap, then you should have been looking at the team being overlapped to begin with, whether it’s EA or any other organization.

Finally, he points out that cross-functional groups are temporary. This was actually the original theme of my posts, so I don’t view this as a concern, but rather an option. What is bad is when a group that was supposed to be temporary lingers on indefinitely.

Anyways, thanks to Raf for the great comments. If you review my posts as part of your decision making process on a COE or CC, I suggest you review Raf’s as well.

I should know better than to blog late at night. I will never be classified as a night person. Anyway, in reading back over my post yesterday on Centers of Excellence or Competency Centers, I never quite finished my train of thought, but a post from the SOA Consortium blogs by Brenda Michelson refreshed my memory. This post recaps a podcast from their March meeting that discussed the topic of SOA Centers of Excellence. In the post, she called out that the panelists articulated the skills required to operate a SOA Center, which included:

• Project/Portfolio Management
• Service Design
• Business Knowledge
• Technical Aptitude
• Communication
• Teaching
• Governance

This list reminded me of a different view on COEs and Competency Centers. A challenge with SOA adoption is leadership. Who drives the organization’s adoption of SOA? If you’re like me, and don’t view SOA as just a technical thing, there’s no easy answer to the question. While enterprise architecture has the appropriate scope of visibility and influence on the technical side, they’re not the best group for handling organizational decisions. From the organizational side, there may an IT leadership group or committee that could handle it, but what about the technical aspects? This is where a cross-functional group may make a lot of sense and could be quite long lived. I know I’ve always thought of SOA as at least a 5 year effort, and looking back now from 5 years after I first said that in an organization, 5 years was clearly too optimistic.

Even given this long-term commitment, I still think the people running the SOA Center should always plan on having a time-limited lifecycle. SOA should become part of the normal way IT operates, not something that requires a special group to manage. While a cross-functional group will be required at the beginning, at some point, individual managers and technical leaders must take responsibility for their parts in contributing to the overall goals of SOA. It may not occur until sufficient organizational change (restructuring, not necessarily people) has taken place, but the goal of the program must be to make the behaviors associated with SOA normal practice, rather than something that must be explicitly enforced because it’s still outside of the norm.

This is a topic that originally came up during a SOA Consortium conference call a month or two ago. Since that time, the topic has come up several more times in my day to day efforts, so I thought I’d post a blog on it.

First, what is Center of Excellence (COE) or a Competency Center (CC)? You can see that I’m using these two terms synonymously, which is my opinion based on how I’ve seen it used at organizations. The second term may be one that is more familiar to people thanks to Gartner’s concept of an Integration Competency Center. The one defining concept that I’ve seen in organizations that have either Centers of Excellence or Competency Centers is that they cross organizational boundaries. That is, they don’t show up on an organization chart, or if they do, everyone that exists in it is connected by a dotted line rather than a solid line. This is a recognition by the organization that while org charts can provide clarity and focus for some efforts, those boundaries can also be a hinderance for others. I personally am of the opinion that no organizational structure is perfect, and if an organization can’t effectively work outside the boundaries of the structure, they’ll struggle. It’s a matter of knowing when you should be working within the boundaries and when you should be crossing the boundaries.

Anyway, given this common thread, I was surprised to find that I was in the minority on the conference call when advocating a position that a Center of Excellence or Competency Center should be a temporary thing, not a permanent one. In reality, it all comes down to the purpose of the team.

Many times, a COE or CC is formed around a new technology for which there is a limited supply of competent staff. It is at this point that an organization must decide how it wants to approach the technology adoption. Is the technology one in which the organization’s demand will outstrip supply if people aren’t trained? If so, a COE or CC can be a valuable tool, if the team understands its purpose. Its purpose is not to hoard all of the development efforts, its purpose is to train others. While short term success is great for building momentum, it will quickly fall apart when the team starts turning down projects because of lack of competent staff.

At the same time, there are scenarios where the demand is light, but the technology is complicated. Here, it makes more sense for a COE or CC to play the role of the outsourcer. Give us your work, we’ll do it and deliver it back to you. The challenge with this also lies with the demand. If the demand level isn’t sufficiently stable, it’s hard to justify creating an organization around it. If the demand is sufficiently stable, then we have a different situation. On the one hand, if the demand is stable, one should consider making this a permanent organization. Is it really a COE or CC, though? Earlier, I said that a common thread is a cross-functional team. If there is a small but constant demand for the use of a technology that justifies an outsourcing rather than mentor or project staffing model, is this more indicative a misalignment in the organizational structure?

In summary, I do believe that centers of excellence or competency centers can be a very useful tool for an organization, but they also have risks associated with them. The key to mitigating the risk is in understanding the engagement model the team will have with projects and making sure it is in alignment with the needs of the organization. If the organization needs to introduce new skills to a broad audience, an outsourcing engagement model won’t cut it. If there isn’t a need for a broad skill adoption, but enough of a demand to sustain a team full of experts, a mentoring or project allocation model won’t work.