Todd Biske: Outside the Box

Archive for March, 2008

A recent post from James McGovern reminded me about some thoughts I had after a few different meetings with vendors.

Vendors have a challenge, and it all stems from a view that they can be the center of the universe. A customer buys their product and builds around it, thereby becoming the “center of the universe” for that customer, exhibiting a gravitational field that attempts to mandate that all other products abide by its laws of physics. In other words, every other product must integrate with it, but that’s the responsibility of those products. For reasons I went into in my last post, that doesn’t work well. It’s a very inward-facing view rather than being the consumer-oriented view.

The challenge is that even if a vendor didn’t want to come across as the center of the universe, for some customers, it is required. For example, if a customer doesn’t have a handle on enterprise identity management, a vendor can shoot themselves in the foot if their own product doesn’t provide some primitive identity management capabilities to account for customers that don’t have an enterprise solution. In the systems management space, you may frequently hear the term “single pane of glass” intended for the Tier 1 operations person. Once again, however, every monitoring system that deals with a specialized portion of the infrastructure will have its own console. It’s a difficult challenge to open up that console to other monitoring sources, and it’s a difficult challenge to open up the data and events to an outside challenge. So what’s an enterprise to do?

To me, it all comes back to architecture. When evaluating these products, you have to evaluate them for architectural fit. Obviously, in order to do that, you need to have an architecture. The typical functional requirements don’t normal constitute an architecture. You can make this as complicated or as simple as you’d like. A passion of mine tends to be systems management capabilities, so I normally address this in an RFI/RFP with just one question:

Are all of the capabilities that are available in your user-facing management console also available as services callable by another system, orchestration engine, or script?

Now, there are obviously follow-ons to this question, but this does serve to open up the communication. Simply put, the best advice for corporate practitioners is to ensure that you are in charge of your architecture and setting the laws of physics for your universe, not the vendors you choose.

I just listened to Anne Thomas Manes’ podcast, “What Does it Take to Succeed With SOA?” that was released on Burton Group’s Inflection Point channel. One of the things that Anne pointed out is that many organizations do not have the right culture, especially on the business side, that promotes the sharing of services. A culture of sharing, collaboration, and trust is required to be successful. She also pointed out that the IT organization frequently mirrors the organization of the business, and if those business organizations don’t share, it makes it very difficult.

I started thinking about the organizational aspects of this. Many people in IT only have awareness of the highest levels of the business organization, and it may not be apparent that there’s a problem. But here are two common patterns that clearly point out the potential problems. First, there’s what I’ll call regionalization. Whether we’re dealing with global entities, or national companies with regional presence, it’s very likely that they have business units aligned along regions rather than along business capabilities. There may be very valid reasons for doing this, but it must also be recognized that they may all be performing the same business functions, only with the expected regional nuances. While it’s oversimplifying the problem, if a company sells widgets in 52 countries, there should be enough commonality to warrant some common services that all of them can leverage. Second, there’s product specialization. I have first-hand experience with an organization that had separate business units (and associated IT staff) for different products that the company offered. There were opportunities for shared services that were recognized within IT, but never made it to reality because of the cultural challenges within the organization. In this case, the cultural challenges were within IT, but it’s just as likely that the same challenges existed on the business side as well.

As Anne rightly points out in the podcast, somehow, we need to present the business value associated with the sharing. In some ways, this shouldn’t be any different than the value that makes companies choose to centralize sales and marketing. One of the big challenges faced within IT, however, it that the associated costs of redundant technology can be a bit harder to quantify. Yes, there are software licensing fees and maintenance agreements, but some of these one time costs are glossed over in deference to the project schedule. While I’ve never personally been involved with a centralization of sales and marketing, I’m guessing that a big part of the equation was an associated reduction in cost attributable to staff reduction, or in a more positive light, getting the cost to revenue ratio looking better by resource re-allocation. If we’re talking information technology, while it’s certainly a possibility, staff reduction doesn’t necessarily come into play, so that associated cost reduction must come from somewhere else, and at least in my experience, IT isn’t very good at quantifying it. So, across the board, our work is cut out for us, but that’s not to say it can’t be done. The one takeaway is to invest heavily in making your pitch. If you don’t have baseline metrics to be able to show the value improvement, whether in increased revenue or decreased cost, take the time to get them together before trying to make your pitch. It needs to be in terms the business can understand and is used to dealing with.

