Flashy GUIs versus Longterm Business Benefits

Put yourself in the shoes of the average IT user in a business department. Armed with little IT knowledge the user will make a choice based on what he sees – the user interface. Therefore software vendors sell ‘cool’ GUI looks with little solid architecture underneath. The long-term issues of maintaining enterprise applications are mostly ignored.

For Web-based document applications, Adobe owns two of the most popular plug-ins on the Internet: PDF and Flash. One can only admire them for having had the perspective to make these plug-ins free of charge and thus promote widespread use. Being free does not mean that using them saves the business money. There are several independent (which I am not despite trying) experts who see the problems of hard-coding for i.e. FLEX applications. I have pointed to their blogs in my previous posts. I on my part have long argued against hard-coded PDF (with or without the use of XML) documents. Using XML makes neither PDF nor Flash/FLEX any less complicated. The programmer has one more layer of interfacing to consider and is even further from the user, while files sizes, required bandwidth and CPU needs immediately quintuple!

For these FLASHy GUI applications a horde of programmers creates a singular hard-coded construct. Yes, I admit that today more tools are available to administer some functions but not for example the GUI in Java, AJAX or FLEX. It is like programming any other graphics environment. To compete with Papyrus many vendors renamed their control files or tables to ‘repository’. Can they define object types freely in all their features like in Papyrus? You better find out what RIA and repository means for them.

As a matter of verifyable fact, Adobe LifeCycle with FLEX does not make an application more FLEXible, but the GUI can be used in the browser. Adobe for example flogs the benefits of using the same form in PDF and FLEX, which I see of little to no value. A FLEX GUI would be dynamic while PDF does can not produce a dynamic document. It is a static page presentation language. There is however something going on within Adobe to enable PDF dynamical formatting by adding some proprietary XML. That this enhancement process is owned by a vendor makes Acrobat/PDF by definition as proprietary as Papyrus and not a standard.

Well, we could have added some triangle brackets to DOCDEF and PQL so we could call it an XML standard. But as this hurts the business by making applications slower and more CPU and network intensive we refrained. Dumping XML as a transport format for Flash GUI definitions in Papyrus EYE substantially improved performance on server and in the Flash plug-in.

ISIS Papyrus delivers such applications since 1998 using its Papyrus Client with the DOCDEF language to create dynamic documents. We are many years ahead of Adobe.  ISIS Papyrus invented the Internet correspondence market that was soon overrun by vendors with hardocded Java frontends, odd XML editors or using Word as an editor.  Analysts promote the use of ’standard’ tools such as InDesign for creating dynamic documents. It shows that they do not understand what correspondence means because InDesign has no means to create dynamically assembled documents and all document logic and data embedding has to be hand-coded.

Creating, deploying, administering and maintaining applications is where the real cost is and it is hidden behind the ‘free’ plug-ins Acrobat and Flash. Enterprise size installations of other products can easily be half a million dollars (or a lot more) in software products and possibly another million dollars in implementation coding for a sizeable installation with several hundred documents. These are my estimates and prone to error. If you have numbers that prove different I am interested to hear them. I will publish them here. The real crunch comes however with maintaining these applications. Any change in screen presentation, data interfacing, and business logic will most likely be again an expensive coding/testing exercise in most other products. An average ISIS Papyrus installation can also be half a million but it will be 250k to implement at most. The business then has total control over the application without needing programmers. With Papyrus the definitions are in the repository with maybe some scripting.

Papyrus offers definable data population into a form, allows entered data to be validated, enables digital signatures (as well as SmartCard and Biometric authentication since 2003) and rights management, and certainly allows web services to be integrated since many years. We have dynamic paginating documents in true WYSIWYG that PDF will not have for some time for Acrobat. We only generate the PDF when the dynamic pagination has been completed based on the data input and document interaction with the user. Yes, Papyrus is not dependent on FLEX but its Papyrus EYE technology is at least as powerful, but more flexible and does not require any programming.

Those vendor’s claims of full batch (structured), on-demand and interactive functionality should be considered with caution. The functionality is compared to ISIS Papyrus is limited.  You might ask whether analyst studies would not show the differences. Many comparison studies do not look at the products. Gartner and Forrester just send out EXCEL sheets to fill out. That is it. No true assessment.

So could Papyrus not also possibly be all smoke and mirrors? Sure. Which is why we always propose to do a Proof of Concept installation to verify feasability before buying anything. But as always dear vendors, I am willing to do an independently assessed heads-on comparison of product functions and long-term impact ANYTIME with ANYONE.


Butler Group: Papyrus Platform Technology Audit

I am pleased to inform you that Butler Group has announced the findings of its well-known Technology Audit for the Papyrus Platform. The process was quite lengthy and I was surprised at the depth of questions and research.  I was even more astounded when I saw the first version of the audit, because it was extremely detailed and technical. Butler Group Analyst Mike Thompson had worked into the core functions of our very broad system. I actually had to ask to use some less technical language (i.e. business objects instead of object-oriented metadata model). This research is clearly directed towards CIOs, IT experts, project managers and not the business user.

The report is either available through Butler Group or can be requested from ISIS. Here are some relevant passages from the research:

Product Analysis:
The ISIS Papyrus Communication & Process Platform (Papyrus Platform v7) is a consolidated solution that brings together Enterprise Content Management (ECM), Business Process Management (BPM), Business Rules Management (BRM), and operational Business Intelligence (BI) using data federation to create composite knowledge applications with front- and back-office collaboration.

