Information Management Trends

I was asked this question in a meeting the other day and to be honest it caught me on the back foot a little, I’ve probably been too close to detail over the past few months to really take a step back and think. The question was ‘What do you see are the current trends or hot topics in the Information Management world?’. Whilst I gave an answer which I believe was acceptable I decided it was time to take a few moments to reflect on what I am seeing in the market. I’m sure there are other things going on out there but I thought I would share some of my views:

SharePoint 2010 – there is no doubt that this continues to be the product with the biggest influence over the market. More and more customers are starting to explore the features which SP2010 delivers and it is starting to find its home within the overall market. It won’t, in fact can’t, do everything that everyone wants but there is a strong discussion to be had on why not SharePoint!

SharePoint 2010 – this time I am considering the impact the product has had on the other vendors in this space. Whilst I think it is too far to suggest that the likes of OpenText, EMC, Oracle and IBM have given up on their core Document Management solutions they have realised that this is a difficult fight for them if they go toe-to-toe on the basic content services when compared to SharePoint. As a result they are all trying their utmost to find their space in the market. IBM and EMC appear to be placing their bets on the Case Management style solutions and OpenText appear to be focussing on the Social Media and Web 2.0 space.

Convergence of Data and Content – this is happening in so many different ways. Top of the tree is Big Data as more and more people are seeing that Big Data is not just about Big Databases but about the amount of information, structured and unstructured, which is generated. Furthermore we’re seeing an increase in the world of Content Analytics and the desire to look into the unstructured world to get more intelligence from this information. This also leads to a desire to act on this information – moving us to the area of BPM which is embedded into the IM world.

Cloud – well everyone talks about it! Its still early days but we’re starting to see more and more moves towards consuming IT as a service and Content is an obvious choice to play in this space. The big vendors are still getting their heads around this area but as this progresses and the customers start to demand this more and more then we will see a change. Whilst the change will be interesting in itself I also think there will be a future challenge in how customers govern this information.

The New User – As per a recent post from Pie I don’t think this is Mobile but I also don’t think it is BYOD as we’re not seeing that happen widely enough…just yet! But there is an increased expectation from users on the IT service they receive, the way they interact with IT and the devices on which they can do this.

Demise of Portals – Strong and I don’t mean all Portals but the traditional JSR Portals are on the way out. They’re either being replace by SharePoint, see above, or more flexible architecture models. I’ve delivered a couple of programmes using the JSR Portals and they can work but its just too hard.

BPM/ACM/DCM – I don’t care what you call it but its out there. I’m of the opinion that the process is not so important but the information is the key. The need to use information to make decisions, the creation of information during the life of a ‘Case’ and the dissemination or retention of information once the process or case has been completed (I’m sure Max would say this is when the Goal(s) has been reached). The way people access, create or process this information will change but the information itself will typically remain the constant. Their is a bit of tension between the pure BPM camps and the ECM camps but we’re also seeing convergence, e.g. Kofax purchasing Singularity.

Changes in WCM – This has been coming for a while and I think the change has happened. Not so long ago the traditional ECM vendors tried to do WCM as well, the best example being EMC. Their product was suitable for only a small number of WCM Use Cases. We’re now seeing the specialist products take a firm hold in the market such as SDL, CQ5 and Fatwire. Interestingly two of those have been acquired in the past 2 years. Adobe have made a big bet on CQ5, it will be interesting to see what Oracle do with Fatwire, I would recommend keeping it separate from their UCM products.

I’m sure there are more, these are just my personal views but it just shows what happens when you take that step back to look at what is going on. There’s lots going on and the pace of change is quick.

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?

Google Chrome

Okay so nearly everyone has a view on it and I had to get mine off my chest. Speed is great, how does it render so much quicker than others? But why can I not right click and refresh!!!!!!

 

Still think this is positive though!

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.

Liferay

I’ve been busy over the past few weeks, combining project work, sales work and building up some capability within our group. Updates to this blog came low down on the priority list but I’ve got a few notes which should keep me with things to post for the next few weeks as a result of the work I’ve done.

Top of the list for me was an experience I have had with Liferay Portal. I was tasked to set up a small demo to showcase it as the content producing Portal for a back end Content and Digital Asset Management System based on Documentum. The integration became something of a crude attempt so not worth mentioning here but my experience with Liferay most certainly is.

