Todd Biske: Outside the Box

Archive for the ‘IT’ Category

Presenter: Andy Kyte

The title of this session is, “If You Had an Application Strategy, What Would It Look Like?” So far, I think I’m going to like it, because he’s emphasizing the need to manage the application lifecycle. That’s application lifecycle, not application development lifecycle. The application lifecycle ends when the last version of the application is removed from production. He’s emphasizing that an application is both an asset and a liability, with the liability being all of the people, technologies, and skills required to sustain it.

He’s now getting a ton of laughs by using a puppy/dog metaphor. He stated that we don’t buy a puppy, we buy a dog. It may be all cute and playful when we get it, but it will grow in a dog that sheds, eats, etc. Applications are the same way. Great quote just now: “Business cases are focused on putting applications in, and not on what to do after it. We are contributed to the problem by not addressing this.” He emphasizes that an application strategy should cover the next seven years, or half the expected remaining life of the application, whichever is the greater.

He’s now talking about stakeholder management and hitting on all the points I usually mention when talking about Service Lifecycle Management. The application is an asset, it must have an individual who is responsible for it, lifecycle decisions should be transparent, and all stakeholders (i.e. users of the application) must be identified and actively encouraged to play some role in the governance of the application.

The rest of the session is focusing in on the creation of the strategy document and making sure that it is a living, useful document. He’s emphasized that it is a plan, but also stressed the first law of planning: “No plan survives contact with the enemy.” It’s recognized that the plan is based on assumptions about the future. By documenting those assumptions, including leading indicators, leading contra-indicators, and expected timings, we can continually monitor and change the plan.

Overall, this is a very, very good session. What’s great about this is it is promoting a genuine change in thinking in the way that probably 90% of the companies here operate. Add a great speaker to the mix, and you’ve got a very good talk.

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.

I’m in a SAP session now. They’ve got their “End-to-End SOA Composition and Middleware Platform” picture up right now. It’s always nice when your vendor’s picture aligns with your own. Specifically, they have a separation between their Enterprise SOA Provisioning layer and their SOA Interoperability layer. Enterprise SOA Provisioning includes “Service and Event Enablement” and “Connectivity and Integration.” In SOA Interoperability, they have “Service Bus and SOA Management.” Thanks to the confusion between the ESB space and EAI space, these two layers are frequently combined, and I think they should be separate. The SOA Interoperability layer should be about mediating across a set of standards that the enterprise has adopted, which the enablement and integration layer is about hooking non-standard things into it. Push those pieces as close to the endpoints as possible, and put the stuff that’s required on all standards-based service messages in the middle. Unfortunately, they’ve now put up a slide on SAP NetWeaver Process Integration 7.1 and are positioning it to cover Service Bus, Service Integration, and SOA Management. So, conceptually they get it, but in terms of the product mapping, there could be some challenges if you don’t deploy it properly. If you separate out one PI environment for SOA Interoperability, and a second environment for Enablement and Integration, a lot of the potential risks can be mitigated.

Presenter: Benoit Lheureux

This was a decent overview of a whole bunch of things including composite applications, *-as-a-Service (software, platform, etc.). I would have preferred it if this presentation had taken more of an advisory, rather than informing, approach. There has to be a large number of enterprises represented here who have SAP, Oracle, or something else in their environment. Rather than going into depth on how to incorporate (e.g. best practices) these packaged applications into an enterprise’s SOA efforts (it did cover it, just at a light level), it went for breadth and spent a lot of time discussing packaged vendors and SaaS providers and their approach to SOA.

Presenter: Anthony Bradley

This presentation has started out with the unsurprising news that enterprise adoption of mashups is significantly trailing its use in the open Internet. He’s come up with a two-faceted classification model for mashups. The first facet is the integration pattern, which is one or more of the following (these aren’t mutually exclusive):

• Visualization integration
• Content integration
• Gadget page space co-location
• Gadget page space integration

The second facet is the application type, which can be one of:

• Personal portal delivery
• Packaged application extension
• Location awareness
• Panoramic awareness
• Situational awareness

All in all, I’m not sure what value this is bringing. I’ve posted previously on categorizations and taxonomies and how they need to have some purpose behind them. I’m not seeing the purpose behind these classifications. Typically, I’ve used classifications in reference architecture work where I try to map a particular type to particular constraints/patterns on the architecture and design, and I don’t see how these groupings do that.

