I have read a lot about the need for BPM to become more standardised, similar to the way in which HTML has a “standard” that is followed. Now, I have already posted about some of the limitations HTML has, and the problems we have with HTML running in different browsers, however, if we tried to do something similar with BPM, the problems will be far far greater than any of those a web developer faces with HTML and CSS…
Standards stifle innovation and hamper evolution
This is a simple statement and it is very true. There are many benefits of working to standards, and I embrace standards in general, however, having standards set in stone for how something works, or is defined, is very different to say, having standards on naming conventions when coding…
The problem with working as a standard is that when someone thinks out of the box, and they want to implement their great idea, they instantly have to break the “standard” to do it. Let’s take HTML as an example. The HTML standard simply doesn’t include everything we come to expect from the web today, this is why Flash was developed in the first place. I know HTML 5 is to be the new standard in years to come, but this looks to be yet another number of years away (and that is a different post). In the mean time, what do we do…Oh that’s right, we abandon the standard and use something proprietary, Flash or Silverlight to get the job done. Once HTML 5 catches up, oh I will more than likely still use Flash or Silverlight as they have moved on yet a further 10 years too…..You also have to remember that Flash has been around for years and years now, so we have worked with RIA for sometime without the HTML standard as such….
The HTML standard needs to work to some extent (even with Flash and Silverlight) because the architecture of the web. We use third party browsers to render and display our web pages, and HTML is the mark-up that describes to the browser what to do. So in this case, sure we need a standard of sorts so that the browsers know what to do with the HTML, and vice versa, designers and developers know what HTML to write that works how they want in a browser….
However, in the world of BPM this really isn’t a good option. BPM is very generic, and can encompass so many things. By stifling organisations to adhere to a particular standard will only stop BPM evolving quickly enough to keep up with business requirements. Take social BPM, if we had to adhere to standards, would Social BPM be where it is today, or would we have a “break away” number of platforms that deliver Social BPM functions and not adhering to the BPM standards….As I said, standards stifle innovation and evolution….
The designer has become the standard
Unfortunately the process designer has become the “norm” or “standard” for how we define processes in a BPM platform. Again, this is far too restrictive and something I have spoken about in a number of posts now. I won’t go over this ground again here, but if you are interested read
https://andrewonedegree.wordpress.com/2010/01/14/intelligent-bpm-maps/
https://andrewonedegree.wordpress.com/2010/03/24/adaptive-bpm-no-mapping-tools/
BPM needs to step back and away from the designer as it currently works. Please don’t miss understand, I am happy to see processes shown graphically, however, I don’t believe this graphical representation (made up front) should be how the system runs. For one thing, this presumes our BA has everything correct, it also presumes that the process will not change based on user requirements and finally, it presumes limited integration (at best). Unfortunately the designer is a great tool for demonstrations and showing processes running quickly, however it is not a great tool once a business buys into BPM and finds out just how restrictive this way of thinking and working is…
Is there a place for standards at all in BPM?
YES! The only place where standards should be introduced is that of integration and API. It shouldn’t matter what technology your BPM platform is built on, be it .NET, Java etc, its API, should be technology and platform independent. This means the standard for an API should be XML Based Web Services. In addition, it should be a standard that the BPM platform itself is built on its own API, ensuring that integrators can gain access to everything they need from the BPM platform via its API (I hate to see platforms – not just BPM – that have a limited API). I wouldn’t take this standard further (though I am sure some would call for specific calls to be used to do x,y and z).
With this type of standard, BPM can be used within other LOB applications, it expands the potential use of BPM and provides businesses with a level of abstraction for business rules that makes their systems far more agile and, if your BPM platform allows it, adaptive….This must the goal for BPM moving forward…
Andrew Smith CTO 
To a certain degree I agree with your statement. I agree that BPM standard would stifle innovation because not every BPM initiative is the same and the investment by a diverse group of organizations will be different based on several factors.
What I think would help are general “best practices” which are agnostic to standards and/or the underlying platforms employed.
Excellent post!
Best practices is the way forward for sure, and that is why i mention API and integration. It should be a best practice to ensure you expose a Web Service based API, it should also be a best practice to ensure that API is complete and not a “subset” of functionality, limiting its use…
BPM (as a discipline, tools and the practice) needs standards – they are steps (like in a ladder) to move forward. Example of W3C is a bit “wider” then you mentioned – there is a set of coherent standards: a) xHTML for structure and content, b) CSS for presentation, c) DOM-based API for dynamic modifications, and d) some other specialized standards. And, very important, there is an architecture which gives the context for all those standards.
Good acceptance of HTML (all vendors are checking their product with acid3.acidtests.org) considerably reduces development efforts – previously 25 % has been spent for covering “specific features” of popular Web browsers.
As well as this is a base for moving to HTML5.
In the case of BPM we have neither real standards (just publicly available specifications) nor architecture. But by having commonly agreed and executable BPMN we can use it within wider range of applications (i.e. innovate), e.g. in the traditional “case management” for planning and execution of short chains of steps (or activities). Similar as in the chess game some players think only about the current move and some players think for several moves in advance.
Thanks,
AS
I have to say that I dont really agree with this. I understand why standards are there for the web, but there is no getting away from the fact that even when adopted, web developers still spend a hell of a lot of their time making adjustments for different browsers interpretations of HTML, CSS etc. In addition, the difference is that the “architecture” is that of the web, which is for anything and everything and was in place before we started really devliering websites as we know them. With BPM, this is very different. We already have the idea and companies have their architecture in place. Why re-invent the wheel just to be part of some “standards”…Waste of money? In addition, BPM has to be far more agile, and it contains so many areas where big efficiency gains can be made, and seen between different vendors (integration, automation, process intelligence, adpative, etc.)
Lets say I wanted to implement a nice animated banner on a website (lets go back just two years), something I would have to do in Flash or Silverlight. However, these arent HTML standards. If I wanted to comply to the standards, I would have to wait for HTML 5 to arrive, and then be adopted by all the browsers, oh and then hope they ipmlement in exactly the same way (which I doubt would happen straight away). That means that I havent been able to deliver what I wanted to, and thats because I am waiting for the standards to a) actually understand and implement that type of design / requirement b) to be accepted and c) to be adopted by all. With HTML 5, I would have been wating a decade or more! That’s just too restrictive, and it is why we have had Flash for so many years. Without it, the web would be a very dull and boring place.
In terms of BPM, imagine a business having to wait almost a decade to actually implement their identified efficiency gains…..Its just not viable…As I have said before, standards sound great, but in reality they slow down innovation and restrict agility. There are so many other examples of this, and one great saying “too many cooks, spoil the broth”…..
[…] Standards in BPM? – Andrew Smith YES! The only place where standards should be introduced is that of integration […]
The ONLY standard needed is an interface to call web services?
Organizations spend a tremendous amount of time thinking, talking, and refining a description of their process. That investment is lost, if it is locked in a proprietary format and you decide to switch to a different tool. My organization spends a lot of energy writing documents — and I want to be sure that we can always read those documents in the future. We make a lot of presentations, and I want to make sure that the presentation graphics files can be read in the future. Wouldn’t the same apply to my process diagrams that we have spent so much time preparing?
Thanks for this, though most of your comment is more for ECM. Though saying that, I dont believe there should be a standard on how ECM works either. There should be a standard on how to extract your content, yes, but not on how properties should be formed etc etc. Thats just too restrictive and will stiffle new ideas and improvements that individual vendors can and will bring to the market…
With regards to BPM, process diagrams are just content, nothing more. I dont believe a BPM platform should be built around a diagram in anycase, this is far far too restrictive. BPM platforms need to be able to cater for defined processes (via intelligent maps) and be capable of capturing processes that emerge from actual use and people doing work (being adaptive). For this to happen, there really doesnt and shouldnt be a “standard” on how the BPM platform keeps this data / works…
Your process diagrams are just that, content, and you can keep these and they will still apply to any new BPM platform if you choose to implement the process in that fashion. In addition, please think of this. If you have a process diagram that maps your rules, and you wish to move to a new BPM platform, by simply importanting that process diagram (if you could) what benefit have you brought to the business? If your new platform provides more rich features, your current map doesnt use them. Of worse still, lets say your new platform doesnt have all the features your current map uses. This just opens up a wealth of problems, when in reality, just using your diagrams as a guide, and by utilising an adaptive platform, you would actually re-evaluate your processes, identify new areas of efficiency gains, streamlining etc and actually, deliver process improvements to the business…
Andrew, you said “As I have said before, standards sound great, but in reality they slow down innovation and restrict agility.” In my reality, the absence of good standards is the obstacle for the progress – in average for the IT industry, 80 % of software lifecycle costs occur during the maintenance phase. This is the effect of our current inability for lossless moving of content in time and space, permanent needs to replace whole applications vs just modernized their parts, etc.
Having a system comprising many “standard” parts actually opens a door of opportunities for small companies which can innovate with a standard part or with an aggregation of standards parts.
You are right about the development of many standards – some of them have been developed bottom-up (i.e. without good context) thus containing a lot of unnecessary features.
Thanks,
AS
When you mention maintenance phases and costs I always see this as just poor development / architecture of systems. In addition if companies standardise around things such as XML Web Services then small companies will always be able to integrate / innovate with other applications / parts. This is “a general” standard if you like that I would like to see all companies adopt, but it doesnt need a “standards” agency or anything formally written up. I think as soon as we start writting rules on standards etc, we actually make things a hell of a lot harder at the design and development stages, which adds cost and I feel, restricts real change and innovation…