Content Management Interoperability Services (CMIS)

Since 2001 we have been making businesses aware that there is a need for Inbound/Outbound business content to be managed in a consolidated business process with common business rules. We never saw these as separate processes.

Finally, EMC, IBM and Microsoft have announced a jointly developed specification called CMIS, which uses Web Services and Web 2.0 interfaces to enable applications to interoperate with multiple Enterprise Content Management ‚repositories‘ by different vendors. (Psst – an archive is not a repository …)

They intend to submit the CMIS specification to OASIS (Organization for the Advancement of Structured Information Standards). The ultimate goal of CMIS – Content Management Interoperability Services – is to dramatically reduce the dramatic cost for multi-vendor, multi-archive environments. Businesses spend a huge amount of time and money to create and maintain custom integration code and one-off integrations for ECM systems as we proposed for so long.

Now with CMIS we can push the clunky archive systems to the server back-end and give the business users the consolidated, easy-to-use, user front-ends for ECM, BPM and CRM with the Papyrus Platform that they actually need.

We can now use CMIS (an SOA like interface spec) to link multiple existing archives (repositories in their diction) to unlock content they already have by adding modern Web 2.0 or RIA user interfaces that exhibit the business processes (ideally trained with the UTA) and the related boundary business RULES.

We are already working to define the CMIS specification for the Papyrus Platform in sync with the available information. Because of our powerful integration features it is fairly easy to do so. As soon as our analysis is complete and we can estimate an availability date, we will officially announce support for the CMIS specification.

Encounters of The Third Kind – Analysts!

I am traveling the US North-East right now on my way to Orlando, where ISIS will be participating in the Forrester Forum.

You know from my speaking and my writing that my stance towards analysts is not overall positive. I have to admit however that especially two people have impressed me substantially – Mike Gualtieri and Mike Gilpin at Forrester Research. While I am unhappy that it costs me a lot of money to be allowed to speak to them in person, I do feel that they actually understand how and why we created a unique DBA Dynamic Business Application platform. More on my ‚Real World Blog‘.

Well, you might think, Max is now trying to flatter those guys to get good ratings in their reports. Nothing could be more wrong. I am very well known within Forrester for my outspoken opposition to some concepts and a number of report findings. I go with Nobel Laureate Robert B. Laughlin ‚I rather be true to myself and disliked than a popular coward.‘ There are other people at Forrester where to respectfully agree to disagree is the only option.

I also had a meeting with Forrester‘s Craig LeClair who had spoken at our US OpenHouse and who is working on another DOM Wave. Phew, we are going to be in it, finally. Will it be good or bad? I have no idea. The research subject of DOM seems to become broader and more complex to judge. We definitely have the broadest functionality in DOM and the strongest link to ECM but will that be seen and weighted as positive? I have seen different.

We were excluded from some Forrester reports because they did not want to ‚confuse readers by introducing new vendors‘. Hey guys, I think that the readers can handle this. They don‘t get confused by a new name! I think it was rather a case of: ‚OOPS, let‘s not admit that we missed something.‘ Good and gutsy people are not afraid of learning something new!

I met with Pete Basiliere of Gartner Group who was the first person ever there to take enough time to listen to what I had to say. Fortunately a very competent man. I am looking forward to their ADF report to come out later this year. He pointed me towards two possible misunderstandings people have about our business. He first thought that we also offer custom development, when I was referring to standard product enhancements on customer request. A substantial difference. He also wondered what we meant by ‚machine learning for process management‘ and whether that would make us eligible for an inclusion in the ADF study. I hope I was able to explain that our technology offers incredible flexibility that no one else can match. I will need to put a ‚machine learning‘ article onto Wikipedia. Apart from great guys like Pete, Gartner in my mind needs to shape up substantially and loose their stuck-up nose.

We have also been included in the upcoming Madison Advisors report on Transpromo. Madison finally put in a lot more effort and went a lot deeper than it did in previous reports. So my not so pleasant conversations with Kemal Carr about the lack of depth in previous research seem to have paid off. It is a very technical report with lots of detail but less product rating and positioning. That is the safe way to go for the analysts because it avoids a potential misrating.

That we do get misrated is nothing new. Years ago we were rated by Harvey Spencer Associates as ‚the company who wants to merge scanning and printing and no one knows why.‘  They propose that our problem (that I don‘t see)  is self-inflicted because our Inbound/Outbound Strategy makes people believe that we are just for certain turnaround documents. Hey guys, there are ONLY turnaround processes! Capture is a fragment YOU created! We are not interested in a price-war in the dying standalone Capture market but want to offer the business a much broader opportunity for process integration. To therefore exclude us from a Capture rating is no more than ignorance. Now that EMC, Oracle and other copy our idea the analysts don‘t admit that they were wrong and we were the first ones.

