One repository to rule them all?

This post is in response to a number of tweets which were going around a week or so ago from the likes of Pie and Lee. The questions which were being discussed were around what is a platform and what is a system. It actually resonated with something else which was going around in my mind for the past few weeks which I wanted to get down and out to the wider world.

I’ve seen a number of times now where vendors are pushing for their Content Management product to be the repository platform for a particular organisation, being able to handle all types of unstructured content. I’ve spoken about this myself with customers and I think there are a lot of advantages to this approach, not least the cost and the simplicity of maintaining a single stack. However there are times when an organisation will have multiple repositories and for good reason.

I was starting to consider which model works best. One thing I considered was the approach to Databases, organisations do not tend to have all their structured data in a single repository but will have multiple different repositories within the organisation which are aligned to specific applications. Admittedly organisations will strive to standardise on a database vendor but the reality is that they will have many, many databases within the organisation with lots of information, sometimes overlapping, sometimes contradictory. In fact this multitude of data has seen the rise of Master Data Management, to help organisations understand which data is the truth, and Data Warehousing where organisations can start to aggregate this data, largely for reporting purposes.

In more recent years we have seen this data made available through a Service Oriented Architecture, where the data and the behaviours associated with it are combined to form services.

So what does this all mean for Content Management? Is it any different from structured data management? And what the hell has this got to do with the discussion on what is a platform and what is a system?

To begin with I cannot see the one repository to rule them all being the way in which organisations go. In fact the recent announcement of EMC’s partnership with Fatwire led to a similar comment from Stephen Powers of Forrester. Further to this we will always see content which is not stored within a single repository, it could be on file shares, it could be within emails, it could be within one of the 2 or 3 different content repositories the organisation use. (Whilst standardisation of technology can be good there are times when having a low cost and easy to use content management system alongside a more feature rich, yet more expensive solution, can be the way forward)

Okay so if we believe that there will not be the one repository to rule them all, where does this leave us? Well I believe it leaves us looking towards the more SOA based view of the world. The repositories expose their content and features which can then be managed through a single layer…this is the platform. When a user works on a piece of content they simply save it with the information needed to identify it, the behaviours they expect of that content and the security rules of that content. The platform layer will then decide which repository to use to store and manage the content. Alternatively users will be able to access a specific system direct in much the way they do now through the SharePoint or Documentum Webtop UI.

This platform layer will be able to interpret and understand what content is available within an organisation and how that content should be treated. This starts to raise other questions such as where does the BPM capability reside and where should content retention be performed? Well this is where I think the platform layer starts to come into its own. For content Retention, read Information retention. It strikes me that in the unstructured world we are well versed in the need to manage and dispose of information appropriately, I am not too sure this is the case in the structured world. This is wrong, the majority of the time the reason for a piece of information being kept or being disposed is due to some of the structured data e.g. customer information, including correspondence, will be based on how long that individual remains a customer, plus whatever period must be added. Similarly in criminal investigations, it is generally related to a date related to the case, be it the court date, charge date or even release date. The simplicity of having a rule where all information stored about an entity (I use the term loosely here) must be retained or can be disposed of should not be overlooked. This leads me on to the question of BPM, similarly a lot of rules which are used and evaluated in the execution of a business process are related to structured information. Many times I have found myself in a position where I need access to some structured information in order to put a rule in a business process. Yes there are solutions to this, e.g. JDBC access to a database form within the Content Management BPM engine, it always seems to be very closely tied to one view or another…whereas it is more important to consider the business process at a slightly more abstract layer which can be easily decoupled from the content repository.

Now this concept may be some way off being achieved but there are two things which lead me to believe it is where we need to be, Cloud Computing and CMIS:

– Cloud Computing. As we start to see more and more organisations put “some” of their content in the cloud the need to understand where their distributed content is will become stronger. I think it ambitious that an organisation will put all their content in the cloud but the lower value content will certainly start to find its way to such a solution. The important thing is that end users do not give a hoot where the content is, they want to know about the content.

– CMIS. It remains early days but the I predict we will see take up of this standard which is wider than the traditional CMS vendors. The more products out there which expose their content through CMIS will make it more likely that a vendor will develop a platform which uses this commonality to provide the functionality I describe above.

