Todd Biske: Outside the Box

Via a crosspost on WebServices.org, I ran across this blogs from Mark Little. He’s right on mark in that the religious debate that occurs between REST proponents and WS-* proponents is very much like debating MacOS versus Windows. In the end, he places REST on the same side as MacOS X. Normally, I’m like Mark in that I take a middle-of-the-road approach. I know that my technology choices are based upon the things that I find important, and that may not be the same set as others. In my case, I am a die-hard Apple user and have been for over 20 years now. I did own one Windows PC for a brief point in time (along with my Mac) and just hated it with a passion. Anyway, to get to the point, my personal preferences are for WS-*. I do think REST has its place, but if it were up to me, I’d stick with WS-*. Given Mark’s analogy, am I now doomed to a life of conflict since my Mac-loving side should point me toward REST?

Where I think the analogy goes south is in equating a minimalist interface to ease of use. Ease of use does not imply taking a least common denominator approach. Ease of use implies presenting the right things to the user at the right point in time, and hiding the complexity that the user doesn’t need to see, if that’s what is warranted. WS-* isn’t about exposing that complexity to every developer. I’m willing to bet that any company that is heavily invested in WS-* development tools would state that there goal is to hide that complexity. Taking it out of the specification merely makes it someone else’s problem. It doesn’t make it easier to use. The only time it could perceived that way is if the solution didn’t warrant it in the first place. That would be akin to Apple marketing Final Cut Pro to all of us making videos of our kids that simply need iMovie. At the same time, it would be just as bad, if not worse, to tell the television and movie studios to use iMovie to build their next big-budget movie or TV show.

The message is that the WS-* development tool vendors need to take a Mac-like approach. Make it easy to use, and hide the complexity. I think they’re well on their way to doing this.

One of the topics that I don’t see discussed much in the context of SOA is business intelligence. I’m not talking about the traditional use of business intelligence tools, I’m talking about using business intelligence tools to the business of IT.

SOA has been described as a movement from building for longevity (built to last) to building for change. While that’s a great description, it doesn’t give any help in answering the question of how to build for change. Therein lies the challenge. We can only guess what new requirements may come along in the future. In some cases, the change may be very apparent, such as a merger or acquisition. In other cases, however, things may move very slowly over time. By the time the changes have become apparent, IT may already be behind the curve in supporting it. How do we shift the odds in the favor of IT?

I think one answer to this is through the collection and analysis of service interactions. The data acquired from the analysis completes the feedback loop back into the architecture to initiate change. Just as the business must monitor its performance through key indicators and make changes accordingly, so must IT monitor its own performance and make changes. It needs to go beyond traditional system measurements around resource utilization, however. We need to understand the patterns of access across applications, and the relationship of those patterns to business and market activities. Services represent key collection points of information to be funneled into the analytical engine, and get the necessary feedback to move the architecture from a static, time-boxed view, to a dynamic, ever-changing view.

No, this isn’t another post on ROI, but rather, a comment to Jeff Schneider’s post on Supply and Demand Side SOA. Jeff states:

Most of the companies that I’ve consulted to start with a ‘supply side SOA strategy’. That is, they create a strategy to create a supply of services. As everyone in the manufacturing world knows, creating supply without demand is a really bad thing…Most manufacturing companies have moved to some variation of just-in-time production. They wait for customer demand before they build the products. You’d think that this would work for SOA but in many companies it isn’t. The reason is simple. These companies do not have a demand-side generator (the sales and marketing engines). Demand-side SOA is a discipline that doesn’t exist in many corporations.

Jeff is absolutely right on here, on several fronts. First off, I’m sure no one would argue that many companies simply start by creating services. Odds are that these services are specific to the project that thought them up, but even if they weren’t, what prevents them from being used by projects down the road? Is it because the developers wrote lousy code? Probably not. The most likely cause is poor communications. Jeff’s demand-side generator is defined as sales and marketing. In other words, getting the word out about what is available! The current registry-based approach for publicizing services is akin to phone book marketing. Do you pick the provider who only lists a phone number, or do you pick the provider with the full page advertisement including hours of operation, customer service philosophies, and the owner’s name? Odds are, that’s not the only place you’ve seen them, either.

