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.

Advertisement

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.

Momentum 2008: Day 1

Day One at Momentum let me focus on Partners with a series of presentations to the partners, be they SIs, ISVs or companies with an OEM relationship. The themes from the day were:

– Solution Frameworks. Big focus for 2009 is for EMC to deliver the vertical solution frameworks which customers can exploit to really bring business benefit. A good example here is a Case Management solution framework, expected to ship in 2008! This will introduce a number of ready built objects and UI features on top of core Documentum which will move the platform nearer to the line of business applications which the customers will gain their benefit from. There will be a number of these frameworks throughout 2009 and sometimes they will be backed up by sample business applications, e.g. Legal Case Management for the Case Management option. This is definitely something for us to look at.

– Quality. Release 6.5 was a major milestone for Documentum as the number of Level 1 defects was reduced from previous releases. This was achieved through improved processes including automated testing and a more agile approach to the product development.

– Complexity. Deployment has sometimes been hard, the new model is to make this easy and tests have proven that the typical install of Documentum has been reduced from 2 hours to around 30 minutes with the introduction of a concept called Express Stacks. Basically the core platform, or essentials, is installed and then vertical stacks can be plugged into it:

Innovation. Building on the Solution Frameworks by partnering better EMC believe they can really show benefit to customers and get them to see ROI much quicker and much greater.

Some of the Technology Initiatives which were discussed during the day include (note these are in no order and when the subject came up twice, I’ve included it below twice to show the popular ones)

SaaS. EMC really see some growth here and have a good diagaram which shows the difference between the location of the Information, or the Repository, and the Application, or the Business Logic. They are actively seeking hosting partners for this and when this is sorted I would expect a new, and probably complicated, addition to the price book. I hope it is not complicated though as this could be a positive move by EMC.

CMIS. Point 1, when asked only 20% of the audience had heard of CMIS. I was a bit disappointed in this as the recent announcements were noted in a number of places. The first time this came up was very much a beginners guide, largely due to the lack of knowledge. I won’t repeat that but the interesting point is that they expect to have a release of the product which is CMIS compliant in mid 2009. They have already trialled some of this in sessions with the other contributors and this really sounds like a positive area.

Virtual Repository Management. This introduces the concept of managing other, third party repositories with Documentum policies. e.g. Content in Sharepoint being subjected to Retention Policies from Documentum.

Next Generation WDK. Moving to a Web 2.0 platform, WDK is now 10 years old and things have moved considerably in that time. The architecture will be unveiled but will be based on a Rich Content Management Platform (RCMP). Will be fully supported in the tooling, i.e. expect that to mean Composer.

Captiva. New releases to come, making it more service based. Next release is English only but multilingual to come.

Document Sciences. Will maintain the focus on the product as a standalone but will also integrate it into Documentum, as two different routes.

CMIS. More talk on CMIS, this time to say an implementation is available now for the Web Services interface. Not checked myself but something to look for on EDN.

Open SW Initiative. EMC have listened to what people have said and will make software more readily available for the techies to download and try out and possibly even provide a more collaborative approach to releases.

XML. Listened to a talk on the xDB but to be honest the information was nothing new on what is already available!

 

Lots there and more to come……

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?

D6.5

D6.5 has been announced on Powerlink now with the following focus areas:

– Platform improvements

– Knowledge Worker solutions e.g. CenterStage

– Transactional Content Management

– Interactive Content Management

– Compliance and Archiving

I’m really interested in the the Knowledge Worker solutions and Transactional Content Management up front but the improvements to the platform and the Compliance and Archiving views need to be looked at as well.

Natives and Immigrants

I picked up these two terms from this post at http://ecmarchitect.com/archives/2007/09/20/767

Digital Natives – the generation of workers who are entering the workplace now
Digital Immigrants – the generation of workers who have adapt to the changing technology

I would consider myself somewhere between the two but with my techie focus, compared to say a lawyer, I’d like to think my interest moves me towards a native. I joined Facebook and get more from the way it has been built and designed than the fact I can keep in touch with people, although I think that will move on slowly.

The two camps above present a real problem for us in the industry. Take a project I am working on now where we are implementing a Portal into organisations which are traditionally very immature in terms of technology. The vast majority of users we have will have had no exposure at all to the likes of Facebook and other mash-ups. In fact some will have had little exposure to the internet.

The strategy we drew up some time ago on the programme was that the Portal platform would become the workplace for these people, the number of users could rise as high as 400,000 and work in many, many different organisations. We would build multiple applications which the users would then access based on role and rights. The applications they access would then be available for them to customise to their own liking, they may not need the full application to do their regular day to day work but could select one or two Portlets for their dashboard.

At the moment the customisation options are not being pushed, we’re keeping them locked away for a rainy day, and for when the user population is more mature in terms of it’s approach to Portals. However it has been very important for us to ensure the design of the Portlets is granular enough to allow for this customisation to work in the future.

