Todd Biske: Outside the Box

Beth Gold-Bernstein had a great post entitled, “The Second S in Saas” that outlined her experience in trying to get a backup restored from an online survey site.

This is clearly important when you’re dealing with external service providers, but I’d like to add that it is equally important for the services that you build in house. The typical large enterprise today is rife with politics, with various organizations battling for control, whether they realize it or not. SOA strikes fear into the heart of many a project manager because the success of their effort is now dependent on some other team. Ultimately, however, success is not defined by getting the project done on time and on budget, success can only be determined by meeting the business goals that justified the project in the first place. If something goes wrong, what’s the easiest course of action? Point the finger at the elements that were outside of your control.

I experienced this many times over when rolling out some new web service infrastructure at an organization. Teams building services were required to use it, and whenever something went wrong, it was the first thing that was blamed, usually without any root cause analysis. Fortunately, I knew that in order to provide good service for the teams that were leveraging this new infrastructure, I needed to be on top of it. I usually knew about problems with services before they did, and because the infrastructure put in place increased visibility, it was very easy to show that it wasn’t the new infrastructure, and in fact, the new infrastructure provided the information necessary to point to where the problem really was. Interestingly, this infrastructure was in the middle, between the consumer and the provider. Arguably, the teams responsible for the services should be looking at the same information I was, and be on top of these problems before some user calls up and says it’s broken.

If you simply put services into production and ignore it until the fire alarm goes off, you’re going to continue to struggle in achieving higher levels of success with SOA adoption, whether you’re a SaaS provider or a service developer inside the enterprise.

Just got this text message on my iPhone:

AT&T free msg: We are simplifying your paper bill, removing itemized detail. To view all detail go to att.com/mywireless. Still need full paper bill? Call 611.

I wonder how much money they’ll save on postage with this action.

You never know what Google alerts will turn up. I got this headline:

SOA Instructors Jailed for Involvement in Colombian Drug Cartel

Boy, you’d think there was enough demand for SOA that they wouldn’t have to turn to illegal activities. 🙂 For the record, this has nothing to do with the SOA that stands for Service Oriented Architecture. This SOA is the School Of the Americas. If you’re interested, here’s the link.

A conversation that I’ve seen in many organizations is around the notion of an “enterprise” service. Personally, I think these conversations tend to be a fruitless exercise and are more indicative of a resistance to change. I thought I’d expound on this here and see what others think.

My arguments against trying to distinguish between “enterprise” services and “non-enterprise” services are this:

Classifications are based upon knowledge at hand. Invariably, discussions around this topic always come back to someone saying, “My application is the only one that will use this service.” The correct statement is, “My application is the only one I know of today that will use this service.” The natural followup then is whether or not the team has actually tried to figure out whether anyone else will use that service or not. Odds are they haven’t, because the bulk of projects are still driven from a user-facing application and are constrained from the get-go to only think about what occurs within the boundary of that particular solution. So, in the absence of information that could actually lead to an informed decision, it’s very unlikely that anything will be deemed “enterprise.”

What difference will make? To someone that makes the claim that their service is not enterprise, does it really give them tacit permission to do whatever they want? A theme around SOA is that it approaches things with a “design for change” rather than a “design to last” philosophy. If we follow this philosophy, it shouldn’t matter whether we have one known consumer or ten known consumers. I think that good architecture and design practices should lead to the same solution, regardless of whether something is classified as “enterprise” or “not enterprise.” Does it really make sense to put a service into production without the ability to capture key usage metrics just because we only know of one consumer? I can point to many projects that struggled when a problem occurred because it was a big black box without visibility into what was going on. If there’s no difference in the desired end result, then these classifications only serve to create debate on when someone can bend or break the rules.

What I’ve always recommended is that organizations should assume that all services are enterprise services, and design them as such. If it turns out a service only has one consumer, so what? You won’t incur any rework if only one consumers uses it. The increased visibility through standard management, and the potential cost reductions associated with maintaining consistency across services will provide benefits. If you assume the opposite, and require justification, then you’re at risk of more work than necessary when consumer number two comes along.

