Todd Biske: Outside the Box

Archive for May, 2008

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.