Master Data for Process, Content and Relationships

I want to elaborate here on the EA to MDM and BPM, CRM, ECM relationship as discussed in my related Real World post.

My 1997 system design used a business repository as the design-end of the application platform. Any change made to the data definitions in the repository will translate to changes in all parts of the applications for CRM, CRM, BPM and SOA interfaces as soon as they are tested and deployed. We actually execute the models! I proposed the combination of inbound and outbound document management ECM with BPM in 2001. We proposed the merging of CRM and BPM in 2005.

When we change a CLASS definition (which is not C++ or Java code, but a OO model description in the repository) because for example the data definition of an SOA interface changes, then this change will be effective through all applications that use that CLASS. Therefore the integration of silos by means of SOA and Eclipse/Java to map the SOA to internal programs creates the huge ‘investments’ that stop products from being OPEN. Linking best-of-breed software with SOA will not produce a best-of-breed system. Clearly integration – and why not by means of SOA – is an essential capability for any product. We joined OASIS to be able to influence the direction of CMIS, for example. We typically install and integrate with ECM, CRM and BPM products, but SOA integration does not yet give you a common user interface and end-to-end processes.

One argument against the consolidated solution that I propose is that ‘we have a substantial investment in XXX’. So what? I am told that businesses do not want to be dependent on a single vendor and prefer OPEN and STANDARD products, when there is no such thing. People have ‘invested’ substantial amounts of gas into their cars and still go out and buy a new one. Enterprises have invested substantial amounts in ECM and still go out and buy Sharepoint, despite all its incredible limitations. Now they ‘invest’ in Sharepoint custom coding … and there is nothing OPEN about Sharepoint at all. That is the reason why we are also offering Sharepoint integration and all processes/cases defined in Papyrus can be accessed through a Sharepoint WebParts GUI.

Businesses have bought ECM, CRM, BPM and ‘you name it’ and they are always ‘locked-in’ because none of these products are OPEN in the sense that you can replace them with another OPEN solution for a reasonable effort and retain all the capabilities. Especially those products with substantial investments, because that means a lot of customizations. OPEN does never happen. Not in my pragmatic ‘real world’.

While the market is slowly waking up to the possibilities, we started to develop a consolidated solution in 1997 and installed the first large healthcare application (3500 users!) on the Papyrus Platform in the US in 2001. My tries to convince US analysts at the time that merging ECM inbound and outbound content (which are the most essential process resources not mentioned by any of the above) with BPM and CRM processes was met with blank eyes. Until we added the BPMN process view in 2009 to our state/event/rule driven processes no one was willing to even consider us BPM. And having functionality across-market fragments is too difficult to grasp for analysts, so they still don’t know where to put us …

Attaching BPMN Flows to Goals in ACM

In fact the modeling power of the Papyrus Repository is so great that anything that any DoDAF specs can be modeled. If there is graphical representation, then a view/edit frontend can be added as we did for UML, RAD Role-Acitivity Diagrams and finally BPMN. Yes, BPMN was not encoded into Papyrus, but modeled (mostly using XPDL attributes) and is executed as such. Therefore it was easy to expand it with the artifacts that represent the resources, activities, capabilities and performers of for example the high-level concepts in  DoDAF proposed by Michael zur Mühlen. We also added Balanced Scorecard strategic objectives and operational targets and linked them to the process goals.  Our customers can use the adaptive process capability to manage business innnovation programs or IT projects. I know that the business planning side can be TOP-DOWN graphically modeled in for example ARIS and you need a huge project bureaucracy to get there because of it.

With Papyrus you can MODEL AND EXECUTE inside a fairly simple adaptive process framework. The main difference is that I see the transparency for strategy coming TOP-DOWN, the customer outcomes OUTSIDE-IN, management targets INSIDE-OUT, and how to execute from the BOTTOM-UP. That substantially reduces bureuacracy and makes the business REAL-TIME ADAPTIVE.

As Craig LeClair of Forrester said to me once: ‘Max, Papyrus can’t be everything.’ My answer was: ‘Yes it can, you just can’t imagine it.’

Copying is the most sincere form of flattery!

It is quite easy to prove that ISIS went out in 2001 to talk to businesses and analysts about the idea and implemented concept in the Papyrus Platform to merge inbound and outbound communications around the related business processes. At that time everyone shrugged their shoulders. Then the IT world got bogged down by ECM, CRM, BPM, SOA and a lot of other complex environments that had to be managed by expensive and slow governance.

I have spent the better part of the last ten years to fight rigid BPM and the idea that business and economy can be expressed – and worse – executed by rules. But finally the concepts of dynamic workflow, collaboration, case management, and most importantly social networks are validating my approach. I have not been alone. Keith Swenson proposed in 1994 similar ideas of dynamic workflow. I am not saying that I was first with everything, but I was first to propose the merging of inbound/process/outbound into a consolidated case.

