There were a number of comments to my last post about whether an organisation can really attain the common goal of having a single ECM repository. Ultimately I do not believe many organisations will be able to reach this, and there are situations when they should not aim for this. One comment pointed out that a single interface is really the goal of an organisation, users do not care where the information is stored but they do want to know how to get access to it.
I then read Pie’s post on how CMIS is already affecting the market and how one organisation in particular have developed a solution which shows accessing multiple repositories through a single interface.
This is exactly where I see the market going, although I think this is a first step. Being able to search for and view all unstructured content is extremely powerful and Pie comments that the first to market is not usually the one who prevails over time, they will though get some traction in the market. Now start to expand this view, bringing structured information into this view as well. I’ve had a look at Palantir recently and this is very interesting technology, imagine the power of a solution which combines some of the visualisation of Palantir with the ability to add content to your collection. Being able to Tweet, or more likely Yam, on a suspect in a criminal case, or on a new drug development. Adding a drawing which shows how a certain part of an Energy plant works in the same view as looking at the organisational structure of that plant. Eventually people will stop accessing information through hierarchies and start to get access to information through subjects or topics, SharePoint is making a strong move in this direction in 2010. In this view of the world the Content Management platform becomes much more of an infrastructure commodity.
It would be interesting to hypothesize how this change would affect the way in which SharePoint has taken the ECM market. Whilst it is true that the UI is not the main reason why SharePoint has made this move it is still important and is a very convincing reason why people love SharePoint so much. Perhaps the power of SharePoint’s Portal approach, in my view not great but still an advantage over most ECM players, could be a compelling argument for SharePoint to continue to grow.
This may make life harder for end customers but there is every possibility that the vendor with the best, and most usable, interface, will not have the best content repository. However it will drive a lot of competition in the market and really get people thinking both about how they store their content and how they want to interact with it as well as interacting with other information sources.
Observing Content Management 
Lee, SharePoint is an expensive bore when you look at the total effort it takes to do anything that is really improving customer communications! if it wouldn’t be for the power of their marketing nobody would look at this nonsense. It is really just a proprietory, expensive development environment. it has taken some ECM market but so what. When business will want to do more things it will not be enough.
Our Papyrus Platform has a much more elegant and powerful approach but how could we outmarket Microsofts billions in advertizing and partner network. No sour grapes here .. but don’t mix up might with good, clever or practical.
What is a ‘best content repository’, please? First it is not a repository but an archive that stores instances. If you care to look it up, a repository is a development management tool. An archive is a database for blobs, so what? So CMIS makes a lot of sense to link that database to applications and we already support it. We at ISIS Papyrus see and supply ECM as just one element of a communications framework that has to encompass all inbound and outbound content on all channels, predefined and emergent processes, social collaboration, business rules mapped to data according to a business architecture.
In the end, Sharepoint is not ECM. It is a collaboration tool and maybe that makes it so interesting. You are right that storing the content is not the key capability but how it enables people to do business. So the integration with BPM and CRM is the trick.
Palantir graphics are fancy, but that does not yet make it an application that improves business operations.
Max, SharePoint is more than a collaboration tool. I do not think it is the answer to everything but for those organisations who understand their needs clearly and think that SharePoint can be ‘good enough’ then it is a very compelling solution. As you allude to though there will be situations where a customer wants to do more and this is when other ECM products will come into play. Re a repository, it most definitely is not a development management tool. A Repository is a place to put things in for safekeeping, exactly what an ECM repository is.
Palantir is in its early days but the ideas behind it will change the way we interact with information. The next wave of workers, those who are in school or in university, are used to much more dynamic and interactive ways to find and use information…the crowd will influence the next generation of IT user interfaces in the workplace.
Lee, thanks for the reply. Sharepoint and Palantir are a matter of taste and opinion. Fine, let’s go on. On repository you are simply wrong. You can look it up yourself.
Application change management is implemented through a central, virtual metadata repository. Virtual means that the entities managed in the repository are freely definable. Would the term repository not be so widely misused by the industry and analysts that is the only name we would need. A similar problem exists for the term metadata.
<repository<
1. See data dictionary.
2. The core of a CASE tool, typically a DBMS where all development documents are stored.
1. /me’t*/ or /may’t*/ or (Commonwealth) /mee’t*/ A prefix meaning one level of description higher. If X is some concept then meta-X is data about, or processes operating on, X.
2. For example, a meta-syntax is syntax for specifying syntax, meta-language is a language used to discuss language, meta-data is data about data, and meta-reasoning is reasoning about reasoning.
Source: http://www.computer-dictionary-online.org/
The common (wrong) usage is that a digital item is archived in a repository using its metadata. A repository is however clearly a development tool that stores templates and not an archive that stores instances. Metadata should describe data properties and not search criteria, which are data elements of the document content.
But you are right the use of repository is commonly for archive, but then IT calls a full-text database a Knowledge System and statistical foolishness Business Intelligence. So what’s new …
I can feel a need to clarify the term repository. I have looked it up and it confirms my earlier posting. Application Management may well be implemented through a central, virtual metadata repository but I am looking much wider than that where the repository is the store of information in a business. Typically one of many repositories.
Lee, without wanting to be a pain, but where did you look it up?
Terminoogy is essential for proper understanding.
I understand your need to look much wider but the term has been used wrongly for ages. As soon as you store data or content instances then it is no longer a repository but an ARCHIVE. An archive particularly should also verify the authenticity of the content. If the content is stored to be processed then it is not even an archive and also not a repository that should only store templates. We call it a ‘pool’. One could call it a BLOB or content database.
The problem is that there is no other term for repository as such. The main difference to normal Software Configuration Management is that is does not only manage the source code but also manages the testing and deployment into production. It also should define the metadata of the master data entities for the Business Architecture that are deployed and used by the templates.
Anyway, as it is commonly used wrong all this leads unfortunately to a lot of confusion in the marketplace. I know I won’t change it but the more people are aware of the unclear terminology maybe the confusion can be reduced. A business certainly can have multiple archives, as it has multiple databases, but it should only have ONE repository. The only thing I admit is that some archive databases have some features that are similar to repositories and that makes the confusion complete if you use it for both!
Numerous places:
http://ardictionary.com/Repository/4294
http://databases.about.com/cs/administration/g/repository.htm
http://searchoracle.techtarget.com/definition/repository
To quote but three. One of these states that a repository could be a collection of databases, that could be fine but in my the physical store is usually called the repository.
Why should we even call something an archive, it is a very outdated term in my mind as it leads to thoughts of another store. There is no reason that content cannot be stored in the same ‘place’ whether it is for short term or long term preservation, especially when the technical implementation of that may mean it moving through different storage tiers in order to reduce the cost of infrequently accessed content.
Using Software Configuration Management in this discussion is unnecessary and confusing, I am talking about Business Information.
Lee, that is fine. Those sources talk about the current use not about the meaning, except in terms of safe-keeping. It totally agree with you on the confusing part. A repository should be about applications, templates and structure and not about curent business information or instances.
The ‘outdated term’ archive is the correct term in terms of safekeeping. We stored things for safekeeping in the archive (vault). But IT needed to sound hip and expensive so now everyone stores everything in a repository and no knows what features that has or needs. You should then also call a normal database a repository, no? Oracle has a great BLOB storage capability. Hm, they actually do that.
Subject closed, I guess. I made my point and we will go on and on and on to explain the differences. Thanks for the discussion!
Hi Lee, I found your post very interesting… you may want to take a look at our CARA application (http://www.generiscorp.com/cara.html) which is a single application to access multiple repositories. Comes at it from another angle, in other words we dont so much focus on getting a single repository, but we “dont care” about the backend complexity in the sense that we provide a single UI experience to users across repositories.
James, that is exactly the right approach. The GUI is however not the only functionality as you will agree. There is a lot of process management, business rules and data interfacing that also requires a common data model.
How did you solve these issues?
Thanks for the comment James, you’ll see that I link through to the Cara product page from my post as it was of interest. I really don’t think organisations will have that one repository, bringing them together in a single interface is an easier ambition to reach.
Hi Max, Lee,
(Thanks for the link, Lee!). Good question about the parts of the repository functionality that are not (yet) part of CMIS. We took the approach that, rather than build something “restricted” to the spec of CMIS at any particular time, we would build the full repository functionality into the interface, even if this was (a) a duplication or (b) required us adding some CMIS features using our own code – for example for our first release of Alfresco, the CMIS calls for security were not yet present, so we built those, and are swapping those out in for the standard CMIS modules as they become available. This does mean additional overhead for us, but on the other hand the commercialization of something like CARA only becomes possible if you dont provide something with limitations to customers; so the CMIS evolution on the backend has to be transparent to them. Of course, this is additional work up-front, but the pay-back will be the increasing number of CMIS functions available over time.
James, we have the problem that accessing a repository and viewing a document is a NON-EVENT. That means it has no benefit as it is not connected to a business activity. What the benefit of such a GUI is you would need to explain.
I have been saying for the last then years that there is no process without content and content without process you don’t need. Even when you look up content that is archived then it is at that time connected to some process. So I dont get the benefit of a viewing access to an archive.
To me CMIS is a backend interface for a process or case management front end and nothing else.
Max, you are totally right. It all boils down to the process. Viewing as such is only important if it is part of review / approval / controlled SOP procedure or other such event.
What we focus on in CARA is the process though – we started from the examination of what companies who use Documentum or Alfresco etc do in a process (CARA actually originally stood for Content Authoring, Review and Approval, but since we extended the functionality beyond those processes, we dropped the meaning and just kept the name). Then we looked at (a) how to streamline that with reduced clicks, fewer screens, intelligent property inheritance etc, and (b) what other things they typically would want to do but couldnt because that wasnt a standard part of the platform’s native interface (advanced reporting, doing processes across multiple documents, etc).
So you are right, a simple viewing tool has little benefit (although we are going to be releasing a set of desktop gadgets/widgets to to those simple things), but it should all be driven by the processes.