It’s certainly true that some analysis of the application portfolio can help create a services blueprint and can lead to a higher degree of confidence in the number of consumers a service might have. This can be an expensive process, however, and projects will still be occurring while the analysis takes place. Ultimately, the only thing that will definitively answer whether a service is “enterprise” or not is time. I’d rather set my organization up for potential success from the very beginning than operate in a reactionary mode when it’s definitive that a service has multiple consumers. What do others think?

I’ve previously posted on SOA in the home. Well, Peter Rhys Jenkins of IBM is doing it. I heard him speak once in St. Louis and he was very entertaining. Anyway, here’s the article on what’s he doing in his house.

Richard Monson-Haefel announced an upcoming telebriefing from the Burton Group that will ask the question, “Is the iPhone ready for the Enterprise?” I think this is going to be a very interesting discussion, and hopefully Richard will post a summary of the discussion after the fact for those of us that aren’t able to listen. It should be a great conversation, as they’re bringing analysts in from various services for the discussion.

Interestingly, with all of this talk about the iPhone and the enterprise, I actually think we’re asking the wrong question. It’s not about the iPhone, rather, it’s about how connected, mobile devices should be leveraged in the enterprise. Certainly, there are plenty of industries where mobile devices already play a key role. Just look at the technology associated with any company in the logistics industry for examples. The real discussion, however, is for those industries where the use of connected, mobile devices may not be immediately apparent. There are many enterprises that still have desktop machines for all employees and are just beginning to look at whether laptops should be issued, let alone consider something like the iPhone. Therefore, there is potential for a disruption in this space, something that could have a fundamental difference in how we go about our tasks.

The reason this discussion is gaining such momentum now, in my opinion, has everything to do with the full-browser capabilities of the iPhone. While I didn’t own a smartphone before getting an iPhone, I did have some experience with a Blackberry (before they had phone capabilities), and made extensive use of the WAP browser on my old Motorola V360. Email and access from the Blackberry was great, but that’s about it. Now, we’ve got this full web browser that can run a variety of web based applications (although not all, my kids can’t play with Webkinz on it due to no Flash, which is probably a good thing, at least as far as playing Webkinz goes). There’s a whole range of applications out there, as Richard calls out, the real potential is in applications developed specifically for the iPhone. Is this any better than some of the custom apps for one of the other smart phones? I’ve never written a mobile app, and I don’t know what limitations they have when the phone doesn’t have full web capabilities. I can only suspect that the recent hype on this subject is an indicator that only now have the doors really been opened. Connectivity is critical to these devices, otherwise they just become a PDA, which has certainly faded away. The question is whether connectivity + small form factor equals disruption. While I use the iPhone Facebook application, I’d hardly call it disruptive. There’s a killer app out there waiting to be written.

While I’m sure the conversation will focus more on the technical details around the iPhone in the enterprise, hopefully it will expand into the potential for mobile devices in the enterprise, whether it’s through a laptop with WiFi or wireless broadband or an device like the iPhone. Ultimately, this is what will decide whether it gets a place in the enterprise versus just being yet another way of getting to the corporate email and calendar.

In his daily links post for the 21st, James McGovern made mention of SOA India 2007 and suggested that they should have gotten me as a speaker. For the record, I was invited to speak at SOA India, but I had one major reason to decline. The conference is over Thanksgiving here in the USA. More so than any other holiday, families get together for Thanksgiving and mine is no exception. I certainly appreciated the invitation, however.

On a slightly related note, in the future these conferences should look to technology to bring in speakers. Flying is expensive, and there aren’t too many conferences that are willing to pay all of the expenses of their speakers. I would have no issue, however, with doing a video conference. While it’s not quite the same as seeing the actual person there, it’s got to be better than not getting speakers at all due to the travel involved.

In addition to commenting on my blog, Francis Carden, CEO of OpenSpan, also was kind enough to give me a short demo of their product. In my previous post, I introduced the concept of a “Desktop Service Bus” and wondered if the product would behave in this fashion. One of the interesting things I hadn’t thought of, however, is exactly what a desktop service bus should behave like? For that matter, what’s the right model of working with an enterprise service bus? More on that in a second.