The need for sales and marketing efforts is especially important where natural barriers exist to communication. If your IT department is spread out across multiple states and even countries due to mergers and acquisitions, getting the word out about the services that are available is not easy. Even within a highly centralized group, there can still be barriers between the infrastructure teams and the application teams. If the infrastructure teams have provided an excellent mapping and transformation service, they need to create the demand from the application teams by getting out and marketing the service to them. If they don’t know about it, they won’t use it. Furthermore, communications is never one way. Odds are, by communicated about services that are available, opportunities for other services will be unearthed. Get out there and start creating demand for your services.

Wow, someone stirred the pot today. Miko Matsumura lashed out on the topic of reuse within SOA, along with David Chappell (the .NET David, not the Sonic David), as quoted in Joe McKendrick’s ZDNet SOA blog. This started with another post by Joe, quoting Charles Stack of Flashline BEA. Stephen Anthony commented on his blog with more questions than answers.

One of the biggest mistakes I think could be made would be to sell SOA purely as a way to achieve the IT Holy Grail of reuse. In other words, reusing reuse to sell the latest technology trend in the same way we used it to sell previous technology trends. Should services be used by more than one consumer? Absolutely. Will all of them? Certainly not. In many cases, the service boundary may be the point that separates things that may change from things that don’t (e.g. interface and implementation). In such a scenario, we are likely providing a more agile solution. Rather than having to rip apart the entire solution, only the services impacted by the business change need to be touched. The change may not be within the service, but rather on the consumer side. I may adjust my process definition and invoke the service at a different time. Do these solutions mandate reuse? Certainly not. Agility in supporting the business and its changes are the primary concern. Eliminating redundancy and leveraging exists assets will always be a goal of IT. While that may cut costs, it’s not going to help revenue. Only my meeting the changing needs of the business through agile solutions can that revenue stream be impacted for the better. If you’re cutting your costs at the same time, even better.

One added note. Mark Griffin made a great point in his blog that if you are striving for reuse, you’d better be prepared for handling change management. Sooner or later, that service will be modified and its interface will change. Whether you have one consumer or many, you’ll need to effectively manage that change.

Technorati tags: soa reuse

Another detour from the usual SOA routine for a plug for my eldest daughter’s school, Immaculate Conception. Like many schools, hers is selling Entertainment Books to raise funds. If you don’t know what an Entertainment Book is, it’s a big book of coupons for local restaurants and attractions. Usually, if you keep the book in your car and remember to check for a coupon, you’ll quickly recoup the cost.

Anyway, Their goal for this year is to sell 1500 books, which would net about $16,500 for the school. While I am going to take her around the neighborhood so she can do more of the selling, I’m also doing my part. After all, entertainment.com has set it up so that purchases made through their web site can be credited to individual sellers. That’s a step in the right direction, and if they’re going to make it available, I’ll take advantage of it. To purchase a book for your area, follow this link. Enter your billing and shipping info, and I, my daughter Elena, and Immaculate Conception School, thank you. For those of you that were looking for something SOA related, thanks for you patience! Perhaps entertainment.com can adopt SOA and allow fund raisers to better integrate their efforts!

As a subscriber to the broadway series at the Fabulous Fox here in St. Louis, I occasionally get email about upcoming concerts and shows with the ability to buy tickets before the general public, or at least before the portion of the general public that doesn’t know someone who has broadway series tickets. Last night, we came home from a meet the teacher night at my daughter’s school and in my inbox was a message that the Cheetah Girls and Hannah Montana had added another show and we could pre-buy tickets tomorrow. Well, my oldest daughter is only in first grade, but my niece is in third grade, and lives and breathes those shows on the Disney Channel. So, my wife was tasked with the responsibility of getting tickets the next morning.

