Todd Biske: Outside the Box

Archive for August, 2007

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.

Dana Gardner has posted the latest episode of his Briefings Direct: SOA Insights series. In this episode, the panelists (Tony Baer, Jim Kobielus, Brad Shimmin, and myself) along with guest Jim Ricotta, VP and General Manager of Appliances at IBM, discuss SOA Appliances and the recent announcements around the BPEL4People specification.

This conversation was particularly enjoyable for me, as I’ve spent a lot of time understanding the XML appliance space in the past. As I’ve blogged about in the past, there’s a natural convergence between software-based intermediaries like proxy servers and network appliances. I’ve learned a lot when working with my networking and security counterparts in trying to come up with the right solution. The other part of the conversation on BPEL4People was also fun, given my interests in human computer interaction. I encourage you to give it a listen, and feel free to send me any questions you may have, or suggestions for topics you’d like to see discussed.

Chris Haddad of the Burton Group recently had a post entitled, “What is a service?” on their Application Platform Strategies blog. In it, he points out that “it is useful to first categorize services according to the level of interaction purpose.” He goes on to call out the following service categories: Infrastructure, Integration, Primitive (with a sub-category of Data), Business Application, and Composite.

First off, I agree with Chris that categorization can be useful. The immediate question, however, is useful for what? Chris didn’t call this out, and it’s absolutely critical to the success of the categorization. I’ve seen my fair share of unguided categorization efforts that failed to provide anything of lasting value, just a lot of debate that only showed there any many ways to slice and dice something.

As I’ve continued to think about this, I keep coming back to two simple goals that categorizations should address. The first is all about technology, and ensuring that is is used appropriately. Technologies for implementing a service include (but certainly aren’t limited to) Java, C#, BPEL, EII/MDM technologies, EAI technologies, and more. Within those, you also have decisions regarding REST, SOAP, frameworks, XML Schemas, etc. I like to use the term “architecturally significant” when discussing this. While I could have a huge number of categories, the key question is whether or not a particular category is of significance from an architectural standpoint. If the category doesn’t introduce any new architectural constraints, it’s not providing any value for this goal, and is simply generating unnecessary work.

The second goal is about boundaries and ownership. Just as important as proper technology utilization, and probably even more important as far as SOA is concerned, is establishing appropriate boundaries for the service to guide ownership decisions. A service has its own independent lifecycle from its consumers and the other services on which it depends. If you break down the functional domains of your problem in the wrong way, you can wind up making things far worse by pushing for loose coupling in areas where it isn’t needed, and tightly coupling things that shouldn’t be.

The problem that I see too frequently is that companies try to come up with one categorization that does both. Take the categories mentioned by Chris. One category is data services. My personal opinion is this is a technology category. Things falling into this category point toward the EII/MDM space. It doesn’t really help much in the ownership domain. He also mentions infrastructure services and business application services. I’d argue that these are about ownership rather than technology. There’s nothing saying that my infrastructure service can’t use Java, BPEL, or any other technology, so it’s clearly not providing guidance for technology selection. The same holds true for business application services.

When performing categorization, it’s human nature to try to pigeonhole things into one box. If you can’t do that, odds are you’re trying to do too much with your categories. Decisions on whether something is a business service or an infrastructure service are important for ownership. Decisions on whether something is an orchestration service or a primitive service are important for technology selection. These are two separate decisions that must be made by the solution architect, and as a result, should have separate categorizations that help guide those decisions to the appropriate answer.

I was just having a discussion with someone regarding Apple’s recovery over the last ten years and what the future holds for them when it dawned on me that there are parallels (sorry, no pun intended) between Microsoft’s efforts in the server-side space in the enterprise and Apple’s efforts in the home.

There’s no doubt that Apple’s strategy has always been about having end-to-end control of the entire platform, from hardware to software. There are advantages and disadvantages to this, with the clear disadvantage being market share, but the advantages being user experience. On the Microsoft side, when they entered into the enterprise market, and this still holds true today, it’s really about getting as much Microsoft software there as possible. They would like to own the software platform from end-to-end.

