Todd Biske: Outside the Box

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.

The east coast Gartner AADI and EA Summits (that’s Application Architecture, Development, and Integration and Enterprise Architecture) are nearly upon us, and thanks to the SOA Consortium and Gartner, I’ll be part of two end user panels again. In the AADI Summit, I’ll be speaking with Mike Kavis and Melvin Greer on “Measuring the Value of SOA.” I think I’ll bring an interesting perspective to this. That session is at 10:45 AM on Wednesday, near the end of the AADI but right before the beginning of the EA Summit. At the EA Summit, I’ll be part of a panel with John Williams, Maja Tibbling, and Marty Colburn in a session titled “SOA and EA: Lessons Learned from the Trenches.” That one is at 8:30 AM on Friday, so stop by the coffee shop on your way down to conference center and pick up a double latte. I’ll be at both events (and blogging) for the duration of them, so stop by and introduce yourself.

Surekha Durvasula had a very good post entitled ‘Why you need a stated “service versioning policy.”‘ In it, she presented 6 different scenarios where multiple versions of services may be required. If you don’t think you’ll need to deal with versioning, perhaps you should review these scenarios and determine how you’ll handle them when the need arises.

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.

In a blog entry last week and his podcast for this week, David Linthicum lamented the fact that many technology vendors are too focused on integration and not enough on architecture. My opinion on this is that the problem lies first with enterprises, and not with technology vendors.

In order to first explain this, I need to split the technology product space into two large groups. First, there are products that are pure infrastructure. They are platforms on which someone else builds solutions. This is the familiar space of database platforms, application servers, network appliances, EAI platforms, ESBs, MOM servers, etc. For products in this space, I have absolutely no problem with the vendors providing products that are focused on making integration easier. Does this enable enterprises to build up layers of “glue” in the middle? Absolutely, but at the same time, the enterprise had to have a need (whether perceived or real) to make their integration efforts easier.

The second group of technology products are the actual business solution providers, whether it’s a big suite from SAP or Oracle, web-based solutions like Workday and Salesforce.com, or anything in between. These vendors absolutely should be focused on architecture first. At the same time, I don’t think many of these products are being marketed and sold on their integration benefits, they’re being sold on their business capabilities.

So, what’s the problem then? The problem comes when the enterprise IT staff involved with technology identification and selection is too focused on integration, rather than architecture. Almost always, when I hear an enterprise talk about integration, it’s a just in time effort. Someone is building some new system and as part of the design of that system, they decide they need to talk to some other system. No thought of this need occurred in advance from either side of the integration effort. In putting together the solution, the focus is simply on the minimal amount of work to put the glue in the middle. As long as this trend continues, the infrastructure vendors are going to continue to market their products to this space. While it’s a noble quest to try to educate and market at the same time, it’s a risky strategy to present using a different mental model than your target audience.

The change that needs to occur is that integration needs to be a primary principle that is thought about at the time a system is placed into production. Normal behavior is to build a solution for my stakeholders and my users, and not think about anything else. In past posts (here, here), I’ve talked about three simple questions that all projects should start thinking about. One of those questions is “What services does your solution use / expose?” How many projects actually identifying anything other than just what their front end consumes? Does anyone see this as a problem? Let’s come back to the infrastructure vendors. They actually do need to think about architecture and services, but in a different space- management. I’ve railed on this in the past. How many vendors expose all of the capabilities in their user-facing management console through one or more service interfaces? If I want to embrace IT Systems Automation, how on earth am I going to do this what what these vendors give me? I’m not. I’m going to have to leverage management adapters in more automation environment. Does this sound familiar? It sure sounds like EAI to me. The best way I see to address this is think about integration in advance. Don’t think about it at the time someone comes and says, “I need to talk your system,” think about it at the time you build your solution and ask the question, “How will other systems need to interact with this.” Yes, this is a bit of predicting the future, and we’ll probably expose things that no one ever uses, but I think an enterprise will be in a better state if they try to anticipate in advance, thinking about architecture, rather that continue with today’s approach of integrate on demand.

The press releases came out today that SOA Software has bought LogicLibrary, with blogosphere comments from Miko Matsumura, Dana Gardner, and Jeff Schneider. I see this as a step toward the bigger SOA platform players by SOA Software. At this point, most of the players in SOA platforms all now have a registry/repository offering. IBM has WebSphere Registry Repository, Oracle/BEA has AquaLogic Registry Repository (consisting of the OEM’d Systinet and purchased Flashline products), Tibco resells Systinet, SoftwareAG has the former WebMethods/Infravio, Iona has Artix Registry/Repository, SAP has their Enterprise Service Repository, and Microsoft has their Oslo efforts. I think it’s safe to say that the vendors that are trying to be the acquirer rather than the acquired have all realized that a registry/repository is the center of the SOA technology universe. Now if only they could talk to each other easily along with the CMDBs of the ITIL technology world.

In my “Future of ESBs” post, I talked about how selling an ESB on its own is a difficult proposition because of the relative value that a developer will place on it. The same thing certainly holds true for a registry/repository, and I think the market has shown that to be the case by now having all of the registry/repository providers get swallowed up by larger fish. It would be interesting to know how many times these products are sold on their own versus being bundled in as a value-add with a larger purchase.

I’ve had this topic on my list for some time now. I’ve used analogies to municipal/local/state/federal governance in past posts, and in a conversation someone made a comment that they thought I was going to continue the analogy on to include lobbyists. I made a mental note, because I knew there were definitely some parallels that could make for good blog fodder.

