KnowledgeForward

Web governance has been a topic of great interest to me for years now because it’s a topic of great interest to my clients.  This is why we gave governance a starring role in our new Microsoft SharePoint Infrastructure Planning and Governance workshop.

I feel that Microsoft has woken up to the importance of addressing governance when it comes to SharePoint, a piece of infrastructure that is notorious for often being deployed (or evolving) in a wildly ungoverned fashion.  But when I look at the actual guidance being published outside of Burton Group, governance often seems to just mean maintenance.  For example, this CodePlex page on Governance and Manageability is 95% about manageability in my definition.  A site recycle bin? Management.  Splitting larger databases into smaller ones? Management. Arguably some of the other items listed here could assist with a governance effort even if they are not governance themselves.  For example, usage and storage metrics reporting could be used to check against a policy that a division shouldn’t exceed 10GB of storage. 

For many years now I have been putting forth the view that web governance uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization.  Technology only fits into this insofar as it supports a process that is needed to assist with compliance with the Statement of Governance.  The real value of governance is that it helps to pre-decide who wins in arguments before they come to a head (that’s the “mitigate conflict” part of my definition).  Details about how to use the admin console to check for orphaned accounts or apply a template to a series of farms are unlikely to cause frothy arguments and are best left to separate maintenance manuals that can be approved and maintained on a different cycle than the Statement of Governance. 

The reason I get picky about what is governance versus maintenance is that the documents are often created by separate people as part of separate efforts and are on different update cycles.  A governance document may state that it’s important that information on the website be kept fresh, therefore all web pages have to be updated every 180 days.  If it then goes on to describe which tools site administrators should use to run an aging tool or how to set site settings to expire documents then that information is likely to get out of date, be harder to find by admins who don’t want to sort through all the high level stuff, and make the document too onerous for non-techies.  A second reason is that governance documents tend to be lopsided if they are created by techies that like filling it with topics they know a lot about and ignoring high-level, non-technical concerns.  A third reason is that anyone who asserts that they’ve written a statement of governance that just sprinkles a few platitudes about scope, goals, and policy into a detailed manual for maintenance and manageability is going to look foolish when the groups that truly understand governance (enterprise architecture teams or other higher level governance teams that have written higher level guidance) see the results.

(Note: This is a cross-posting from the Collaboration and Content Strategies blog)

I wanted to mention that we are doing another SharePoint workshop on April 1st and 2nd in Boston.  You can find all the details (and register) on the website. 

This time around we have two separate workshops (you can register for either or both).  The day one workshop is much like the old workshop, but without the implementation-related material which means more time for the capabilities.  The day two workshop is now a full day of infrastructure planning and governance.

I’ll be there along with Karen Hobert and special guests Guy Creese, Peter O’Kelly, Larry Cannell, and Mike Gotta (”scheduled to appear” as they used to say as a caveat in corny promos).  This is a great place to get unbiased advice about SharePoint.  Burton Group does not do implementation, vendor-sponsored research, or vendor-sponsored workshops.  So these workshops include a lot of information about what SharePoint doesn’t do well, where the pitfalls are, and how it stacks up to products from other vendors.

Day One: Understanding Microsoft SharePoint v3/2007 in Context

This workshop provides a strategic, enterprise-level assessment of SharePoint’s capabilities and implications. It is designed for organizations seeking to determine if, when, and to what extent SharePoint should play a role in their collaboration and content infrastructure.

Day Two: Microsoft SharePoint Infrastructure Planning and Governance

The 2007 release of SharePoint offers an important opportunity for implementers of earlier SharePoint releases to re-evaluate their often tactical, disorganized, and organic SharePoint environments, and to approach collaboration and content management design, governance, and deployment from a strategic, enterprise point of view.

At the 2008 SharePoint Conference Bill Gates said that the SharePoint business has now surpassed $1B in sales and 100M licenses sold. While I believe those numbers are overstated (Michael Sampson does a good job of explaining the difference between sold seats and bundled licenses and a platform play), my own ongoing conversations with our clients confirms great interest in SharePoint, even among those who are already dedicated to other platforms.  Why such interest?  Is it, as Mr. Gates says, “the result of the great combination of collaboration and information management capabilities it delivers”?

I’ve been digging a bit deeper into why people at these clients are so interested in SharePoint.  I find it interesting how many of them already have products in house that do what they want Sharepoint to do.  This includes collaboration products like Lotus Notes or eRoom, content management products like EMC Documentum or Interwoven TeamSite, or portal products like IBM WebSphere Portal Server or BEA Aqualogic Interaction.  So why do they still want SharePoint?