A comment from Steve Jones on the Yahoo SOA group a while back really struck a chord with me as a great observation and a conversation yesterday reminded me that I wanted to blog about it (Steve did so as well, in this blog entry). In discussing the difference between a service and an application, Steve had pointed out that the integration-centric view within application development tends to create a “series of ‘not my responsibility’ handoffs.” I think this is very true. Application development is frequently very producer-centric. That is, the focus is on the application itself, not on the users of the application, whether it be a person or another system. Where these dependencies occur, the parties involved can frequently be more concerned about their own pieces, and not about the experiences of those using them. When something goes wrong, as Steve points out, it can frequently be a series of handoffs between groups that are saying “it’s not my problem.”

This was reminded to me in a conversation yesterday when the person I was speaking with made a reference to the SEP field from “The Hitchhiker’s Guide to the Galaxy.” An SEP Field was a mechanism for making something invisible. From everything2.com, I found this explanation:

A SEP field is used to hide something in plain sight. This phenomenon works on the principle that the human brain will filter out impossible objects and situations so as to preserve the sanity of the owner of the brain. When an impossible object or situation is encountered, the brain decides that it is somebody else’s problem (SEP) and promptly deletes it from its perception of reality.

This is an area I’m pretty passionate about, and why I think I’ve enjoyed both usability and SOA. Both of these practices are inherently about consumption, not production. While clearly we need to produce applications and produce services, the focus needs to be producing something that is consumable. If someone has a problem with it, don’t make it invisible by saying, “well, that’s your problem,” because it’s not. Without consumers, you have no service. As a service provider, you must be concerned with how your service is being consumed and be doing everything in your power to ensure successful consumption and a positive experience.

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.

It’s been a while since I’ve blogged (a really nasty sinus infection contributed to that), so this comic seemed appropriate.

Anyway, I, like many other people, did a double-take after I read this blog post from Anne Thomas Manes of the Burton Group. In it, Anne states:

It has become clear to me that SOA is not working in most organizations. … I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures … deploying the best technology the industry has to offer … And yet these SOA initiatives invariably stall out. … They have yet to demonstrate how all this infrastructure yields any business value. More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration. … Thus far I have interviewed only one company that I would classify as a SOA success story.

I’ve always believed that the changes associated with SOA adoption were a long term effort, at least 5 years or so, but it was very surprising to only see Anne only find one success story, although further comments indicated she had only talked to 7 companies. 1 out of 7 certainly feels right to me. Things became even more interesting, though, with some comments on the post which indicated that Anne’s definition of success was, “Has the initiative delivered any of the benefits specified as the goals of the initiative?” She indicated that every company said that their goals were cost reduction and increased agility. My question is how did they measure this?

Another recent post that weighs into this was Mike Kavis’ post on EA, SOA, and change. Mike quotes Kotter’s 8 steps for transformation which include creating a vision and communicating a vision. Taking this back to Anne’s comments, if a company’s SOA goals are increased agility, my first question is how do you measure your agility today? Then, where do you want it to be at some point in the future (creating the vision)? If you can’t quantify what agility is, how can you ever claim success? Questions about success then are completely subjective, rendering surveys that go across organizations somewhat meaningless. While cost reduction may appear to be more easily quantified, I’d argue that many organizations aren’t currenlty collecting metrics that can give an accurate picture of development costs other than at a very coarse-grained level. It would be very difficult to attribute any cost reduction (or lack thereof) to SOA or anything else that changed in the development process.

This brings me to the heart of this post- setting expectations for your SOA efforts and measuring the success of your SOA journey is not an easy thing to do. Broad, qualitative things like “increased agility” and “reduced costs” may be very difficult to attribute directly to an SOA effort and may also fail to address the real challenge with SOA, which is culture change. If culture change is now your goal, then you need to work to describe the before and after states, as well as some tactical steps to get there. In a comment I made on one of my own posts from quite some time ago, I spoke of three questions that all projects should be asked:

1. What services does your solution use / expose?
2. What events does your solution consume / publish?
3. What business process(es) does your solution support?

The point of those three questions was that I felt that many projects today probably couldn’t provide answers to those questions. That behavior needs to change. Now while these were very tactical, they were also easily digestible by an organization. The first step of change was simply to get people thinking about these things. The future state certainly had solutions leveraging reusable services, but I didn’t expect projects to do so out of the gate. I did expect projects to be able to tell me what services and events they were exposing and publishing, though.

