Note: This is the second post in my Freedom within a Framework series, which is about enabling the coexistence of enterprise and opportunistic applications. You can read the introductory post here.

As I stated in my introductory post, I believe that it is possible to achieve a balance between the need for stability in enterprise applications, and the need for quick and agile innovation in opportunistic applications. They key to this balance lies is in determining where the domain of control for IT can safely transition into a environment of open access to information. This is a “line of demarcation” that allows for a clean separation of certain types of applications. The best way to picture this concept is to imagine a line on an X-axis, with control of technology at the left side, and anarchy at the right. “Command and Control IT” typically lives as close to the left as is possible, while the world of “consumer-driven IT” lives quite far to the right. There are opposed to be sure, but it is possible for IT to reconcile these differences and foster both sides by creating a shared understanding around which classes applications should be enterprise-class and which can and should be treated as opportunistic.

Another way to visualize this concept is with the “Long Tail,” which is depicted in Figure 1 below. The “Long Tail” was a term coined by Chris Anderson in Wired Magazine to describe how the business models of companies like Amazon or Netflix enables them to profitably offer a wider range of goods and services than traditional organizations. The concept (also referred to as a heavy-tail or Pareto distribution) is a well-known statistical occurrence where a high-frequency population (depicted by the region in green below) is followed by a very long low-frequency population that gradually diminishes in area (or “tails off”). In many cases, the long tail portion of the graph, colored in yellow below, can actually represent the majority of the area under the line in the graph, even though the frequency is lower along that portion of the line than it is in the green area.

Figure 1 - The Long Tail

When applied to Amazon and Netflix, this concept is used to illustrate that organizations with powerful distribution channels can make just as much or more selling ten copies each of 10,000 obscure books as they could selling 100,000 copies of one best-selling book. The application to many organizations is just as powerful when information is the product. Assume for a moment that the green portion of the graph represents enterprise-class applications with a large internal user base and the “long tail” or yellow portion represents opportunistic applications with a much smaller number of users. This is depicted in figure 2 below.

Figure 2 - The Long Tail for Applications

In this scenario, the “long tail” theory argues that an organization could serve more users with several hundred opportunistic applications than it does with a small number of enterprise-class applications, but at a much lower cost. Thus, a “long tail” model can enable an information-driven organization to serve its customer base effectively without greatly increasing the cost of software delivery. Such a model does so by enabling the kinds of opportunistic development which most IT organizations would likely never have the bandwidth or justification to pursue because they are applications which are tactical in nature and which may only serve a small number of users.

While a “Long Tail” mindset enables us to create a clear line of demarcation, simply classifying one type of application or information set as enterprise and another as opportunistic isn’t enough. It is entirely possible for IT to pursue this demarcation with good intentions, and then stifle innovation by requiring that all applications, including opportunistic ones, be developed using only one type of platform or programming language. Thus, another key to creating “Freedom within a Framework” is that IT must give up as much control as is possible, while at the same time recognizing the assets and information over which the enterprise should retain control. In my next post, I’ll discuss the concept of an IFaP architecture which, I believe, provides a powerful architecture for enabling open innovation while, at the same time, providing IT with a framework to manage its information assets.

For the past several weeks, we’ve been working on creating a viewpoint of our future-state architecture that enables a greater degree of low-hurdle innovation with technology than we currently enable. The goal is to enable anyone across the globe, inside of the organization or out, to make use of public information we provide to create applications of value, even if that value is only seen by a single individual. Call it Web 2.0; Call it Enterprise 2.0. Call it what you will. We’re calling it either Freedom within a Framework or the Framework for Rapid and Empowering Development (FRED) depending on to whom we’re currently pitching the idea. The latter is our EA marketing savvy at work…

The idea is simple: We want to create an environment when enterprise applications can be created and managed in an enterprise way, and opportunistic applications (i.e. ad-hoc process applications and mashups) can be created freely and with little to no involvement from the IT organization. IT does what it does best, but explicitly steps back from “owning” all information and technology in an organization. From concept to implementation, I believe that one way to foster such an environment is to allow the world of WS-* and the world of REST to co-exist within the enterprise. Rather than an either/or decision, we want enable and encourage both styles for certain types of situations.

The culmination of our work around this idea was a paper published internally at the end of November, along with a demo that provides an example RESTful interface (which depends on our existing SOA) and a couple of applications which consume information presented by those interfaces.

Over the next few weeks, I plan to post excerpts from this paper and some of the meat from the demos. My intent in doing so is twofold:

1) To posit an alternative to the REST vs. WS-* debate. I am certainly not the first to argue for cohabitation of these styles. I only wish to add my voice and provide another perspective.

2) To obtain feedback from Enterprise and SOA Architects who have either already considered, are considering, or have implemented a similar design. I’d love to hear feedback in the coming weeks from anyone wanting to way in on any of the topics below.

I’ll publish the first post tomorrow, and the subsequent ones every couple of days after that. Here are the topics I plan to post about, in order:

• Embracing the Long Tail
• IFaPs: Enabling the Long Tail and Protecting the Enterprise
• REST: The Entry Point for Innovation
• Benefits of a RESTful Interface
• REST and Security
• A Demo RESTful Interface
• Demo Opportunistic Applications

As I add posts, I’ll return to this post and add the hyperlinks.

Looking forward to the discussion!

Saw this post from Brady Forest on O’Reilly Radar, which points to the official announcement on the AWS blog. This may not mean as much to many of you who have been using S3 for a while now, but it’s big news for a guy like me because I know better than to bring technologies like S3, EC2 and Mechanical Turk into any serious internal conversation unless I can say “yes” to that SLA question. Looks like AWS is getting ready for prime time. And why not? Most of us have been expecting this for a while now.

I will echo Arthur’s request for more to the SLA, specifically for stats on uptime and availability. I think that all services should provide information like this to be as clear as possible in letting you know what you are getting by consuming said service (and our internal guidelines say as much), but this kind of information is especially vital with services in the cloud. I’m confident that they’ll get there, but in the meantime, I’ll echo that feature request.

On another note, why the heck is O’Reilly charging $149 for a glorified whitepaper on developing applications for Facebook? I use Facebook. I like Facebook. I think there is something to be said about developing applications for it… in certain situations. But could we just take a moment to breathe here before they hype train carries us all away?