The Portal FactoryFebruary 2, 2007 at 3:04 pm | Posted in Microsoft SharePoint, portals | 1 Comment
For my upcoming report on building portals in SharePoint I’ve been mulling over the idea of how to easily describe my idea of what I mean by “portal” (since the word itself is pretty much meaningless) and why it’s important. Since my early reports on portals for META Group in 2000 and for the 5 years, 41 reports, 4 marketwide portal vendor Metaspectrums, and 2 primary research studies that followed (phew!) I’ve been referring to this as “Enterprise Portal Frameworks”. Now at Burton Group, I’ve been taking advantage of the opportunity to rethink how to describe the concept.
The EPF phrase worked fine and tied in to an overall infrastructure concept of a framework as being scaffolding that could be filled in. The analogy I used was that of the refrigerated cookie dough. It’s more than a recipie, but less than buying prepackaged cookies in a bag. It’s premixed and ready to slice off, maybe add some sprinkles, and bake. But it still took a little while to explain and I wanted a term that would get the reuse idea across my clearly. I think I’ve got it: “portal factory”.
Here’s the idea:
Buying, architecting, designing, installing, and integrating a portal requires significant time, personnel resources, and money. Duplicating that effort for every portal interface required would waste time and money. It would also burden cross-functional users of multiple portals with baffling user interface inconsistencies and create maintenance hassles. Nearly all organizations with successful portal implementations provide a common, pre-integrated set of services and guidance for building portal interfaces for any group that needs one. I refer to that pre-integrated set of services for building portals as a portal factory.
The goals of a portal factory as opposed to assembling each portal from piece parts are:
§ Findability: Stamping out portal sub-sites using a portal factory enables the information and navigation on all of the sites to be tied together. Searching across all of the sub-sites is enabled and navigating to the correct page becomes much easier. This also enables a common hub to establish subscriptions, XML syndication, and alerting that all help connect up useful information to the information workers that would find it valuable. This ability to simplify the finding of information is referred to as “findability.”
§ User Interface Consistency: A well-designed web site provides a more usable experience. But the cross-functional nature of information workers necessitates consistency as well as good design. Most knowledge workers and nearly all management and executives will utilize multiple portal sub-sites. Even a lower level knowledge worker may access several subsites such as a departmental or divisional sub-site, project sub-sites, role-based subsites (such as for .NET programmers), and administrative sub-sites (such as information technology helpdesk and travel and expense submission). The more sites one accesses, the more important consistent user interface elements such as navigation, footers, columns, and color schemes become to increase usability and findability.
§ Infrastructure Consistency: Just as users benefit from consistency across the front end of portal sites, infrastructure owners and developers benefit from consistency across the back end. Determining how to integrate user management infrastructure (directories), security (single sign-on), enterprise applications, manage its application server (clustering), and set up an integrated development environment for it is a difficult and time-consuming task required skilled personnel. Once the back end has been figured out, it would be a waste to repeat it.
§ Maintainability: Web sites built using a portal factory should break less often. And when they do break they should require less time to fix and require a more common skillset for the repair. There are two reasons for this increased maintainability. First, since more time and more skilled personnel can be expended on a reusable factory than a single-use web site, these web sites will be developed with best practices in mind. Second, since all sites coming out of the factory are designed the same, anyone who can fix one of the sites will find it much easier to help fix another.
§ Ease of creation: Integrating infrastructure, building connectors to applications, and customizing templates require a higher level of information technology skill than content creation. So reusing that work results in less staff staff hours and lower skill requirements.
§ Rapid time to portal: Since infrastructure integration work has already been done and many design elements are pre-determined, there will be less ramp up time needed before the specifics of the web site can be addressed.
The portal factory concept helps address a common question from portal implementers: “how many portals should an organization have?” This is a trick question since it contains an unstated assumption about whether a portal is just the interface or the set of infrastructure underneath it. If one is referring to the interface, the answer is that there should be as many portals as there are users since portals are personalized websites. But if one is referring to the set of infrastructure beneath the portal – the portal factory – it becomes clear there should be as few as possible, and sometimes one.
I give as a rule of thumb a 3/30/300 model where the realistic goal is to have roughly 3 portal factories (one for customer-facing product sites, one for partner sites, one for intranet sites), assume 30 sub-sites off of each (30 products on a customer site, 30 divisions or org areas on an intranet), and then 300 pages on each of the sub-sites. It depends on business need though of course – the 3 could vary a bit for each company, the 30 more so, and the 300 could vary quite a lot depending on the topic.