This type of process can then lead to one of the success factors that Anne called out in her comments which was the creation of a portfolio of services. Rather than starting out with a goal of “cost reduction” or “increased agility”, start out with a goal of “create a service portfolio.” This sets the organization up for an appropriate milestone on the journey rather than exclusively focusing on the end state. Without interim, achievable milestones, that end state will simply remain as an ever-elusive pot of gold at the end of the rainbow.

First, I have to admit that I’m part of the 99.8% of IT Conversations subscribers that currently aren’t donating, but that will be changing in the very near future. Given that I listen to at least 3 or 4 programs from them per week, I have no excuse for not donating.

I was happy to hear on Doug Kaye’s message today that they’ve added a smart playlist function. I had tried their personal playlist function previously, and just as Doug pointed out, I didn’t use it due to the need to actively manage it. It was far easier for me to download everything and just fast forward through the programs that didn’t interest me. Now, I can simply enter the topics I’m interested in and the series I regularly listen to, like Phil Windley’s Technometria, Moria Gunn’s TechNation and BiotechNation series, and Jon Udell’s Interviews with Innovators. This is great addition, so thank you IT Conversations and The Conversations Network. My membership donation will be coming shortly.

Thankfully, this has never happened to me.

Thanks to my father-in-law for passing this one along.

I received two questions in my email regarding my previous post on Service Lifecycle Management, specifically:

• Who within an organization would be a service manager?
• To whom would the service manager market services?

These are both excellent questions, and really hit at the heart of the culture change. If you look at the typical IT organization today, there may not be anyone that actually plays the role of a service manager. At its core, the service manager is a relationship manager- managing the interactions with all of the service consumers. What makes this interesting is when you think about exposing services externally. Using the concept of relationship management, it is very unlikely that the service manager would be someone from IT, rather, it’s probably someone from a business unit that “owns” the relationship with partners. IT is certainly involved, and it’s likely that technical details of the service interaction are left to the IT staff of each company, but the overall relationship is owned by the business. So, if we only consider internal services, does the natural tendency to keep service management within IT make sense? This approach has certain risks associated with it, because now IT is left to figure out the right direction through potentially competing requirements from multiple consumers, all the while having the respective business units breathing down their neck saying, “Where’s our solution?” At the same time, it’s also very unlikely that business is structured in such a way to support internal service management. Many people would say that IT is often better positioned to see the cross-cutting concerns of many of these elements. So, there are really two answers to the question. The first answer is someone. Not having a service owner is even more problematic than choosing someone from either IT or the business who may have a very difficult task ahead of them. The second answer is that the right person is going to vary by organization. I would expect that organizations whose SOA efforts are very IT driven, which I suspect is the vast lot of them, would pick someone within IT to be the service manager. I would expect that person to have an analyst and project management background, rather than a technical background. After all, this person needs to manage the consumer relationship and understand their requirements, but they also must plan the release schedule for service development. For organizations whose SOA efforts are driven jointly with the business, having a service manager within a business organization will probably make more sense, depending on the organizational structure. Also, don’t forget about the business of IT. There will be a class of services, typically in the infrastructure domains, such as authentication and authorization services, that will probably always be managed out of IT.

On question number two, I’m going to take a different approach to my answer. Clearly, I could just say, “Potential service consumers, of course” and provide no help at all. Why is that no help? Because we don’t know who represents those service consumers. Jumping on a common theme in this blog, most organizations are very project-driven, not service or product driven. When looking for potential service consumers, if everything is project driven, those consumers that don’t exist in the form of a project can’t be found! I don’t have a background in marketing, but I have to believe that there are probably some techniques from general product marketing that can applied within the halls of the business to properly identify the appropriate segment for a service. The real point that needs to be made is that a service manager can not take the field of dreams approach of simply building it, putting some information into the repository, and then hoping consumers find it. They have to hit the pavement and go talk to people. Talk to other IT managers whom you know use the same underlying data that your service does. Talk to your buddies at the lunch table. Build your network and get the word out. At a minimum, when a service is first identified, send a blast out to current project managers and their associated tech leads, as well as those that are in the project approval pipeline. This will at least generate some just-in-time consumers. While this may not yield the best service, it’s a start. Once some higher level analysts efforts have taken place to segment the business into business domains, then the right marketing targets may be more clearly understood.

I actually had to think harder than normal for a title for this entry because as I suspected, I had a previous post that had the title of “Importance of Identity.” That post merely talked about the need to get identity on your service messages and some of the challenges associated with defining what that identity should be. This post, however, discusses identity in a different light.

