What secret agents can teach us about Project Teams

Posted on 28/07/2011 by markjowen

I’m a fan of “secret/special agent” TV programmes.

For years. my wife and I have bought the American TV series “NCIS” on DVD, and when winter draws in, we catch up on what the NCIS team are up to.

More recently, I’ve been watching the British tv series “Spooks“, on DVD, and have just finished the first four series.

Both are enjoyable programmes. NCIS (Naval Criminal Investigative Service) is about a team of special agents led by the seemingly passive aggressive Gibbs. In his team (initially) are Caitlin, and Anthony.

Spooks is about the MI5 and deals with the trials and tribulations of being an agent of Her Majesty’s Government. There are 3 main characters – Tom Quinn, the Head of the Counter Terrorist unit in MI5, along with Zoey, and Danny, two junior case operators.

While watching these, one thing became really obvious to me. A good project team does not rely on its stars. In NCIS they started with three main characters. And at the end of the second series, one of these 3 gets killed. Does that mean the end of the show? No – they hired someone else to become a main (totally different) character.

And Spooks goes even further, In the second episode, one of the “regular” characters gets killed. Then, at the end of the 2nd series, Quinn gets killed off. Bam! The lead character. And then before the third series has finished, the other two get killed off as well. And the series just kept going. New characters were introduced – each bringing something different to the mix.

A good team is like this. It shouldn’t rely on its stars. The people making up the team each add value, but should never be irreplaceable.

CMIS is here … but where?

SharePoint “Upgrades” and discovering ...

The true value of CMIS

CMIS is here … but where?

Posted on 23/07/2011 by markjowen

Note – this post is in a draft format. It was written in June 2010 and was never published. The information in this post is not complete.
I have released it now as part of my AIIM CMIS Product Guide post.

CMIS 1.0 was ratified in the beginning of May 2010. This is the standard that will allow interoperability between the various content management systems that are currently on the market. For more information on CMIS, refer my Small Brain Notes on CMIS. Go and read it now, and when you are finished, click on the back button. I’ll be waiting…

Ok – now that you understand a bit of what CMIS will offer, let’s ask the question – when will it be available in these disparate content electronic content management systems?

Let’s look at the list of companies that were associated with the creation on CMIS 1.0

And…who is ready for CMIS?

Founders

