Papyrus ACM embeds goal-oriented BPM methdology

On the subject of Papyrus ACM versus BPM, there are a lot of misunderstandings and misconceptions and some intentional misinformation. When businesses ask about ACM, everyone wants to be ACM, but when I try to define what it actually is, no one wants to truly participate to not be suddenly left out in the feature checklist. A similar thing happens when we try to distinguish what ACM is in difference to other TLA’s and most commonly to BPM. No one wants to alienate the BPM crowd, analysts, consultants and IT architects alike. Everyone chickens out, and is to afraid to have an opinion. We are all buddies, it is all good and we sell it all because obviously customers need it all. ‘We convince others with our passion and ideas.’ Wishy-washy nonsense. You are not standing up for anything. I admire Adam Dean, because he had the guts to say: ‘This is what I think about ACM compared to BPM.’ Great! Stand up and fight! Let’s have a discussion, but let’s not get personal. People attack other people directly as a matter of last resort. They have no other arguments left. Just like in a political campaign. And there is a lot of politics in the ACM versus BPM debate as well.

Yes, I am passionate about my ideas too and my idea is that BPMS-flowcharting (note the ‘S’ for suite or software) is a flawed concept applied to anything more but the most simple, banal process needs. Why should I not say that? I would have to say: ‘While flowcharts are good we developed something else anyway.’ Absolutely not. Why not compare? Where would Apple be today without the hilarious adverts of two guys posing as Macs and Windows PCs? Where would Oracle be without its blunt, full-page adds with checklist comparisons to its competitors? Get a grip on life people, its competitive! All experts who blog are selling themselves too as experts in their fields. For scientists too its either publish or perish! Others post on LinkedIn to find a better job. Let’s stop this pretense and simply be openly and honestly competitive.

It is no secret that I am the Chief Architect and co-owner of a successful, established enterprise software business. There is full disclosure. I don’t sell what I have, but I develop what I propose to be the best solution for my prospective enterprise customers. Like Apple, I don’t develop according to market research. Customers always just ask for more features in a product, but they won’t ask for a new solution they can’t imagine. Nevertheless we are extremely customer-oriented, because there are no hard-coded applications that we deliver. All our out-of-the-box capability is modelled and can be configured and changed without programming!

We are in many ways like Apple, just that we aren’t in a mass market. Apple owns the complete stack of functionality and can control it. The ISIS Papyrus Platform owns the complete stack and can control it too. But then you are not OPEN and STANDARD I am told, but neither is Apple! You can buy BMWs and Superyachts as accessories to the proprietary iPod/iPhone plug! Openness must not be about providing open technology interfaces, but about opening solution functionality to the business users. We use SOA or anything else that will provide data. We can read or create any XML file, but so what? Standards must not be about some XML files that users could not care less about, but giving a standard user interaction to all business users for a consolidated customer experience in the organization. Give them the ability to create processes on the fly without going through a technical and management bureaucracy.

But we aren’t even talking about product features. The subject is a very principal question. Do you want to put your people and business into a flow-charted straightjacket or not? Yes, go for BPMS flowcharts. No? You need something that empowers the business user for goals and outcomes, but not just in theoretical Balanced Scorecards and Powerpoints and then monitor some disconnected KPIs. Real-world, real-time, real product! Maybe some BPMS can do that too? Great, show me!

As an example, here is a segment of a ‘Purchase to Pay’ end-to-end process created in just a few hours by a non-technical person using the ACM capabilites and goal-oriented processes. (To watch the video in high-resolution, don’t forget to press HD in the right upper corner and then switch to full-screen in the right lower corner.)

Let me close by saying that Papyrus ACM is certainly not anti-BPM, because my solution proposal clearly focuses on PROCESS OUTCOMES. We also have a BPMN compliant flowchart editor, but I am also clearly saying that one cannot guarantee outcomes in customer interaction with rigid processes. You can certainly put a lot of BPM governance bureaucracy in place to manage the analysis and design BEFORE execution and the monitoring and optimization AFTER execution, but what it really needs is that both are moved INTO execution. And that is the key difference between ACM and BPM, while ACM also follows the BPM principles. What I am personally opposed to is to try and map how your business works into low-level, step-by-step flowcharts. But if that’s what you  really want to do, you can do that with our Papyrus platform too and you have all the master data, content, event and rule handling included for free. You don’t like that? Well, enjoy your integration projects!

The final point to make is that we are just talking about silly acronyms. I wish we would not need to, but it is the market fragmentation by analysts that causes it. There is also the wish of some businesses to be given simplistic choices so they don’t have to understand what they are buying. I suggest to focus on real-world business needs and not the assumed scope of an acronym. There are thousands of BPM methodology messiahs who have a serious problem with how BPMS technology is used. I am no different. I just propose a technology solution to the problems and that’s where the conflict with other vendors comes in. So its really just a storm in a waterglass.


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 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 …

