Todd Biske: Outside the Box

Archive for September, 2007

Two recent posts by Jeff Schneider and Nick Malik, recently brought some attention to a very important aspect of SOA, which is funding it.

Jeff’s post, entitled “Budgeting for SOA” gives a great breakdown of all aspects of adopting SOA, which based on my experience, would certainly be a multi-year effort. He begins with establishing the SOA Foundation, which includes establishing a strategy, roadmap, reference architecture, and governance strategy, continues on with SOA Infrastructure Realization, establishing a SOA Governance Team, performing architectural analysis, training the staff, and then building the services and their consumers. Jeff articulates the costs associated with each of these for a typical organization based upon his experience.

Nick’s post, address the other side of this, which is where to find the money. In his post, SOA Economic Model: Avoiding Chargeback with Transaction Ration Funding, Nick calls out his disdain for chargeback models, and instead presents an alternate view whereby shared resources are funded out of a fixed operating budget that is funded through some form of flat tax. The teams that are funded by this pool are then allocated funds based upon the amount of transactions they process. While Nick presents a very simple model based upon the number of transactions, I’m sure other funding models could be used since a simple request count doesn’t take into account the complexity of the services, but his model is accurate in that it properly incents the service development teams. The teams that use the services are going to pay the tax no matter what, so they’re also now incented to make use of the services being provided, unlike a chargeback model whereby they pass less if they don’t use the shared services.

I think both of these posts do an excellent job of laying out the possibilities. Unfortunately, I wish more organizations were at the state where they have to worry about these factors. It seems that the vast majority of organizations are simply trying to build services out of existing efforts. Unless those efforts are sufficiently broad in scope (and surprisingly, many organizations I’ve seen do have at least one major initiative that typically qualifies), it’s unlikely that services will be created that will have broader applicability. Now I consider myself an optimistic person, but I also recognize that this is not an easy challenge. To get to what I envision and what Jeff and Nick describe represent fundamental changes in the way software development takes place. To do this will mean leveraging staff that already operates out of a shared funding model, such as enterprise architecture, since their efforts merely need to be assigned by the EA manager. If the EA group establishes the appropriate strategic models, smaller projects with limited scope can now demonstrate how the will contribute to broader strategic goals, thus warranting funding of shared services, versus doing things they way they’ve always been done. All of this comes back to something that I frequently bring up in discussions around SOA adoption. If the only thing that’s changed within IT is that the same old projects that we’ve been doing for years now are creating services within them, do we really expect to see any kind of dramatic change within IT, or will it just be chalked up as another overhyped trend? I, as an EA, certainly plan on doing everything I can to make sure that’s not the case. We have to be careful not to bite off more than the organization can chew at any given time, but we also need to make sure that we are the impetus for change.

