Todd Biske: Outside the Box

Archive for the ‘Management’ Category

Frequent commenter Rob Eamon suggested a topic for me, hopefully he won’t mind me copying his email verbatim here:

One term that is starting to bug me more and more is “the business.” There is an implicit definition about this group and in IT circles that group is almost always referred to as “they.”

“That’s for ‘the business’ to decide.”
“We need to touch base with ‘the business’ on that.”

IMO, this tends to reinforce divide between groups.

So what exactly is “the business?” Why is IT typically assumed to be excluded from this group? Aren’t all groups in the company part of “the business?” Why do so many refer to “the business” as “internal customers?”

Smaller companies seem to embrace this seemingly arbitrary division much less so than do large companies.

I’m with you Rob. Many organizations have a separation between IT and everyone else, and even worse, it’s always IT referring to everyone else as “the business,” versus the non-IT staff treating IT as if it weren’t part of the company (although that happens too).

Part of the challenge is that IT works with nearly everyone outside of IT, and there isn’t a good term to describe them as a whole. Unfortunately, you hit the nail on the head. By referring to them as “the business,” there’s an implication that IT is not part of “the business.” It’s a shame that this is the case. I remember back in my days of focusing on usability where I had the opportunity to work on a cross-functional team with members of the Internet marketing group on an application. It improved things tremendously when we were able to work as a team, rather than as “the business” and IT. Unfortunately, this still tends to be the exception rather than the norm. So what should we do? Well, I don’t think we need another term to use. What we should be doing is getting off of our IT floors, and actually learning about the rest of the business. When we need to refer to a group outside of IT, refer to the group by their organizational name. If the application is for marketing, don’t call them “the business,” call them marketing. If it is for HR, call them HR.

One other question Rob asked was around the notion of “internal customers.” Like him, I don’t like the customer metaphor when talking about internal IT. The scary thing is, if IT had more of a customer service mentality, things would actually be better. The fact is, IT doesn’t have a good track record of customer service. We get away with lousy service because we’re part of the business. If we were an outsourcing company, we probably would have been shown the door a long time ago. IT should be better, not worse, than an outsourcing group. The only way to achieve this, however, is to get everyone in the company operating as a team, and continuing to emphasize that team mentality. It’s far too easy to get away with poor behavior with those you know, because the ramifications are usually less. As a testament to this, I think of my kids. First off, they’re great kids. But, if you’re a parent, I’m sure you can relate to this. My kids typically have excellent manners when dealing with the parents of their friends. When they come home, though, manners can be forgotten at the door. From a ramifications standpoint, my wife and I would probably be much more upset if they took out a bunch of toys at their friend’s house and didn’t help clean them up than if they took them out at our house and didn’t clean them up. Wouldn’t it be great if we had consistent behavior at both?

Part of this is human nature. This is why the “team” mantra must be something that is continually communicated over and over. The company I work for has a huge emphasis on safety. Not a day goes by without safety being brought up in some discussion. If they were to stop communicating about safety, I’m sure the behavior would eventually trend toward less safety. The same holds true for a team mentality. You can’t spend one year emphasizing teamwork and expect everything to stay that way when you stop. If teamwork is important, make it a part of everything you do, and keep it a part of everything you do. If you want to start from a grass roots effort and you work in IT, stop using the term “the business.” Instead, find out what group in the business you’re referring to, and use their name. I know I still use that term on many occasions, so I’m going to eat my own dog food and try to improve from here on out.

Presenter: Jeff Hiatt, Prosci

Jeff isn’t with Gartner, so this session should be different. It’s already started well his use of these green and red cards we all have. He’s asked us a few questions and asked us to raise either the green or red cards. It’s made it very easy to see answers instead of the usual hand-raising approach.

His first statement on his slides is: “The speed of technology deployment will not be gated by IT innovation, but rather by the ability to manage the people side of technology changes.” Absolutely!

He just walked us through an exercise where we wrote down a project name, its purpose (why are we changing), the particulars of it (what we are changing), and the people that will need to change how they work (who will be changing). He pointed out that most technology professionals don’t consider the last column and really struggle with answering it, but yet not dealing with it can stymie the entire effort.