The parallel in this is that when Microsoft moved beyond the desktop, where they had nearly all of the market share, they suddenly had to deal with a heterogeneous environment rather than a homogenous one. Microsoft’s strategy is not one of integration, however, it is about replacement. Over time, they’ve had to yield to the fact that integration will always be necessary, and that many infrastructures are too well established to incur the cost of a migration to an all Microsoft environment. That being said, Microsoft would be happy to take your money and do it, and they still continue to position their products so that thought is in the back of your mind. I don’t know of anyone who would argue with the statement that Microsoft solutions work best in an all-Microsoft environment. That’s not to say that it doesn’t work really well in a heterogeneous environment, it simply says that if you want the best Microsoft has to offer, you have to go 100% Microsoft.

Now let’s talk about Apple. I’d argue that the state of the market for the integrated, intelligent home is around the same point (maybe a bit less mature) that enterprise infrastructures were when the whole middleware rage occurred in the 90’s. Companies were just starting to realize the potential and the importance of integrating their disparate systems. Today, consumers are just starting to realize the potential of integrating the technology in their houses. I’m not going to make any predictions about when it will become mainstream, as they’re usually wrong, but I do think it’s safe to say that the uptake is definitely increasing in slope rather than remaining flat. Apple is in a very similar position to Microsoft. The home is a heterogeneous environment. Apple works best in an all Apple environment. Will Apple take a path similar to Microsoft to where they integrate where they have to, but are really focused on getting a foot in the door and then it’s all about more Apple? Or will there be careful decisions on where the strategy is about integration and where the strategy is about extending the platform? To date, I think they’ve done the latter. We don’t see an Apple-branded TV, instead we have a set top box that talks to TVs.

The biggest factor may not be what Apple does, but what everyone else does. Microsoft continues to gain market share in the enterprise because integration of heterogeneous environment is still a painful exercise. As look as there is pain in integration, there’s always opportunity for platform-based approaches to gain ground. Integration in consumer technologies is certainly a different beast, as there are standards and a certain level of status-quo. It’s not a painful effort to hook up stereo components from multiple vendors. At the same time, however, it’s ripe for improvements in the experience, case in point, the 100+ button remote control associated with most receivers. Likewise, the standards change all too often. Back when digital camcorders came out, Apple had a big win with integration with iMovie that no one else had. Over the past 8 years however, the digital camcorder manufacturers have changed formats to the point where you can’t say whether a digital camcorder will work with iMovie or not. It just shows that if you don’t control the platform end-to-end, your entire strategy can fall apart quickly based upon those pieces outside of your control.

I think Apple’s taking a very careful approach on what problems to tackle and when. The one thing I’m sure of is that Apple’s presence in the consumer will make the next 10 years in the home very exciting. While one could argue that the availability of the Internet in the home started the process of the demand increasing at a faster pace, I also think you can that Apple’s products, more so than any other consumer products company, have enabled that pace to continue to increase.

Back in February, Jason Bloomberg of ZapThink posted a ZapFlash entitled “Competitive SOA.” I didn’t blog about it at the time, but this topic was brought back to the forefront of my mind by this post from Ian Thomas, with some follow-on commentary from Joe McKendrick.

While I’m not one to take one side or the other strongly, I must admit that I have significant reservations about a competition model, whether it is internal competition as suggested in the initial ZapThink article, or it is competition between IT and outside providers of services. First, let’s get the easy part of this out of the way. Part of Ian’s article is about simply running IT as a business and having good cost accounting. I’m certainly not going to argue about this. This being said, there’s a big difference between being a division or department of a company versus a supplier to a company.

I believe strongly that a customer/supplier relationship between IT and the end users of IT in the business is a bad thing, in most cases. If IT moves to exclusively to that model, the business leaders should clearly always be considering outsourcing IT completely. In doing so, it definitely sends a clear message that technology usage is not going to be a competitive advantage for this company. I believe that outsourcing can make sense for horizontal domains, where cost management is the most important concern.

The right model, in my opinion, is to have IT be part of the business, not a supplier to the business. To be part of a business, you need to be a partner, not a supplier. Brenda Michelson posted some excerpts from a Wall Street Journal interview with three CIO’s: Meg McCarthy of Aetna, Inc., Frank Modruson of Accenture Ltd., and Steve Squeri of American Express Co. Some great quotes from this:

Ms. McCarthy: At Aenta, the IT Organization is critical to enabling the implementation of our business strategy. I report to the chairman of our company and I am a member of the executive committee. In that capacity, I participate in all of the key business conversations/decisions that impact the company strategy and the technology strategy.

Mr. Squeri: I believe that over the next 10 years, the CIO will get more involved in the overall business strategy of the company and see their role expand in importance. The CIO will be increasingly called upon not only to translate business strategies into capabilities but to become even more forward-looking to determine what capabilities the business will need in the future.

The days of tech leaders as relationship managers and “order takers” will go by the wayside and they will be called upon to create and drive technology strategies that drive business capabilities.

It’s great to hear these leaders calling out how IT is becoming a partner, rather than a supplier. While our business leaders are certainly more tech-savvy than they have been in the past, there is still significant value in having people that specialize in technology adoption and utilization on your leadership team, just as you have people who specialize in sales, marketing, operations, etc.

Ian suggests letting “self interest flourish within the bounds set by the organisational context as long as it delivers cost-effective services but punish it by outsourcing where it doesn’t.” Cost reduction is just one factor in a complex decision. Holding the threat of outsourcing over IT may certainly in a more efficient operation, but applying those principles to areas where the decision shouldn’t be based on cost efficiency, but strategic impact to the business is a risky proposition. Let the business, which includes IT, decide what’s right to outsource and what isn’t. It shouldn’t be a threat or a punishment, but a decision that all parties involved agree makes good business sense.

The latest Briefings Direct: SOA Insights podcast is now available. In this episode, we discussed semantic web technologies, among other things. One of my comments in the discussion was that I feel that these technologies have struggled to reach the mainstream because we haven’t figured out a way to make it relevant to the developers working on projects. I used this same argument in the panel discussion at The Open Group EA Practitioners Conference on July 23rd. In thinking about this, I realized that there is a strong connection in this thinking and SOA. Simply put, it is all about the consumer.

Back when my day-to-day responsibilities were programming, I had a strong interest in human-computer interaction and user interface design. The reason for this was that the users were the end consumer of the products I was producing. It never ceased to amaze me how many developers designed user interfaces as if they were the consumer of the application, and wound up giving the real consumer (the end user) a very lousy user experience.

This notion of a consumer-first view needs to be at the heart of everything we do. If you’re an application designer, it doesn’t bode well if you consumer hate using your application. Increasingly, more and more choices for getting things done are freely available on the Internet, and there’s no shortage of business workers that are leveraging these tools, most likely under the radar. If you want your users to use your systems, the best path is make it a pleasant experience for them.

If you’re an enterprise architect, you need to ask who the consumers of your deliverable are? If you create a reference architecture that is only of interest to your fellow enterprise architects, it’s not going to help the organization. If anything, it’s going to create tension between the architecture staff and the developers. Start with the consumer first, and provide material for what they need. A reference architecture should be used by the people coming up with a solution architecture for projects. If your reference architecture is not consumable by that audience, they’ll simply go off and do their own thing.

If you are developing a service, you need to put your effort into making sure it can be easily consumed if you want to achieve broad consumption. It is still more likely today that a project will build both service consumer and service provider. As a result, the likelihood is that the service will only be easily consumable by that first consumer, just as that user interface I mentioned earlier was only easily consumed by the developer that wrote it.

How do we avoid this? Simple: know your consumer. Spend some time on understanding your consumer first, rather than focusing all of your attention on knowing your service. Ultimately, your consumers define what the “right” service is, not you. You can look at any type of product on the market today, and you’ll see that the majority of products that are successful are the ones that are truly consumer friendly. Yes, there are successful products that are able to force their will on consumers due to market share that are not considered consumer friendly, but I’d venture a guess that these do not constitute the majority of successful products.

My advice to my readers is to always ask the question, “who needs to use this, and how can I make it easy for them?” There are many areas of IT that may not be directly involved with project activities. If you don’t make that work relevant to project activities, it will continue to sit off on an island. If you’re in a situation where you’re seen as an expert in some space, like semantic technologies, and the model for using those technologies on project is to have yourself personally involved with those projects, that doesn’t scale. Your efforts will not be successful. Instead, focus on how to make the technology relevant to the problems that your consumers need to solve, and do it in a way that your consumers want to use it, because it makes their life easier.