Todd Biske: Outside the Box

Archive for January, 2006

WebServices.org created a marketing opportunity for several vendors by asking a number of industry visionaries to tell uswhat to expect for 2006. Personally, I’d love to see Joe do the same thing with technology analysts. Most of them have posted their 2006 predictions, although I haven’t seen anyone roll them all up with appropriate analysis.

Back to the vendors predictions: my first reaction was that most of them (but not all) made statements consistent with their marketing messages. What’s good about this is that now we can compare them for consistency, inconsistency, etc. and see what conclusions can be drawn. Let’s start with the buzzwords.

• ESB: Three people mentioned ESBs: Paul Patrick (BEA, they sell one), Paul Lipton (CA), and Bob Brauer (StrikeIron). All three extremes are covered on this one. Paul Patrick sees “an increasingly important role for ESBs” emerging. Paul Lipton dismisses ESB as an “excessive and inappropriately used buzzword.” Bob Brauer comes in the middle, merely stating that emphasis will shift from the infrastructure components to “actual solution building.”
• Governance: This one had more press. Paul Lipton also classified “governance” as an “excessive an inappropriately used buzzword” but then said the new “excessive and inappropriately used buzzword” will be policy, which has clear ties to governance. Bob Brauer included governance in the list of items that had previously been emphasized. Andrew Nash (Reactivity) never used the word governance, but did discuss the need for standard semantics for policy-based management (we need semantics for the actual service definitions, too). Inge Cheng (Layer 7), stated that there will be “questions of how services can be governed consistently across application and organizational silos.” Miko Matsumura (Infravio) wins the award by titling his comments, “It’s About Governance, Governance, Governance.”

Looking for common threads across all of these, I see the following:

• We’ve only begun our understanding of Governance. My own recent blog called out the confusion around development governance versus operational management or run time governance. Paul Lipton (CA) called out the same thing. Over half of the comments had something to do with governance, so it’s clear that there’s still plenty of life left in that topic.
• Enterprise SOA adoption will still be few and far between. Andrew Nash (Reactivity) made some very conservative comments regarding SOA adoption, but stated that there “have been some real projects with real money behind them.” Wayne Ariola (ParaSoft) hit on a topic that hasn’t received much discussion, which is trust between service provider and consumer. The “not done here” mentality of many developers is a barrier to enterprise adoption, and until that culture changes, progress will be slow. Inge Cheng (Layer 7) calls out that most implementations have been at the project level, not the enterprise level. Miko’s (Infravio) comments on governance stressed that the barriers are “organizational, political, social, and regulatory.” These don’t change overnight. Paul Lipton’s (CA) comments are that there will be “an increased realization that SOA is more than an IT initiative.” This doesn’t say that the business side will get involved with SOA adoption in 2006, only that they’ll begin to understand that they need to be involved. All of these things point to a slow, conservative uptake. Andrew Nash phrased it well: “I’m not going to say that 2006 is the year where it will all happen. Rather, this is the start of a long-term, steadily increasing use of SOA.”

What would I like to see? I’d like to see some case studies on companies who are starting to show results from an SOA adoption that was formalized no earlier than 2003. Most case studies I’ve seen fall into two categories:
1. Projects that were well-suited for SOA and Web Services, but existed solely within a single domain of the business, eliminating many of the governance and management issues inherent to an enterprise adoption.
2. Enterprise scale initiatives that began prior to 2003, where the direction was clearly laid out by a CxO level executive to embrace enterprise architecture, system reuse, and elimination of redundancy. These typically only mention Web Services at the end of the study when they state that they are incorporating the use of Web Services and associated infrastructure into their environments.
Three years should be long enough to show some preliminary results across the enterprise, even if this was going on while business still churned along.

I think there’s going to be a butterfly effect of blog postings from the latest ZapFlash. As always, the ZapThink guys (in this case Jason) have managed to take a hot topic (SOA Governance), look at it from an unexpected angle (chaos theory), touch on many of the key aspects of it, get people thinking about the possibilities down the road, and introduce just enough controversy to get people talking about it (like me).

The first thing that struck me was when Jason introduced two views of SOA Governance. He states:

There are two faces to SOA governance, however. On the one hand, SOA governance simply means governing a SOA implementation initiative — for example, communicating corporate policies to developers implementing Services, and giving them the tools they need to follow those policies as they assemble the various elements of the SOA implementation. On the other hand, there’s a broader, more strategic definition of SOA governance: IT governance in the context of SOA.

The example of IT governance that he uses later in the article is that of a business executive changing the SLA associated with a corporate report to require a one-day turnaround rather than a one-week turnaround. My first question is whether or not this constitutes SOA governance. This isn’t the first discussion around SOA governance that has broached into this territory, and the truth is that there is no solid definition of what is SOA governance and what isn’t.

