Is Papyrus ECM, BPM, CRM, EAI or a Mashup?

In my post ‘Redefining BPM? Who wants that?’ I discussed the problem of market fragment definitions by analysts. To shorten my posts and to seperate opinion from product related discussions, I want to add the following here.

Till today, if a product does not offer a flowcharting tool it is clearly not considered BPM. The Papyrus Platform has offered the state/event driven and tool/material controlled processes mostly focused on content with Papyrus since 2001: That’s not BPM I was told. It was not yet Design-by-Doing (adaptive in Jim Sinurs (Gartner Group) diction) then, but processes could be dynamically changed at runtime. We added to that user-definable business rules in 2003, but no, that was not BPM either, but clearly it was Design-by-Doing. In 2007 we introduced the User-Trained Agent that would kick off activities based on a machine learning principle and that is Design-by-Doing ALL THE WAY. Nope, we were told by analysts and customers – no flowcharts means it is not BPM. So now we do have the BPMN designer as one option to define structured processes as well, are we now suddenly BPM? Nothing else has changed. Is that now good or bad? Should we not provide the designer so that we can be ACM? Maybe someone will now consider us ‘Pure-Play-BPM’ as well? Oh my god, the implications of that. Seriously, that whole game is utterly senseless.

Question: As soon as you empower the process owner and his team to execute any way they feel works and you get the most efficient execution, does anyone care if they use a flowchart or if it is called workflow, BPM or collaboration? Absolutely not. BPM is mostly bureauracy today and linked to inhumane Measure-to-Manage management paradigmes such as SixSigma and Balanced Score Card. If you focus on errors and numbers that’s what you get. No more. By what means would that improve outcomes for people – employees and customers? Well, it doesn’t.

So why is everyone trying to expand BPM now? They do not want to admit that possibly BPM is not the final wisdom that it was proposed to be for so long. Now, that there is a movement that they know in their guts will kill old-style BPM, they at least want to retain the name because then they won’t have to admit to have been wrong. I see history repeating itself. When we were first to introduce printer-independent, graphical design, dynamic document formatting in 1994, a customer got up really upset: “Why are you doing this? Forms worked fine and as soon as our competitors will pick this up, we will have to do it as well!” The same thing is happening now. I actually had someone ask me at the process.gov conference in Washington: “Why are you rocking the BPM boat? Once someone starts to do Adaptive Processes, we will have to follow along and all the money we spent on BPM will be wasted.” Sorry, guys – I told you so for a long time. Now the time has come.

I for my part don’t really care whether the solutions we offer with the Papyrus Platform are considered BPM, ACM, ECM, CRM, EAI or Mashups. And in fact, it should not matter to our customers either. Analysts do not make our life easier, but there are those highlights that make my day. While being stuck in Washington due to the ash cloud over Europe last week, I used the time to give a two hour LIVE-DEMO of our Papyrus Platform to Mike Gilpin and John Rymer of Forrester Research. If you look them up you will note that they cover APPLICATION DEVELOPMENT and not BPM. While they do not endorse products this way, I still want to share what they said: “Max, you told us for two years that you have implemented what Forrester calls ‘Dynamic Business Applications‘ and finally this demo has convinced us that what you do is unique and very powerful and matches with our concept.’

So what do I do now? Dump all the other TLAs and jump onto that bandwagon? I guess not. We simply will continue to spend our money to develop what our customers need and not on advertizing or bandwagons. I am pretty sure that our customers will appreciate it in the long run. Yup, I am that naive …

Advertisements

NoSQL and Elastic Caching in Papyrus

Mike Gualteri posted on his Forrester Research blog on Application Development about NoSQL and Elastic Caching. Quote: ‘The NoSQL idea is pretty simple: Not all applications need a traditional relational database management system (RDBMS) that uses SQL to perform operations on data. Rather, data can be stored and retrieved using a single key. The NoSQL products that store data using keys are called Key-Value stores (aka KV stores).’ Mike sees the difference as: ‘Ultimately, the real difference between NoSQL and elastic caching may be in-memory versus persistent storage on disk.’