So, in a typical government, what do lobbyists do? In a nutshell, they do whatever they can to influence the policy makers to establish policies that are benefits the lobbyists or whoever they represent. In general, I think most individual voters probably have a negative view of lobbyists, except those whose beliefs happen to align with their own. So, are they a good thing or a bad thing?

Let’s come back to the whole purpose of governance. My definition of governance is that is the combination of people, policies, and processes that an entity utilizes to achieve a desired behavior. People set policies and processes ensure they are followed. As a reminder, enforcement processes are only one subset of processes that can be used. An organization could just as easily focus on education processes rather than enforcement and achieve the desired behavior. I stated earlier that lobbyists try to influence the policy makers (people) to establish policies in the interest of the lobbyists. Where this becomes a problem is when the people involved in governance lose sight of the objective of governance. Lobbyists are frequently associated with or simply referred to as “special interests.” By that term alone, there’s an obvious risk. Policies should be set to achieve the desired behavior of the organization, not the desired behavior of any special interest.

This is actually a frequent problem in the typical corporate enterprise. The first potential scenario is when the desired behavior of the enterprise isn’t well defined. Therefore, the policy makers won’t base their policies on enterprise behavior, but rather on the desired behavior of the people in the organization who have their ear (the lobbyists). This can go down a really bad path, because it’s likely to lead to infighting within the governance structure, and most likely ineffective governance.

The second scenario is when the desired behavior of the organization is well known to the policy makers, but not to the rest of the organization. Once again, the rest of the organization will operate like a bunch of lobbyists, trying to sway policy in their direction so they can do what they think is best. The governance team will likely be perceived as being in an ivory tower and out of touch. The real problem in this scenarion is that the constituents in the enterprise don’t know what the desired behavior is, and as a result, they’re guessing. Some will be right, many will be wrong, and all will be unhappy.

A third scenario, which can’t be forgotten is the role of vendors and other third parties. Once again, their vested interest is not in your desired behavior, but theirs. Buy our products, buy our services. You need to be in control of the desired behavior and choose vendors and services that are in alignment, rather than letting them try to change your policies to something more amenable to them.

The whole point of this is that the presence of lobbyists in the entity being governed has the potential for problems. If you see a lot of lobbying in your organization, the first place to go back to is your desired behavior. If that behavior is well understood by the organization, your need for active enforcement should be far less because people understand and want to do the right thing. If the desired behavior isn’t known by the governors or the constituents, you’ve open the doors to outside influence and controversy. This doesn’t imply that a governor shouldn’t have advisors, but the first question that should always be asked is, “Is this action consistent with the desired behavior we want?”

Yogish Pai had a interesting post titled, “A decision maker’s concern about ESB.” In it, he provided two quotes, one from a Chief Architect of a financial services company and another from a CTO of a transportation company, both of which were raising some concern about leveraging an ESB.

ESBs have been one of the more controversial technology products in quite some time. They’ve been attacked as either rebranded EAI technology or efforts by vendor to “sell SOA” when most of us pundits have all stated that you can’t buy SOA. I’ve posted in the past (here, here, and here) on ESBs with more of a neutral approach, discussing capabilities that are needed and simply pointing out that ESBs are one way of providing those capabilities, and that’s still my stance. I’ve had the opportunity to work with companies that had purchased an ESB as well as companies that wouldn’t touch it with a ten foot pole. In both cases, the companies had found a suitable way to provide these capabilities, so you can’t say that one approach was better than the other.

What ultimately will decide the fate of the ESB will probably not be the specific technical capabilities associated with it, but the value that enterprises place on those capabilities. My past posts have stated my preference that the capabilities associated with the space really belong in the hands of operations rather than the hands of developers. As a result, you’d have to compare the cost/value of an ESB or other intermediary to the cost of other network intermediaries, such as switches, load balancers, and proxying appliances. Unfortunately, the ESB space is dominated not by traditional networking companies, but middleware companies. As a result, the products are being marketed to developers with feature after feature being thrown in, creating overlap with service hosting platforms, integration brokers, and orchestration engines. This dilutes the benefits of the core capabilities, and if anything, can make it more complicated to get those things done. In addition, these products may now clash with other products in the vendor’s portfolio, putting the sales staff in a difficult position.

The challenge that I see is that the value of a typical network load balancer from the view of a developer is pretty low. From their perspective, the features provided by the load balancer are minimal compared to what they need from the typical application server. As a result, I suspect that ESBs are very likely to become bundled capabilities rather than standalone products. It certainly means that there’s room for open source products, given that developers aren’t putting a lot of value to those capabilities, yet they are necessary. Open source products still need mindshare, however, so it will be interesting to see where it goes.

Since Dave was nice enough to give me another shout out in his podcast this week, I thought I’d follow up in my blog. I thought he did a much better job in discussing my post when he said that these new breeds of applications and services that are available on demand are (my words) another tool in the toolbox of the enterprise architect. There’s no doubt that there are potential cost benefits to these platforms, and a review of them should be something you consider as your architecture evolves. Just remember, however, that they don’t define your architecture any more than any product installed on site defines your architecture. They only define your architecture if you let them, and that’s a bad situation. Rather, define your architecture, and choose the solutions that best fit your needs, whether it is building it in house, buying an off the shelf product to install on site, or going with a web-based provider. Don’t focus on functionality alone. Make sure that it aligns with your management needs and your information needs as best you know their future direction. You need to be in control, not at the control of your vendors.