This morning, 15 minutes after tickets went on sale, my wife called me with her frustrations in trying to obtain tickets. There seemed to be no rhyme or reason to what tickets showed up as “best available.” When I decided to help out, the site went haywire and would only return me unreadable characters. While we think we managed to purchase some tickets (we still haven’t received any email confirmations 10 hours later), the experience was about as bad as it can get. Of course, MetroTix has a virtual monopoly on ticket sales so they can get away with having awful service, because there’s nowhere else to go.

Anyway, my point was not to complain about the awful service. What I wanted to discuss was their need for SOA. For all I know, they may have one, but if they do, it certainly doesn’t work very well. Ticket sales are certainly a classic case of channel expansion. Years ago, you had to go the venue to get tickets. Slowly, ticket brokers were added, then phone orders, and then internet orders. Unfortunately, the only thing the channels have done is allow you to wait and get frustrated in the convenience of home. MetroTix has a unique problem in the nature of their traffic, since it comes in huge surges at the time tickets go on sale. What’s worse is that for whatever reason, all shows tend to go on sale at 10am, rather than spreading the shows out over the course of the day, spreading the load.

So, I suggest the following to the IT department of MetroTix:

1. Embrace SOA and make available some services for ticket purchasing! I’d suggest letting some resellers handle the customer facing end, but you need to fix the next item first.
2. Leverage some infrastructure on-demand. Could something like Amazon’s EC2 handle the load?
3. If you don’t do this, then get some consultants/advisors on becoming a customer centric organization to help you. I’m sure Patricia Seybold would love to have a chat.

The SOA Governance space was given a little jolt yesterday with BEA announcing their purchase of Flashline. Dana Gardner posted some good analysis on this on his blog at ZDNet, as did Neil Ward-Dutton.

What I’m interested in is how big the “repistry” (regository?) will become over time? As I think about it, the registry/repository is somewhat like the database of SOA. Most solutions, after all, need some form of database. The repistry of SOA has allowed convergence of the development time asset repository with the run-time service registry. What’s next? In my mind, we must now proceed into the management repository. The buzzword frequently associated with systems management is ITIL. Guess what? You’ll frequently see another repositry associated with that space called the Configuration Management Database, or CMDB. A convergence across this space makes perfect sense. Part of the metadata associated with a service needs to be the machines where it is deployed. Odds that, that information may already be in the CMDB.

If you can see where I’m going with this, you’ll now see that the problems that were created as new databases were put out for every client-server application could come back to haunt us, as we now have repositries for niche areas that overlap with each other, causing potential for replication and synchronization issues. Do I then create a repositry services layer that provides a single view of the truth? Do I need some form of repositry federation? How about a meta-repsoitry? Of course, the repositry itself already was a metadata source, so now I have meta-metadata. Ugh, I’m giving myself a headache. I have full faith that the vendors will become aware of this, and eventually we will have a repositry that encompasses the capabilities of UDDI registries, software asset management, configuration management, and much more. The real question is whether any enterprise will have mature enough processes to leverage it all successfully…

Technorati tags: soa uddi regsitry repository

A brief change in topics from my usual rants about SOA. Those of you who have met me know I’m an Apple fan. The first computer I ever bought with my own money was an Apple //c, and I’ve been an Apple owner ever since. I’ve never had the latest and greatest Mac, however, I was an owner of a first generation iPod. Along the way, I upgraded to a third generation, added a shuffle, and recently went up to a black video iPod.

Anyway, as we all know, there’s no shortage of accessories for the iPod, including speakers, cases, voice recorders, bluetooth adapters and headphones, and FM transmitters. I’ve got my fair share of these. But, as I glanced through September issue of MacAddict Magazine, I’ve determined that the craze has gone too far. Yes, some people may have thought we’d reach that point when entire vehicles were being sold as accessories for the iPod. I was okay with that though, since people do listen to a lot of music in their cars. So what iPod accessory could it be that has made me say things have gone too far? It is the iCarta: Stereo dock for iPod with Bath Tissue Holder.