I already posted about the powerful clustering and caching algorithms of the Papyrus Platform some time back. It was now interesting to read about combining NoSQL and Elastic Caching. The Papyrus Platform uses both the same concepts on the lowest layer to support the metadata repository, rule engine, and the distributed, object-relational database and transaction engine. Even the strict security layer and easy to use thick- and thin-client GUI frontend benefit from the powerful object replication and caching.

  • Reliability and Scaling: Papyrus offers the benefits of reliability and scaling through replication. Persistence and storage management concepts are defined on a per object type and node type form. Data can be spread across thousands of nodes. Also user PC’s can have their own local node and storage. Actually, that will be even true for mobile phone users once our mobile kernel will be available later this year for iPhone, WinMobile, and Symbian.
  • Fast Key-Value Access: Papyrus supports straight key-value access but also PayprusQL object-relational access (similar to Xpath), offering query and search across data in widely distributed KV storage nodes. Those can also be offline (dumped to tape or DVD).
  • Distributed execution: Papyrus executes object-state-engines and methods (implemented in PQL), events, and rules. The deployment of the application is automatic to the local node where the data is or any other chosen node. It does not take developers (clever or not) to distribute the load across multiple servers.
  • Change of data structures: Due to Papyrus WebRepository and its class versioning we can add fields to objects without the need to restructure database tables. New instances will simply have the new fields. Data storage IS NOT XML format because the performance to parse it is dreadful. Papyrus uses field-length-keyed hex-codepaged strings that can be parsed 20 times faster.
  • Latency: Papyrus can use transient objects that not saved to disk when the data does not have to be persisted. This significantly reduces the latency of data operations. In-memory operation is thus not a downside for large or persistent objects because it can be chosen per object type (class or template).
  • Reliability: Papyrus provides distributed caching with data replication algorithms to store the data on multiple nodes. If one of the nodes goes down, the load balancer in V7 will move the user session to another node and continue with the proxy objects there. A more efficient object distribution for a HA cluster will be available in Q410.
  • Scale-out: With Papyrus you add and remove nodes during operation. Currently the application can choose how the objects are distributed across nodes. The next release in Q410 will provide this distribution on system level as a part of the backup and recovery procedure.
  • Execute in data location: Using distributed code execution, developers can distribute the workload to where the data resides rather than moving the data to the application. Execution of methods on the owner node of the tool is the basic functionality. Full Distribution  is no problem with PQL.

It does not require enterprise application developers and architects to create architectures with the above features as they are embedded in the Papyrus Platform peer-to-peer kernel engine. Papyrus thus provides all the benefits of NoSQL and Elastic Caching without the technical complexity:

  • Achieve savings by reducing RDMS licenses and maintainance.
  • Add scaling layer in-front of databases, SOA or MQ messaging.
  • Build Web applications with shared session and application data.

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.

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.

Forrester Application Development & Program Management March First Look

This is my response to Forrester’s Jeffrey Hammonds March First Look:

Dear Jeffrey,

I have read your March 20th First Look several times now. For some reason I kept it in my inbox.

Now when I was about to clean it I found what was bothering me. Everyone at Forrester is talking about what the NEXT FIVE years will bring in terms of application development technology to enable change. You say that developers need to develop means to enable change, because of the fourth paradigm of SOA, rules and CEP will enable that.

What I disagree with: First, programming in the sense of coding for applications is too complex and there is nothing anyone can do to make change easier. Second, agile processes will never be delivered by coded applications and best-practice release management. It requries a life-cycle repository but that can’t be used with coded applications, because there is no 100% roundtrip from model to code and back. Third, why should anyone need to wait for five years?

You also mention that RIA will be the next big thing and here I am not in disgagreement. It should however not be a programming model like Adobe Flex which will once again resist the change you are asking for. What I see missing in most process applications is however not a cutsy web-GUI but the core information carrier – content! Business documents are not BLOBs, because they typically contain data that has to be mapped to the data models of the business process. Why does NO ONE talk about that? There is a huge amount of coding going on to integrate MS-Word and PDF and OCR-images and all that code will resist change! XML, XSL and other acronyms do not solve that problem as promised. It all requires a lot of code to work.

The future that you are talking about is here and has 200 corporate users with up to 3000 seats!
a) The ISIS Papyrus Platform has a model&rule-to-production paradigm via its WebRepository to deploy powerful versioned application models time-synchronized to any number of production servers.
b) Papyrus uses a state/event model for processes rather than an limited flowcharts.
c) Business rules can be created to control processes in terms of compliance.
d) Processes are created by teaching the complex event patterns (CEP) that define the process progression to our User-Trained Agent.
e) The metadata model of the platform is populated via the Adapters (DB, MQ, SOA) with federated business data and thus directly available to the users, content, rules, and the CEP functionality. This enables real-time business data to be used for process decision making without the need for a data warehouse.
f) Inbound and Outbound content is handled by our ECM and DOM modules and imbedded into the context of the process/case.
g) User frontend is either the configurable Papyrus Desktop our the new Papyrus EYE web presentation that uses Flash and is deployed also through the repository. In difference to Adobe Flex there is not a single iine of Java or .NET code needed to trigger a process from a business application data set, create the related content and present it to a Web front end.

There is more on our Website http://www.isis-papyrus.com and we have our OpenHouse in Dallas and Vienna coming up and you are invited to see this for yourself. We may be at the Forrester IT-Forum if things work out, so please drop by.

Sorry for budging in on you and thanks for reading this!

Freundliche Grüße,
With my best regards,
Max J. Pucher
Chief Architect ISIS Papyrus