Todd Biske: Outside the Box

Archive for the ‘SOA’ Category

James McGovern has a few

outstanding questions on becoming an industry analyst. One of his five questions wasn’t directed at becoming an analyst, but interacting with analysts:

I have seen many bloggers comment on how software vendors should interact with industry analysts but have never seen anyone really explain how us folks in corporate America should? Come someone please blog about best practices in this space?

As a corporate America user of research from analysts, here’s my take on this. As with most things in this world, there are companies who are leaders, followers, and laggards. The 80/20 rule applies, with the “follower” category taking up the 80%, and the remaining 20% equally split between the leaders and the laggards. The leaders are taking risks, trying to innovate, and, when they choose wisely, reaping the rewards. The followers sit back and watch, and then try to follow a similar path of the leaders, albeit at less risk. The laggards, well, they’re distracted doing something else and eventually get left behind to wither and die.

The challenge for companies in this follower region is to identify the trends that lead to success, versus the trends that were not successful. SOA is a great example to use here. Virtually every single presentation I’ve seen on SOA begins with a definition. This is because there are so many different ways of applying service-oriented principles, and the right approach is dependent on the company’s strategy. When the CIO simply makes a statement that the company is going to embrace SOA, someone has to go out and figure out what that means. There are two common ways of doing this:

1. Hire someone who has helped other companies embrace SOA, effectively outsourcing the strategy and execution. When the consultants leave, so does the thought leadership. While some of that knowledge will carry over, the ability to analyze and implement primarily stays with the consultants. They go on to the next big thing, while the corporate workers continue to maintain the status quo.
2. Seek out information to build the internal thought leadership. This is done through books, magazines, whitepapers, webinars, and conferences. Of these, the best sources are going to be the ones that involve the widest coverage of case studies. Who has this? Analysts.

If we didn’t have analysts, the source of these items would lack breadth. The only entity with significant coverage would be vendors. Vendors’ bottom line is selling product, period. While they publish whitepapers, host conferences, etc., and these can be at a very high quality, it is all comes down to selling product. Outside of vendors, consulting firms are next in line. They, however, are more interested in sharing resources than they are in sharing information. If they share information, their resources may not be necessary. User groups and conferences that are not vendor sponsored tend to be local, which may constrain the amount of information that can be shared due to local competition for resources. So, there’s a big gap that needs to be filled, and that’s where the analysts can help.

Back to the original question: how should corporate America work with them? Clearly, the communication should be a two-way street. Just as the best service interfaces will probably come about through close communication between consumers and providers, the best analysis will come out through close communication between analysts and customers. The question, then, is how does the funding model reflect this? Do companies that share their information with analysts get discounts? Using the 80/20 rule again, 80% of the companies will likely be consumers of information only. That’s probably enough to sustain a healthy revenue stream. For the 20% that do share information, I would expect that discounting would be involved. If those companies fall into the leadership category, analysts may even need to pay for access to those companies. After all, these are the companies paving the way without support of external analysis, and they are the ones that the followers want to emulate. I’ve never had a research firm offer to pay me for information, so I don’t even know if this occurs.

Fortunately, analysts don’t publish evaluations of their corporate customers, so there isn’t the same conflict of interest that exists in the vendor space. There is potential for conflict of interest when two competing companies work with the same analyst firm, but again, the analyst research typically speaks in generalities, so this risk is mitigated. Additionally, many of the leaders are usually willing to talk about their experience, and are encouraged to do so. James’ should be familiar with this practice at The Hartford. This is further supported by the existence of research companies like the Corporate Executive Board who work to establish networks of companies for direct information sharing.

Ultimately, analyst firms exist to facilitate information sharing. Reading publications, case studies, vendor strategies, etc. is a full time job, and most companies are focused on providing solutions for their customers. Every company will have a different stance on how much “overhead” they want to fund. If the preference is to focus resources on execution rather than analysis, external research analysts will fill the gap. If a company is willing to fund analysis activities, there is a ton of free and low-cost information available. You may have every vendor knocking down your door, but it can be done.