Product Operation:
The Papyrus Platform manages a Business Architecture meta model in its central WebRepository and uses an application life-cycle change-management infrastructure to deploy the model metadata into its productive servers, portals and end-user PCs via the completely transparent Enterprise Service Bus that connects all platform nodes.

The Papyrus Platform has been designed to ease the integration with existing IT infrastructures and applications; it enables the creation of reusable objects that map processes to existing applications, and it facilitates rapid process development and immediate distributed deployment. These document and process templates are stored and deployed throughout the enterprise from the Papyrus WebRepository to mainframe, UNIX, PC, and Web environments without conversion, reprogramming, or even recompilation.

These cost-intensive integration aspects of creating process-centric service applications is all too often overlooked; as though simply abstracting the processes will somehow remove the pain of integration and mapping the process activities to underlying source systems. By using a business-architectured model, ISIS Papyrus has not only addressed many of the unanswered questions posed by BPM, but also implemented a workable solution.

Product Emphasis:
The ISIS Papyrus Platform has been designed to hide the deeply technical nature of the solution (and the problems it solves) behind a set of technologies that create an environment that is both user friendly and user valid. The solution crosses a number of boundaries and that is one of the issues that ISIS Papyrus has to overcome in moving the solution to market; it does not fit neatly into a recognised space, but that does make it any less useful nor any less relevant to the market, it is simply a question of helping the market understand the true depth of the problem.

Mike Thompson also fully understood the problem that we face with bringing a radically new solution to the market. I certainly hope that over time we will be able to make the market see that powerful business solutions do not have to be complex and difficult to implement. Nor do they need to come from the big vendors …

Sir Walter von Ockam had defined his famous ‘Occam’s Razor’: “All things being equal, the most simple solution to a problem is most probably the right one.” The Papyrus Platform is a lot simpler than most other options to implement consolidated ECM, BPM and CRM environments.

Adobe FLEX versus Papyrus EYE

Tony Byrne, analyst with CMSWatch, put out an interesting blog post about Adobe FLEX.

To summarize his perspective he says that FLEX allows vendors like EMC Documentum to create nice demoware, but cause long-term problems for the user. I absolutely agree, except that I feel similar about Ajax in terms of complexity and maintenance. We looked at FLEX and decided against it because it is pure (and not so simple) programming, therefore creating support and maintenance issues. But  one should not mix up FLEX with the Flash engine that is in many ways one of the most powerful graphic environments available.

Tony pushes his finger deeply into the user-requirement for GUIs wound. Ouch! We know that one. Business users buy GUIs and not systems or architectures. We have been fighting for user-GUI acceptance for a decade. We never managed to make it flexible and appealing and user-configurable enough. We recently tried FLEX and found it way to rigid to solve those issues in any practical way.

Others disagree with Tony, saying that it is not a problem of FLEX but what vendors implement with it. That may be partially true. I still would not want to base my customers user interface on a library of Flash plus FLEX and having to debug both. Duane from Adobe says that proper coding avoids those problems and claims that Adobe LiveCycle solves many of those support and versioning issues. Having been exposed to LiveCycle I seriously doubt that.

The only way to avoid the problems of FLEX and AJAX is to use managed life-cycle deployment for the EYE GUI components as we do with the Papyrus WebRepository. There is no Java coding required to assemble a GUI layout but just parameterizing the GUI objects in our EYE designer.


Our GUI definitions deploy transparently to QT in our PC desktop and to Flash in the browser. There are no deployment issues except that you will need a minimum level of Flash version installed. I guess that is doable. Because the communication with our Flash engine is not XML and uses an encrypted data format, the security concerns are addressed. The performance issues disappeared when we dumped XML as a transport format and created our own GUI server protocol on top of HTTP. As it happens we also have an AJAX implementation in the works but it will be less appealing, with less features.

The answer to our users is: “You can modify the UI yourself on a role-by-role basis WITHOUT CODING in a GUI design tool, and our platform safely controls the versioned deployment, so we can teach you how to adapt your GUI to your needs in just a few days.”

Our decade long fight for GUI acceptance  is over and we won it.

Papyrus EYE is several times more powerful and flexible than FLEX!

Is security finally a mainstream subject?

When we announced in 2003 that we were adding a tightly integrated security functionality into the Papyrus Platform the response was absolutely amazing.


Till today I am amazed at the lack of professionalism that such a nonchalant security attitude presents. How can any executive or IT manager simply ignore it? Now that more and more data thefts and security breaches become public maybe the tide is turning. A couple of years ago EMC bought Authentica – a 20 head startup – to do the same thing. The focus of Authentica was to secure content on remote and mobile devices. I was amazed at the time to hear that Documentum had no such functionality up to that point. EMC has acquired a long list of software products before and after that to try and get anywhere close to what the Papyrus Platform offers as a total. But it is a huge difference if you are playing mix and match or if the system as a whole employs a full security strategy.

The Role/Policy authorization of Papyrus is not just for outer shell protection – stop people from braking in – but it controls what a particular user role can do with any particular kind of object in a particular business unit. It is more than just simple access control. Papyrus also offers to properly authenticate the user by either password or SmartCard access and if necessary using Biometrics such as fingerprint readers. But that is not all. The content (actually any object) has to be protected from prying eyes by encryption even if it has been copied to the PC of an authorized user. The Papyrus Object Space database offers that facility.

Yes, EMC is compared to ISIS Papyrus a big cheese and they are still filling the holes!