We just did another example where he asked the audience how many people have managing the people side of change as part of their job responsibilities, and there were about 10 people who said yes. That’s a big problem if this can be the biggest challenge in being successful.

We’re now walking through some best practices for managing change. The first deals with sponsorship. Jeff called out how sponsors need to be actively engaging throughout the lifetime of the project, building a coalition of support for the change. He especially emphasized middle management, as their research has always shown that middle management is the most difficult group to change.

Item two was having a structured approach the managing the change associated with the project. I don’t know that I’ve ever been on a project that had this, although, one challenge we have in IT is actually having visibility into that. If the change required is in the business side, often times that is invisible to IT. That, in and of itself, is a problem.

The third item is communications. Of course, face-to-face communication is important. Another important this is who delivers the message. The preferred sender of change messages is one of two people. For business messages, it’s the CEO or President. For personal messages, it’s the employee’s direct supervisor.

The fourth and fifth items were dedicated resources for change management and employee participation. We were all scoring ourselves as we went through this, and in the end, we used the red card/green card “visual vote” and it was very clear that about 95% of the people in the room were at risk for having poor change management. Definitely a very clear message, the real question in my mind is how to get IT visibility into the change that our solutions will introduce into the business. This strikes a chord with me, since I’m a big proponent on involving end users from my background in usability. Good talk!

Presenter: Anthony Bradley

Anthony’s going to present Gartner’s new framework for building SOA business cases. He immediately began by stating that you can’t build a general business case for SOA. Rather, the point is to build an SOA business case for a particular business need. I can tell it’s the end of the day, as my attention span is dwindling quickly. This framework presentation is having the same impact on me as when I was first introduced to RUP. It appears to have a level of detail that makes it difficult to digest. The other thing that hasn’t been immediately apparent to me is why this isn’t a framework for building IT project business cases in general, rather than just SOA business cases. I’ll have to dig into the notes on this one, but right now, I’m a bit skeptical.

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.

One of the things I recently started thinking about was the relevance of social networking sites like Facebook, Myspace, Plaxo, LinkedIn, etc. have to enterprises. While there are certainly individual usage of these sites, is there a play for the enterprise? Ann All of IT Business Edge, had a post about two weeks ago titled, “Facebook Not So Useful as a Business Tool,” quoting a study from Flowing Data that “just a tiny percentage of Facebook’s 23,160 applications are business-oriented.” In the comments that followed, one reader named Peter stated “businesses should take a serious look at integrating social media in their marketing strategy.”

The more I thought about this, the more I agree with Peter. If your company has individuals as either direct or indirect customers, I’m sure that the marketing department has segmented them into different groups each with their own strategy for how they will be marketed. I don’t know of any enterprise of significant size in the U.S. that doesn’t have an internet presence, and I’m willing to bet that nearly all of their marketing departments see their web sites as more than just a place to get electronic versions of paper documentation or marketing materials. In other words, the web site has gone through three phases.

1. The Information Web: In this phase, everything revolved around pushing information out to the visitor.
2. The Transaction Web: In this phase, the communication is bi-directional, predominantly focused on information from the enterprise, and business (i.e. money) coming from the visitor.
3. The Participatory Web: Here, the emphasis shifts from the individual to the community. It’s not just the enterprise pushing information out, it’s the full ecosystem all of the site visitors and all of the enterprise’s partners.

The big challenge with this third phase comes down to community. When an enterprise tries to own the community, it will probably work very well for established customers, but it may have a hard time bringing in new members. In contrast, a site focused on enabling communities of all sorts, like Facebook or MySpace, is better positioned for community growth. If this is the case, why wouldn’t an enterprise try to involve these sites in their marketing strategies as a growth tool. The point would not be to own the community, but to attract new members to its community. This is no different than the physical world where a company establishes a branch office or a retail location in a community. It has to compete with others, but at the same time, if it is perceived as valuable and meeting the needs of the community, it will survive and thrive. The time is ripe is to think about how your company can build applications and content for these sites to attract new interest.