Buy yours now, $149.95 at Atech Flash Technology. Of course, a friend told me about a scene on the show Eureka where a character walks into a room that is supposed to be a bathroom but is empty. Then, the toilet, tub, etc. all slide out from panels in the room, including a screen over the toilet that can display any newspaper in the world. The character remarks that he’ll never have to come out again. I guess if he had an iCarta and a healthy supply of podcasts from IT Conversations, he may not have to come out…

Technorati tags: apple ipod

Something I’ve blogged about in the past is vertical SOAs, even wondering the role they’ll have in the consulting world. Today, I listened to a podcast from Dana Gardner on IT Shared Services with two reps from HP. I’ve only learned a little bit about ITIL, but this podcast has me wondering whether ITIL is the vertical SOA for running IT. So, two questions out there for my friends in the blogosphere, especially other enterprise architects that have an interest in management technologies and SOA for IT.

1. Are you adopting ITIL in your organization?
2. If so, have you been able to use the ITIL processes to apply SOA to the business of IT?

I plan on getting up to speed on ITIL and seeing if it makes a suitable example for showing a real-world example of how to go from documented business process to SOA. I’ve always felt that SOA for IT would be a great place for an organization to start. After all, we IT professionals should understand the business of IT. Unfortunately, excellent support for management of systems is not something the vendors get around to providing until version 10. I challenge the vendors listening to come to the market on day one with secured Web Services for management functions, allowing the IT organization to utilize business process and workflow technology to increase the efficiency of the IT organization.

Technorati tags: soa itil shared services itsm

Congratulations and best of luck to Brenda Michelson. She recently left her position with Patricia Seybold Group and introduced Elemental Links, Inc. To quote her blog:

Elemental Links is an IT consulting and advisory practice specializing in strategy, architecture, and portfolio planning for business-driven IT.

Brenda’s announcement got me thinking about the role of consulting in SOA adoption. For the record, I am not a consultant nor have I ever been a consultant, at least in the formal paid sense. I fall into the category of practicing Enterprise Architect like James McGovern and Mike Herrick. I would be an end-user of consulting practices. While I have many friends that are practicing analysts and/or consultants in this space, including Brenda, Jeff Schneider, and the ZapThinkers, Jason and Ron, they all tend to come out of the IT consultancy/advisory space. While there certainly is a market for this, and will be for some time, what is the right way to grow a business in this space?

The answer to this will largely depend on your view on whether SOA is an IT-driven thing or business-driven thing. We all know that a goal of SOA adoption is to render this a moot point. After all, IT is part of the business, isn’t it? While IT-Business alignment will continue to garner significant press for years to come, most would agree that SOA adoption should be about the business and not about the technology. Presuming things head this direction, what does this mean for SOA Consulting companies? Will they be competing for business with companies that provide assistance in adopting Six Sigma and other business re-engineering and improvement efforts? To what extent will these consultancies need to become specialists in different verticals, such as manufacturing, health care, financial services, retail, etc. in order to be successful? Will the marketplace shift to groups that have a more business-centric focus on technology, such as companies like Patricia Seybold Group and Elemental Links? Will SOA become more associated with business discussions than with technical discussions, or will some other term be used?

In my mind, the bigger problem is on the business side. There are lots and lots of consulting companies that exist that can author services in any desired flavor and platform. The real problem is in identifying what the right services are. There are plenty of case studies that have leveraged services for technical benefits, such as in a B2B integration scenario, but where are the case studies that are about SOA and BPM efforts leading to business change and innovation? Who are the consultancies that will make this happen? What will they look like 5 years from now?

I’d love to hear the thoughts of Brenda, Jeff, Patricia Seybold, and any others on this, in as much as they’re willing to share, since it certainly involves their business strategy. I’d also like to hear what other enterprise practitioners like James, Mike, Scott, Mark, and others have to say.

Technorati tags: soa bpm consulting six-sigma

We’re beginning to see some movement around vertical service architectures, or better put, the creation of reference service architectures for particular business domains. For example, back in April, HP had a press release announcing “Industry-specific Service-oriented Architectures.” Last week, on August 3rd, IBM announced the acquisition of Webify. Rich Seeley of SearchWebServices.com stated that Robert LeBlanc, general manager of IBM WebSphere Software, characterized a vertical focus as the next generation of SOA.