Two days ago, I posted about my own aha moment with regards to SOA. This was in response to the latest ZapFlash from Ron. Today, they released their latest podcast
, which was further discussion about policies, contracts, SOA, and Web Services with Eyal Ma’or, CEO and co-founder of Silver-kite.

My own experience had to do with a realization on how aspects of things that we used to put into source code can be extracted and enforced through policy-based infrastructure. This is exactly the scenario that Eyal discussed with Ron and Jason. They discussed the lack of domain specific policy languages as a current barrier. To me, that’s one half of the problem, the other half being corporate culture. How many organizations have the maturity to properly express technical policies, let alone business policies? I fully believe that this is the way of the future, however, I don’t think I’d put this on my list of predictions for 2006 or 2007. My questions to my readers out there (and I’ve emailed it to Eyal, Ron, and Jason as well) is what policy domains can we apply this in today? Clearly, the most advanced domain is security. Whether through proprietary languages as part of an identity and access management infrastructure or through WS-SecurityPolicy, it can be done today. Beyond security, how would you prioritize the policy domains (and what are the policy domains)? Mine are:

1. Security
2. Routing/Accessibility (I’m not sure if you routing is the proper term, but this gets into the domain of load balancing algorithms and the drivers beyond them.)
3. Auditing/Compliance
4. Integration (i.e. transformations)

None of these begin to get into the “business” space, and I’m sure this is far from a complete list. What would be on your list? Leave comments or a trackback!

In the latest ZapThink ZapFlash, Ron Schmelzer provides some guidance on services, contracts, and policies. He speaks of the “aha” moment that many of us experienced when learning object-oriented programming languages, and compares this to a migration to service-oriented development.

Ron goes on to discuss the differences between a policy and contract based approach versus an object API-based approach. He discusses the need for a many-to-many relationship between policies and contracts, as well as between contracts and implementations. His analysis is correct, but what he didn’t go into is how the “aha” moment can occur.

In my own case, the key to this was when container-managed code was introduced with the J2EE platform. One of the goals of J2EE was to remove the responsibility for security, transaction management, and more from the developer by declaring the policies surrounding this in a separate configuration file. When J2EE was introduced, Sun also outlined the roles and responsibilities associated with a development project. One of these, the Application Assembler, was intended to create this descriptor file, while the Application Component Provider was responsible for the implementation. In my experience, these two roles were typically played by the same person. There’s even recognition of this in the C# and .NET framework where these policies are implemented by annotating source code. This is also now common practice in the Java camp as well, first through JavaDoc tags, and now through J2SE 5.0 Annotations.

When I began investigating Web Services, the “aha” moment occurred when I realized that the declarative policies that were established in a platform-specific manner can now be utilized independent of the platform. In fact, the entire “container” concept can be externalized from the actual implementation container. Since Web Services are sent as XML messages on the wire, policies can be enforced anywhere between the consumer and provider. Working on the infrastructure side of things helps this understanding, because some policies, typically routing, are already configured on a separate device from the application container.

This truly is a light bulb moment, because of the implications. As soon as policies can be externalized from the source code and execution container, we begin down a path where policy definition can be separated from policy enforcement points. Once policies are separated from the enforcement points, a new breed of tooling can be created for policy definition appropriate to the policy setters, rather than appropriate to the enforcement point.

For example, an organization may have an Information Security department that sets policy, but it may require an IT operations staff member to express that policy in a way that can be enforced by the infrastructure. If that same infrastructure also enforces routing policy, there is a dilemma. The person configuring routing policies should not be able to configure security policies. The key to this, as Ron suggests, lies with standards and tool support. By creating standard policy languages, an interoperability framework for sharing policies between editing, management, and enforcement points can now be created.

The more I think about this, the more there is to say. Some more thoughts:

• To have success as a good service provider, you need to provide a good service.
• Services developed in Corporate IT are inherently more difficult than many Web 2.0 services because of the user-developer disconnect. In the case of Web 2.0, many services are consumer oriented. Guess what? Most developers are also consumers. In the corporate world, services are business oriented. Chances are, you don’t also play the role of the business user. Interestingly, however, we still are always moving in a direction of allowing the actual end user to build their own systems. Arguably, many tech-savvy users come up with new ways to utilize technology beyond what the IT department provides, whether it’s as simple as a good set of bookmarks in their browser, or some sophisticated use of scripting.

One last thought- I recently read An Introduction to Enterprise Architecture by Scott Bernard. One of the points he makes early in the book is that one element of enterprise architecture is social theory. Given this debate and my own experiences, I couldn’t agree more.

There’s some interesting banter going back and forth between Dion Hinchcliffe and Steve Vinoski, stemming from Steve’s IEEE Internet Computing column, entited The Social Side of Services.

In this blog entry, Dion states that socializing SOA is “not the first order of business or the most important aspect of adoption.” Steve counters in his own blog.

Whether you agree with Dion or Steve, this is a very interesting conversation. I, for one, fall more on Steve’s side. In 1998, a presenter at SD East spoke on implementing reuse in a corporate IT shop, and his experience at several large firms was that marketing and communications was the number one factor in achieving success. I tend to agree. The degree of communication across IT groups is simply not what it needs to be to foster reuse. Dion dismisses this, and more blames it on “software that is actually extremely hard to mesh together.” Here, I disagree. I don’t think that integrating a typical corporate Web Service using SOAP/WSDL is all that more difficult that integrating a REST-based service, especially for system-to-system interaction. I’ll give REST or simple XML over HTTP the nod for AJAX-to-service interaction.

Dion does make some good points that corporate developers do need to embrace, however. He states that “Web 2.0 approaches to service design dictate an almost extreme preference for encouraging unintended uses.” Here, he hits the nail right on the head. Roy Schulte commented in a webinar that we need to switch from “build to last” to “build to change.” If an internal IT team builds a great service, they need to understand what it means to be a service provider, and encourage any usage they can get. If they take a rigid stance with regards to their customers, they won’t be successful.

Where I see the gap in this debate is really the cultural differences between Web 2.0 development and corporate development. Corporate developers are working to the demands of the business according to a project schedule. I’m willing to bet that the typical Web 2.0 Google Maps mashup is not, or at least not in the early days. On top of that, the mashups are creating new applications out of existing parts that would be too expensive to go and build from scratch. I don’t think any Web 2.0 programmer (unless they work for MapQuest, Yahoo, or the mapping provider…) could go out and write Google Maps on their own. For the services being reused in corporations, this isn’t the case. Often times, the developer has everything they need to write it themselves. In this situation, it absolutely is about marketing and communication. If the developer doesn’t know someone has already done it, they’ll go off and do it themselves. If they do know it exists, now it’s more of a trust and control issue.

In the Web 2.0 world, we’re encouraged to communicate, socialize, and share. (hmmm, isn’t this what Steve was saying is a critical factor?) If the service needs to be tweaked, we’d contact the service provider and get it tweaked. Even in the Web 2.0 world, if the group was unresponsive, that service will quickly fade away.

In the corporate world, the team providing the service does not have resources assigned to that project, and this makes project managers very, very nervous. They’re now dependent on something outside of their control, and unless the corporate culture changes to allow that, they may be apt to do it themselves, strictly to control their own destiny. If your organization can’t built the internal trust to get over this, they won’t be successful with SOA.