Installation – okay so there are a few options for installation, I use Tomcat so it was a straight choice between the packaged or unpackaged version of Liferay; supported by MySQL. I elected to go for the unpackaged version as this would enable the product to run in the same container as my Documentum installation and from a management perspective decrease some of my overheads. However when getting into the installation it soon became clear why there was a packaged version! The installation procedure for the unpackaged version was lengthy and complex, and thus open to mistakes. Numerous config files were required to be updated within the Tomcat container and I could not find sample files on any of the, rather clunky, support sites/forums. After a much gnashing of teeth I actually gave up, I only wanted to see the damned thing running and to spend too long was not the most efficient use of my time. The packaged version was a breeze and was easy to switch between the native database and MySQL. We’re up and running. (I will return to the packaged version in the future but I’m going to need to sort out my tomcat installation first!)

First Steps – nice looking interface but I was a little confused on how to get really cracking. Played about with the basics before finding my way around, the documentation was not great here and a beginner’s guide to Portal Administration would be a great starter. Where I became unstuck next was in the management of pages, all the config I did appeared to be for my user account and not for general users. What I wanted was an Admin Console where I could create 3-4 sample pages with some Portlets on which would be displayed to all authenticated users; not possible during my initial investigation. Anyway, its a demo so what the heck, it will look right for the end product…right!?

Adding Portlets – so I’m resigned to a single account, well let’s see what these out of the box Portlets are like. First impressions are good, no wait, very good. Lots of choice of what look like mature and attractive looking Portlets. Did not like the icons used all the time and the interface looked a little awkward at times but that can be worked on. There was lots of choice in the Portlets and it was easy to change their names and customise their look and feel, for my demo I particularly like the XSLT translator. (Those in the Documentum know will get this, WebPublisher is great at spitting out XML and XSLT, putting these in the right places means I’m a big step towards a demo acceptable solution!)

Journal Content – further investigation show that Liferay has its own embedded Content Management solution, known as the Journal. There are a few Portlets for this, some to assist in the management of content within the Journal and others for the presentation of content. The simple management of HTML content was more than enough to get me going, however wouldn’t it be great if the content I author and manage in the Documentum could be pushed into this store for the publication out through the Portal. Next task is to fid the damned content, nothing stored on the file system but a quick check in the MySQL catalog finds the approriate table, although I did not look too hard there seemed to be little documentation on this structure and how to interact with it….I certainly did not find an API to interact with it. The HTML is stored within the database, as text. Things are looking better, simple publication from the more advanced Documentum store into the Liferay Journal store looks to be answer to my question. if only things were this simple. With a lack of documentation and an increasing focus on other parts of the demo I begrudgingly consigned this idea to the ‘would like to have’ tray, possibly to be revisited in the future. XSL translation it will be for the demo.

Summary – whilst I did not fully explore the Liferay Portal the areas where I had experience were enough for me to get a reasonable picture of the product. Big question first, would I use it again…..yes, undoubtedly but I woudl approach it with great care if I was looking to do something too complex. It appears great as a simple Portal solution and as a headstart to getting a Portal up and running it would be a good choice. The biggest problem I found was the lack of useful documentation and the poor support forums. I didn’t get round to developing Portlets for the Portal so cannot comment on the ease of depoyment, but if it is as complex as deploying the Portal container itself then I’m relieved! Nice small package, not one to take on the big boys when you’re looking for those complex multifunctional Portals but if its laregly content you’re looking for then have a look at this.

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 😉

Portal Thoughts

The current project I am working on is deliverying a Portal Framework for a public sector organisation in the UK. Previous to this I worked on a project delivering an B2E Portal for a Pharma company.

On the current project we have a number of debates between some of the techies about the value of Portals and whether we are using the product in the correct manner.

What we are doing to start with is to deliver a single Portal application and the surrounding framework. Without question if this app was all we were delivering then Portal would be the sledgehammer for the nut. This is very much a functional Portal and would possibly have been better built as a simple app for an app server. However the strategy is to supplement this with other Portals Applications which will mix content and functionality such that the Portal as a whole becomes the definitive workspace for the user population. I believe we are doing the right thing by using Portal and the debate we have had tend to get down to the gritty subject of granularity of Portlets, how do you decide when to develop the app as a single Portlet and when as a collection? We have no doubt been impacted by the immaturity of JSR 168, roll on JSR 268, but I believe we have struck a fine balance between too many Portlets with complex relationships and the snigle Portlet which would not allow users to, in the future, develop a dashboard of their ‘favourite’ Portlets.

 The dashboard concept is new to the user population and is something we need to start to address as new Portal Apps are developed…I’ll keep you posted on how this goes.

An opportunity

Welcome to my blog, this is something I have been meaning to do for a few months now and have now managed to get some time to get going.

 Anyway, now its here and here is a feel for some of the topics currently occupying my thoughts and things which I will be writing about in the coming weeks:

– EMC/Documentum OEM Edition

– ECM and Web 2.0

– Browser v Desktop

– Documentum 6

– The future of eRoom

– The value of Portals

 Quite a bit to keep me going!