I remember back about 7 years ago when I was introduced to TogetherJ. A colleague had Peter Coad’s book, Java Modeling in Color with UML. Coad’s gave example models across a wide variety of business areas. While modeling the internals of the systems may not be as useful, as this is likely to vary widely by enterprises. What may not vary as much, are the services that expose the functions of the major components of the enterprise. This is where this new wave of vertical service architectures may have some legs. Companies will be free to implement the services however they want, but the identification of what services, at least some good subset to get started, are needed can be provided in the form of reference architectures. I’m not an industry analyst, so I don’t have the luxury of having seen many enterprises, but my gut tells me that if you compare two retail organizations or two health care organizations, the core services they require are going to be very similar. Differentiation can be made by the implementation of these services, the management of them, and the remaining 20% of services that aren’t typical of all organizations in that vertical.

This starts to imply that there is a range of commodity services that could have wide applicability and are likely not business differentiators, at least not in the sense that you have them. It’s more about how you use them. To that end, it would be great to see community efforts that address some of these domains. I’ve previously blogged about SOA for education. How many elementary, middle, or high schools do you know that have enterprise architects? How many of them even have any dedicated IT staff at all? Often times, it may be the computer instruction who is also acting as architect and operations support. My daughter’s school has a volunteer technology advisory board made up of parents with IT backgrounds that try to assist in the school’s technology efforts. I’ve logged many hours helping them with varied tasks like web site support and the installation of their WeatherBug station. Largely, however, all of the efforts are handled by Mrs. Lewis, who also happens to be teaching all of the kids about computers all day long. It would be great if we technologists, whether analysts, developers, architects, support, etc., could use of skills to help out in the community on these technology related items of our own good will.

Speaking of good will, James McGovern, is one enterprise architect who has posted a few times on giving back to the community, whether through his efforts to teach programming to high schoolers, or now to raise money for the Juvenile Diabetes Research Foundation. I applaud James for his efforts and encourage others to do the same. While it may not be development of vertical SOAs for medical research foundations, it’s still the right thing. I will make sure that the Juvenile Diabetes Research Foundation is on my charitable donation list for this year.

Technorati Tags: SOA, JamesMcGovern

Back at the end of June, I posted some of my thoughts on personalized services after the announcement of Google Checkout. At that time, a lot of my thinking was on how a service provider can personalize services for their consumers. Since then, my thinking has went in a different direction. In cases like Google Checkout, a third party is in the position of being able to collect and potentially share lots and lots of information about our shopping practices (no worse than what credit card companies already have).

What would be very interesting is if these service providers gave the true owners of the information the ability to control who and how could access it. This actually creates a very interesting scenario, and one that I think demonstrates the importance of the policy-based infrastructure now available for Web Services. Let’s suppose there is a competitor to Google Checkout called PayIt. PayIt is storing purchase information in their data centers. Let’s also suppose that PayIt can makes this information available to the shopping partners that are leveraging their checkout service, in either an aggregated or anonymous fashion. In reality, the owner of the data being shared is the individual shopper, not PayIt and not their retail partners. Google, however, is acting as both the data steward and the service provider. How does the data owner get involved? The data owner, you and me, sets the policies. While PayIt provides the service, we provide the policies that govern the service execution- who can access them, and what information they can see. Since most of us don’t work for PayIt, there needs to be a way to externalize the policy management from the service execution, even outside the firewall. While this is an extreme example, the same needs exist inside the firewall. The group that own the source code and deploy the services may not be the same group that sets the policies regarding who can access them. While today we have tools for externalizing authorization policies, we’ll soon need better tools for other types of policy management tailored toward the end policy manager which could be you and I.

Brenda Michelson has another good conversation going on her eBizQ blog regarding SOA and Agile Development. Here is my comment:

I fall in the crowd of classifying SOA and Agile Development as apples and oranges. I wouldn’t call it oil and water, because there are some things that agile development practices address that are directly applicable to SOA adoption.

First, my definition of SOA is always at the enterprise level. In my mind, there’s no such thing as an SOA project, only an enterprise SOA adoption effort. If I was on a project that was building both services and consumers, I think agile development would definitely be a good thing. The reason, however, is because by the nature of the project definition, the required collaboration should be in place to allow rapid change. At the enterprise level, however, the service provider and the service consumers are likely on completely different schedules, across many different projects and teams, all of which are barriers to communication and collaboration. Without communication and collaboration, agile efforts will struggle.

At the same time, creating rigid service interfaces that don’t change is completely the wrong approach. The problem is poor communication between service providers and services consumers, not an interface that changes. The business does not remain constant, and anyone who thinks that service interfaces can be defined once and set in stone is destined for failure. The key to success is change management. Change management is not a problem in agile development because of close communication between the parties impacted by the change.

So, I think the takeaway should be that SOA adoption must ensure that communication and collaboration between providers and consumers occurs. It doesn’t mean that service interfaces should change on a rapid basis, as individual component interfaces may on an agile development project, but it does mean that change should be managed.

I’ve decided that my blog needed some kind of name besides “Todd Biske’s blog.” While it certainly implies that it contains what I think, it doesn’t imply much about how I think. I originally thought about calling it “The Big Picture” but someone already has a blog by that name. I would call myself a big picture thinker before I’d call myself an “out of the box” thinker, but when it comes to SOA, a frequent message I give is to think out of the box, so it fits.

The above photo is of my youngest daughter at about 6 months old. I used this picture on a slide in my very first external presentation which was on SOA. I think that thinking outside of the box is an inherent part of adopting SOA. No matter how much strategic planning has gone on, and how much context is given, as soon as things get turned into a project, the project plan takes over and the more strategic needs go on the back burner. It’s important to keep thinking strategically while acting tactically, always taking steps toward continued improvement in the enterprise. If you don’t have someone whose responsibility it is to think outside of the box, you’ll probably have a much longer road ahead of you.

I was listening to the CIO Daily News Podcast this morning and their report on Google Checkout and it got me thinking about privacy and personalization. The first thought running through my mind was that this could be a gold mine for them with their advertising model. While I don’t know the details of how it works, it is possible that their service could have visibility into not only how much money you spent and who you spent it with, but all of the products you purchased, as well. The key to the whole advertising model is targeted advertising. With the ability to see this, even if it winds up being no more than the dollar amount rather than each line item, Google could now sell advertising for say, MacWarehouse, that would show up on technology related queries by users who they know have made purchases at MacMall. It would be no different than checkout coupons at the grocery store. Anyone who has purchased baby food has probably received coupons at checkout for a competing vendor. If Google is able to see each line item, the information only becomes even more powerful. Looking at what amazon can do just with their knowledge of how their site is used, imagine what could be done where your purchasing habits were aggregated across a wide number of e-commerce sites.

My point of this post was not to raise a bunch of privacy concerns, however. I know that data collection is a part of life and I think it does far more good than harm. What I really began thinking about is the notion of personalized services, the outcome of collecting all of this data. What is the appropriate way to incorporate personalization into a Web Service? Does personalization impact the interface definition? The more common example is alternate implementation paths, which wouldn’t necessary imply a new interface. An example of this is the gold-platinum user. Perhaps their requests always get routed to the server with the least amount of load. Another example would be a flight reservation system. If the system knows that I always request window seats, a personalized service would always recommend a window seat when available if the request came from me. Other simple cases could simply be the inclusion/exclusion of particular operations. Outside of formating of values, I haven’t come up with a great example of where the interface would vary, but I’m sure they exist. It’s a difficult question though, because personalization is usually associated with something that’s destined for a user rather than something that is destined for another system. The one thing that is a definite must, however, is that identity must be on all service requests. There should be no such thing as an anonymous request. If not, you have no hope of personalization.

So, has anyone out there run across some case studies of personalization applied to SOA?