Back in 2005 I was listening John Newton’s presentation at AIIM in Philadelphia. At some point John started to talk about history of Documentum. The way he perceived it was interesting. He tracked the idea from database (Ingres in this case) to the system which would act as a database for documents.
This “Database for Documents” concept resonated in my mind. First, it explained the software architecture of Documentum. What is more interesting, it implicitly assumed that the whole ecosystem that appeared around databases during several decades of their existence would be probably transferred in one form or another into the world of databases for documents.
This conclusion by itself did not lead us to anything useful but when we started to think about ways to visualize information architecture of SharePoint the idea of entity-relationships diagrams came up in mind.
There is a powerful mathematical theory that stands in the foundation of relational databases. There is no such theory in content management world which looks like a collection of generalized ideas that different vendors rush to implement in response to their clients requirements before trying to build a foundation for certain solution. It seems that as of today there is not enough information collected by the use of content management systems to produce such a foundation.
This way of thinking lead us to MetaVis Architect for SharePoint and its graphical notation to represent SharePoint information architecture in the form of visual entity-relationships diagrams. Database architects and developers use entity-relationships diagram for years. Our idea was to transfer this concept to modeling of SharePoint information architecture.
In a sense, it is our first approach to the issue. Which aspects did we miss so far considering ever changing nature of SharePoint and the existence of other vendors on content management market with their own approach to content management theory? Which SharePoint functions are fundamental for content management and which functions are related to the specific implementation or certain use case? The answers to these questions will come with the increasing use of SharePoint in real situations. What is your opinion?