One analyst to really mess up was Celent. For an unknown reason they felt that they needed to rate technology in their American Insurance market study, when there is no one at Celent to even look at and in my mind understand technology. The rated our technology the lowest and in difference our application range very high and gave NO INDICATION as to why and refused to comment when asked to explain. No surprise they were recently sold off.

Fortunately European IT people do still spend time to look at products themselves to see if they fit. We will however also be in a Strategy Partners Study in Europe soon I hope. They too put in a lot of effort to look at the product, so I am hoping for a good positioning there and that some of it will rub-off on the US.

So those were my encounters with the ALIENS. Some friendly, some fiendish but in the end they are all human and prone to errors. They neither possess a crystal ball nor do they see things your way. Does all the effort that I put into the analysts pay off for the customer … hmm? It is a little bit like reading about a car in a magazine before you buy. That is fine as long as you go and try for yourself! There were a lot of negative reports on the BMW bikes compared to the Japanese for example, but when I went to test drive them – the new BMW-K1200R was the one for me, regardless.

Banana Applications?

Based on feedback I need to make something clear first: We at ISIS Papyrus NEVER provide custom code for a single customer. We deliver a STANDARD product only and all customers on a same release have the same functionality. But yes, we do expand our product functionality on request that becomes a standard feature of the next software release and is fully included in our QA and 2-3 month of regression testing.

Despite that, we recently had once again the discussion with a client as to why the ‘Papyrus Solution’ he has acquired does not work the way he needs it to work. He complained that there were lots of bugs that had to be fixed and that so much testing had to happen at the customer site. Previously people had used the joke that Papyrus was ‘banana software’ that ripened at the customer. As a matter of fact it is not the Papyrus system that has to ripen at the customer. It is the application that has to be defined the way the business needs it. And that is just the way it should be!

Why do people complain? Is the software really that unstable that it requires continuous bug-fixes at the customer site? Absolutely not. There are three situations in which customer management (usually people not involved in the project) make such comments.

First, there could be a real bug in the software. We are not gods who can create flawless code and we also can not test each and every possibility Papyrus can be used for. In 90 per cent of cases such a malfunction can be bypassed. There are in fact very few crashes in our software which has to do with the 9 compilers that it usually runs through. While GUI crashes are the most annoying to business users and impact opinion the worst, they are the least important because it is a different executable than the node kernel and does not make the system unstable.

Second, the customer makes new functionality a ‘critical requirement’ during a project. Either we expand our software or else … That means that our normal three month quality cycle can not be performed. This problem is the worst once again in Desktop and Client. It was the main reason for us to develop Papyrus EYE, so that we do not have to expand our solution for a specific project but can simply define the GUI much like we do documents and processes.

THIRD AND FOREMOST, the Papyrus Platform always runs an application that is custom-defined for the business. Yes, they build on existing frameworks of classes and rules, but the beauty of it is the managed and controllable customization concept. BUT, it still is a custom application and that is the way it should be. In many cases that custom definition was not performed by ISIS consultants but by a partner or an external consultant. When a customer now calls and says that the ‘Papyrus System’ is unstable he refers in 99.9 percent to his APPLICATION that in most cases was not defined by ISIS. So in the worst case he has a ‘BANANA APPLICATION’ that was coded by consultants in hit-and-run style and never properly tested.

Do not get me wrong. I am not trying to shift the blame here or not take responsibility. We have always made those applications work and rarely had to fix crashes to do so. The Papyrus Platform enables fast application definition but that does not mean that they can not be wrong or do not have to be tested. They need less testing and can be fixed faster, but it needs a normal project management approach. Hardly ever does a customer allow for enough time for testing. As the project is the delayed, the project deadline is not. So the testing timeslot gets shorter and shorter. That applies mostly to the adapter interfaces, because usually the Papyrus Framework is long done before the backend application can deliver test data. Are you aware that is the main reason that techies like XML files? Because it is easier to create test data by hand in XML than in some other binary format.

In a project a year ago I had to visit the customer site to calm such waves. The application had been created by a non-ISIS consultant who had no time to come back. It had worked fine, but then the customer decided to replicate it to three production nodes with linked workflow queues. It actually worked this way, but the defined queue rules were interfering with each other. Once we figured that out it was easily solved. The main problem was that the production manager would just log the bugs but had no interest to support the debugging. So they had a huge amount of problem tickets from ONE bug. Also a way to create IT jobs.

So I have to ask project managers, production managers and CIO’s to understand that there are systems and applications. If an application does not work on a platform like Papyrus it is mostly the defined application that has to be changed. If your document in MS-Word does not have the right text you don’t call Microsoft. You simply correct it. You can do the same with the Papyrus Platform because it is not complex Java programming and the changes are perfectly managed in the WebRepository.