Francis did a nice little demonstration for me that showed how custom integrations could be built quickly, first by interrogating existing applications (desktop or web-based) and grabbing possible integration points (virtually any UI element on the screen), and then by using a visual editor to connect up components in a pipeline-like manner. If you’re familiar with server-side application integration technologies, think of this tool as providing an orchestration environment, as well as the ability to build adaptors on the fly through interrogation.

Clearly, this is a step in the right direction. Francis made a great comment to me, which was, “People stopped thinking about this [desktop integration] because they’d long forgotten it was possible.” He’s right about this. With the advent of web-based applications, many people stopped talking about OLE and other desktop application integration techniques. The need hasn’t gone away, however. Again, using the iPhone as an example, many people complain about its lack of cut-and-paste capabilities.

Bringing this back to my concept of a desktop service bus, there clearly is a long way to go. When I see tools like OpenSpan or Apple’s Automator, it’s clear that they’re targeted at when a need to integrate is determined after the fact. You have two systems that no one had thought of integrating previously, but now there is a need to do so. This is no different than integration on the server side, except that you’re much more likely to hear the term “silo” used. When I think about the concept of a desktop service bus, or even an enterprise service bus for that matter, the reason a usage metaphor doesn’t immediately come to mind is that it’s not the way we’ve traditionally done things. When we’re building a new solution, the collection of services available should simply be there. There’s a huge challenge in trying to organize them, but if we can organize all of the classes in the Java API’s and all of the variety of extensions through intelligent code completion, why can’t we do the same with services, whether available through a network interaction or through desktop integration? It will take a while before this becomes the norm, but thankfully, I think the connectivity of the web is actually helping in this regard. Users of sites like Flickr, Facebook, Twitter, MySpace and the like expect the ability to mash and integrate, whether with their mobile phones, their desktop machines, other web sites, and more. Integration as the norm will be a requirement going forward.

One of my email alerts brought my attention to this article by Rich Seeley, titled “Desktop Integration: The last mile for SOA.” It was a brief discussion with Francis Carden, CEO of OpenSpan Inc. on their OpenSpan Platform. While the article was light on details, I took a glance at their web site, and it seems that the key to the whole thing is this component called the OpenSpan Integrator. Probably the best way to describe it is as a Desktop Service Bus. It can tap into the event bus of the underlying desktop OS. It can communicate with applications that have had capabilities exposed as services via the OpenSpan SOA Module, probably through the OpenSpan Studio interrogation capability. This piqued my interest, because it’s a concept that I thought about many years ago when working on an application that had to exist in a highly integrated desktop environment.

Let’s face it, the state of the art in desktop integration is still the clipboard metaphor. I cut or copy the information I want to share from one application to a clipboard, and then I paste it from the clipboard into the receiving application. In some cases, I may need to do this multiple times, one for each text field. Other “integrated” applications, may have more advanced capabilities, typically a menu or button labeled “Send to ABC…” For a few select things, there are some standard services that are “advertised” by the operating system, such as sending email, although it’s likely that these are backed by operating system APIs put in place at development time. As an example, if I click on a mailto: URL on a web page, that’s picked up by the browser, which executes an API call to the underlying OS capabilities. The web page itself can not publish a message to a bus on the OS that says, “Send an email to user joe@foobar.com with this text.” This is in contrast to a server-side bus where this could be done.

In both the server-side and the desktop, we have the big issue of not knowing ahead of time what services are available and how to represent the messages for interacting with them. While a dynamic lookup mechanism can handle the first half of the problem, the looming problem of constructing suitable messages still exists. This still is a development time activity. Unfortunately, I would argue that the average user is still going to find an inefficient cut and paste approach less daunting than trying to use some of the desktop orchestration tools, such as Apple’s Automator for something like this.

I think the need for better integration at human interaction layer is even more important with the advances in mobile technology. For example, I’ve just started using the new iPhone interface for FaceBook. At present, there is no way for me to take photos from either the Photos application or the Camera application and have them uploaded to FaceBook. If this were a desktop application, it isn’t much better, because the fallback is to launch a file browser and require the user to navigate to the photo. Anyone who’s tried to navigate the iPhoto hierarchy in the file system knows this is far from optimal. It would seem that the right way to approach this would be to have the device advertise Photo Query services that the FaceBook app could use. At the same time, it would be painful for FaceBook if they have to support a different Photo Query service for every mobile phone on the market.