I had the opportunity to attend a great presentation from Stephen Young, Founder and Senior Partner of Insight Education Systems. The talk was around the concept of micromessaging, which can be further broken down into MicroInequities and MicroAdvantages. To understand these, Stephen started with the difference between denotation and connotation. Denotation represents the words we use, while the connotation behind those words reveals the true meaning of what is being said. This can involve body language, inflection, tone of voice, and much more. As he pointed out, humans (or humanoids) have been communicating for hundreds of thousands if not millions of years. The written word has only been around for a fraction of that time. Therefore, so much more about how and what we communicate is conveyed by more than just the words. He did an exercise with us where we tried to describe what a dog does when it is happy. While most dog owners know within a fraction of a second the mood of their dog when they walk in the door, trying to convey that recognition process to someone else solely through words is incredibly difficult. In other words, our brains are very well tuned to picking up on things outside of the words in a conversation.

Getting back to the concept of micromessaging, MicroInequities are all of the very small things that we do in a conversation that have negative connotations, such as folding your arms, losing eye contact, giving a “ho-hum” response to the work of some individuals while lavishing excessive praise to others when the outcome of each was similar, etc. In contrast, MicroAdvantages are positive micromessages. The FAQ at the Insight Education Systems page does an even better job of explaining this. A very simple example of MicroInequities was the use of apologies in the workplace (and elsewhere). How often have you heard someone say, “If I offended you, I’m sorry.” Right off the bat, the use of the word “if” makes it a qualitative apology, and not a sincere one. Stephen said, “If you step on someone’s foot, do you say, ‘If that hurt, I’m sorry?’ No, we simply say, ‘I’m sorry.'” He used the example of Michael Nifong, the former attorney in the Duke lacrosse team case. His apology contained this:

To the extent that I made judgments that ultimately proved to be incorrect, I apologize to the three students that were wrongly accused. I also understand that, whenever someone has been wrongly accused, the harm caused by the accusations might not be immediately undone merely by dismissing them.

Analyzing this, we see that the apology immediately starts out with a qualifier. It then uses the terms “that ultimately proved to be incorrect” which connotes “I still think I was right.” His apology is only directed at three students, who he does not name, which excludes the impact to Duke University, the coach who lost his job, the team who lost their season, the families of the players, etc. On top of that, he didn’t even show enough respect to mention the players by name. The gist of this was that apologies should be about the impact, not the intent.

The talk went on to demonstrate the impact of our body language when listening and how it causes speakers to behave differently even when conveying the same or similar information, as well as the differences (and similarities) in different areas of the world. Already today, I have stepped back and adjusted the wording in an email I was composing as a result of this talk. I plan on putting his book on my Amazon wish list and encourage all of you to do the same, and, if you have the chance, hear him speak or bring him to your organization for a workshop.

James Urquhart sent me an email about one of his posts and invited me to join the conversation. After reading his post and Simon Wardley’s post, it was interesting enough that I thought I’d throw in my two cents.

The topic of discussion was Google’s new App Engine. Per Google’s site:

Google App Engine lets you run your web applications on Google’s infrastructure. App Engine applications are easy to build, easy to maintain, and easy to scale as your traffic and data storage needs grow. With App Engine, there are no servers to maintain: You just upload your application, and it’s ready to serve your users.

The theme of James’ post, and why I think he invited me into the conversation, is does this matter to the large enterprise? I tend to agree with James. While I think this is cool technology, in its present form it’s probably of little value to the typical large enterprise. At the same time, I would definitely qualify this, and Amazon’s cloud of services, as disruptive technologies. I can’t help but find myself making mental comparisons to Clayton Christensen’s discussion of steel mills. Smaller steel mills came along and catered to the low end, low margin area of the market that the larger, integrated steel mills were happy to give up. Over time, however, those smaller mills expanded their offerings until the business model of the larger mills was completely disrupted. Will something similar occur in the infrastructure space?