I’ll post again in the future as I see this being expanded into some of the Web 2.0 features which exists, plus some discussion on visualisation of all this information.

Advertisements

Pie’s Application Separation

Interestingly when I first read Pie’s tweet to advertise this post I thought it was going to be focussed on Content Enabling applications. I suppose it is but some of the applications he talks about content enabling are very close to the platform services being provided, e.g. WebPublisher and Centerstage. Does this mean I think it is wrong? No, not at all. Pie has exposed a model which is very interesting. With the Core Server customers would buy the platform and a way to interact with the basic services the platform provides, it would be interesting to understand where the line is drawn on Basic Content Services…e.g. is MOSS in this group?

For Applications Pie adds the likes of WebPublisher and Centerstage, the Documentum apps. In this space I see some separation between these style of products and the more vertically focussed implementations. Something more akin to:

– Extended Content Applications – those applications which are still focussed on providing horizontal content solutions but with enriched services focussed on a specific ECM Use Case such as Web Content Managment or Digital Asset Management;

– Business Solution Content Applications – those applications which are taking a specific business solution where there is a need to interact with unstructured content and providing the application to perform these tasks;

It is the latter which I am becoming increasingly interested in, I’m making some notes on a post about Case Management which I hope to post this side of Christmas.

So will Pie’s model work? Yes. Do I think the market is ready for this? Not yet, and I think it is the vendors who are the farthest away from this concept although CMIS should provide a vehicle for them to provide this. Take Documentum for example, with their CMIS release they have some very basic content services which they can expose…the decision they need to make now is which services form the rest of the platform services and how can they expose these in a way which enables CMIS to develop.

There is also a certain amount of kudos which is taken from having your app used by customers at the front end, moving ECM closer to being an infrastructure may not be something the vendors will necessarily embrace. But then how many times will you hear people say things such as “Documentum is a really annoying product” (Quote taken from a quick search of Twitter for Documentum)? The answer is quite high, and this is something which creates a poor reflection on Documentum as the users are typically complaining about the way they interact with the services and not necessarily the services themselves.

Any vendor that can shape themselves to providing the most scalable, performant, secure and compliant unstructured store which provides a rich set of services which can be used will be one step to establishing a differentiator for themselves. The second step will be to get a strong strategy of working with partners to use those services in business focussed applications such as Contract Management, Case Management and Purchase to Pay applications.

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.

Opportunities

So I’ve been doing some more thinking about the opportunities which will be brought about from the CMIS announcement. (I’ve also had a read through the Domain Model spec and will comment on that in the future). Where is the value in all this going to be? Probably the key question being asked right now. I’m not thinking technical here, at the end of the day your average employee will not give a damn about the fact that their systems now interact via REST, we can save that for the technologists amongst us.

My belief is that, when this comes to fruition, it will enable providers, be they SI’s or vendors, to provide more template based applications, the process templates which will underpin their core activities. By having the templates defined, configurable and reusable, customers will soon be able to focus on these business processes rather than the complexity of the integration with their underlying systems.

Consider a New Starter process where the offer letter is correspondence stored in one ECM system but the Induction Booklet is stored in another; the process definition could be consistent but the activites requiring interaction become more service based. Activities, or Services, become reusable from one organisation to another, regardless of the technology; a big step towards adding value through Service Oriented Architecture.

Organisations who grasp these opportunities will steal a march on others and lead the adoption of the standard as and when it becomes more widely available. These do not necessarily need to be ECM experts, but are more likely to be those who can add value to the operation of the business through increasing efficiency, reducing costs, improving rate to market etc… At the end of the day we are here to improve businesses, CMIS could be a big step in this direction.

SOA Conversation

So I was on the train the other day when I overheard a conversation between two IT professionals. One was a young budding Web Developer and other a more experienced technician. I didn’t listen in on purpose but my ears pricked up when they started on one subject.

Budding Developer – ‘So you must be considering SOA then…?’

Old Hack – ‘Yes, its something we muct look into.’

Budding Developer – ‘So what product are you using then?’

I didn’t say anything but it does surprise me that people still think putting in a product gives you an SOA. Its not about a product, its about an approach and how you design and build your business services and relate these to the IT services you provide. If the ideas I heard continue then this will become another failure in IT, unfortunately it won’t be the idea/paradigm which is the problem but the implementation and understanding of it.

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.