Finally these ideas are taking hold despite the fact the most large businesses are still not that much interested. How do I know? Very easy, because large vendors such as EMC are now (as of 2009/10) starting to propose and market exactly that concept. Do they have the software to actually do it? Yes and no.

They have the software because EMC and others have gone on a shopping spree for fitting SW vendors: BPM, ECM, CRM, CCM, XML storage, search engines and portal products were acquired. That in itself does not yet offer a solution because at first you have to make it all work together. If and when these vendors will even come close to Papyrus remains to be seen. Some integration they do via SOA, other is via Eclipse-based Java coding but all in all a complex configure-develop-assemble-deploy process is necessary to get something up and running. The promise of zero code processes is very far fetched to say the least, especially when the process inludes the terminology develop!

With EMC for example you need a lot of coding for an AJAX front end, merge it with the Archive Portal, link it with Digital Asset Management, add Web Publishing, analyse, develop, map and manage the processes into web based queues, or create a fairly complex case management scenario, SOA/Java integrate a dedicated, independent Capture suite with a different front end technology, do the same with the independent document creation suite – all just to get anywhere close to what the Papyrus Platform does out of the box!

Yes – I hear you say – but EMC is the leading vendor! Yes – I say – that much is true, but that does not make it a better product. Their technology is much older than the Papyrus Platform, that also has a good maturity of ten years development and use. Our Papyrus Objectspace has the lightweight objects from the outset that they are now marketing as an innovation. EMC and others have a huge support legacy from ten different customer bases to consider. So they have a much harder time to coordinate ten different software labs and efforts than our centralized architecture effort. And it shows. Look, I am not saying that EMC has poor products. I admire them for having gone down that road and first step up from hardware to buy Documentum and then to build their large software portfolio. But that’s all it is. A portfolio that YOU or a partner has to integrate to get a working solution.

And that is the key difference between Papyrus and all other vendors. Papyrus is a truly consolidated platform with a single application repository, a distributed database and transaction engine for archiving and execution, fully enabled for SOA and XML (despite my lack of enthusiasm about it) and certainly supporting everything you might want to call an ‘open standard’. Where EMC is struggling with the migration from ‘eRoom’ to Centerstage Ajax widgets with additional FLEX programming, Papyrus is offering the revolutionary EYE technology that maps a user defined GUI function to our QT based desktop, as well as a FLASH frontend and Ajax and Java engines in the works. Managed by the WebRepository, the business user can change the GUI without touching the process or application.

Papyrus Case Management is much more advanced than its competitors with the User-Trained Agent automated process discovery, the NLR Natural Rule Language and the Activity Recorder/Player. It makes every BPM product of this planet look old and does away with the immense BPM analysis, implementation and maintenance effort. Machine Learning based document and text classification defines the ‘State-of-the-Art’ of information capture.

Add to that the Social Networking capabilities (chat, wiki, blog) embedded in Papyrus EYE and a business suddenly no longer needs three to four different BPM products. Each business unit (process owner) can implement the way they see fit without technology restrictions or a huge project workload.

Last and certainly not least there is the deeply embedded and watertight security functionality of the Papyrus Platform, which in difference to any other vendor and product is not just a layer with outer shell protection. Papyrus does not just lock the wrong people out, but it requires each user to be authenticated with a role, policy and privilege for any action at any point.

Let me close right here and say that I appreciate the flattery, because finally it is easy to see that they are all copying our long range approach.

Innovation and Opportunity

The ISIS Papyrus Platform is one of the most innovative IT products available. Here is a list of truly unique features that have no competitor:

  1. Peer-to-Peer object-relational database and transaction engine
  2. Distributed enterprise service bus with central metadata management.
  3. Version controlled metadata repository for distributed database definitions.
  4. Deeply imbedded security and authorization concept.
  5. Automated network discovery and communication tuning.
  6. User accessible metadata repository and vocabulary for business architecture.
  7. User definable GUI with recording, training and natural language input.

Analysts such as Forrester, Butler and Strategy Partners are slowly waking up to the fact that the ISIS Papyrus Platform is a force to be reckoned with. Our competitors claim that they are more innovative, flexible and modern simply because they have been in the market shorter. A company such as ISIS simply has to be old-fashioned because it has been in business for over 20 years … I would hope that any CIO worth his money would see through that pitch, but I see business being named innovative just because they jumped on the XML/Java bandwagon. That is not innovation!

A serious software company with many satisfied customers such as ISIS has one problem: Supporting existing customers and keeping new product versions upward compatible. Also ISIS has to try to achieve that as well as possible. A new business has no customer base and therefore they can do things any way they want. But that is not yet innovation. Apple has in difference been there long and is still one of the most innovative businesses.

