Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

This topic has been wandering around my head for a while, and a recent post by Joe McKendrick of ZDNet brought it back to the forefront. Sidenote: why can’t people get Joe’s name right? David Chappell of Sonic Software called him Joel McKendrick, and every time David Linthicum quotes him in his SOA Podcast, it sounds like “Joe McItrick.” Anyway, in this entry, Joe has some quotes from John deVadoss of Microsoft. He states:

In the Q&A, deVadoss says the most important thing about SOAs is that they are a means to an end — not an end in and of themselves. “There is . . . a preponderance of what I call the top-down, big-bang mega approach, which is often guilty of trying to ‘do SOA’ as opposed to delivering business value,” deVadoss says. “The fundamental problem with the big-bang mega approaches to SOA is that they almost always end up being out-of-sync with the needs of the business.”

There’s a lot of truth in that statement, but how do organizations end up that way? One suspicion that I have is that the organization was already that way to being with. I had the opportunity to have lunch with someone two weeks ago who is a VP of Operations (business operations, not IT) at a local enterprise. We discussed how he was leveraging BPM technologies. I left the lunch thinking how great this was that the use of IT was being driven by a tech-savvy business executive. There wasn’t any discussion about top-down or bottom-up. Having a plan for where the business needed to go was part of his job, not something that needed to be justified. He knew what could be taken on and where IT fit into the picture, and was able to successfully leverage it. Take now, in contrast, an enterprise where IT is a bunch of order takers, without clear strategic planning. It’s certainly possible that the lack of strategic planning goes all the way back to the business, as well. The lack of IT alignment may just be a symptom of poor alignment throughout the organization. Organizations like that are going to struggle to accomplish anything of a strategic nature, SOA and BPM just being recent examples. While there may be some room for some incremental success, there are bigger problems that exist preventing it.

In short, while SOA is touted as some as the tool which will increase IT and business alignment, so far, it’s only the enterprises that already had great IT and business alignment that are truly leveraging it successfully. Think of it like the difference between the automobiles that we drive to work and a Formula One race car. Technology in the race car could allow us to drive ridiculously fast, but if you put the average driver in that car, they’ll crash and burn. It’s only the drivers that were already on the racing circuit that can stay on the track. For the rest of us, there is a culture change that must occur in the organization before we can get on the track.

Yes, a Momentum shift is underway! While I could be talking about my hometown Cardinals playing better baseball and beating the Padres tonight, I’m not. Instead, I’m talking about MomentumSI, my new employer. I’ve joined their team of top consultants on SOA and am looking forward to helping their clients be successful with their SOA initiatives. MomentumSI is a blog-friendly company, as evidenced by the blog of their CEO, Jeff Schneider. I look forward to having a little bit more freedom in some of the topics that I cover. I previously was part of an Enterprise Architecture team for a financial services company, which put some limits on things that could be discussed. If you’ve got questions about me, questions about Momentum, or topics you’d like to see covered, please don’t hesitate to ask.

I was reading the October 2 edition of eWeek, and on page 16 there is article by Darryl K. Taft titled, “AJAX, SOA to Merge.” The rate of acronym mergers and acquisitions is beginning to rival the rate of SOA company mergers and acquisitions. The bulk of the article is devoted to a discussion of some announcements from JackBe and TIBCO. The one that set me off was on JackBe’s Presto platform which now includes an “ASB (AJAX Service Bus).” So now I need a specific service bus to each technology I use to expose services? I thought that technology mediation was a key feature of an ESB? Of course that’s not entirely true since I seem to be hearing more and more about ESB federation. That seems like an oxymoron to me. We need to forget about all of the marketing buzzwords and focus on the capabilities (not acronyms) that are needed by the enterprise like mediation, transformation, security, etc.

I’m currently reading The Innovator’s Solution by Clayton Christensen and Michael Raynor. This is a business book from Harvard Business School Press, not an SOA book, at least so I thought.

In Chapter 5, titled “Getting the Scope of the Business Right,” the authors discuss product architecture and interfaces. Keep in mind that this is a business book, so the product they refer to could be consumer electronics, a box of kleenex, I-beams, etc. The authors state:

A product’s architecture determines its constituent components and subsystems and defines how they must interact- fit and work together- in order to achieve the targeted functionality. The place where any two components fit together is called an interface. Interfaces exist within a product, as well as between stages in the value-added chain. For example, there is an interface between design and manufacturing, and another between manufacturing and distribution.

