Blogger: Craig Roth
I'd like to talk today about refrigerated cookie dough. Well, actually I'd like to talk about portal infrastructure and other cases where collaborative infrastructure is reused, but I find that the store bought refrigerated cookie dough where you slice cookies off a roll works great as an analogy.
The analogy came out of a full day discussion I had with an infrastructure analyst at Meta Group where I worked in the collaboration group. I was trying to convince him that portals were a real thing, not just a fuzzy term. He was coming at it from an infrastructure perspective and asking how it can be a real thing when practically all its pieces, such as an app server and content management, already exist independently.
I dismissed the idea that a portal was just a design pattern, best practice, or blueprint. If it was, it was just a piece of paper that said it's a good idea to connect an app server to search, content management, and single sign-on and make the interface configurable. No, it wasn't that abstract as smart organizations were spending real money on actual products.
But I also dismissed the idea that a portal was an application. Except in the very early days of portals, organizations weren't just installing it out of the box like an app. There was significant development and integration work required. And companies that obtained good benefits from portals leveraged them many times (such as portals for each product, portals for each division, and special project portals all built leveraging the same infrastructure setup work), which is a hallmark of infrastructure.
The answer we came up with (for the record I think Bruce, the other analyst, suggested it first) was store-bought refrigerated cookie dough. Like this. Rather than buying a printed recipe or finished cookies, portal buyers were getting something inbetween - a set of ingredients that were pre-mixed, but ready to slice off, customize, and bake later each time a portal website was needed. It's true that content management already existed, as did collaboration, single sign-on, and many other components. But here they were being pre-integrated in a mix-or-match way for the creation of dynamic, personalized websites. You could use, for example, the built-in content management or substitute any of three other content management products using pre-built connectors. Same for all the other pieces - they were all ready to finish off, but left to the buyer to finish as desired. Also, since organizations often want many portal websites, they were ready to slice off and customize every time a department or project wanted a portal site.
A central portal group provides an organization a portal framework. They select the product, app environment, work with the identity team to connect to the directory and single sign-on, connect to the collaboration product being used, design the highest level navigation and UI, connect the content management tool, and figure out operational details. This framework is only created once, but now every time a part of the organization wants their own portal site they can take this framework, which already has 70% of the work done, and bake it however they like within the bounds of the governance that is established. This balances the need for a department (or other such interest group) to want its own portal and the need for the organization to leverage existing investments in products, development, and best practices with the need to reduce the time spent reinventing the wheel for every portal website.
This insight provided me a clear answer to a famously murky question: how many portals should a company have? The answer became obvious: you want to have as many portal websites as needed (after all, portals are about personalization), but ideally there is only one portal framework they are built off of. In real life it's still often a few frameworks due to very different needs, purchasing environments, and governance structures, but that isn't a reason to abandon pre-integration and reuse all together - just create as few frameworks as possible and ensure they are sliced off and finished multiple times to best leverage the investments.
Over the years I've seen that this is indeed how organizations that are happy with their portal investments are treating them - as pre-integrated frameworks that can be easily instantiated to meet the specific needs of groups that had portal needs. So while I don't recommend real-life rolls of cookie dough (too many preservatives and too much sodium; just make your own dough and keep it in the fridge), I have found that portal infrastructure has found a better application of this concept.
Thanks for the image of the fridged cookie rolls. This leads me into the idea of vegetables fridged in small bricks... ;)
Posted by: Birger Hartung | January 12, 2009 at 07:29 AM