Momentum 2008: Developing Web 2.0 with Centerstage

This was a more technical session than the previous one I posted about, really looking to get more under the hood of Centerstage and look at some of its key concepts. Some of the concepts include:

- Space, e.g. an eRoom, i.e. an area where a group of people can work together. Each space appears as a tab, much like tabbed browsing (Why not just use the tabbed browsing functionality in the browser then and not have the look repeated?)

- Page, a collection of content, attachments, widgets. It is a composite view of ‘objects’. Pages can be templated for reuse. Pages themselves can be versioned.

- Section, a collection of pages within a Space. These also can have templates to ensure commonality.

- Tags, each object can be tagged. These are implemented through relationships and thus are not keywords, this also helps in terms of management of your tags. There are views available which are driven by tags, e.g. I can see all information for a given tag, implemented like tag clouds. I can also select which tags are important to me thus reducing the clutter in the tag cloud.

We then moved on to the architecture which was of real interest. A large block diagram was put on the screen which showed the various layers in the Centerstage architecture. The points I took from this are:

- provide clear separation in the layers;

- use of DHTML and other RIA toolkits;

- UI based on a combination of RCMP (Rich Content Management Platform), ExtJS and DWR (Direct Web Remoting);

- interaction with the core of Documentum through services, WS*;

- DWR is a custom protocol for Java <-> Javascript;

- ExtJs gives no server side page generation, exact version was 2.2;

- No JSPs;

- widgets can be developed and added fairly easily;

- widgets provide customisation but can also be done through XML configuration and some policy objects;

- widgets will tend to be a collection of .js and .css, but flex and silverlight will also be supported;

- views are a grouping within a tab, these are exposed as a ‘chiclet’ – made me chuckle anyway!

- flows through the UI are defined by actions which are a flow through the containers, defined in xml on the server;

Other things to note in the session:

- content in Centerstage will be exposed through Webtop, but the look will be slightly different;

- the product was compared to the tenets of Web 2.0, unfortunately not the tenets I would have used which are SLATES

Overall this is an exciting product, I think there will be opportunities for it but as I said previously it is a crowded marketplace. It is a big shift in technology for Documentum and I wonder how long they will stick with WDK before they move to this approach for all their clients….its something new for the techies to get their teeth into and we will have a couple of years when we need to be proficient in WDK and RCMP, which is the label they gave it.

The last thing I will say on this though is that I believe this is the nearest EMC will get to a Portal, without purchasing a Portal product. Not a J2EE Portal container but the paradigm of widgets is very similar to that of widgets and I can imagine users asking to see some custom widgets which interact with other systems such as an ERP system or MOSS. The Portal word was never used by EMC and this is not their published approach but it does not take too much brainpower to see the analogy.

Momentum 2008: Introduction to Centerstage

My first open session of Momentum and an opportunity to hear more on Centerstage. Previously I have read about Centerstage and had a few discussions with people, I was hoping to build on this knowledge. For those that don’t Centerstage is the new UI from Documentum, it is not a replacement for webtop but is more in the eRoom space. It is close to Sharepoint in its style.

An introduction was given on how the way we work has changed. Changes in the way we interact on the web are feeding into the enterprise. People are always connected and expect to receive information in a timely fashion. The information which they receive should be managed in a CMS.

Centerstage has been produced to promote sharing, to promote people working in a community and to overcome the problem of information silos.

Some of the key points from the demo:

- the UI is very configurable;

- ease of use was a primary objective;

- the new faceted search looks great, this lets the user perform a search and then narrow this down further through facets…basically sets of metadata;

- one such metadata item is the topic, this looks like keywords but more on that in a later session;

- it includes the concept of a widget which can be added to the page/site (more on these later too!);

- pages consist of a mix of widgets and inline content;

- Pro version will include Public Spaces (need to find out more about these);

- the product is about providing composite views of information;

- everything is RSS subscribeable;

- everything can be tagged, these are implemented as relationships;

- Pro will include a greater choice of available widgets;

- quick view of the mobile solution, looked very much like a twitter interface;

- solution plans for customisations, called extension points;

- they introduced the new layer for interoperability, named Rich Content Management Platform (RCMP);

Overall this really was an introduction session, I’ll attend the more technical ones to get a better idea of how it works. I was really impressed with the UI but this is a move into a crowded marketplace for EMC, this is going up against a number of others mainly MOSS. The big thing that struck me in the session is that this is as near as EMC will get to having a Portal, unless they ever do purchase a Portal vendor. The concept of widgets is very similar to Portlets and will enable integration with other systems…even more so when considering the use of CMIS as an integration layer protocol. The session was very well attended which demonstrates the level of interest in the product, I’m not sure we will see much in 2009 but towards the end of year and into 2010 I think we might see some interesting options around this area.