The point of this post is to call some attention to the problem. What’s good for the world of the server side can also be good for the human interaction layer. Standard means of finding available services, standard interfaces for those services, etc. are what will make things better. Yes, there are significant security issues that would need to be tackled, especially when providing integration with web-based applications, but without a standard approach to integration, it’s hard to come up with a good security solution. We need to start thinking about all these devices as information sources, and ensuring that our approach to integration handles not just the server side efforts, but the last mile to the presentation devices as well.

Richard Monson-Haefel posted a great piece on his blog on widgets and gadgets (also posted on the Burton Group APS blog here). It serves as a good introduction to them. After a thorough definition, he primarily focuses on their use in a consumer setting. As a followup, I’d like to see him post more on their role in the enterprise. It’s something I’ve commented on, as well as Om Malik. As I’ve stated previously, I really think they have a potential role in workflow-based solutions as a vehicle for providing lightweight interfaces that are single-purpose in nature, that is, they provide an interface for doing exactly the task that needs to be done, nothing more, nothing less. They start up quickly and they go away quickly. Hopefully Richard will take the bait.

Phil Windley, Scott Lemon, and Ben Galbraith had a nice discussion on the iPhone, Apple’s iLife and iWork, user experience, consumer-friendliness, and much more in the latest IT Conversations Technometria podcast. Sometimes, their best podcasts are simply when they get together and have a discussion about the latest happenings. It was very entertaining, especially the discussion around the iPhone. Give it a listen. Also, make sure you give the Paul Graham essay on “stuff” mentioned by Phil a read.

I was a panelist for a discussion on the Future of SOA at The Open Group Enterprise Architecture Practitioner’s Conference in late July. The session was recorded and is now available as a podcast from Dana Gardner’s BriefingsDirect page. Please feel free to followup with me on any questions you may have after listening to it.

Back in December, I posted some kudos to my local Apple Store at West County Mall in Des Peres, MO. Back then, during the week before Christmas, they replaced one of the fans in my MacBook Pro in about two hours, when I was expecting to be without for a week. This fan issue was a known problem with the first generation of MacBook Pro’s with the Intel chips. Anyway, the other fan in it started rattling away recently (thankfully while it was still under warranty), and I took it in this past Saturday at 5:40pm. They told me it would be about 5 days. I let them know that I use it for work and would be traveling on Tuesday morning, so if there was anything they could do to get it done by then, that would be great (I have an older Powerbook that I was prepared to use). Well, at about 10:40am on Sunday morning, the call came in that everything was fixed. Once again, whether it’s a case of extremely conservative estimation or someone going over and above to get it fixed, I’m a happy customer. My MacBook Pro is quiet as a whisper again and I’m thankful to the techs at the store. I talked with a few of the guys there, next time I need to remember to get their names to publicly thank them.

I was trying to figure out why the comments on my blog pages are always printed in some hard-to-read, microscopic font. I’m not a CSS expert, in fact, I’d say I barely know enough to have my blog page look halfway decent. When I did my redeisgn, my goal was to find a pre-made WordPress theme that I liked, and change as little as possible.

Anyway, I found out that in the Safari 3.0 beta, you can right-click anywhere on the page and select “Inspect Element.” You’ll get the following pop-up:

This allows you to see exactly what CSS styles are being applied to the element in question. If you click on a parent element in the top pane, Safari will briefly outline the element on the page in a red box, so you know what aspects of the page any style changes will cover. For a CSS-newbie like me, this enabled me to figure out exactly what CSS entry needed to be changed to fix my comments. It turns out the author of this theme didn’t do anything with comments and that most of the entries in the file were copied from whatever theme was used as the basis. Anyway, my comments are now bigger and hopefully more readable, and I learned something about Safari in the process. By the way, I do not know whether this same feature exists in the Windows version, I’m on a Mac.

A fellow member of the SOA Consortium, Surekha Durvasula, EA Manager for Kohl’s, recently posted her perspective on service versioning on the SOA Consortium’s blog. At the end, she asked five questions, to which I thought I’d respond.

