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.

Advertisements

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.’

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 …

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:

Mike Gualtieri on ‘Horses for Courses’

In his Application Development blog, Forrester’s Mike Gualtieri posted on the phrase ‘horses for courses’ relating to the need of many different software products for CEP and business rules. Here is my response:

“Mike, I too had not heard the phrase before. I am however not in agreement with the comparison. Why? Horses have evolved naturally and did develop certain special abilities based on their environment. While software evolves too it is however not tracing a typical fitness landscape. Rational thought is used to form a product that has certain abilities. Strangely enough, we are right in the middle of the different faiths about natural evolution or intelligent design. Yes, if software was developed for a special use and change was driven by the user demand of that group then it evolves accordingly and you will have ‘horses for courses’. Things take a long time but the solution fits the – usually special – needs well. This is how I believe nature works too.

In difference to nature, we do take the role of the Great Architect of the Software Universe and software can be a good fit for most uses if designed accordingly. Especially if we look at ‘Business Technology’ rather than ‘Information Technology’. Business does not want five different horses that can not even be ridden by the same rider. The business landscape changes much faster than the software can evolve. We have to design software that is so flexible that it can be shaped by the business user on a day to day basis. Isn’t that what CEP and BR is mostly meant for?

Complex Event Processing and Business Rules should be right at the heart of any business technology and thus not be hard coded for special uses. Following my own faith in the above, I am pretty sure that with Papyrus we have designed a horse that can be trained in a few days by the people in the know to perform as good as the limited ‘horses for courses.’ It does that by using CEP and BR.”

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.