The general answer these clients give me is that the products they currently use are overly complex (often limiting the departments that can use them to those with budgets for IT support) and often so expensive to license that only users with high levels of need get access and training for them.

To a certain extent, the excitement about SharePoint has really been a reflection of disillusionment with existing collaboration, content management, and portal products.  The people that are interested in SharePoint - despite already having incumbent alternatives - see at first glance a product that may finally provide easy-to-use, inexpensive, web-based collaborative solutions.  But that doesn’t guarantee they won’t be just as disillusioned with SharePoint once they get into it.  SharePoint is still new and it will take another year or more before we start collecting enough data points on enterprise-class installations to tell if SharePoint is the real deal.  “The grass is always greener on the other side of the fence”, and there are often more consultants, developers, support staff, and 3rd party add-on vendors grazing on the SharePoint side of the fence than expected. 

Burton Group was founded as a special kind of analyst firm - one that is specialized in infrastructure and is able to go deep technically.  Accordingly, our Collaboration and Content Strategies service was founded on the premise that collaboration, content, and communication have become infrastructure as well.

Many users still think of email as an application.  Part of it is.  But the vendors realized a while ago they needed to carve out the parts of email beyond POP3 and IMAP4 that should go on the server, named them Domino and Exchange, and now they are treated like infrastructure with service levels, backup/recovery, contingency plans, farm scaling, and operations-minded folks in charge of it all. 

Well, Microsoft Office is an app right?  Sure, until Microsoft realized they needed to carve out the parts of Excel that could go on the server and created the Excel Server part of Microsoft Office SharePoint Server.  A Powerpoint server is rumored to be in the works too.  And Office Business Applications (OBAs) are being created on the principle that Office is infrastructure that can be reused.  It can be repurposed to produce applications that treat Office as infrastructure, connected to line of business apps, rather than a hermetically sealed application.

Well, SharePoint is an app right?  Bingo!  That’s where this gets you into trouble. It has a purpose built front end and a wide and deep pool of infrastructure underneath it.  When the purpose built part doesn’t do exactly what you want, it can be a long fall down to the deep pool underneath.  SharePoint buyers should understand that as much as the initial demos look like an application, really they are buying collaboration and content infrastructure. If you go into SharePoint thinking it’s an app because the demos or out-of-the-box test install you did seemed to do what you want, you can be very surprised when all of a sudden this starts looking like infrastructure.  You quickly move from being an application owner to an infrastructure owner and those are very different hats to wear. 

As the infrastructure nature of communication, collaboration, and content (I’m including content creation in this category, not just what WCM or DM tools do) is being properly realized, we’re seeing a separation of what used to be considered “applications” into infrastructure with an application on top.  The infrastructure parts keeps getting thicker (such as email going from POP3 to Domino and Exchange).  Accordingly, there needs to be more awareness - from end users and from vendors - of how the transition is made from application to infrastructure. 

The transition is difficult, but doesn’t need to be as painful as it has been.  Not if vendors recognize quickly what parts of their apps need to be pulled out and treated as scalable, reliable, reusable infrastructure and are clear about the depth and solidity (how far are you likely to get before needing to call for a team of coders, is this supported, etc) of the applications layers they provide on top.  Enterprises need to set up management processes and organizational structures to catch new infrastructure as it sinks from the application layer down into their domain and to understand the difference between infrastructure capabilities surfaced in a demo sort of UI and real applications.

Infrastructure has special characteristics that applications do not have and that can stymie implementers of communication, collaboration, and content technology (such as discussion groups, document libraries, portals, and wikis) that seems like an application at first:

• Infrastructure (with regards to the kind of communication, collaboration, and content software we’re talking about here) needs an application to be useful.  Will a little bit of customization and tweaking to the out-of-the-box UI and templates be sufficient to act as an application?  If not, who is going to design and build your application now that you have the infrastructure?
• Infrastructure is meant to be reused and repurposed, so who is going to own something that will be leveraged by a multitude of groups?  Probably not the first team that wants an application - if that’s the case it will be game to see who can stand on the sidelines the longest and let the first, most desperate group that needs an app take the plunge and wind up owning and paying for the infrastructure the groups on the sidelines will now leverage. 
• Infrastructure needs to be managed.  It needs availability (according to negotiated service levels [SLAs]), contingency planning, backup/recovery. This is stuff that tends to be considered boring and “not in my job description” for programmers and power users.