Google ECM

Earlier this week an announcement was made of a partnership between Capgemini and Google,

A colleague of mine was certainly excited about this news and it started some debate within our group. I had briefly looked at Google Docs some time ago in an effort to ensure me and the wife can share information whilst I am away doing the usual consultant travelling, she wasn’t keen so it didn’t go very far.

Where does this fit in with ECM I hear you ask? Well on a number of levels, the most significant is the impact on Sharepoint.

There is no doubt that MOSS 2007 is having a significant impact on the ECM marketplace. However one of the biggest advantages of this is its ease of use through the traditional MS desktop. If more and more companies look to the Google Apps model then this advantage is removed. I’m not for one minute suggesting that this means the end of MOSS 2007 but it does suggest that there is a stronger future for the other suppliers than they perhaps expected and it will only take a partnership between one of the vendors and Google to really see this.

Secondly, but closely related, is the old chestnut of standards. Google are clearly delivering a wide reaching capability here and at the moment they are looking to simple file management. As this matures they may, I suspect will, see demand for more function rich ECM features such as check-in, check-out, better version management, lifecycles and workflows etc… Could the advent of this see an opportunity for us in the ECM space to define these standards and look to Google to provide an open interface which different ECM vendors could look to expose which the Google Apps would hook into. Imagine an organisation with an existing FileNET or EMC deployment who want to move to the Google Apps model, the standards based inteface would mean this is an infinitely easier exercise than having to code Google Apps to fit in with their ECM repository or vice versa. Of course this also means that the Google Apps model may also need to change slightly with the repository actually being held within the organisation, eventually we may even see this disappear and organisations simply ‘renting’ Google Apps space with the level of ECM functionality they wish influencing the price they pay. I wonder if any ECM vendors have approached Google with this idea and offering their repository, if they haven’t and do start to look into it then remember where the idea came from 😉

ECM Web Services

Laurence has written an excellent post about fitting Sharepoint into the ECM picture.

The comments about the rewrite of eRoom are interesting and confirm thoughts which I am sure a number of us have had for some time. eRoom as it is does not have a future and EMC need to repurpose it and break down its features into a number of services which can be added on to the core Documentum products and then exposed through the clients. This started in the past with the Collaborative Services.

The killer in Laurence’s post is his dream of standard ECM Web Services definition. This should not be a dream and should be something we are moving to, but I am not sure it should be about plugging in an ECM platform to either Sharepoint or eRoom but more about exposing the ECM and Collaboration services which the products expose into whichever presentation layer the customer wishes to use. Note I am saying ECM and Collaboration services, both are required.

On a recent project we used Trac for our wiki and Subversion for our Config Management, this included code and documentation. If there had been better support for some of the config management services of Subversion which the wiki could have harnessed then we would have not had a slightly awkward UI to battle through to get to important documents. No reason why this could not have been through standard EMC Web Services.

When we start to consider some of these we will be moving much closer to the Web 2.0, SOA buzz words which are being touted much more. Something to ponder and think about no doubt.

Future of ECM

John Newton recently blogged on the future of ECM and gave his predictions on what will happen to the ECM market. I think there is little doubt in his statement that MOSS will be the biggest single disruptive influence on the ECM market in the coming months/years. He also made a statement about the expansion of Alfresco as being another disruptive influence on the market and then went on to discuss the Alfresco strategy of meeting the needs of Web 2.0 and exceeding the likes of Sharepoint. This is an interesting note and one which is something I believe is the omission from his list of predictions: 

–          the emergence of Web 2.0 and the ensuing battle between the browser and the desktop Microsoft have made a dramatic incursion into the market with their MOSS release and to the average end user of ECM they are in pole position to become the leading product in this space; after all these users are familiar with the Office products and are somewhat ignorant to the merits of the other approaches. This is in no way a criticism of the users, they have a product which meets their needs as they are now and is something they have become familiar with over a period of time. 

However it is up to us in the IT community to ensure that end users are aware of what alternative approaches may bring them, or even their IT departments if the advantage is not necessarily functional. Note that this does not mean technology led projects which I strongly disagree with, a successful architect should be able to introduce new technology to users which not only meets their obvious requirements but highlights other possible gains….the former remains the priority.  Back to the point though and if we see a surge in the browser as the desktop, as oft quoted in our community, I do not expect Microsoft to be in a great position to exploit this. Of the big players in the market I expect EMC/Documentum to be in the best position to exploit this as they now have a reasonably mature product and have already spent time looking into this. IBM/FileNET will continue to struggle with how to integrate their products. I’ll certainly be keeping an eye on Alfresco and how they develop in this space. For the time being though Sharepoint will be on the minds of most CIOs seeking an ECM solution, it is still unproven but as a Collaborative product would be high on my list of recommendations. If however more structured Document Management is required I’d be looking to ensure my customer does not tie themselves into a product which does not have a roadmap for how to react to the future direction we may see.