An architecture is interdependentat an interface if one part cannot be created independently of the other part- if the way one is designed and made depends on the way the other is being designed and made. When there is an interface across which there are unpredictable interdependencies, then the same organization must simultaneously develop both of the components if it hopes to develop either component.

The book goes on to discuss the pros and cons of interdependent architectures and how they create a performance versus flexibility tradeoff. Interdependent architectures yield greater performance, modular architectures yield greater flexibility through tight specifications. This is certainly analogous to IT and SOA, as SOA is all about standards-based interfaces and higher flexibility. If you read on, however, you find that there is a perpetual see-saw like motion that consumers take regarding performance over flexibility. In the early days, a market may be built on performance and features using a completely proprietary model. The original Apple Macintosh is a great example of this. Apple controlled it end to end, and as a result, provided performance and features that no one else did at the time. Over time, however, a consumer base built up that was not so interested in performance and features, but was interested in flexibility. This eroded Apple’s market share and made Bill Gates rich. Today, however, the pendulum has swung back. Apple’s success with the iPod is largely due to the proprietary, integrated experience they can provide by owning the solution end-to-end.

So what does this mean for the SOA practitioners out there? It means that we must be judicious in where we apply the principles of SOA. If the business requires flexibility, SOA is where we need to be. If the business does not require flexibility, SOA may be a tough sell. Today, we’re at the apex of the pendulum swing on the side of flexibility. The business is demanding it, and SOA is there to save the day. As you build out your services, however, keep in mind that the pendulum will swing back. There will be a time where performance and features will rule over flexibility, and your IT systems must be prepared to support it. What’s the key? The key is that both interdependent architecture and a modular architecture understand the concept of interfaces. If you know where your interfaces (services) belong, you can choose to make those interfaces more or less proprietary as appropriate. Any large organization will likely find that some services need to be very specific to a single consumer to meet performance needs while other can be designed to support the masses. Those decisions are based on the needs today, however. Over time, that consumer-specific interface may need to be used more broadly as the pendulum shifts. If you never had a service there to begin with, it will be a far more difficult task.

David Linthicum, in this blog, this blog, and this podcast, rails on the recent trend of SOA Governance products. I’ve been a frequent listener of his podcasts, and I usually agree with what he has to say, but not in this case.

As we know, last year the buzz was around ESBs (Dave railed on those too), this year the buzz has been around governance. He correctly points out that most of the vendor products “are directories, repositories, or registries, at their essence, and may or may not include policy management.” He then states that there is “no clear architectural use case for most of these tools” and that they are “application development support tools, akin to configuration management and metadata management of years gone by.” Hmm… I think someone else pointed out the relationship of these tools to configuration management databases.

So, where’s the problem? Dave states that the biggest thing missing is the focus on architecture. He correctly states that architecture brings agility, rather than focusing on reuse. Again, no arguments with that statement. What he never states is what the role of governance should be in architecture. He implies that the tools should be offering something more, but never states what that is. If the tools really are all about management, is that really a problem? After all, that’s largely what governance is. According to dictionary.com, one definition of governance is “a method or system of government or management.” Personally, I think that SOA has actually given a more concrete purpose to these tools that have struggled to gain a significant foothold until now.

I’m sitting here watching the New York Giants and the Indianapolis Colts and I thought of Fantasy Football. I’ve never had a fantasy football team, but I do understand how it works. It’s part simulation and part reality. The simulation part is your role. You’re the GM of the team and you draft your players, make trades, etc. The reality part of it is that how well your team does is based on how the players you drafted actually perform in their NFL games that week.

So, I starting thinking about this, and wondering if there are any parallels that could be applied to IT. Sure enough, there are. First off, in the BPM world, a common feature that many vendors are working toward is the ability to run process simulations. Just as with Fantasy Football, these simulations need to take in actual production statistics to give an accurate portrayal. Sounds great, right? What’s missing, however, is the statistics. Football, and virtually every other professional sport, with baseball being the king, has statistics on just about anything interesting to any individual, from the guy who tivo’s every single game to watch them the rest of the week, to the person who doesn’t know the difference between a touchdown and a touchback.

What would our IT systems be like if we had the same level of statistics on them? Besides making a new career for the IT statistician, I think we’d have a far greater understanding of how IT makes the business successful (or unsuccessful).

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