Resolved
1 votes
As Scott Francis reported from bpmNEXT:
We can characterize many of the sessions as targeting 'making BPM easier'… but more specifically, there were a subset of talks focused on delivering BPM without writing code.
So how big do you think zero-code BPM will be in the future?
Tuesday, April 15 2014, 09:40 AM
Share this post:
Responses (16)
  • Accepted Answer

    Tuesday, April 15 2014, 09:51 AM - #Permalink
    Resolved
    2 votes
    The best answer to this question also was part of the article referenced, specifically:
    For anything sufficiently complex, the design UI tends to be just as complicated as writing code – or at a minimum, too complex for non-coders to use, and too inefficient for coders to want to use.
    Maximum simplicity is certainly a worthy goal, and definitely is gaining visibility. (Saw this in spades at the AIIM Conference two weeks ago too.) But it is unrealistic to expect we will eliminate all coding any time soon -- if ever -- unless we are talking about single-button interfaces to the least complex processes imaginable.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 10:04 AM - #Permalink
    Resolved
    6 votes
    BPM is about managing work and resources in light of desired business outcomes. Some of those resources will require no code and some will be deep and shared logic that will likely be code (old or new). While a good goal is less code, zero code is not a realistic or an attainable outcome. I'm not sure if 80% is model driven,data driven or drop down enhanced, but we could see percentages north of that number for some processes. Just my take
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 10:05 AM - #Permalink
    Resolved
    5 votes
    One day there will be an IT platform that will require no code to deploy and maintain
    Said no-one ever outside of marketing. Won't happen. We can expect increasing levels of pre-existing 'customization' code to take care of integration requirements, or for predictive workflow conditions for example but at some point even standard rule sets will require tweaking. Each client, each implementation, every process, every IT landscape is different, you can't escape the certain amount of customization to make BPM effective for individual client scenario. For sure, predetermined code can help the business user gain some experience and knowledge around BPMS to navigate it to a point but to get the best out of any BPMS you will need to learn some of the nuts and bolts. Zero code has nothing to do with design UI. Let's junk that myth please. Design UI and end UX is a separate entity to be dealt with. BPM isn't about being cookie cutter. So why market it like that.
    Like
    2
    • Patrick Lujan
      more than a month ago
      "integration requirements." #TouchNose
    • Keith Swenson
      more than a month ago
      Good response. Designing is coding; coding is designing. You can't separate them. However ... you might have a system that is not designed....
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 10:08 AM - #Permalink
    Resolved
    3 votes
    It has always been the goal of BPM to significantly reduce or eliminate code, In reality however it is unlikely that we will ever achieve a code free environment. There are far too many crunch points that just require a developer to sit down and write code. Integration still seems to be the biggest area of complexity. When I look at the BPM tools on the market, they all promise a zero coding experience, apart from the very basic screen layouts and process designs, most tools require the more complex requirements to be coded. Pega Systems, in my opinion, goes the furthest in generating code behind it's configurable interface, but even here, for complex requirements you need to resort to Java. In the future we will undoubtedly have more sophisticated model driven environments, Mendix is moving in this direction, that essentially generate more and more code. As our understanding of design patterns matures, more design patterns will become standard building blocks, such as UI's, WSDLS, Integration API's etc however as we try to integrate newer technologies with older ones the models just won't keep up.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 10:22 AM - #Permalink
    Resolved
    4 votes
    It depends... I don't see the need for coding if all you want to do is extract an attachment from an email, upload it to Google Drive and assign some tasks to people. In fact, many more processes will be automated with the BPMS if business people can do it themselves. For many processes, they are willing to make compromises in terms of the features and flexibility. For many other processes integrating custom coding is a crucial necessity. At Effektif we are working hard to ensure that simple processes can be done by non tech business users without coding. And that custom code can be integrated by developers when needed. Ensuring that business people are not confronted with the complex technical details is the crucial requirement.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 10:28 AM - #Permalink
    Resolved
    2 votes
    I am with Tom. BPM should follow the rules of a good design environment - simple things must be simple (zero coding) and complex things must be possible (via interpretive languages). Re-usability of natural building blocks such as process patterns is critically important to simplify the life of business people. The BPM industry must make the process patterns executable and portable between BPM tools. Thanks, AS
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 11:16 AM - #Permalink
    Resolved
    3 votes
    No, it's the "white leopard" of BPM just as the paperless office is of ECM. Theo and Nicholas snailed it, as long as BPM doesn't operate in a vacuum and has to play nice with other apps' servers on the machine floor code is not going away. Ever.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 11:33 AM - #Permalink
    Resolved
    1 votes
    While coding won’t be eliminated, zero code for BPM is the biggest game in town. If BPM product owners and designers aren’t continuously striving to reduce coding then I wonder what they are at. The process app market is the industry response to the demand for zero code.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 12:55 PM - #Permalink
    Resolved
    2 votes
    The concept of "zero code" is the wish-fulfillment myth of the industry. People desire systems that automatically do thing for them. They tried it, and found that they had to tell the computer what to do in what situation -- this is coding. Then a clever trick was played: the idea of typing a bunch of text in an unfamiliar syntax was associated with the idea of coding. People thought that the hard part about getting the computer to do what you want is the typing part. If we can eliminate typing, we can eliminate coding. That is, if we can make a system where you tell the computer what to do without typing, and only by using a mouse to drag and drop shapes, then you won't have to do any coding, right? But you still have to learn what a bunch of obscure symbols mean, and what their interaction might be. It turns out that the "typing" is not the hard part about the coding. Dragging and dropping symbols on a map to tell the system exactly what to do is still coding, and it is just as hard as typing the code in text, because the hard part is figuring out what should be done in what situation. There are some examples of no-coding systems if we look for them, we can talk about two that stand out: 1) Google Page Rank: When Yahoo was the top of the search world it employed a bunch of people to code up an index to the web. That is, they looked at a page, and decided where it should fit. Google invented Page Rank which gleaned associates just from the links between existing pages. No person had to decide that "giraffe" was associated with "african animals" instead that emerged from the data set without human involvement, that is, without coding. The algorithm can be tricked by purposefully constructing misleading links, but this is not programming in any traditional sense. 2) Google Translate: Every phrase translated gives you the option to see both the original and the translated version, and then you can "improve" the translation. Nobody has to sit down and 'program' the translator by defining rules for it to follow under certain situations. Instead from the examples, it works out the rules by itself. Two properties are common of these: (1) they learn by example, and not by being given explicit rules, and (2) nobody is in control and can take responsibility for the results. There is then a possibility for a BPM system that learns by example, but nobody yet in the industry is ready for a system that can not be controlled. There is a deep set management belief that if you let workers do whatever they want, they will behave chaotically. Instead, command and control is needed to coordinate action. Which is one reason why showed a flock of starling flying in my BPMNext talk. Clearly organization emerges without needed any single individual in control, and without telling other exactly what to do. But the industry is clearly not ready for a BPM system which exerts no control over the participants in the process. Exerting control is what programming is all about, and therefor you will not see a zero-code BPM system sold as a BPM system. Oh, damn, this turned into another blog post: http://social-biz.org/2014/04/15/zero-code-bpm-systems/ :-)
    • E Scott Menter
      more than a month ago
      "Dragging and dropping symbols on a map to tell the system exactly what to do is still coding, and it is just as hard as typing the code in text, because the hard part is figuring out what should be done in what situation."

      I get where you're going here, but I think you're overstating the matter. I agree of course that understanding the problem to be solved is a prerequisite in either case, but that just means the only thing you're actually measuring when you compare the two is the difficulty implementing a solution once you've reached that understanding. Both coding and workflow construction are specialized skills, but, take it from somebody who has done plenty of both (as perhaps you have as well): coding is harder.
    • Scott Francis
      more than a month ago
      Scott, I think I get your meaning - that the right "model" for something (dropping symbols to build it or drawing on a whiteboard) is easier than solving the same problem with pure code. I agree (and I think Keith would agree) - but that's not the same thing as saying that one is easy and the other is hard. It is a spectrum. And when you don't have the right "model" then coding will actually be easier. A big part of the magic of building development tools is finding the right "model" for the tooling.
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 01:58 PM - #Permalink
    Resolved
    -2 votes
    This zero code journey has started where all business logic is now pre-built recognising that people create all information and business logic never changes. We started such R&D over 20 years ago and with a very simple design involving powerful links for “collaboration” and rules that opened the “zero code” door. Let’s put this into context. Bill Gates saw it in 2008 when he announced plans to build a declarative modelling capability reducing the need to code calling it the “holy grail of development forever”, “the dream the quest…. but would be in a time frame of 5 to 8 years.” http://www.infoworld.com/d/developer-world/gates-talks-declarative-modeling-language-effort-386 And Thought leader Naomi Bloom wrote “Writing less code to achieve great business applications was my focus in that 1984 article, and it remains so today. Being able to do this is critical if we’re going to realize the full potential of information technology” “….how those models can become applications without any code being written or even generated”. “If I’m right, you’ll want to be on the agile, models-driven, definitional development side of the moat thus created…..” “…”If your Enterprise vendor isn't pretty far down this path, their future isn't very bright”. Let me pick out comments made (apologies in advance if upsets any one) which may help understanding on how we had to learn in those early years of R&D Steve the UI yes that is the most important aspect of user needs but does not “need” coders to build the required delivery and creation of information. It is feed direct from the back office “engine” or with extensive tag library data can be orchestrated from any source. Intelligent forms can be created Jim agree 100% “zero code” where very complex issues may well need a coder but simple routine day to day business logic we are probable at 95% always need “help” to tackle legacy maybe custom APIs etc and complex intelligent processes might need a coder. Theo “Won't happen”…well not if you think “Each client, each implementation, every process, every IT landscape is different, you can't escape the certain amount of customization to make BPM effective for individual client scenario” That is traditional IT thinking which of course suits big vendors…… Fact is think how people actually work and the support human and system they require then you realise the logic is generic for any process. Nicholas “Integration still seems to be the biggest area of complexity” sure is if you think “integration” but think communication and orchestration of info or specialist application PAYE currency convertor etc. Also “.essentially generate more and more code” is not the answer nor is BPMN; “declarative” eliminates that thinking and makes a significant contribution of easy change in build and the future. Tom “For many processes, they are willing to make compromises in terms of the features and flexibility”. We have found no compromise need with in built flexibility! A user at early adopter quote sums it up. “It captures all my weird and wonderful ideas and all done without telling me that I am expecting too much!” This is a must for next generation BPM platforms? AS “Re-usability of natural building blocks such as process patterns is critically important to simplify the life of business people”. Well said the less than 13 generic task types with links do just that why recode over and over something that does not change? Patrick “…machine floor code is not going away.” To us that is the custom API code and the “5%” code I refer to with Jim But once built it is reusable. But the all process needs and “orchestration” taken care of so analysts build not coders? Peter “The process app market is the industry response to the demand for zero code” Now we can deliver at enterprise level simple small or complex and big includes CRM ACM SCM etc. Keith “Dragging and dropping symbols on a map to tell the system exactly what to do is still coding,” Sorry that is nonsense! Code is geek land writing in techie language indeed it alien to the business skill set which must drive BPM. We use coders to build the BPM Platform with the purpose not to “need” them to build any process application! “the hard part is figuring out what should be done in what situation” Yes but try speaking and listening to business users they know…it is simple really. Just go simple step by step what is needed to create the individual or collective outcome/goal. An alien way for IT to work hence the divide that a good BPM will bridge without need to think about coding restraints? Finally “Exerting control is what programming is all about” just sums up why the target of Zero code in important old style “command and control” needs to be removed? The core thinking and research articulated in this paper http://www.igi-global.com/chapter/object-model-development-engineering/78620 Anyone want a copy let me know. PS just love those negative votes as we move from being ignored to ridiculed or is it fight...... classic reactions to "disruptive"..... just a question of time?
    • Scott Francis
      more than a month ago
      I don't think the negative votes are just because of your points of view, but also for how you're expressing yourself. if it makes you feel better to think that disagreeing with everyone makes you more right, so be it, but the difference between vision and hallucination is testing your ideas in the market.
    • David Chassels
      more than a month ago
      Scott I understand and apologised before I started! However these views are not "vision and hallucination" as we have had to work hard with early adopters learning about what we had created. One has been running as a CRM/ACM now for 12 years with constant change and the most efficient body in the sector. It is a true paradigm shift with more to come.

      But we were over a decade ahead of our time with all early adopters business driven and just could not get IT to understand. Likes of Gartner and Forrester just ignored us as did the big integrators and did not understand as we are different; it is classic "innovators dilemma"? Raising money in the 90s was “easy” but after the 2001 burst IT bubble it was impossible to raise new money so we “boot strapped” our way forward as a R&D company waiting for the market to be ready supporting early adopters and advancing the technology with web capability.

      This “code” discussion just hits the spot so my "passion" may well come across as “lecturing” as we do challenge established ways! Indeed I learn a lot from such exchanges but be under no illusions it is real. Now we get ready to globalise heading south and east (US only via partners) and on the cusp of huge global contract and linked funding. As I said time will tell…..?
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 05:01 PM - #Permalink
    Resolved
    2 votes
    I feel like I just "trolled" the BPM forum! Many good and thoughtful posts here, really appreciate it. Especially had a good laugh seeing Keith's "damn this turned into another blog post" comment :) Thanks everyone this was a fantastic read. Going to reference it in our blog for sure! Scott
    The reply is currently minimized Show
  • Accepted Answer

    Tuesday, April 15 2014, 06:14 PM - #Permalink
    Resolved
    1 votes
    Codeless, paperless, whatever: it's all asymptotic. You don't really expect to reach these ideals, but surely there is value in getting as close to them as possible. BPM has so far delivered the biggest contribution in both of those areas, and can be counted on to continue to do so.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 16 2014, 04:27 AM - #Permalink
    Resolved
    1 votes
    To continue to claim that BPM has been so great in the past without any proof won't change reality. BPM has contributed substantial consulting costs, business rigidity and mindless staff to the business for the sake of cost cutting and not much else. Great minds should be able to let go of the past and look to the future. Keith's 'blog post' (which I commented on there) is the most realistic perspective on this. Zero-Code BPM is marketing lie and most of all it is utterly irrelevant. Find my take in this post: http://isismjpucher.wordpress.com/2014/04/16/the-zero-code-bpm-white-lie/ What this must be about is to empower the business to perform purposeful collaboration and provide top-down and bottom-up tranpsarency. Zero code or not only refers to orthodox BPM technology stacks.
    • David Chassels
      more than a month ago
      Max even I agree 100% zero code is not likely but 90% is very achievable and it’s the way Enterprise Software driven by BPM thinking will go. Simple processes e.g. expenses can be 100% no code but say a product configurator is likely to need 10% but the build project is driven by the business analyst with coders delivering very specific complex needs. However everything should be reusable so next time the code if required will be less.

      I read your post and picked up this so to gain another negative vote here goes! You say “Data collection as well as process optimization and continuous improvement have to happen in real-time. Which means that current BPM and Case Management systems will never be able to implement it as they are missing the real-time access to such information.” Well our BPM Platform delivers real time feed back which is a modern day absolute requirement to help empower people. Indeed if this can’t be delivered you will never fully reach optimisation of your business operations so add to the shopping list! I think we are agreed on that.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 16 2014, 06:14 AM - #Permalink
    Resolved
    2 votes
    When Scott sparked the initial discussion with some very interesting additional comments from Max and Scott, I told him that this kind of discussion is very relevant and should not be buried in blog posts and forums. This is what managers should understand (or at least some). If a "zero code" approach is possible, software vendors should be worried about how to implement it and help the customers create a vision of how that path should be possible, and this is the important part, for that purpose it should be lead by engineers and not by marketing personnel. You can call it utopian, but like most IT projects from 20 years ago that were willing to incorporate artificial intelligence they were also utopian and today they are looming. This should guide the design principles of such systems and such an approach. This does not have nothing to do with the fact that to create this possibility it is necessary to create code (the system that will allow code free development) and diverting the discussion to this path. From a managers perspective, is fooling and goes to a capillary discussion that they are not interested in. But still, in some business contexts it is possible to create and deploy "zero code" (zero fat) process applications. Not recognizing such possibilities is up front not believing that the system the vendor sells is capable of that (that for me is a very surprising fact). Nevertheless, in most business contexts, like banks, insurance companies and telecoms the "zero code" approach is impossible because of the myriad of systems that exists, each having their own coupling mechanisms.
    Like
    2
    • Patrick Lujan
      more than a month ago
      Man, I won't be able to make it to Portugal this year, but it's definitely on my docket for next year. We gotta talk.
    • Alberto Manuel
      more than a month ago
      Patrick

      Seems you are already defining the agenda of BPM Conference Portugal 2015
    • Scott Francis
      more than a month ago
      Patrick maybe we need to coordinate travel plans :)
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, April 16 2014, 06:33 PM - #Permalink
    Resolved
    3 votes
    As many people on this blog have hinted, there is a difference between "code" (i.e. a text-based syntax to telling a computer what to do) and "computational thinking" (i.e. a thinking about or decomposing a problem such at a computer can solve it at scale). Both a C++ Programmer and a expert user of Excel practice "computational thinking" although I'd argue only one of them is doing "code." If by "code" you mean syntax, then I think its quite possible to build applications (BPM and otherwise) in a "zero-code" way. Visual BPM tools are just the next generation in a long line of visual development environments that have made it possible for people without training in "syntax" to build robust systems. Note that even within the world of "code" we have been traveling up the ladder of abstraction for years: Java requires programmers to think less about memory allocation than C++ did and C++ (and other 3 GL's) offered levels of abstraction above Assembler. Where the marketing gets in the way, however, is when people assume that "zero code" means "zero complexity" or "zero computational thinking." If you want to design a business process that integrates to multiple data stores, leverage existing assets and is built to be decomposed into reusable components, then you have to practice some degree of "computational thinking." My real-world experience, however, is that you can find people with real business experience (team leads in a contact center, senior adjudicators of exceptions/disputes, etc.), who have the capacity for "computational thinking" and train them to define systems without writing coded syntax. This was true when Pega first started defining workflow systems using 3270-based forms, and its true now for BPM systems that use more abstractive and attractive visual metaphors. For this to work, the metaphor must be business-centric and person implementing it must have some degree of a computational mindset. If that is your definition, I firmly believe you can define an application without "code," and I believe that doing so offers huge benefits in terms of communicating and collaborating with business experts to both define and change that application. But you can't do it without some sort of thinking about the design and computation impact of what you are doing. Keith, to your point, I think there is a growing class of applications that require even less design thinking. Case Management apps that users literally "design by doing" will be an interesting shift over the next few years, and already, we see large numbers of clients adopting self-learning adaptive algorithms to drive marketing, fraud analysis, collections, etc. These are applications automatically define themselves over time, but even there, most business retain some sort of design control, usually through a non-coded visual metaphor.
    • Scott Francis
      more than a month ago
      good definition/distinction between "code" and "computational thinking" - thanks for this comment - i'll remember that phrasing for future use.
    • Keith Swenson
      more than a month ago
      Don, excellent explanation: it depends upon whether when people hear the term "no code" they think that means "no computational thinking". We could run a poll of people who might be typical customers and see if "no code" means to them "no programming" (which I think it does). Programming is hard work. Some languages are clearly far better than others, and that makes a difference.

      If coding means using "text based syntax" then we should not fool ourselves into thinking that graphical processes are free of that. When defining a real process using a graphical notation, you still have to define variables with data types. When you have a XOR gateway, you need to define the branch condition using a "text based syntax" which must refer to variables and literal values properly. At points in the process it will need to calculate new values from existing values, and once again you have to use an expression based on a "text based syntax". Those claiming that there is no text-based symbolic logic in a graphical processes are not honestly considering the whole story.

      The joke at BPMNext was when one presenter claimed that the entire process was made without coding, while he brought up dozens of full page, multi-tabbed property sheets, with perhaps 100 cryptic settings on each diagram element, including xpath expressions, which presumably must have values that correspond with values in other property sheets. Saying that there is no complicated text-base symbolic logic is silly.

      The drag and drop is only the first 5% of the process definition.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, April 18 2014, 04:13 PM - #Permalink
    Resolved
    1 votes

    Full disclosure: I have represented Intalio ("zero code") and Magic Software ("code free") as a sales person; although the statements about code were established in both cases before I arrived. Whatever anyone thinks about the technologies in question, the statements nevertheless resonated with many prospective customers.

    Paradoxically, I agree with most of the statements expressed by participants here -- both for and against the idea of zero code and model-driven anything. And it is possible to hold both conflicting views simultaneously, by segmenting my prospects into more or less technical audiences. Some people want the velocity possible with code-free; others want to know they can punch out to full coding in Java.

    Are there compromises in code free? Probably. Is the technology evolving to make code free and declarative technology more powerful? Sure. Should we all be using more patterns? Probably. Is this a black and white question? No. Will code free technology get better in the future? Absolutely.

    The one thing I do know is that "the tail should not wag the dog", which is to say that business should work to ensure that it is not held hostage to code. Business is about business and software technology is about enabling the objectives of business. Insofar as models and declarations and patterns enable us to express the concepts of business directly and explicitly, as opposed to being mediated by layers of code and complexity, we will be further ahead.

    The reply is currently minimized Show
Your Reply

Join the Discussion

Want to join the discussion?

Login, or create an account to participate in the forum.

Top Participants

Dr Alexander Samarin
275 Replies
23/09/2016
David Chassels
269 Replies
23/09/2016
Emiel Kelly
220 Replies
23/09/2016
Bogdan Nafornita
209 Replies
25/09/2016
E Scott Menter
182 Replies
23/09/2016