1. How many versions of a service should be “live” at any given time? How many versions are too many?
   I’ve actually blogged on this one, so make sure you read this entry before reading the rest of my answer. I’ve yet to see this put into practice, however, for two reasons. First, many organizations are still focused on getting version one out the door, so the pressure isn’t on to solve this problem. Second, organizations are still learning how to manage the service consumer and service provider relationship. The approach I outline requires significant maturity in managing consumers and product lifecycles. In the typical project-based culture in IT, this level of maturity is hard to find. In the absence of maturity, I typically see an arbitrary number set (usually 3). Setting a limit certainly recognizes that versioning must be dealt with, but only time will tell whether that number is right or not.
2. Do you use the service mediation layer to achieve backward compatibility?
   I’ve certainly advised companies that this can be done, but again, haven’t seen it put into practice yet. If we have a policy that says two or more versions must be able to co-exist in production, that implies that we have the ability to route to either of them. If we can do this, there shouldn’t be a need to leverage a mediation layer unless some consumer can’t change in time. This is why I think lots of companies are picking 3 as the “right” number of versions to support. It assumes that when version 2 comes out, consumers should be able to move to v2 by the time v3 is ready. If you choose to only have one version running in production (the latest), and leverage the mediation layer, you may eventually run into a type of change that isn’t easily mediated at which point you need to fall back to having multiple versions running at once. Knowing this, I’d make sure I knew how to run multiple versions at the same time first, and then try to leverage mediation where it makes sense.
3. Where do you determine the service version – the mediation layer, the service consumer, or a service provider?
   Let’s handle the easy one. If you handle it at the service consumer side, you’re effectively saying that consumers must explicitly specify a version somehow. If this is the case, versioning effectively goes away, the explicit specification would treat a different version as if it were a different service. You could certain leverage a mediation layer and apply some transformations to send a V1 request to V2, but eventually you won’t be able to mediate for backward compatibility. If the version desired is not explicit, now we have to handle it through a mediation layer or at the service provider. My personal preference is to leverage the mediation layer for this routing. Otherwise, your service implementation will now be littered with logic to determine what version the request represents, map that to the appropriate implementation, etc. I just don’t think that belongs in code. That belongs in a policy repository. If you externalize this, the service developer can just focus on building services.
4. Do you have governance models and policies around transitioning existing consumers to new versions? Who is responsible for executing that transition?
   Again, I’ve yet to personally see this in practice from an SOA standpoint. I have seen it put into practice from a shared infrastructure standpoint, however, such as rolling out a new version of an app server. Governance is critical. When the governance processes did not allow appropriate priority for these versioning efforts, it was a nightmare. It’s not just about funding for the upgrade, but it’s also about funding the impacted consumers and ensuring they have the resources to do their part. Second, the service provider must make it a consumer-friendly process as possible. Before that new version is ever put into production, the service team should have figured out exactly how their consumers will be impacted. In the infrastructure example, the team responsible for the app server worked with every single application hosted on the platform to make the process as painless as possible. They presented this approach when they requested funding for the effort, and the IT governance process made sure the impacted teams were onboard before it was approved. As a result, it went very, very smoothly. Planning these upgrades is tricky however, as unless things are properly coordinated and bundled, the entire IT project portfolio can get bogged on with independent versioning efforts. There does need to be some master planning over the whole portfolio.
5. What is the most graceful way of “retiring” or “decommissioning” a service?
   If you’ve tackled the first question of how many versions, this shouldn’t be an issue. If you’re enforcing your policy, all consumers of V1 will have migrated to V2 or V3 before V4 goes in. V4 goes live, V1 is shut down. Of course, this is where management must come into play. Whether you perform authorization or not, all service requests must have identity attached to them. If you don’t, you’ll never know whether all the known consumers have migrated. There shouldn’t be any unknown consumers, and if there are, some process wasn’t followed long before this decommissioning effort. In addition to identity, you also need to know the usage profile. I had one consumer of a service that was only run once a quarter, as it was part of quarterly financial processing. If I relied on daily usage counts of 0 to judge when to decommission, this could be devastating for a consumer that is run once every 90 days.

I look forward to the day where these conversations are applicable to the mainstream. Clearly, there are thought leaders and some companies that are already facing these issues. The majority will be following in the future, so now is the time to start thinking about this.