He now had one slide that talks about the need to architect systems that allow them to be “mashable.” This I agree with, but again, it’s nothing new. We’ve been talking about this since the early days of portals, and you could even argue that it’s been around longer than that. He did present a proposed architecture for some of this at the end that may prove valuable to some attendees. Unfortunately, I don’t think he convinced anyone in the audience that mashups is something they should be thinking about. Personally, I think even the term puts some people off. I’d rather hear about the need to support “integration at the glass.” There’s too much of an association between mashups and just throwing something on a Google Map to make it have broader appeal, in my opinion.

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: Daniel Sholler

It’s Tuesday morning, and I’m attending this one over breakfast. He’s just made an interesting comment regarding companies, using the insurance industry as an example. He stated that while most insurance company provide the same services, they differentiate based on how they organize. I was hoping he’d take this further and talk about how organization impacts SOA adoption, but no luck.

Another comment he made is that Gartner sees a correlation between companies that succeed with SOA and companies that have mature identity management practices. If identity can’t flow through all of your service interactions, you’re going to run into problems. I agree with that.

On to standards. He has another slide up that shows the different types of relationships an organization may have. At the bottom, a completely internal interaction relies on a private subset of information and process models. In the middle, a company talking to a partner has a closed agreement that defines them. At the top, a company interacting with a “cloud” service has an open agreement. Anyone interacting with the cloud can see the information and process models available. He’s then gone on to show how their is a spectrum of standards that one must be concerned with. Once again, no arguments here.

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.

Presenter: Matt Hotle

“Governance is the key to predictable results” is the title of his first slide. At first glance, I disagreed with this statement, but as he explained it, he emphasized the use of policies and how they guide decision making. That I agree with. I don’t know if I’m comfortable going so far as to saying it’s the key to predictable results. I think it’s the term “predictable” that’s causing my discomfort. As I’ve said before, governance is about achieving a desired behavior, which is a slightly different view than predictable results. When I hear “desired behavior,” I don’t think of standard processes, when I hear “predictable results,” I do. Perhaps I’m nitpicking since I’m somewhat passionate about this space.

BTW, 92 minutes into the Steve Jobs’ keynote, iPhone 3G has just been announced. Are they selling them anywhere in the Orlando World Center Marriott? No? Rats. Now back to governance.

The slide he’s showing now has one very good nugget. He states, “SOA Governance needs… a funding model to maintain services as assets (service portfolio management/chargeback).” I’ve always felt that if an organization wants to do services the right way (see Service Lifecycle Management), it would inevitably wind up challenging the typical project-based funding model in most IT shops. Matt is now talking about the term “application” and while he didn’t go as far as I have in the past (see The End of the Application), he did make it clear that the notion of “application” needs to change. He just hit another key point with me! He said that what he’s outlining is “product management” and most IT shops don’t have a clue how to do product management. Boy does that sound very familiar (see this, this, this, this, and listen to this).

Presenter: Nick Jones

This session was a well-presented, broad overview of the web application space. Near the end, Nick touched a bit on choosing architecture for mobile applications, which gets into the decision on developing for the web, sacrificing some capabilities and usability, versus developing for a device, which provides more capabilities, but also introduces additional challenges given the average lifetime of a mobile device, let alone the broad number of devices and platforms available. It’s a bit disappointing that it wasn’t more broadly attended, although I think that part of the problem was that the session was targeted at Mobile Web 2.0, rather than on the decisions between writing a device or OS specific mobile application versus a mobile web application. There’s no doubt that more and more companies are going to start thinking more about how to leverage and support mobile access, so I expect that attendance will be increasing in these sessions in the next year or two, especially if we get a 3G iPhone in the next 30 minutes or so…

Susan Landry and Matt Hotle are giving this presentation.

Matt had a couple good quotes in the introduction:

• Governance is a framework that allows management to be successful.
• Governance is the set of processes that allow us to safely move from the past to the present and into the future.

Susan just covered a key topic, which was to perform stakeholder analysis. Each stakeholder has their own interests, political agendas, etc. I can agree with this. I define governance as the people, policies, and processes an organization puts in place to achieve desired behavior. A huge problem will ensue if there isn’t agreement among the stakeholders on what the desired behavior is, so getting them all on the same page and understanding their differences is very important.

The session is now over. One thing I disagreed with a bit was in their definition of governance, they limited it to the policies and processes associated with the efficient allocation of resources. I think this is only one aspect of it. As I called out earlier, it’s about achieving desired behaviors. The efficient allocation of resources is only one contributor to it.

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.