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!

• Microsoft: My way or the highway with SOA? Though Microsoft can certainly afford to do "SOA their way" and though such approaches have certainly worked in the past, I wonder if this one might actually hurt them is the long run. As Joe says, "What Microsoft appears to be doing... goes completely against what SOA is supposed to be all about, which is the ability to deploy and run what you need based on what you need, unencumbered by the limitations of vendors' systems." Wouldn't it be ironic if Microsoft's way of forcing organizations to "do SOA" causes organizations to turn to SOA itself as a way to minimize their dependencies on Microsoft systems?
• Project Zero: IBM enables REST-based development - Not surprising to see IBM adding support for REST, especially since Microsoft is doing the same by adding a Web Programming model to its WCF upgrades in the .NET 3.5 Framework. In many ways, this simply underscores David Chappell's assertion that the REST versus WS-* debate is over. While we may still have a place in our hearts for one over the other, the major vendors seem to be saying "why not both?"
• Binding SOA to BPM instead of BPM to SOA - Not sure I understand the assertion that we should attach SOA to the swimlane diagram and not BPMN Nick. Pools and Lanes are used heavily in BPMN, so what is it about BPMN that you have an issue with? If it's the BPEL/automation side of BPMN, then I agree, but I think that BPMN can be very useful to organizations without that side, especially since what you get is a standard Process modeling language where none exists today.
• Why Sales isn't process driven - According to Steve Jones, the "mechanism for the implementation and measurement of a service" (process) isn't always the same thing as the drivers for and value of the service (goals). Meaning that our services ought to pay attention to user goals first and the underlying process second. It's a UCD/UX perspective for SOA...
• PowerPoint: Boon or Bane? I tend to fall into the camp of PowerPoint is a misused tool, not a bad tool in and of itself, though its conventions in the form of automatic title and bullet regions do encourage bad behavior. 
• Stuff - I read recently that it took the self-storage industry 25 years to build the first billion square feet of storage space and only 8 years for the second billion. Yet our houses have grown by 80% and we still face a storage crisis. Stuff is best gotten rid of...

• Enterprise Architecture, REST and SOA all sit down at a bar? - More on REST, SOA and EA and EA's responsibility to be relevant to project teams.

• Do Enterprise Architects ask Stupid Questions? - There are no stupid questions, only questions that self-righteous people think are stupid.

• Build versus Buy versus Opensource - Good advice if you can get Opensource in the door. Of course, vendors charging a premium to solve common problems already solved should be reason enough to adopt opensource...

• Loc.alize.us - A Google Maps and Flickr mashup that brings photos of different lands to you. I'm planning a trip to Italy right now and it's nice to be able to get more than just the top-down view that Google Earth and Maps provide. Google Earth has functionality similar to this, though I like the UI here better.

• What SOA needs to learn from Ruby On Rails - Though I'm not sure what "Canned SOA" would look like, I agree with the argument that SOA needs some measure of default convention which can be leveraged.

• The Developer Theory of the Third Place - My third place is usually one of several coffee houses or restaurants with free WiFi close to my work or home. BTW, If you're ever in Colorado Springs Scott, we'd love to have you drop by and share some of your expertise.

• Free Code - Getting IT out of the Applications business - IT takes EIM and the Business Event Ontology and gives the business (Biz Process Devs specifically) the ability to write "free code." While it sounds a little counter-intuitive, it certainly has some promise.

• Never Email Anyone Over 30 - I've seen many enterprises that think that Email + IM = collaboration needs met and I find it pleasantly surprising to see that IM as a collaboration tool is diminishing in the eyes of the younger generation of workers in favor of things like SMS, Wikis and Blogs (Twitter is probably just about in its own category). What that means however is that the enterprises who are just now getting IM in the Enterprise are still behind the curve... so what's your strategy for embracing the next generation of collaboration tools? Does an Enterprise vendor have to offer it before we'll buy it?
• Practical Enterprise Architecture - Some good tips on creating valuable Enterprise Architecture.
• What is Enterprise 2.0 - As much as I don't like the phrase, or "concept versioning" in any form, I like what the idea represents in terms of driving information access, interconnected applications and devices and collaborative and open work.
• SubSonic - This looks to be a very nice ASP.NET scaffolding framework that parallels much of the project start-up scripts that makes Ruby on Rails such a nice environment to work in. (via Ken Scott)
• Should people adapt to computers? - Agreed Scott. I think that people have adapted enough... it's time to set them free, and I don't mean by turning their coffee table into a computer either.
• Enterprise Architects versus Business Architects - While I certainly don't think that the role of EA is to create services within an Enterprise SOA, I do think that EA has a responsibility in handing valuable business process knowledge to an SOA team that then knows which services are needed. Otherwise, services end up being created to wrap whatever database entities a given project needs next. In any case, the key is that EA has a responsibility to be relevant to SOA efforts, not the other way around.
• Enterprise Architecture is like Herding Cats - Don't know what I could possibly add here...
• Is Serendipity the Heart of the WS-*/REST Debate? Serendipity is probably a large part of the discussion, but I think a key to Nick Gall's General Principle of Serendipity ("Just as generality of knowledge is the key to serendipitous discovery, generality of purpose is the key to serendipitous (re)use.") is that one can rarely (even in an enterprise) plan for explicit reuse of a service. As such, you plan for serendipity.