Tibco was kind enough to let me know that a new Greg the Architect video, Off the Grid, is now available. I just watched it and it is a riot. You can watch it here at the Greg the Architect site, or, if the plugin I just installed works correctly, you should see the YouTube player below this.[kml_flashembed movie=”http://www.youtube.com/v/CnhEfxxhg34″ width=”425″ height=”350″ wmode=”transparent” /] 

I had the opportunity to do a review of a book, and then discuss it in a podcast with the author and Dana Gardner. The book is entitled, “Succeeding with SOA: Realizing Business Value Through Total Architecture” and is written by Dr. Paul Brown of TIBCO Software.

You can view a transcript here, listen to the podcast here, or I’ve also added it as an enclosure on this entry.

I enjoyed this book quite a bit, and have to point out that it’s not your typical technology-focused SOA book. It presents many of the cultural and organization aspects behind SOA, and does a pretty good job. It tries to offer guidance that works within the typical project-based structures of many IT organizations. While I personally would like to see some of these project-based cultures broken down, this book offers practical advice that can be used today and eventually lead to the cultural changes necessary. Overall, I recommend the book. I found myself thinking, “Boy, if I were writing a book on SOA, these are things that I’d want to cover.” Give the podcast a listen, and check out the book if you’re interested.

Full disclosure: Outside of receiving a copy of the book to review, I did not receive any payment or other compensation for doing the review or participating in the podcast.

As reported by many bloggers/analysts/columnists, including this article by Tony Baer, BEA announced Project Genesis. Tony, in his article, stated that “there is considerable speculation that it will build on the [newly announced AquaLogic Enterprise] registry/repository.” I have a couple comments on the announcement that I wanted to discuss here.

First, we have yet another API in the metadata registry/repository space. Back in February, IBM created a whole bunch of brouhaha when they stated that they felt a new standard was needed for registry/repository communication, concluding that UDDI wouldn’t cut it. Now, we have the Metadata Interoperability Framework. Add this to UDDI, the WSRR protocol, HP/Mercury/Systinet Governance Interoperability Framework, and I’m sure this won’t be the end. You could certainly throw in LDAP for good measure, as well. Interestingly, no one has criticized BEA that I’ve seen for this move, but then again, they didn’t publicly come out and state that UDDI won’t cut it, either.

Second, given all of these APIs for metadata communication, it certainly does raise the question of whether metadata is really at the center of the SOA technology universe? Clearly, if all of the major platform vendors are now having to come up with custom protocols for communication with their registry/repository, it certainly means that there’s a lot going on with it. If you think about it, a metadata repository is a bridge between the design/development time world and the run-time world. Likewise, it also plays a key role in the run-time world and the world of operational analytics. Most people would also agree that most SOA efforts strive to separate non-functional concerns from functional concerns and allow for a policy-based approach to allow changes to be configured rather than coded.

We’ve certainly come a long way from the early days of the registry/repository where the focus was solely on design time discovery of services. Organizations that are solely focused on design time discovery of services still wrestle with whether they even need a registry/repository prior to reaching some critical mass of services. Vendors like BEA, IBM, and WebMethods are all certainly now pushing the Registry/Repository for much more than just this. I’ll admit, I have some concerns that we’re getting too far out ahead of the need of many enterprises. I’m a big proponent of a policy-driven infrastructure for SOA, but I’ll also admit that if you don’t have a sound understanding of your services and their consumers first, it’s not going to reap the benefits that are possible. Only time will tell whether we’re over-engineering based on what-if scenarios or if this level of sophistication driven by metadata is applicable to the masses.

One of my pet peeves when it comes to discussing services is when an organization gets into debates over whether a particular service is an “enterprise service” or not. These discussions always drive me nuts. My first question usually is what difference does it make? Will you suddenly change the way you construct something? It shouldn’t. More often than not, this conversation comes up when a project team wants to take a shortcut and avoid doing the full analysis that it will take to determine the expected number of consumers, appropriate scoping, etc. Instead, they want to focus exclusively on the project at hand and do only as much as necessary to satisfy that project’s needs. My advice is to always assume that a service is going to be used by the entire enterprise, and if time tells us that it’s only used by one consumer, that’s okay. Unfortunately, it seems that most organizations like to make the opposite assumption: assume that a service will only be used by the particular consumer in mind at that moment unless proven otherwise. This is far easier to swallow in the typical project-based culture of IT today, because odds are the service development team and the service consumer team are most likely the same group all working on the same project.

The natural argument against assuming that all services are “enterprise” services is that all of our services will be horribly over-engineered with a bunch of stuff thrown in because someone said, “What if?” The problem with over-engineering a service (or anything else) doesn’t stem from assuming that a service will have enterprise value, it stems from someone coming up with “what if” scenarios in place of analysis techniques to deeply understand the “right” capabilities that a service needs to provide. Analysis isn’t easy, and there’s no magic bullet that will ensure the right questions are asked to uncover this information, but I think many efforts today are not done to the best of our ability. As a result, people make design decisions based on a best guess, which can lead to either over or under-engineering.

I believe that if you are adopting SOA at an enterprise level, it will result in a fundamental change in the way IT operates and solutions are constructed. Requiring someone to prove that a service is an “enterprise” service before treating it as a service with appropriate processes and hygiene to manage the service lifecycle does nothing to promote this culture change, and in fact, is an inhibitor to that culture change. Will assuming that all services are enterprise services result in higher short term costs? Probably. Building something for use by a broader audience is more expensive, plenty of studies have shown that. On the other hand, assuming that all services are enterprise services will position you far better to achieve cost reduction in the long term as advocated by SOA.

I received a press release in email from Xignite entitled “Partnership Delivers Financial Professionals Responsiveness, Collaboration Via Timely Earnings Data.” In this release Xignite announced their partnership with Wall Street Horizon, a provider of earnings event and calendar information to the investment industry. Xignite will redistribute Horizon’s earnings and events calendar content as part of its street-event driven series on-demand financial web service.

While I normally don’t try to be a recycler of press releases from vendors, as I’d much rather comment on things more directly associated with work as a practicing architect, I’d be very happy to see more and more of these types of releases. Why? In the past, I’ve talked about the importance of events, such as this post. One of the challenges, however, is that I don’t really feel that there are good sources of events, especially ones that come in from outside of the enterprise (although there are times that I think that outside sources are more likely that internal sources…). Here’s a press release that shows that external sources are appearing and through partnerships, trying to increase their audience. It would be great if some of the industry consortiums for specific verticals would develop some standards in the event space.

Another Briefings Direct SOA Insights podcast has been posted by Dana Gardner in which I’m a panelist. In this edition, Dana, myself, Joe McKendrick, and indepdent blogger Barb Darrow discussed the role of RIA and rich media with SOA and the impact of associated technologies, such as Flash, AJAX, and Silverlight on the space. You can find a full transcript here or listen to it here. You can also subscribe via iTunes.

Okay, well maybe not the “High Life”, but I’ve had that Steve Winwood song in my head. On Monday, I am returning back to corporate life after nearly a year with MomentumSI. In a nutshell, a year as a consultant has shown me that the corporate world is where I am most comfortable, and best suited for my career goals. MomentumSI treated me very well, and I’m very impressed with their team and their offerings. I learned a lot from the excellent team that they have, and do plan on keeping in touch with them, offering insight from the corporate practitioner’s perspective as they continue their success. I certainly thank Jeff, Alex, Tom, and the rest of the MomentumSI team for the opportunity.

I’m not going to reveal where I’m going, other than to say that it’s a Fortune 500 company in the St. Louis Metro area where I reside, and I’m not returning to A.G. Edwards/Wachovia (AGE isn’t a Fortune 500 company, anyway). I’ll be an enterprise architect, involved with SOA, and other cool architecture topics. While I’m sure people will figure out where I’m working, this blog represents my own personal thoughts and opinions, and not that of my employer or anyone else (and there’s a disclaimer on the right hand side of the blog that states exactly that). I’m very happy that I’m going somewhere that doesn’t mind that I’m a blogger, and I fully intend on adhering to their policies regarding it. So, it’s back to the world of big IT and corporate politics for me, and I’m looking forward to it. While my colleague James McGovern has lamented about the lack of corporate EA bloggers in the past, he can add me back to the list!

As reported yesterday, all of the early iPhone adopters who aren’t already receiving some form of a rebate (like of the Apple employees who got a free iPhone) will receive a $100 store credit for use at the Apple Store. I did not expect this, and I wasn’t one who was crying sour grapes, but I’m very happy to be able to put it toward my eventual purchase of Leopard in October, or iWork ’08 sometime between now and Christmas. Hopefully there won’t be a bunch of people complaining that it should be $200 rather than $100. Apple was under no obligation to do anything, and as Steve said in his open letter, this is what happens when you make technology purchases. Technology either gets better or cheaper, the important thing is to be happy with your purchase the day you make it and ensure that you feel it is money well spent at that time.

Steve Jobs and Apple cut the price of the 8GB iPhone to $399 from the $599 that I paid for it. This is a very unusual move by Apple, as they traditionally have not changed their price points, but instead, offered more limited capabilities at a lower price point. I think it is a smart move, however, as it puts the price point at a much a closer level to phones that are considered its competitor. Unfortunately, I bought my iPhone on day 1, but I’m not going to complain. Sure, I’d love to have that $200 back, but the ultimate question we all must ask is whether or not the money spent has been worth it. For me, it’s a resounding yes.

As for other announcements, the key question is whether people will choose to keep their old cellphone and get the iPod touch. Personally, if I were buying an iPod, I’d certainly go for the iPod touch, regardless of whether or not I wanted the Wi-Fi web browsing. The quality of the video is a no-brainer and at least for my use, 16GB would be fine. On the topic of Wi-Fi, however, I have to admit that the only time I use Wi-Fi on my phone is at home, and on the rare occurrence that I’m in a restaurant with free Wi-Fi. Probably 95% of my usage is over the EDGE network, so the Wi-Fi capabilities isn’t as important to me. But, given that there’s probably a large contingent of iPod owners in the 17-24 range that are leveraging the Wi-Fi capabilities of their university or college, I’m sure this will be a big win.

Courtesy of Nick Gall, this post from Andrew McAfee was brought to my attention. Andrew discusses a phrase which many of us have either heard or used, especially in discussions about SOA: “It’s not about the technology.” He premises that there are two meanings behind this statement:

1. “The correct-but-bland meaning is ‘It’s not about the technology alone.’ In other words a piece of technology will not spontaneously or independently start delivering value, generating benefits, and doing precisely what its deployers want it to do.”
2. “The other meaning … is ‘The details of this technology can be ignored for the purposes of this discussion.’ If true, this is great news for every generalist, because it means that they don’t need to take time to familiarize themselves with any aspect of the technology in question. They can just treat it as a black box that will convert specified inputs into specified outputs if installed correctly.”

In his post, Nick Gall states that discussions that are operating around the second meaning are “‘aspirational’ — the entire focus is on architectural goals without the slightest consideration of whether such goals are realistically achievable given current technology trends. However, if you try to shift the conversation from aspirations to how to achieve them, then you will inevitably hear the mantra ‘SOA is not about technology.'”

So is SOA about the technology or not? Nick mentions the Yahoo SOA group, of which I’m a member. The list is known for many debates on WS-* versus REST and even some Jini discussions. I don’t normally jump into some of these technology debates not because the technology doesn’t matter, but because I view these as implementation decisions that must be chosen based upon your desired capabilities and the relative priorities of those capabilities. Anne Thomas Manes makes a similar point in her response to these blogs.

As an example, back in 2006, the debate around SOA technology was centered squarely on the ESB. I gave a presentation on the subject of SOA infrastructure at Burton Group’s Catalyst conference that summer which discussed the overlapping product domains for “in the middle” infrastructure, which included ESBs. I specifically crafted my message to get people to think about the capabilities and operational model first, determining what your priorities are, and then go about picking your technology. If your desired capabilities are focused in the run-time operations (as opposed to a development activity like Orchestration) space, and if you developers are heavily involved with the run-time operations of your systems, technologies that are very developer-focused, such as most ESBs, may be your best option. If your developers are removed from run-time operations, you may want a more operations focused tool, such as a WSM or XML appliance product.

This is just one example, but I think it illustrates the message. Clearly, making statements that flat our ignore the technology is fraught with risk. Likewise, going deep on the technology without a clear understanding of the organization’s needs and culture is equally risky. You need to have balance. If your enterprise architects fall into Nick’s “aspirational” category, they need to get off their high horse and work with the engineers that are involved with the technology to understand what things are possible today, and what things aren’t. They need to be involved with the inevitable trade-offs that arise with technology decisions. If you don’t have enterprise architects, and have engineers with deep technical knowledge trying to push technology solutions into the enterprise, they need to be challenged to justify those solutions, beginning with a discussion on the capabilities provided, not on the technology providing them. Only after agreement on the capabilities can we now (and should) enter a discussion on why a particular technology is the right one.