‘Communities of Practice’ – could they be the solution to better Portal content management ? – Part II

I’m writing this second chapter to the discussion of ‘Communities of Practice’ based around recent conversations both strategic and casual that I’ve had amongst my Portal team at TransAlta. These topics I hope to describe are likely already used by other organizations or are being considered by other SAP Portal customers, and as such I hope to solicit some good feedback around the concepts I’ll cover.

The first concept that I find very intriguing is the idea of ‘Community’ portals. This would refer to individual Portal environments that each serve a separate ‘Community’, interest group or organizational unit. One example where I saw this used was at Siemens, where the folks at BearingPoint built a Finance portal. As a result, the entire content, theme and functionality of that environment was focused around Siemens Finance department. This would give their Finance team a closer ownership of their Portal, and given the appropriate access, the ability to administer and manage the content that would comprise that portal. I find this a very effective technique of forcing a single look and feel throughout your portal. Also, you, as a developer of a ‘Community’ portal, can better determine what are the types of content that are suitable for proposal to the users of that ‘Community’ portal, because you only serve one interest group.

With our current myTransAlta portal, there still exists the discussion of who owns the portal, or who is responsible for this area of the portal or another area. The reason is that we, the Portal team, hoped that eventually one of our customers would step up to the plate and take ownership, but this has yet to occur. It is frustrating for us now, because we have considerable difficulty determining how best to serve our customers needs without any clear direction as to the types of content we should propose, whether it be collaboration tools, knowledge management and so forth. The concern is that the myTransAlta portal may become less of an application environment, and more of an information source. Our approach could have been to consider only a few select groups that we know require web based content management and build our portal around that, even though the content would be publicly available, those specific groups could maintain the content, and we could focus on building better solutions for them, rather than waiting for another group to jump on the portal bandwagon to build their solution for the portal. Our portal team ends up looking like we are slow in evolving the portal, and much interest in the portal is then lost.

A ‘Community’ portal would be quite similar to building a unique Lotus Notes database for a specific interest group. It would have basic resemblance to other portals, but the content would be focused specifically around the needs of that community. Surely, this will be a point of discussion as we move forward with our myTransAlta portal evolution.

The second concept, and one that is recommended by SAP, is the ‘Federated’ portal approach. With ‘Federated’ portals, we would have the exact same portal configuration, but in the various locations of the organization. This is very beneficial, especially if an organization is divided across varied geographical locations, and network bandwidth is a severe constraint. With this approach, we could make some content more tailored around that specific geographical location, such as keeping Canada content in the Canada region and US content in the US-based portal.

As TransAlta approaches its relaunch of the myTransAlta portal, there has been discussion around using the ‘Federated’ portal approach, primarily to resolve the ongoing issues around network bandwidth constraints. Since TransAlta is split across the globe, from the US to Australia to Mexico and Canada. Many of our remote (outside of Canada) users complain about extremely slow rendering times for the Portal. As such, the currently designated best approach is using the idea of ‘Federated’ myTransAlta portals. Thus, we could have the same content, but the rendering times would be identical if not better, in some cases as the servers reside locally in those various domains. This idea of having ‘Federated’ portals is much similar to having multiple replicas of Lotus Notes databases across different Lotus Notes servers, despite their geographical location. Although the content is replicated at scheduled periods, the process of replicating is automated, making duplication of changes unnecessary from one replica to another. TransAlta is seriously considering this option, as the notion of being at head office has benefits should go away. ‘Federated’ portals will create that ‘One Stop’ environment where all employees, regardless of their location, come together, collaborate, and get their work done, and most importantly help the company as a whole accomplish its goals.

With either the ‘Community’ or ‘Federated’ portal approach, there are certainly costs involved. With each new portal environment comes the cost of additional servers, network hardware, and so forth. But, if the needs of the end users are more important to the organization that intends on making the portal a central part of how the company runs its business, than the cost should not be an obstacle to proceed. And, ofcourse there is the added administrative and development effort that are required around both enhancing and supporting each environment, including keeping the portal software up to date. This, ofcourse can be a major obstacle, if your team is small and already dedicated full time to supporting a single production environment. I hope that other companies out there have already had discussions around these concepts to assist in making their portals the killer applications for their respective organizations. And, if so, that they can provide some valuable feedback as these broad topics deserve a large forum, and SDN is the ideal place for this dicussion to take place!