The source of the confusion, as I see it, is that both areas Jason describes involve policies. Does this mean that the act of setting policies is always an act of governance? The concern I have with Jason’s example is that the act of the executive changing the policy is an example of poor governance. How many governments enable this kind of legislative power? This sounds like a dictatorship. I’m not implying that executives shouldn’t be empowered, but policies shouldn’t be enacted or changed without a thorough understanding of the consequences.

The second thing that struck me about this article is that in typical ZapThink fashion, this scenario is absolutely possible. It may not be the business executive, but it certainly could be an operations staffer, or even worse, it could be the system itself! I recently replied to a query on a mailing list about applying SOA in areas outside of business applications with an operational management scenario that was fully automated. The automation was controlled by policies that could be performed by intelligent infrastructure with operational interfaces exposed as web services, orchestrated through a BPM platform. All aspects of this are declarative in nature.

The real risk that Jason is pointing out has more to do with automation of processes that it does with governance. With more and more systems being configurable through declared policies, this leads to automation possibilities, which in turn can lead to exactly the possibility that Jason describes.

The takeaway, as I see it, is that the industry is continuing to move in the direction of empowering the user, all driven by a desire to have our systems be more flexible and responsive to business change. We have to think about what the impact of that future state is. If the business users have the power, what governance has to be in place around the changes that they can now make?

James McGovern posted some comments on what “the real problem” is in adopting SOA.

The most important thing that he called out is that “SOA is a paradigm shift.” I couldn’t agree with this more. While he went on to apply this to IT staffers that have worked in legacy environments, I would go even further than that. Anyone who hasn’t had the opportunity to work on a large scale program that impacted a significant portion of the enterprise falls into this category. Why? They simply haven’t had to look outside of the boundaries of the project they were handed. I think this probably impacts the average client-server developer far more than the legacy developer. A VB6 developer has probably built a lot of point solutions for a small set of users. The legacy developer has been the one having to stretch their system to integrate with the demands from the changing business.

Independent of any individual developer, an enterprise wide SOA implementation absolutely requires a paradigm shift. It is a culture change, plain and simple. As long as we continue to define projects in such a way that it is difficult to see outside of the boundaries of that project, we won’t be successful. Think about the case studies that have been published regarding SOA. How many of them are service-oriented applications versus service-oriented applications? Don’t get me wrong, there is nothing wrong with service-oriented applications, and it absolutely is a step in the right direction. It is not service oriented architecture, however. If you look at a case study for service oriented architecture, you will find that the culture change was directed from the top down. Without this culture change, the path to a service oriented architecture will be far longer, and probably far more painful.

I’ve said this before, and I’ll keep saying it. In order for SOA to achieve the goal of accommodating business change, IT has to be willing to change first.

Hey, maybe Phil Wainewright reads my blog. Yesterday, I posted some comments about his blog on LooselyCoupled.com, and some of the excellent comments he made regarding SOA Repositories. I pointed out the importance of marketing and communication to reuse, and how the social networking aspects of Web 2.0 was a perfect fit for this. I called out Verizon’s SOA as a perfect example. Well, lo and behold, today, Phil posted on his ZDNet blog today:

Learning to love software reuse by ZDNet‘s Phil Wainewright — Only when you move to a truly loosely coupled services architecture do you get to reuse software without the temptation of changing the code. But there are still obstacles.

If you follow this, you’ll find that Phil posted on Verizon’s SOA. That certainly sounds familiar. It was either pure coincidence (which is entirely possible, he could have planned the split of content between the two blogs all along) or maybe he read my posting. Phil, drop me a comment if you did!

Phil Wainewright, of ZDNet and LooselyCoupled, posted an article on SOA repositories at LooselyCoupled. I thought it did a great job in calling out the phases that we’ve gone through in realizing that a system facing registry was not enough, and that tools were needed at design and development time that were human facing, i.e. repositories. Joe McKendrick of ZDNet also posted a summary of this.