So the next time someone shows you the interface for a great looking communication, collaboration, or content tool, think about stepping back and saying “That’s great infrastructure.  Now who builds the app on top of it and who manages the infrastructure?”

Note: This is a cross-posting from the Collaboration and Content Strategies blog.

I just finished watching a Flash movie on integration of SAP into SharePoint (my Tivo’s on the fritz so I couldn’t watch Jon Stewart as planned). I thought I’d post my notes here to save you the 20 minutes or so it would take to watch it here, although you’ll miss out on the nice British accent and spiffy Flash graphics. It matches up pretty well with my outline of Integration With SharePoint and Anything, which proposed a similar continuum of 9 integration levels (from most complex to least) as: Programmatic/API level, Database/Repository/Metadata, Execution, Web Services/SOA, Portlets/Web Parts, Single sign-on, Unified search, Screen scraping, and Linking. They reverse the continuum, but hit most of the same notes.

Here are my notes of the presentation, followed by a few comments:

Document management:

• Their scenario assumes you store your content in SharePoint and then use WebDAV, web services, or a packaged .NET data provider (.NET Data Provider for mySAP Business Suite) to get at it
• You can use the Business Data Catalog (BDC) to search for SAP data from Sharepoint

Front-end integration:

• A few low-end methods are mentioned, such as linking, using framesets to embed pieces of SAP portal-displayed views inside a SharePoint page, and embedding customized portlets (not sure what kind they mean)
• WSRP: SAP acts as the WSRP producer in this scenario and SharePoint as the consumer. This is apparently a custom bit of work as you need to produce the xml-compliant templates in visual studio.

Content integration

• Business Data Catalog (BDC): It doesn’t say whether there is a non-manual way to create the BDC metadata for an SAP system. While SAP systems are highly customized, there are often tools that can be run against them to do discovery of customizations and allow click-and-drag access to data objects. It doesn’t seem like that is done here
• Forms: Online forms from MOSS can be submitted to SAP
• You can develop iViews in Visual Studio. There’s a portal add-on, a portal runtime for .NET, and a Java .NET interoperability plug-in that runs in SAP
• They mention additional integration that is needed such as SSO, multiple iViews in a SharePoint page, and migrating iViews into SharePoint

They point to www.microsoft.com/sap and www.duet.com as well as their generic msdn and sdn.sap sites for reference.

A few comments from me:

WSRP portlets have been a sticky issue for SharePoint and, indeed, when listening to the slickly produced Flash movie, I can clearly detect that the part about using WSRP portlets from SAP in SharePoint was done as an overdub. The vocal quality and volume changes for that section. It could be they just needed to clarify the technical detail later, or they had to be very careful to say what they can do because one bit of wrong wording would expose some limitations with that method. Or maybe last minute decisions were made that required redubbing (like a lack of packaged WSRP portlets).

They don’t mention unified search between an SAP portal and SharePoint site. If anyone out there has gotten that to work well I’d like to hear how you went about it.

In general, this demonstrates that integration with SAP or SharePoint occurs across several dimensions and any organization looking at integration needs to consider all of them. If a vendor is asked about integration and gives a nice detailed answer about one level (such as portlets) you need to ask about all 9 levels.

As an exercise, the integration that Day Software (a content management vendor) announced today with SAP can be analyzed across these levels as well. Day’s press release says:

Day’s extended capabilities provide out-of-the-box portlets, allowing managed content that is dynamically associated with the SAP NetWeaver Portal, to be displayed through iViews. Presentation capabilities are supported through the use of iViews, themes and external facing portals. Integration into portal navigation and TREX search is also available. Day extends the value of managed content through multi-language support, inter-portlet communication, content sharing and personalization. Support for LDAP and Single Sign-On enables seamless integration into the portal framework.

While the devil is in the details, you can at least see they are touching the bases. Once you see the integration dimension pattern, it becomes easier to assess SAP or SharePoint integration.

I thought I’d write a few thoughts on a question a client just asked me. I’ll call it the “SharePoint and anything” question and it’s quite common. The company has standardized on some product(s) for collaboration, content management, and portal but now SharePoint is sprouting up all over the place and they want to know what to do. This issue has many dimensions and possible paths, so I’d recommend a client actually talk to me so we can work through it. But I’ll give the high level outline here.

The first question they tend to ask is “Do other companies have this issue?” Definitely! For lots of reasons, both good and bad, the majority of large organizations winds up with more than one system for doing collaboration, content management, and/or portal. I’ve talked to some that list several full portal products in use. There’s a difference between asking what other companies are doing and what best practice is though. Getting down to one platform may not be possible, but it’s a vector in most cases (there’s some complexity here that I won’t expound on right now).