Portal Futures

I managed to discuss a presentation recently with a colleague on the future of Portals. Having had experience of delivering major Portal programmes in a number of different sectors, with varying success, I was interested to hear the insight into where the Portal market will develop.

Five years ago if you were looking to implement an employee Intranet the buzz was about Portals. Vendors such as Vignette, IBM and Aqualogic had the products which would enable the enterprise to share, collaborate and work together. I worked on one such major programme and the biggest drive was cost, bringing multiple feudal intranet sites into a single Portal for commonality and reduced servicing costs. Another, more subtle, driver was around the knowledge sharing and collaborative products which were starting to become available then. The result was a fairly structured implementation which did give users access to features and information from a single view.

Now though the world is a different place, largely due to the advancement in sites such as MySpace, iGoogle and Facebook. These sites are generally less structured than the Portal which was delivered, the model for its growth is more on the trust which is granted to the developers to create new features and share them. Add to this the increases use of Blogs and Wikis and there is a big increase in the means through which people can keep in touch. Its my opinion that the Portal products which were at the top of the list five years ago are no longer the products to be considered now.

One thing which struck me on two of the major Portal programmes I worked was the relative inflexibility of the Portal container framework, note I was involved in two different Portal products. At the time of the first delivery Web 2.0 was not a term people were aware of, the second delivery was around the time of the emergence of the term. Both programmes had different business drivers and difference goals, one was a B2E portal which was primarily aimed at consolidation of a large and feudal group of intranet sites in a large company. The second was more about bringing together information from various information applications into a single application to aid in business efficiency. Users would act on and process the information to complete the business process.

In the first programme we thought long and hard how to manage and then expose the content which was currently displayed in the intranet sites, this was achieved through integration of a Portal product and a leading WCM system. This was achieved but I was concerned at the approach which developed in the first few weeks of operation, content was ‘thrown’ into the Portal with little regard for its relevance and structure in relation to the wider picture. Add to this the other Portlets which were developed, largely based around collaboration and it is now clear to me that the organisation were actually ahead of the technology in their thinking around social networking within the Enterprise. However the organisation were very ‘brand’ oriented with several unique brands contained within it, this focus meant there was a strong desire to retain the brands of the sites which were being migrated into the Portal. At times I felt as though the stakeholders were more concerned with the appearance of their specific areas than the content which went into it. This was very much a content driven Portal and whilst great savings were made in bringing numerous disparate sites into a single Portal framework I am sure things could have been done better if senior support for a more radical approach was forthcoming. As ever the technology was a challenge but in fact the greatest challenge was with the people.

The second programme demonstrated weaknesses in the Portal container as we sought to build an application within the container. The application was the first in many to be built into the Portal framework with the long term goal of users having a single entry point into the applications they used. Experience has taught me that to build a single web application in a Portal container usually leaves the project incurring additional effort that would not necessarily have been required if a pure web application had been built. However with multiple future applications being discussed this was the correct approach. The difficulty though was in designing the Portlets which would be developed for the application. We had two forces in play, one to keep things simple and reduce complexity through implementing as few Portlets as possible. The other force was to increase the possibility of information and feature reuse by breaking down the Portlets into more discrete components. For example consider a Portlet which displays a list of Products, by selecting a Product the Portlet could be developed to publish the selected Product information to the Portal container; other Portlets could then receive and react to this event e.g. a Stock Level Portlet which could display the current Stock Levels for the selected Portlet. This is an interesting, and exciting, prospect but the reality is that the difficulty in developing, and then maintaining, this portlet interaction is difficult in current Portal containers. I admit to not having looked closely at the latest JSR spec for Portlets but I have doubts that the JSR spec is the correct way forward as it is technology specific and does not allow for Portets (or rather Web Parts) from SharePoint to reside in the same paradigm.

Putting the technology to one side though the only way in which different teams could develop Portlets for this level of interaction is through a common Information Model, i.e. only when it is agreed that constitutes the identifier for each Product can this be progressed. In fact a current complaint of mine with some of our internal tools in this space is that we have too many different information repositories and it is very difficult to get a view of all relevant information in one place. Whilst introducing some technology can help this it will only work when the Information is stored and managed correctly; if I did not tag this as Portals then it would not appear as a Portals blog entry.

There is a lot in this post, although there is a theme underpinning it. For organisations to embrace Enterprise 2.0, and by that I mean the use of Web 2.0 tools within the Enterprise, we will need to address three key challenges:

- what is the purpose. Too often this is missed but what are the business objectives and the benefits which can be seen. If this statement includes the use of terms such as Web 2.0, Enterprise 2.0 or SOA then it has missed the mark completely.

- what is our current information model, how is information captured and stored, how can this information be presented?

- given the two previous statements what do we need from the technology to support this?