Mastering The Unpredictable

Recently I co-authored a book on ACM Adaptive Case Management.

Many current implementations of process and case management solutions are at odds with modern management concepts. While that applies to all workers, it is especially relevant for highly skilled knowledge workers. Motivation is achieved by empowering people to be valuable team members rather than through command-and-control-oriented process implementations. Adaptive case management sits at the center of gravity for process, content, and customer relationship management and therefore plays a key role for effective execution toward business goals.

While ACM is about bringing the benefits of adaptability to existing knowledge workers, I propose to expand that into “Adaptive Process” that combined with an empowerment management paradigm turns more production workers into knowledge workers rather than just automating the production workers’ work.

There is an obvious need for dynamic processes that BPMS vendors are already addressing. The reality of BPM shows that it is very difficult to top-down analyze and simulate business processes and link them to KPIs in a continuous improvement cycle. Measure-to-manage optimization is counterproductive to improvement and innovation. Only empowered actors can use their intuition and experience for sensible action. The dynamics of economy require a self-organizing structure that is resilient to fast changes through its ability to adapt.

Agility cannot be enforced by methodology, and it is not a product feature. It can only be achieved through the agile mindset of management who will put the right technology in place that empowers agile employees. Process maturity is not about how well processes control employees, but how much process control is given to employees to achieve goals and outcomes.

Adaptive process technology exposes structured (business data) and unstructured (content) information to the members of structured (business) and unstructured (social) organizations to securely execute—and continuously adapt with knowledge interactively gathered during execution—structured (process) and unstructured (case) work in a transparent and auditable manner.

You can find all about it here: ‘Mastering The Unpredictable’

BPMN/XPDL Execution in Papyrus

Those who follow my blogs might already be bored with my frequent bickering about process management. That I am not the only one to criticize the BPM market you can read in Terry Tschurter’s paper on the BPM State of the Nation 2009.

The worst thing I could do is to complain about something that I do not know much about. Therefore I would like to show to you that we at ISIS Papyrus are no strangers process management concepts, as easily proven by this announcement of the BPMN/XPDL Editor of our Papyrus Platform. I will not go into the details of either BPMN and XPDL here.

Keith Swenson is the authority on XPDL and BPMN and covers the relationship in this post: The Diagram is the meaning.

Let me just say that BPMN is a modeling notation for designing processes and XPDL is a superset that also contains graphical features of the actual drawing. Therefore we decided to cover both in the Papyrus Platform. Why did we do that if I am so opposed to BPM? As you might know, my opposition is mostly related to the huge, disconnected analysis and optimization process bureaucracy. Therefore we defined standard BPMN/XPDL to be used as execution engine:

BPMN/XPDL in the Papyrus Platform can be created and edited while you work and executed AS-IS.

It is fully executable by linking with the UML data models, content artifacts and Natural Language Rules defined in our Papyrus WebRepository. Also BPMN/XPDL is stored in the WebRepository using Papyrus’ change management and automatic, distributed deployment capability. All additional logic necessary is cleanly encapsulated in those classes and is not created during BPMN conversion into BPEL or by expansion with Java. BPMN in Papyrus is mostly used to define sub-processes in our Adaptive Process concept. The user interface is handled by our Papyrus EYE widgets so there is no XSD/XSLT mapping and Ajax forms programming. The business data are simply accessed through the UML classes linked to our Service Adapters (SOA and others). Finally, BPMN can be used in an Adaptive Process environment and allow 100% runtime editing.

Here is the Papyrus Platform BPMN/XPDL 2.0 Designer:

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.

Papyrus Application Scalability

Many Papyrus Platform installations have recently grown substantially and therefore means of application scalability have become a common subject. The principal scalability of the Papyrus Platform is unlimited due to its peer-to-peer cluster design but it is restricted by the synchronicity needs of the application. Simply reading or displaying documents or content from storage has no limitation, but keeping multiple write accesses in sync creates scalability issues. Clearly, when the number of users is doubled from 1000 to 2000 users then it does require monitoring and if necessary scaling the HW. When the number of documents or process tasks is doubled from 1000 to 2000 per hour that also requires consideration ow that load can be safely spread across server nodes.

Scaling Papyrus Platform applications is very simple compared to for example three-tiered Web/Java/SQL/SOA application clusters. A more detailed discussion of Java Application scalability I have posted on my ‘Real World’ blog.

User complaints that the ‘application is slow’ without any details being measured are not helpful but have to be taken seriously. Often the user has no means to understand that the processing requirements for similar looking documents can differ substantially. The document might be simple for the user but the backend process can be fairly complex. We propose that proactive monitoring is established. The Papyrus Platform has all the means for such monitoring available.  Simple dashboards can be created and summary reports are available.