Next, it’s important to determine if you are in an overlap scenario or a contextual integration scenario. Contextual integration just means you have two non-overlapping, complimentary technologies you want to use together like SharePoint and an ERP system. Great - that’s a whole discussion of it’s own that, you guessed it, I won’t expound on right now. But more often it is overlapping with other technology that does a good portion of what SharePoint does. That’s when I poke around and find out why it’s emerging. Because if SharePoint is growing up from the grass roots among other installed alternatives, it must be meeting some latent need that isn’t being met by your current collaboration, content management, or portal.

There are many different types of integration and sometimes organizations want several of these. The project owner has to determine which integration they will need to deal with.  Types of integration include:

• Programmatic/API level: Either custom coding or dedicated bridging applications like SAP’s Duet
• Database/Repository/Metadata level: Sharing or direct access of directories, documents in a document library, etc.
• Execution: Being able to port across platforms, like Mainsoft for Java EE, Portal Edition
• Web Services/SOA: Wrappering functionality in one portal for use in another
• Portlets/Web Parts: Java portlets that can surface SharePoint discussions, libraries, or lists. Or, vice versa, Web Parts that can surface content from other portal, collaboration, or content management products
• Single sign-on: Passing credentials from one system to another
• Unified search: Ensuring that a search done from SharePoint can pull up documents and discussions in another product, or vice-versa
• Screen scraping: Old-fashioned scraping of HTML from one site to display in another
• Linking: As simple as it can get - just helping users of one portal know when information is available in the other by providing a link (but not actually surfacing any content or helping with single sign-on)

Before getting too techie about it, I need to point out that there are technical and non-technical solutions to overlapping portal solutions. Governance and usage procedures are a critical part of the integration and sometimes the entire answer if there are technical constraints. Letting users know when they should upload a document to SharePoint versus their company intranet or their contract management system increases findability of key information.

This is a really quick summary. There are a lot more possible paths to this discussion, such as “systems integration” (connecting it to your infrastructure services, installing and customizing it, etc.), federation scenarios, vendor-specific information about the “anything” vendor and how easy they are to integrate with SharePoint, and more. But those will have to wait until another day.

I ran a breakfast roundtable here at the SharedInsights Portal, Collaboration, and Content conference this morning and found it to be quite enjoyable and enlightening (despite the hotel dragging away the coffee and tea service too quickly…). The table had about a dozen attendees, mostly architects, and was a good cross section of portal implementations. A large food franchise, a few large government agencies, a major retailer, a vendor (not a portal vendor), a real estate firm, and an international utility were represented.

The primary issue they were all faced turned out to be integrating service oriented architecture (SOA) concepts into their portal environments. Point goes to Plumtree a few years ago who dedicated themselves to the “enterprise service bus” concept. Portals were originally created as “Swiss army knives” that could connect and adapt to all sorts of identity management, security, content management, and application products. It seems that need is still prevalent. Unfortunately, the vendors have been slipping into the mode of integrating the portals into their infrastructure stacks and playing favorites by connecting to their own infrastructure first and then allowing a standards based connector to everything else (blaming it on the other vendors if they can’t take advantage of JSR 170, JSR 168, LDAP, etc.).

It was interesting that while the momentum is certainly in favor of Microsoft and IBM right now, none of the people at the table reported using them as their main portal. Instead it was BEA, Vignette, and a few Oracle. One was interested in open source as well. The table felt that the reason is that legacy environments are not going away, particularly for content management and portal. While many vendors can show a nice, unified stack now, that doesn’t help the practical reality that organizations face with the large amount of built up legacy infrastructure. Governance is a key success factor then in getting each part of the organization to agree to corporate standards even if it is a little less useful for them. Optimizing enterprise-wide sometimes means a sub-optimal environment for those that heavily use another app that offers a portal.

Workflow was also important to the attendees. A few had workflow/BPM tools they wanted to hook up to the portal such as TIBCO and Ultimus, while others were interested in the more simple capabilities you get out of a portal itself.

In part one of this posting I gave my overall impression that IBM Lotus has done a good job of bringing some excitement to the Notes/Domino camp. Here are some thoughts I had from the presentations and my conversation with IBM VP John Allesio.