ISIS has not only been first in many capabilites but has always pushed the envelope. Papyrus document formatting in transactional, on-demand and interactive mode is still the most powerful and by far more capable and performant than anything using XML such as XSL-FO. The document classification of Papyrus Capture still defines the state of the art. The metadata state/event driven modelling of processes is unique and more advanced than your basic BPM Suite. The machine learning for processes is an industry first as well.

I have challenged our competitors to head-on comparisons many times and they always decline. I have asked analysts for functional comparisons and they rather go by market share. Finally I don’t understand that these products are still bought without a proof of concept installation. Try before you buy is the only approach that makes sense.

The recession offers many opportunities and more scrutiny when buying software is certainly much more in vogue. All vendors claim to be innovative so call them out and put it to the test. Just adding buzzwords to the marketing pitch is not even innovative marketing.

Analysis, Fact and Prediction

I am sitting here sipping my morning coffee in the Tradewinds Resort in St. Pete Beach, in Tampa Bay, Florida. I flew in to attend the XPLOR conference from snowed-in Boston last night where I had another fairly tiring meeting with Forrester Research.

By chance I had arrived when Forrester’s Andrew Bartels just held a presentation on the economic outlook. Following current industry estimates he believes that the IT industry will start to see growth again from the 4th quarter 2009. Well, could be. If nothing happens in between. I found more interesting that he proposes that we are at the beginning of new cycle of IT spending for applications that are ‘smart‘. I am in principle agreement because we started that with our User-Trained Agent, but the term ‘smart’ has been so oversold that it will be hard to use it that way. He then suggested that the ‘smartness’ would have to be focused on certain market verticals and here my question was why? If the software was smart enough it would adapt to the needs of the vertical. He said, it would not be that smart. But after a little discussion I came to agree that some knowledge acquired by our User-Trained Agent could be valuable within the vertical – if the business is willing to share it. Another subject to be clarified in the near future …

I have said previously that I prefer Forrester over many other analysts because they are attentive. I have met with Craig LeClair and Sheri McLeish to discuss an upcoming report on customer communications or CCM, which is an expansion of the previous DOM Document Output Management field. Craig and Sheri are very knowledgable in this arena and it was still extremely difficult to get the functionality of the immense spectrum of Papyrus across. I was my second visit because during the first one hour session there was not enough time to discuss the Papyrus Interactive and On-Demand functions. It will be very interesting to see what comes of this resarch. As we are covered by Forrester for the first time (because I had not bothered before) my expectations are low. I cannot imagine that they will let us leapfrog the ‘established’ players on our first participation no matter how good we are.

A couple of discussion points are worth sharing with you. First, Craig did say that he considers the number of installs in the US as a measure of product quality. So now you know why you will find the large players up front and it is not because they have the better product. When analysts consider market share and revenue, they rate advertizing budgets and sales tactics but not how good the product is for the user!

One point of poor rating was my sceptic stance towards the use of ‘standard’ XML. There is no reason why native use of XSL-FO would ensure higher quality and accuracy of processing than conversion to an internal format. According to Information Theory the functionality of a language such as XML is not intrinsic but defined in how the tag structure is interpreted and executed in the code. There is no difference between a conversion to internal formats or mapping one XML to another. As the meaning of XML tags is never fully defined (try to look up and understand XSL-FO descriptions!) the quality of interpretation is always limited. This is proven by the available open source XSL processors which are not compatible in function. Therefore all software vendors have their own special versions. Conditional processing, resource management, font support, multiple codepage support and external SVG charts make the use of XSL-FO a propietary affair.

There is one acceptable XML benefit that is obvious, when you are transforming into a web document. But for any serious business application you have to create an electronic original (sometimes even digitally signed) that you need to present and transmit. It is a grave mistake to accept the limitations of XML for transactional business documents for this tiny benefit. Additionally the presentation of XSL into web browsers is not standardized either. An enterprise user only gets controllable document quality by presenting to either image, AFP or PDF.

Another point Craig made was that only Adobe gets the highest mark on PDF support. I see. Thank you for admitting that PDF is still a proprietary format. Why do we not get the highest mark for being best in supporting the Papyrus Repository?

Craig also took issue with our Papyrus EYE user interface, saying the FLEX is better because there are more developers for FLEX on the market. We do not need programmers with EYE but FLEX is better because there are more programmers for it? 

George Colony, Forresters President, focuses on the other hand on a Business Architecture as the basis for tomorrows applications. Yup, that is the way to go and that’s what we supply with the UML2 models in our Papyrus WebRepository. I am bracing myself against the disappointment of Forrester rating us poorly because they can’t understand the power of our repository that are also valid for a seemingly simple communications application. But then all formatting vendors claim to have a repository, because they just call it that. AIA ITP has a directory with a couple of configuration files and a few tables with text and letter structures and they call that repository??? Get real, please. 

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.