Todd Biske: Outside the Box

Archive for September, 2006

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.