On the SOA front I was pleased by the way in which the new services (Quickr and Connections) have been architected for consumption. The usefulness of collaboration is enhanced when it can be used in context with applications, data, or content it is referring to. This contextual collaboration requires being able to blend the collaboration services into existing applications and interfaces rather than forcing the user to switch to a dedicated interface. The connectors built into Quickr (for accessing RSS, blogs, content libraries, etc.) are a good example of building services meant to be consumed. This is still an issue I have with SharePoint, which is currently marketed and demoed as the center of its collaboration universe rather than a participant in other non-Microsoft applications.

WebSphere Portal 6.0 was also discussed, but it seems like sideshow at a Lotus conference. While WPS is becoming increasingly important to Notes/Domino customers, it still appeals to a different set of customers. WPS seems to me to be an incremental update and technology refresh, including features such as a template library, fly out menus and navigation, drag and drop, a portlet palette, and look and feel enhancements. But there was a bit of marketing spin mentioned twice that rubbed me the wrong way: “Integration at the glass”. If all I want is to integrate at the glass I’ll get an open source portal like JBoss Portal. If you’re just looking for web UI stitching with some personalization and an implementation of the standards, then open source is a lot cheaper than WebSphere Portal. But most large corporations need a full size portal product (or whatever similar technology is embedded in their superplatform). The value you get out of the full size portal product is the back-end integration into enterprise applications and infrstructure services, which are not “at the glass”. But enough ranting on that …

My teammates have commented quite a bit on the collaboration and social software additions in Connections and Quickr, so I’ll save a few calories by not retyping what they said. But I’d encourage you to see the blogs of Mike Gotta (multiple postings), Peter O’Kelly (multiple postings), and Karen Hobert for some great insight.

I am interested to see how the strategy for Quickr evolves in regards to being a SharePoint competitor. IBM was ready with a list of things Quickr can do that SharePoint can’t (DB2 data stores, works on more platforms and through more access mechanisms, etc.), but there was no comment on whether that list is supposed to explain why it is a different product category than SharePoint (apples and oranges as it were), or a better product in the same category (a better and shinier apple). The pricing (which hasn’t been announced yet) will be a big clue into how directly they wish to compete against Windows SharePoint Services 3.0. Hey, I’m a capitalist - I enjoy competition and think the end users of Quickr and SharePoint would both benefit from direct competition. But my prediction is that any direct comparisons will be played down and a safer - if less fun - path will prevail.

I’d like to go back to a topic that’s been near and dear to my heart for about 15 years now - user interface design. I did quite a bit of work on web usability in OS/2 GUIs and again in the early portal and web days when it seemed UI design hadn’t caught up with the need for dynamic and personalized sites (it still hasn’t). Well, my rant today isn’t about UI design for portals, but for the security-trimmed interfaces that are all the rage these days. There seem to be an increasing number of applications whose interfaces make me feel like a precocious child being shielded from the dangerous consequences of my inquisitiveness.

Microsoft has taken the plunge, most noticeably for me in SharePoint. I’m trying to find the audience creation functionality in Microsoft Office SharePoint Server 2007 and the problem seems to be that my server doesn’t have that functionality enabled. But I can’t tell for sure. Searching for specific step-by-step instructions has proven futile except for one streaming video of a presentation of someone demonstrating it with the camera focusing (or trying to) on the screen behind the speaker.

I had a similar problem with an audio waveform editor that I have. The manual kept referring to some great pitch fixing functionality. It made it seem so easy to launch the editing screen that they didn’t even have to describe the process other than to say “After launching the pitch editor …”. I spent half an hour searching for it (right click on the waveform? Is it a button in another wave editing screen?) to no avail. Finally after an email to support I was told it’s only on the “pro” version of the product (this isn’t mentioned anywhere in the manual as it must have been a last minute marketing decision to make that a premium feature) and therefore the interface was trimmed not to show it to me.

I understand the usefulness of the security or rights trimmed interface. It can help both the app owner (keep users from asking about features they don’t have) and end user (avoid confusion by simplifying the interface). But I believe it’s being overdone and without due consideration for the negatives (it’s hard to definitively tell an option is not present, so one continues searching).

UI designers should:

1. Allow opting in or out of a trimmed UI. Consider an option for the end user to select “advanced mode” that shows all options with those not selectable grayed out
2. Make sure manuals and online help are accurate. They need to show exactly how to launch their functionality (the exact menu or button and where it’s found) and describe why it may not be visible
3. Consider the negatives of a trimmed UI as well as the positives and act accordingly. For applications where precociousness is not as prevalent or dangerous consider just graying out unavailable options.

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.