Scalability is not only about tuning or maintaining an acceptable response time for a growing number of users. It is unreasonable to expect that the system will handle growth in users and transactions automatically. No system does. Papyrus has many load balancing and tuning options and many are set either by default or by the system. We found that some automatic functions had to be changed for weak networks or when growth was not gradual but for example many users, nodes or new documents and processes were added at once. That is related to the automatic version control and deployment of the Papyrus Platform.

Document application are a complicated conglomerate of GUI, process, and rule execution threads that read and write data from a number of service interfaces or databases. The performance of the SOA backend service interfaces or the database is much more relevant to the scalability than the user front end. Using common database or transaction measurements the Papyrus Platform executes millions of transaction per hour. That is however irrelevant. The question is how that translates into user experience!

The following measurements are used to define the quality of scalability:

1) IRT – Initial Response Time: from request to first usable feedback

2) TRT – Total Response Time: from request to completed function

3) SRP – Service Processing Time: the time the request is actively being processed

4) SQT – Service Queuing Time: the time the request waits for processing

5) ATT – Average Transaction Throughput: transactions performed in a time window

These values can not be taken from the system itself but the measurement of user experience has to be defined in the application. In a multi-tiered Java application that is practically impossible. A screen refresh may or may not be connected to a previous user entry. Papyrus assigns a JOB-ID to each user data entry and enables the tracing through all the functions and servers. A JOB-ID will now trigger the five above measurement points and thus enable a real-world measurement. It is planned to provide a ‘User Experience Dashboard’ for each user that will display a kind of ‘VitalSigns’ statistics for real-time feedback.

The Papyrus Platform uses the Application Performance Analyzer or APA to measure those values and relate them to the general statistical data about CPU, I/O and RAM usage.

APA Tuning and Monitoring

APA offers a unique level of insight across all application functions from the user click on the desktop or portal to the final display. Next to the elapsed time measurements, the measurement of resource usage is the key to understanding and tuning. How much CPU, RAM, disk I/O and network bandwidth is consumed per transaction and in total has to be known for tuning.

Web/Java/SOA applications have substantial overhead for sticky-load-balancing, transaction-safe Java caching and database clustering, and parsing and validating the XML data for SOA data communication. Rather than the immense complexity of clustering multi-layered caches – with multiple conversion from tables to cache pages to objects and reverse – the Papyrus Platform collapses the horizontal structures and work with a purely (vertical) object model from definition to storage. The proxy replication mechanism of the Papyrus Platform uses a partitioned caching concept where there is always a unique data owner and each server node uses a replicated copy that is either pull or push updated. The objects do not have to be de/serialized as they are cached/replicated/binary-stored as is. The same object caching mechanism works transparently for all objects regardless whether they are populated via Web services, external databases or from the Papyrus objectspace.

As a consequence of this future proof design the Papyrus Platform can scale linearly as servers and nodes are added to the application clusters. It is however important to segment the database properly. Papyrus provides transparent object access and search across any number of nodes without any changes to an application. it is important to understand that even with a powerful system such as Papyrus the application has to be defined scalable as much as the system.

Forrester’s Henry Peyret on EA Evolution

This is my response to a Forrester publication on Enterprise Architecture Evolution:

Quote: “The recently published Forrester Wave™ on enterprise architecture (EA) tools demonstrates that the real benefit of these tools is not in the modeling itself, but in the modeling that supports real EA objectives — such as knowledge-sharing, collaboration on standards, and providing aggregated dashboards that help decision-makers choose from different scenarios.”

I happen to not fully agree because while all the above is important the EA tools proposed are outside the actual application and purely in the development environment. Evolution is however an internal function of the execution itself. Here my response:

Henry, interesting subject indeed!!! But does the term EVOLUTION not imply a seamless functionality within the application system? Nature seems to evolve without someone performing simulation and analysis and then makes an assumption as to which changes might bring an improvement? Well, we could have a religious discussion here on ‘Intelligent Design’ but let’s stay away from that. Evolution works by taking fitness information straight from the execution and feeding it right back into the next cycle of execution. Darwin was even apparently wrong that fitness happens by chance because he was not aware of the functionality of GENE EXPRESSION. Genes do not have to change to improve the design, they just have to be expressed in a more fitting way.

We need to do the same with software! Analysis, simulation and monitoring are NOT AGILE, Henry! They are just little less rigid. In any case I propose that no-one wants or needs rigid processes no matter how well analyzed or simulated! Simulation is guess work and yes, using the Monte Carlo method the guess work can be optimized but it still is a ‘gamble’ (sic). Las Vegas calling. Business needs an environment in which processes – and applications representing those – tune themselves with fitness information coming straight from user interaction in real-time into the next execution cycle.

This is what the Papyrus Platform does with its User-Trained Agent. Let the users do their work and feed real-time performance data right back into the execution environment to improve the processes by discovering decision patterns based from user interaction. Analysis and simulation are – like process I might add – outdated concepts from manufacturing. Running a business well is not manufacturing, it is about empowering the business user to service the customer and not by putting BOTH into a process straight jacket.