Just a quick note to thank Brenda Michelson for coming to St. Louis last week, and for the good people at CAIT (Center for the Application of Information Technology from Washington University) for setting it up, including my good friend Fred Domke. It’s a shame that her luggage couldn’t make it, but she still made the best of it. As Brenda reflected in her blog, events like these (the CAIT event, not loosing your luggage) can only help all of our work get better. I look forward to CAIT’s continuing workshop on SOA and being a part of it. As if that wasn’t enough, Thomas Erl also paid us a visit courtesy of Microsoft, including copies of his latest book.

Both presentations were very good. I always enjoy these exchanges on best practices and approaches to SOA. Everyone comes at SOA in a slightly different manner, and it’s interesting to see what points others emphasize or include. Thomas clearly came from the technical side of things, which was appropriate for the audience. Brenda, as I had hoped, brought the user element back into the mix. I was glad to see this as well as recent articles that also touched on this from Ron Schmelzer of ZapThink and JP Morgenthal (blog) of Avorcor.

Anyway, it was a good week for SOA in St. Louis. Hopefully, it’s the beginning of a good trend, although I certainly don’t mind having to travel to Orlando, San Francisco, etc. to discuss SOA.

I’ll be part of a customer panel in Phil Windley’s SOA Governance session at the upcoming InfoWorld SOA Executive Forum. This event, as well as recent publications on SOA Governance (Phil’s article in the Jan. 23rd print edition of InfoWorld, Jason Bloomberg’s Butterfly Effect ZapFlash), have me thinking more and more about this topic.

One very simple analogy to make regarding SOA Governance is to compare it to traditional government. What does Congress do? What do your local city leaders do? This is actually a very good analogy, because it works for all definitions of SOA Governance, whether applied to strategic planning, design-time governance, or run-time governance. Recently, I’ve started thinking about more intricate details of this analogy. It is certainly true that SOA Governance has to do with setting and enforcing policy, just as does traditional governance. What’s interesting, however, are the types of policies being set and the communication involved in those processes.

A great illustration is my own experience. From mid-1994 to late 1997, I lived in California. During that timeframe, California had ballot initiatives on discrimination in state university admission processes (Proposition 209) and on basic services (i.e. health care) for illegal immigrants (Proposition 187). As part of the voting process, California would provide a sample ballot, as well as statements on the proposed initiatives and candidates. There would typically be a statement for the initiative/canditate along with a rebuttal, as well as a statement against the initiative/candidate along with a rebuttal. I found this to be extremely valuable in my own processes to be an educated voter.

In late 1997, I moved to Missouri. The most highly contested initiative for my first ballot as a Missouri resident was cock fighting restrictions. Missouri politicians are only now beginning to debate things like smoking bans in restaurants. Thankfully, I’ve moved to southern Illinois where we at least have the influence of Chicago on statewide issues to keep things a bit more progressive. Neither state, however, provides anything to help me be an educated voter. I have to rely on my own research, in addition to the normal media.

What this demonstrates is that in addition to figuring out what SOA means to your company, you also need to figure out what SOA Governance means to your company. Should you be progressive about governance and focus on cutting edge concerns, or do you still need to cover the basics? What information do you need to provide as part of the governance process, and how much do you involve the people who will ultimately be governed by the policies being set? Ultimately, success will largely depend on how well your approach to these topics match your corporate culture. If your company is conservative, adopting a progressive stance on governance may be too much shock for the company to take right off the bat. Likewise, A conservative approach on governance may put a halt to the rapid innovation occurring at a progressive company. The same holds true in traditional government. The focus of media attention in the middle east has been on the fact that voting is occurring, rather than on what topics are on the ballot. Simply having a vote for the highest levels of government is enough of a culture change. Anything more would have been a failure.

As with any change, and SOA is most definitely a change, the key is understanding where you want to go, creating a plan to get you there, and then executing that plan. SOA Governance is simply another element to be addressed. Take the time to understand what your needs are and the pace that they can be addressed. If you’re currently using punch cards, hanging chad and all, but voting on things that have minimal impact on society, switching to an electronic voting machine isn’t going to help.

Tags: SOA, Governance

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.