ECM – EMC have stated that Documentum 6.7 is CMIS complant. This is due out in 2011.
Microsoft,k
IBM
- Have released a servlet that sits on Websphere. This allows CMIS clients to access IBM FileNet and IBM Content Manager repositories. (http://www.ibm.com/developerworks/data/downloads/cmistechpreview/index.html).
- IBM are also

These three were there in the beginning, and developed the initial draft.

Reviewers

The following companies also played a part in the moulding and shaping of the CMIS standard:

Alfresco – Version 3.3 (available now)
Open Text,
Oracle,
SAP

Others Adapting their systems to be CMIS compliant:

ASG Software Solutions
Content Technologies ApS
Day Software
Ektron
ESoCE-NET
Exalead, Inc.
FatWire
Flatiron Solutions Corporation
Greenbytes GmbH
Harris Corporation
Nuxeo
Saperion AG
Sun Microsystems
Vignette Corporatio

Here is a list of the vendors with regards CMIS compliance.

Vendor	Product	CMIS Support Timeline
Alfresco	Alfresco 3.2	Available for testing
EMC	Documentum	First half of 2010
IBM	Content Manager	Second First half of 2010
IBM	FileNet P8	Second First half of 2010
KnowledgeTree	KnowledgeTree 3.7	Available for testing
Microsoft	SharePoint Server 2010	First half of 2010
Nuxeo	Nuxeo DMS 5.3	Available for testing
Open Text	Enterprise Library Services (ELS-Beta)	CMIS connector available now
Open Text	Open Text ECM 10	Mid 2010
Oracle	Oracle Universal Content Management	Not known
SAP	SAP DMS	Not known
Sense/Net	Sense/Net 6.0	Available for testing

AIIM’s CMIS Product Guide!!! (markjowen.com)

FirstDoc User Group – Vienna

CMIS – what are the adoption plans for 2011?

Momentum Lisbon – Virtual Momentum.

Momentum – another year – another set ...

SharePoint “Upgrades” and discovering ...

Trad ECM is so out-of-touch

EMC Momentum – Day 1

FirstDoc User Group 2011 – a look back at th...

SharePoint “Upgrades” and discovering a small compatibility issue.

Posted on 01/03/2011 by markjowen

Recently a friend of mine was working on creating a Document Management portal.

That is, he was using SharePoint as the user interface, and was populating the pages with web parts that would allow the user to interact with a back-end document management system.

He had built up the Portal using SharePoint 2007, and had created several sub-sites that contain web parts that were relevant to the requirements of specific groups of users. He had run some informal testing and had confirmed that the web parts were offering the business users the functionality that they required. He had also spent some time on the design of each page. He was using a standard master page so that each sub-site had the same look and feel, but had made small tweaks to each page so that the presentation of the web parts was optimal.

Then he wanted to move the system to a SharePoint 2010 system. Fortunately the Portal site was not yet in use, and nothing extra, or unknown, had been done to the sites, so was pretty sure there wasn’t any customization. However he wasn’t sure what the best way to get his Portal from 2007 to 2010. So he called me.

We had a look at the options:

In-place upgrade,
Database Attach
Build the site from scratch.

SharePoint 2010 had already been installed on a new, suitably spec’d server, so an in-place upgrade was not an option.

We examined the database attach method. This would involve making a backup of the 2007 content database, restoring it in the new SQL Server installation on the the new server, This sounded like a good option. The only thing we were worried about was the third-party we parts (the ones that hooked into the third-part document management system). We weren’t quite sure how these were going to respond.

We considered the third option – building the site from scratch on SP2010. This also introduced new challenges. Could we migrate the default. master from 2007 to 2010? I knew that 2010 didn’t use default.master, but now used v4.master. What impact would that have? We also had the ribbon to contend with, as well as the “Tags & Notes”, and “I like it” buttons. (The sites were meant to be static, offering only the ability of users to work with their documents. It was not meant to be a “social” site.)

One other benefit of an in-place, or database attach upgrade, was the fact that SharePoint 2010 offered a “Visual Upgrade”. That is, the 2007 look and feel is maintained, and there was the ability to “preview” how the sites would look in 2010. Once you were happy with them, you could make the changes permanent.

This would have been nice, but, because of the fact that we wanted to make sure that we could document how the Portal was built up, we decided that option 3 would be the best option.

So – the decision was made. The first step was to install the third-party web parts. And this is where it got interesting. We were using the latest version of these web parts that were SharePoint 2010 compatible, so we thought there would be no problem.

Except there was one small thing…

The third-party web parts were designed to use WSE. WSE, or Web Services Enhancements, is an add-on to the .NET framework that offers improvements to security and communication. It was released in 2005. The SharePoint server had been installed by another department according to a “standard”, and this included WCF, or Windows Communication Foundation. WCF was brought out as the “next-generation web service/interoperability framework”.

So here was the question: Do we get the department that installed the SharePoint server to uninstall WCF, and install WSE? Or do we ask the vendor to test, and certify that their web part technology will work with WCF?

Removing WCF and installing WSE would have very little impact to the overall scheme of things (the server was not being used for anything else), BUT it would mean a non standard installation.

On the other hand, the vendor has stated that their application was compatible with SP2010, and one would assume that it would be designed to use the newer WCF component.

Currently the discussion is going back and forth between the two options.

One thing though, this small compatibility issue wouldn’t have become quite so obvious if we had not decided to build up the Portal from scratch.

Related material:

Determine upgrade approach (SharePoint Server 2010)
Interoperability between WCF and WSE 3.0
What’s New in WSE Version 3.0
What Is Windows Communication Foundation

——————————————————————————–

FirstDoc User Group 2011 – a look back at th...

What secret agents can teach us about Project Team...

The 12 Networking Truths as applied to SharePoint ...

Killa Hertz & The Case of the Missing Documen...

Killa Hertz & The Case of the Missing Documen...

“Selling” something new to the users &...

In SharePoint, where the heck do I fit in? ECM spe...

Will IT actually help? – A response to Dux

The true value of CMIS

Posted on 03/06/2010 by markjowen

In this post, I delve into the true value that CMIS will dish up to the ECM world.

Improve Interoperability

John Newton has written a blog called “Irrational Exuberance on CMIS?“

In it he describes how he…

“… believes CMIS can transform the ECM industry, allow for significant growth and spawn whole new companies and markets.”

John was on the CMIS panel at AIIM and relates how others on the panel didn’t have the same enthusiasm for CMIS as he did.

(Before I go any further -if your asking “What the heck is CMIS?”, I recommend you click on this link and read what Wikipedia have to say about it.)

True Value of CMIS

I agree with John’s comment in his post – CMIS isn’t going to expose all the functionality of the various ECM systems, but it will improve interoperability, and this will be BIG.

A document management’s repository will now be accessible. Not only through the client for the specific enterprise content management system, but also from other enterprise content management systems.

Is there a hidden agenda?

This is great news! I am really stoked about this. I think that it has great advantages.

However, the cynical part of me looks at this, and thinks “Hmm..”. Why?

Because the cynical part of me understands that Microsoft was one of the first companies involved in the CMIS initiative.

And if you were trying to sell a wonderful new system such as SharePoint, one of the biggest hurdles for companies will be the fact that a lot of companies will have many, many documents stored in costly, established ECMS.

The fact is – SharePoint is a great application. It provides a wonderfully customizable, familiar user interface, and is great for collaboration. It is also quite good at being an ECM system (with SharePoint 2010 starting to show some real teeth), but companies are unable to just dump their existing ECMS (which usually meets the particular requirements of the business grandly) and switch to a new Microsoft product. There is usually too much tied up in licence costs, as well as processes, and the cost of a migration is something that cannot be taken on without a great deal of planning, and soul-searching.

However, if there was a way that SharePoint could “easily” talk with the existing ECM in a friendly way, it suddenly becomes a lot more attractive. A SharePoint interface could be created that allows users to work in a way that is familiar while connecting to content stored in the existing, built-for-purpose ECM system. The value of Microsoft’s application has increased.

And further to this, with CMIS, there is the opportunity for new applications that can take advantage of the ability to interoperate with multiple disparate Enterprise Content Management system.

This means that the repository will no longer be the silo.