Todd Biske: Outside the Box

Archive for May, 2006

Dave Linthicum had a great quote on his eBizQ blog:

Integration should be a configuration exercise, not a programming exercise, especially when considered in the context of a SOA.

While it may be true that some integration still needs to be programmed, we should be striving for configurable integration. As standards are adopted and incorporated into more and more systems, we can get there.

There’s a lot more to Dave’s statement, however. If you read between the lines, the message is that to really achieve the agility touted by the SOA pundits, the things that need to be touched when a business change occurs should be configured, not coded. Coding is a longer exercise than configuring, in most cases. In order to reach this goal, tools will need to continue to improve. At the same time, we can’t lose sight of the importance of testing. The promotion cycles associated with the deployment of a coded solution typically require extensive testing in order to enter an environment. In the case of a configuration change, that may not happen, but in the future, the impact could be catastrophic, as ZapThink analyst Jason Bloomberg called out in his ZapFlash, SOA Governance and the Butterfly Effect.

The point of all of this is that if you are an Enterprise Architect leading an adoption of SOA, you need to make sure that you’re making the appropriate things configurable, geared toward your operations staff, and using your developers for the most important things, developing business services.

Congratulations to my friend, Brenda Michelson, on her new blog on eBizQ, Business Driven Architect. Brenda is the “architect-in-residence” for the Patricia Seybold Group, and was kind enough to appear at a workshop in St. Louis a few months back, presenting some of her research on SOA.

Her most recent posting lists some practitioners in business-driven architect positions. A few of these are on my blogroll, while I hadn’t heard of some of the others. Now I have, and have added them to my subscriptions. Personally, these practitioners are the ones I enjoy reading the most. Perhaps it is because I’m a practitioner myself, so the issues they discuss hit home. So thanks, Brenda, and I look forward to hearing what you have to say!

James McGovern asks why more enterprise architects aren’t speaking at industry conferences? As an enterprise architect who has presented at an industry conference, I offer the following opinions:

• As James suggests, the conference chairs don’t have a good network of practitioners. I established my contacts not through my employer, but through participation in the online community on my own time. Those enterprise architects that don’t do this go unknown. I, like James, would love to see more participation from our peers.
• On the other side of the equation are the enterprise architects themselves. Rightly so, their primary interests are in helping their company. Their thought leadership needs to be directed internally, first. This is the same reason why you’re far more likely to see a vendor, consultant, or analyst quoted in the press than an enterprise architect or other corporate practitioner. Unless you happen to be one of the lucky few who work at a company with a very liberal external communications policy, it can be very difficult to get approval for outside communications.

I consider myself very fortunate to have had the opportunity to speak at industry conferences in the past, and in the future. I am a strong proponent of giving in order to receive. The more willing I am to share my knowledge, the more likely people will open up to me and share their own knowledge. I’m of the opinion that most companies have people just as smart or even smarter than myself, and therefore, that means they’re probably thinking about many of the same things that I am, at least from a technology perspective. It’s not a competitive advantage situation if we’re simply discussing the merits of open source software versus commercial software; Java, C#, and Ruby; etc.

Thank you Phil Wainewright! Phil recently posted a blog on ZDNet titled: “It’s the user experience, stupid”. It’s nice to see the “long-neglected backwater of usability” getting some well deserved attention.

The Business Week article that Phil mentions was particularly interesting because it mentions “the natural advantage” that companies like SalesForce and NetSuite have because of their ability to track all activities going on in their solutions. So what can we learn from this? Is this about usability? In part, it is. While I’m sure these companies are performing usability tests, nothing beats actual field observation when it comes to usability. In the setting of a usability lab, if you’re fortunate enough to have one, you can glean a lot of excellent information. Unfortunately, it’s still a lab setting, and is largely dependent on your ability to get representative users. Unfortunately, we also can’t go out on observe each and every single user.

In the absence of field observation, the next best thing is to collect as much information we can from the solution itself. If you do this with a desktop solution, the spyware police will be all over you, regardless of how good your intentions were. If you host the solution, all bets are off.

So how does this tie into SOA? It ties into SOA for two reasons. First, SOA is about taking a more granular approach to the entry points into our solutions. By decomposing the problem down into independently maintained pieces, additional entry (integration) points have now been created. Every entry points represents a new location to collect metrics. Secondly, if you choose to use XML to represent the messages for your service interchanges, the opportunity exists to glean information from those messages (all the more reason to make sure you’ve encrypted all elements of the messages for which privacy must be maintained). Through analysis of this information, we can learn more about the service consumers and their usage patterns. Voila, there’s your field information. Need another example? Head over to IT Conversations and listen to Nathan Eagle’s presentation from Where 2.0 on what information he was able to glean simply by monitoring the location of cellphones, and the cellphones in proximity that were detected via Bluetooth.

Now there are obvious privacy concerns with the collection of any information. There are also clear benefits to the collection of metrics through management infrastructure. The key point of all of this, however, is that the better you are able to understand the needs of your customers, whether they are humans sitting in front of their web browser, or other systems issuing web services requests, the better solutions you’ll be able to provide. It’s not simply about collecting the information, but about collecting and using the information to make things better.

In between the recent (and completely unnecessary, in my opinion) debate over Web 2.0 and SOA, a more pessimistic tone toward SOA has begun to emerge. Joe McKendrick recently discussed this in his ZDNet blog, “Is SOA ready for the ‘slope of enlightenment?'”

The pace of things that the press, analysts, and vendors like to push is absolutely ridiculous, and increasingly frustrating. Unfortunately, it’s the way things work. Simply writing this blog has given me some exposure to this world. It is no easy task to continue to come up with interesting SOA related things to discuss on this blog. Kudos to bloggers like James McGovern who are posting every single day, and on the whole, keeping it interesting. I’m doing it on my own time, with only a goal of sharing information with experts in the community. Imagine if I was actually trying to make a living based on this information. In order to keep it interesting, you either have to provide a new spin on the same old information, or take the emphasis off of the information and focus it on the presentation. The most successful path is to do both: continue to look for a new angles (and new information), while doing so in a manner that keeps people interested.

On the flip side, there are those of us that are actually trying to adopt SOA within an enterprise. What’s a realistic timeframe to do so? It certainly isn’t 6 months, and I’d be hard pressed to believe that it can be done in a large organization in 18 months. Let’s face it, unless you’ve already taken some of the first steps toward SOA prior to the recent hype cycle, we’re talking about an effort that will take years, not months. It’s hard to market something successfully for that long of a timeframe. A case study that states that a company is 40% of the way there is less interesting than one that makes it appear that a company is 100% of the way there.

As companies are in the middle of their adoptions, comments about the “trough of disillusionment” actually make it more difficult for organizations to be successful due to management by magazine. The marketing hype continues the trend of unrealistic expectations, too much focus on short term gains, and a lack of strategic planning. For once, it would be nice if technology adoption had expectations like the drug discovery process. It takes years, often more than 10, to bring a successful drug to market. When a potential lead compound is found by a company researching cancer cures, there is no huge marketing hype. The lead compound merely goes to the next stage in a long, long process. Only when some form of clinical trial success begins to occur does the marketing machine come into play.

While I’m certainly not advocating a turtle’s pace in SOA adoption efforts, I am advocating a steady, managed approach. There are technology trends that will provide short term benefits, and there are technology trends that are broader and more strategic in nature. A company needs to leverage both to successfully use technology for competitive advantage. Just because it is technology-based, doesn’t mean that it can be implemented faster than any other strategic initiative.