It occurred to me recently that we’re on a path where having an accurate representation of the organization will be absolutely critical to IT success. Organizations that can’t keep ActiveDirectory or their favorite LDAP up to date with the organizational changes that are always occurring with find themselves saddled with a boat anchor. Organizations that are able to keep their identity stores accurate and up to date will find themselves with a significant advantage. An accurate identity store is critical to the successful adoption of BPM technology. While that may be more emerging, think about your operations staff and the need for accurate roles associated with the support of your applications and infrastructure. One reorg of operations and the whole thing could fall apart with escalation paths no longer in existence, incorrect reporting paths, and more.

So, before you go gung-ho with BPM adoption, take a good look at your identity stores and make sure that you’ve got good processes in place to keep it up to date. Perhaps that should be the first place you look to leverage the BPM technology itself!

While I don’t normally comment on press releases that I occasionally receive in email, one tidbit in a release from Active Endpoints about ActiveVOS™ 5.0 caught my eye:

Active Endpoints, Inc. (www.activevos.com), inventor of visual orchestration systems (VOS), today announced the general availability of ActiveVOS™ 5.0. …

Scenario testing and remote debugging. ActiveVOS 5.0 fundamentally and completely solves a major pain experienced by all developers: the question of how to adequately test loosely-coupled, message-based applications. ActiveVOS 5.0 includes a new BUnit (or “BPEL unit test”) function, which allows developers to simulate the entire orchestration offline, including the ability to insert sample data into the application. A BUnit can be created by simply recording a simulation in the ActiveVOS 5.0 Designer. Multiple BUnits can be combined into BSuites, or collections of smaller simulations, to build up entire test suites. Once deployed into a production environment, ActiveVOS 5.0 delivers precisely the same experience for testing and debugging a production orchestration as it does for an application in development. Remote debugging includes the ability to inspect and/or alter message input and output, dynamically change endpoint references and alter people assignments in the application.

Back in November, in my post titled Test Driven Model Development, I lamented the fact that when a new development paradigm comes along, like the graphical environments common in BPM tooling, we run the risk of taking one or more steps backward in our SDLC technologies. I used the example of test-driven development as an example. As a result, I’m very happy to see a vendor in this space emphasizing this capability in their product. While it may not make a big difference in the business solutions out there, things like this can go a long way in getting some of the hard-core Java programmers to actually give some of these model-driven tools a shot.

For all of my architect readers, give today’s Dilbert a glance. 🙂

Here are the SOA, BPM, and EA events coming up in March. If you want your events to be included, please send me the information at soaevents at biske dot com. I also try to include events that I receive in my normal email accounts as a result of all of the marketing lists I’m already on. For the most up to date list as well as the details and registration links, please consult my events page. This is just the beginning of the month summary that I post to keep it fresh in people’s minds.

• 3/3: ZapThink Practical SOA: Pharmaceutical and Health Care
• 3/4: Webinar: Implementing Information as a Service
• 3/6: Global 360/Corticon Seminar: Best Practices for Optimizing Business Processes
• 3/10 – 3/13: OMG / SOA Consortium Technical Meeting, Washington DC
• 3/10: Webinar: Telelogic Best Practices in EA and Business Process Analysis
• 3/11: BPM Round Table, Washington DC
• 3/12 – 3/14: ZapThink LZA Bootcamp, Sydney, Australia
• 3/13: Webinar: Information Integrity in SOA
• 3/16 – 3/20: DAMA International Symposium, San Diego, CA
• 3/18: ZapThink Practical SOA, Australia
• 3/18: Webinar: BDM with BPM and SOA
• 3/19: Webinar: Pega, 5 Principles for Success with Model-Driven Development
• 3/19: Webinar: AIIM Webinar: Records Retention
• 3/19: Webinar: What is Business Architecture and Why Has It Become So Important?
• 3/19: Webinar: Live Roundtable: SOA and Web 2.0
• 3/20: Webinar: Best Practices for Building BPM and SOA Centers of Excellence
• 3/24: Webinar: Telelogic Best Practices in EA and Business Process Analysis
• 3/25: ZapThink Practical SOA: Governance, Quality, and Management, New York, NY
• 3/26: Webinar: AIIM Webinar: Proactive eDiscovery
• 3/31 – 4/2: BPM Iberia – Lisbon