There are certainly parallels in the potential markets. Big enterprises are not the target of Google or Amazon, just as the smaller steel mills focused on re-bar rather than on the more expensive and potentially lucrative market for structural beams or sheet metal. One key difference, however, is that it’s hard to figure out who the “big steel mill” is in this case. Clearly, both Google and any major enterprise currently buy servers. So, Google is not disrupting HP, IBM, Dell, etc. What we’re really talking about disrupting is the internal IT data center. In most cases, save for outsourcing the data center to EDS or IGS, there is no business to be disrupted. The right comparison of this to the steel mills would be a comparison of companies that leveraged the products from the smaller mini-mills disrupting the companies that leveraged the products from the larger, integrated mills. While efficient cost controls are certainly part of the equation, there’s much more that goes into the disruption equation.

In the end, it’s very clear to me that tools like Google App Engine are good for the industry as a whole. They cater nicely to the low end of the market and the size of Google can sustain low margins or even a loss on making these services available. Over time, some of the companies that leverage them will become bigger companies, making additional requests of Google, which will in turn evolve the product that with each evolution makes it more attractive to a broader set of customers, eventually including the big enterprise.

If you work in a typical large IT enterprise, it’s very likely that there are one or more committees that frequently receive presentations from various people in the organizations. These can be some of the most painful meetings for an organization, or they can be some of the most productive. Here are some of my thoughts on how to keep them productive.

First, if you are a member of one of these committees, you need to understand your purpose. If you are part of the approval pipeline, then it should be clear. Your job is to approve or deny, period. If you can’t make that decision, then your job is tell the presenter what information they need to come back with so you can either approve or deny. Unfortunately, many committee members often forget this as they get caught up in the power that they wield. Rather than focusing on their job, they instead focus on pointing out all the things that the presenter did or did not do, regardless of whether those things have any impact on the decision.

Second, the committee should make things as clear as possible for the incoming presenters. I’ve had to endure my fair share of architecture and design reviews where my guidance was, “You need to have an architecture/design review.” At that point, the presenter is left playing a guessing game on what needs to be presented, and it’s likely to be wrong. Nobody likes being stuck in a meetings all day long, so give the people the information they need to ensure that your time in that weekly approval meeting is well spent.

From the perspective of the presenter, you need to know what you want from the committee, even if it should be obvious. As I’ve stated before, the committee members may have easily lost sight of what their job is, so as the presenter, it’s your job to remind them. Tell them up front that you’re looking for approval, looking for resources, looking for whatever. Then, at the end of your presentation, explicitly ask them for it. Make sure you leave enough time to do so. It’s your job to watch the clock and make sure you are able to get your question answered, even if it means cutting off questions. Obviously, you should recognize that there is some debate, and ask appropriately. In the typical approval scenario, you should walk out of the meeting with one of three possibilities:

1. You receive approval and can proceed (make sure you have all the information you need to take the next step, such as the names of people that will be involved)
2. You are denied.
3. The decision is deferred. In this scenario, you must walk out of the meeting knowing exactly what information you need to bring back to the committee to get a decision at your next appearance. Otherwise, you’re at the risk of creating an endless circle of meeting appearances with no progress.

I hope you find these tidbits useful. They may seem obvious, but personally, I find them useful to revisit when I’m in either situation (reviewer or presenter).

On the Yahoo SOA group, there’s been a long conversation going on regarding (among other things) whether or processes operate at a higher level of abstraction than services which inevitably leads to a BPM first or SOA first debate. For the record, I don’t think that a process-centric approach necessarily leads to success. I made the point that I’ve seen first hand where a process-based viewpoint did nothing more than turn the silos 90 degrees. That is, where we previously had some capability locked away inside an application and only of value to that application, we now have the same capability locked away in a process, and only of value to that process. Both situations can be problematic. A service-centric approach, however, where we focus on a business capability and build outward focusing on consumption, seems to represent that “middle-out” approach.

Anyway, to get to the point of the post, a comment that both I and Anne Thomas Manes of the Burton Group made is that we’ve seen very few (in my case none) organizations that are structured around this notion of capabilities. Rob Eamon, a frequent commenter on this blog, replied to one of Anne’s messages (where she suggested that IT organize around capabilities) with this:

What does this really look like? Does the business organization line up in any way with the capabilities? What is the interaction between those responsible for business and those responsible for IT? Does business group A accept that “capability group X” has responsibility for business groups A, B, C, M, and N? So before capability X can be extended or changed, coordination is needed with all of them? Or is there a proliferation of different interfaces for X? …To paraphrase an old, old Byte magazine humor piece (http://home.tiac.net/~cri/1998/elehunt.html), we have little information about hunting the elephants but lots and lots about packing the jeep.

I thought Rob’s message was great, and one that we should all think about. SOA isn’t a panacea for all things wrong in IT, and even more importantly, if it isn’t broken, don’t fix it. That being said, there’s also a lot of “well, we’ve been doing it this way for 20 years and nothing has fallen apart yet” mentality as well, and the right answer certainly lies somewhere in the middle.

Getting back to Rob’s message, he presents a scenario where 5 business groups all need a common capability. If this is the case, the question is how is that being handled today, and is it a problem? If all 5 groups have their own implementation of that capability, is that an issue or not? If the current organization handles that dependency fine, and the current path is in alignment with the long term strategy, why change anything? If it’s not in alignment with the long term strategy, then you have justification to change. The real disaster is when we don’t even know that those common capabilities exist. Then, you don’t even know whether you have a problem or not, and by the time you figure it out, you now lack the time to get it fixed. This is the situation where I think most organizations are. They’ve read the press and think SOA has potential. They know that there is room for improvement in the IT/Business relationship. Beyond that point, it gets really fuzzy. An integration-centric approach to SOA has some legs, but that really lives in the IT space and produces incremental gains, at best. Any other approach really requires some analysis of the business and the information technology that supports it to determine whether there’s value to be obtained or not. Unless someone has that view, it’s hard to say whether enterprise SOA will provide significant value or not. I’d go so far to say that it’s difficult to say whether anything of a strategic nature will provide significant value or not.

So, the question remains, how do you organize for SOA? Clearly, there’s no one answer. As many, many people have said, it has to start with the business and the things it’s trying to do. As Rob suggested in his message, simply changing the structure of IT may not be enough. If the business side hasn’t recognized that there are benefits to leveraging shared services, then anything IT does along those business capabilities may not help. Sure, there are some things that can be done strictly within IT, but those have more to do with the business of IT, than the true business. Any change in organization has to make sense for the business objectives, however. Take sales and marketing as an example. There are plenty of organizations that have shared sales and marketing, and plenty of organizations that have separate sales and marketing organizations along some other dimension. I think the same thing will likely hold true for organizing around SOA. Where the business needs dictate shared business capabilities, you adjust the organization, both business and IT. Where the business needs don’t, efforts to push SOA may run into resistance. If the business lacks the necessary domain knowledge to know where SOA can fit and where it may not, then it really doesn’t matter what structure you pick, it’s going to be a struggle.

I attended a presentation from Raul Camacho from the SOA Solutions group of Microsoft Consulting Services yesterday. The talk provided some good details on some of the technical challenges associated with lifecycle events associated with services, such as the inevitable changes to the interface, adding new consumers, etc., but I actually thought it was pretty weak on the topic. I thought for sure that I had a blog post on the subject, but I was surprised to find that I didn’t. Some time ago (January of 2007, to be specific) I indicated that I would have a dedicated post, but the only thing I found was my post on product centered development versus project-centered development. While that post has many of the same elements, I thought I’d put together a more focused post.

The first point, and a very important point, is that the service lifecycle is not a project lifecycle or just the SDLC for a service. It is a continuous process that begins when a service is identified and ends when the last version of a service is decommissioned from production. In between, you’ll have many SDLC efforts associated with each version of the service. I presented this in my previous post like this.

Raul’s talk gave a very similar view, again presenting the lifecycle as a circle with an on-ramp of service identification. The activities he mentioned in his talk were:

• Service Identification
• Service Development
• Service Provisioning
• Service Consumption
• Service Management

There’s many similarities between these two. We both had the same on-ramp. I broke out the SDLC into a bit more detail with steps of release definition, development, testing, and deployment, while Raul bundled these into two steps of development and provisioning. We both had management steps, although mine labeled it as the triple-M of monitoring, marketing, and management. The one key difference was Raul’s inclusion of a step of service consumption. I didn’t include this in my lifecycle, since, in my opinion, service consumption is associated with the lifecycle of the consumer, not with the lifecycle of the service. That being said, service consumption can not be ignored, and is often the event that will trigger a new release of the service, so I can understand why one may want to include it in the picture.

The thing that Raul did not mention in his talk, which I feel is an important aspect, is the role of the Service Manager. We don’t need Service Lifecycle Management if there isn’t a Service Manager to manage it. Things fall apart when there isn’t clear lines of responsibility for all things about a service. For example, a frequent occurrence is where the first version of a service is built by a team that is responsible for both the initial consumer and the service. If service ownership and management falls to this team, it is at best a secondary interest, because their real focus was on the delivery of the service consumer, not of the service itself. A second approach that many organizations may take is to create a centralized service team. While this ensures that the ownership question will get resolved, it has scalability problems because centralized teams are usually created based upon technical expertise. Service ownership and management has more to do with the business capability being provided by the service than it does with the underlying technologies used to implement it. So, once again, there are risks that a centralized group will lack the business domain knowledge required for effective management. My recommendation is to align service management along functional domains. A service manager will likely manage multiple services, simply because there will be services that change frequently and some that change infrequently, so having one manager per service won’t make for an even distribution of work. The one thing to avoid, however, is to have the same person managing both the service and the consumer of a service. Even where there is very high confidence that a service will only have one consumer for the foreseeable future, I think it’s preferable to set the standard of separation of consumer from provider.

So, beyond managing the releases of each service, what does a service manager do? Well, again, it comes back to the three M’s: Monitor, Market, and Manage. Monitoring is about keeping an eye on how the service is behaving and being used by consumers. It has to be a daily practice, not one that only happens when a red light goes off indicating a problem. Marketing is about seeking out new consumers of the service. Whether it’s for internal or external use, marketing is a critical factor in achieving reuse of the service. If no one knows about it, it’s unlikely to be reused. Finally, the manage component is all about the consumer-provider relationship. It will involve bringing on new consumers found through marketing and communication which may result in a new version, provisioning of additional capacity, or minimally the configuration of the infrastructure to enforce the policies of the service contract. It will also involve discussions with existing consumers based on the trends observed through the monitoring activity. What’s bad is when there is no management. I always like to ask people to think about using an external service provider. Even in cases where the service is a commodity with very predictable performance, such as getting electricity into your house, there still needs to be some communication to keep the relationship healthy.

I hope this gives you an idea of my take on service lifecycle management. If there’s more that you’d like to hear, don’t hesitate to leave me a comment or send me an email.

While I always take vendor postings with a grain of salt, David Bressler of Progress Software had a very good post entitled, “We’re Running Out of Words II.” Cut through the vendor-specific stuff, and the message is that routing all of your requests through a centralized process management hub in order to gain visibility may not be a good thing. In his example, he tells the story of a company that took some existing processes and, in order to gain visibility into the execution of the process steps, externalized the process orchestration into a BPM tool. In doing so, the performance of the overall process took a big hit.

To me, scenarios like this are indicative of one major problem: we don’t think about management capabilities. Solution development is overwhelmingly focused on getting functional capabilities out the door. Obviously, it should be, but more often than not there is no instrumentation. How can we possibly claim that a solution delivers business value over time if there is no instrumentation to provide metrics? Independent of whether external process management is involved, gateway-based interception is used versus agent-based approaches, etc. we need to begin with the generation of metrics. If you’re not generating metrics, you’re going to have poor, or even worse, no visibility.

Unfortunately, all too often, we’re only focused on problem management and resolution, and the absence of metrics only comes to light if something goes wrong and we need to diagnose the situation. To this, I come back to my earlier statement. How can we have any confidence in saying that things are working properly and providing value without metrics?

Interestingly, once you have metrics, the relationships (and potentially collisions) between the worlds of enterprise system management, business process management, web service management, business activity monitoring, and business intelligence start to come together, as I’ve discussed in the past. I’ve seen one company take metrics from a BPM tool and placing them into their data warehouse for analysis and reporting from their business intelligence system. Ultimately, I’d love to see a differentiation based upon what you do with the data, rather than on the mere ability to collect the data.

Ok, so Brenda Michelson called me out today on a conference call that I hadn’t made any comments regarding the impact of the economy on SOA initiatives. Of course, that’s like dangling a carrot in front of my face, so I now feel obligated to at least say something.

As I’ve stated before, I consider myself to be very pragmatic. I try to avoid knee-jerk reactions to highs or low. So, the recent buzz around how the economy would impact SOA efforts was a bit of a non-event for me. Companies have always had to deal with their own performance, and adjust their budgets accordingly, and obviously, the general economy has a role in that performance. Depending on your industry, it could be large, or it could be insignificant. So, whether it’s an SOA project or any other IT project, the decision making process is still the same. The only things that have changed are the resources that are available. If we have resources to do it, do it. If you don’t, it gets put off. Now, if we’re discussing how SOA initiatives should be prioritized relative to other IT projects, it’s a different debate, and one that is independent of the current funding at hand.

The other angle on this discussion is whether or not successful SOA adoptions will help companies when their revenue streams are not what they’ve been in the past. If we come back to the marketing terms for SOA: reuse, agility, etc., I think these are all realized in the form of IT productivity and efficiency. In other words, I’m either getting more things done in the some standard time frame, or I’m reducing the time it takes to get any particular solution done in comparison to similar efforts in the past. I firmly believe that SOA should be doing this, and therefore, it’s a logical conclusion that companies that have successfully adopted SOA are in a better position to execute in an economic downturn than their competitors that haven’t. Of course, that assumes that information technology plays a key role in a business’ ability to execute and can be a competitive differentiator. There you go, Brenda!

The IT as a service provider discussion was brought back up by Joe McKendrick of ZDNet in this blog. In it, Joe made reference to a past blog of mine in which I stated my opinion that a customer/supplier relationship between IT and their end users in the business was a bad thing, and I still believe that. Joe’s post brought to light some small nuances on that opinion that need clarification.

In my original post, I stated that IT moving solely to a supplier model to the business is an invitation to be outsourced. If you’re simply an order taker, there’s no reason that someone else can’t take those orders. The value-add that an internal IT department provides is not technology expertise, but technology expertise combined with knowledge of the company. Any SaaS provider or outsourcing agency must provide services to a mass market, or at least a market with more than one customer.

Getting back to Joe’s post, the inference that could be made is that IT shouldn’t be a service provider. This is not the case however. The IT-Business relationship should be a partnership, but you can’t be a partner if you’re not providing good service. Understanding the services that you bring to the table and doing them well is critical to the relationship. The difference is that those services do not define the boundaries of the relationship. Instead, they bring structure and foundation to it, on which partnership can be built. If your foundation is weak, the relationship will crumble. Therefore, adopting principles of service management within IT is a good thing, however, don’t approach it from the standpoint of competing against outside service providers. The decision to use outside providers should be made by the business, which includes IT. IT should be the one driving the discussion to say, “some aspects of our technology are really becoming commoditized and we can achieve some significant cost benefits through an external provider” rather than being told, “you’re a commodity and we’ve outsourced you.” In this sense, IT is no different than other business support organizations. Take HR as a good example. One could certainly argue that HR could be outsourced as it provides commodity services that all companies need. Every large company I’ve been at still has an HR department, though. What is more the norm is to have HR working as part of the business to make good business decisions on what aspects of HR to outsource, and what aspects of HR should remain within the company because there is value add. Only someone within the company can really understand the corporate culture which is critical to attracting and retaining talented individuals.

Be a partner in your business, but ensure that your partnership is on a solid foundation.