No one will argue that one of the reasons for embracing SOA is reuse. Reuse has been somewhat of a holy grail in software development, however. My first introduction to the challenges associated with reuse came at the Software Development Expo East (SD Expo) in 1998. I can’t remember who the presenter was (and unfortunately, the archives at http://www.sdexpo.com/ only go back to 1999), but he stated that the number one factor that determined success or failure of an enterprise-wide reuse effort was marketing and communication.

Therefore, it’s no surprise to me that the industry is starting to rally around the notion of a repository, rather than a registry. In reality, it goes far beyond that. If the key to success is marketing and communication, this seems to be a great fit for everything that is Web 2.0. The example of Verizon’s IT Workbench Portal is a great case study. While Verizon’s approach did begin with a CIO mandate, their approach was not strong-handed, but rather a non-intrusive process that integrated seamlessly into the developer’s world. The term repository almost seems too limiting in this context. Perhaps this is the first big example of how the social networking aspects of Web 2.0 can be utilized productively in the corporate world.

Yesterday, I was driving my oldest daughter to school (she’s in Kindergarten) and she was very excited. On Thursdays, her class goes to the computer lab, and “computers are her favorite subject!” So, that night at dinner, I asked her what she did in computers. She told me that they went to a new web site that had a doodle pad. They were all supposed to draw a picture of something (I don’t remember what), and then they could draw whatever they wanted. I asked her what she drew, and she said, “A three-dimensional apartment building.” Not the answer I was expecting.

Anyway, what does this have to do with SOA? Well, first off, the fact that my 5 1/2 year old daughter is drawing “three-dimensional apartment buildings” in Kindergarten tells me that the pace of things, and the need for information for this generation is only going to grow. If this isn’t a reason to start building agility into our systems, I don’t know what is.

Second, a common analogy for enterprise architecture these days is that of city planning. How many of us can look at the “doodle pad” of our enterprise architecture and know where to place those three dimensional apartment buildings? Or, is your architecture have more parallels to the hot political potato of eminent domain? Are you having to bulldoze applications that were only built a few years ago whose residents are currently happy for the greater good? What about old town? Any plans for renovation? If you aren’t asking these questions, then are you really embracing enterprise SOA?

In talking to the computer teacher this morning, she said that my daughter had drawn a cube. A box. To her, it wasn’t just a box. It was a three-dimensional apartment building. One of the pieces of advice I had in my talk at the IQPC SOA conference in Chicago last October was “Think Outside the Box.” My 5 1/2 year old daughter is doing this. To be successful with SOA, someone in your organization has to be doing this. If you’re still thinking in terms of the application at hand, you won’t get there. Someone needs to have the responsibility to be looking for these opportunities. Not everyone can look at a vacant lot in the city, and envision what can happen by bringing the appropriate business to that lot. Not everyone can look at the open land on the outskirts of town and envision what it can become. Every successful city has someone who has done this, working with developers and the community at large to make it happen. Use this analogy, and find those planners in your organization who are not simply looking at one building or one subdivision. Find the ones who can look outside of the box, and build your services blueprint that you need to chart the future course.

There have been a number of blogs recently discussing Web 2.0 and SOA. In his IT Toolbox blog, David Linthicum quotes Dion Hinchcliffe, essentially saying that Web pages are becoming less important, and Web services are becoming more important.

One thing that I’ve spoken with some people about is applying the concepts of SOA to the Presentation Tier. I think portlets are to the presentation tier what Web Services are to the business tier. In the same way that the business tier is headed toward orchestration and composition of services, the presentation tier should be headed toward orchestration and composition of presentation services, i.e. portlets. This tier is far more challenging than the business tier, simply because this is the interface that deals with people, and people are complicated. The number of things that can be (and need to be) communicated through a user interface is far greater than what needs to be communicated from a WSDL file.

That being said, I think we can really get somewhere if some of the best thinkers on server-side SOA got together with some leading usability / user interface gurus and tried to come up with a solution. If we had a solution that captured the dynamic behaviors and flexibility required on the user interface side, this could in turn be utilized to enable dynamic behaviors and flexibility on the server side even more.

Jeff Schneider, of MomentumSI, posted his predictions for 2006. One of them was this:

The Business Process Platform becomes the accepted standard as the foundation for enterprise software.

This was very interesting. One thing I’ve commented on in the past is the tooling support for contract first development, and how the BPM tools work better when taking a contract first approach. One thing that I don’t think too many people will argue with is that with advances in frameworks and code generation, the opportunity for more visual development environments on the server side is increasing. You can look at BEA Workshop, M7 (now also owned by BEA), or Microsoft’s Whitehorse as examples of this. Therefore, there is a convergence that is happening between these two environments for developing services. While this convergence continues, what do we do in the short term? What things are best suited for development on a business process platform, using schema-driven tools, and what things are still best suited for development in a traditional OO programming language? Certainly, problem number one is that each tool has its own custom development “language.” While most of the tools either have or plan to have BPEL support, the development language is usually a graphical model from which BPEL can be generated/exported. What about the model for reuse? Do we need OO concepts like inheritance in these visual models? What other programming concepts are being rendered unnecessary for typical corporate IT development because all of the source code is generated behind the scenes, if at all (do these tools generate code or are they tightly coupled with an execution container that interprets the models on the fly… I suspect the latter)? I’m very interested in hearing what other practitioners are doing- where are they getting big wins from the graphical model-based business process platforms and where are they continuing to utilize programming languages.