Native Apps and BPM

Scott Francis
Next Post
Previous Post

Interesting article by John Gruber, “Native Apps are Part of the Web“.

I can’t believe someone is still writing this in 2014. Users love apps, developers love apps — the only people who don’t love apps are pundits who don’t understand that apps aren’t really in opposition to the open Internet. They’re just superior clients to open Internet services. Instagram didn’t even have a web interface for years, but native app clients for iOS and Android didn’t lock Instagram into anything. Their back-end is just as open as it would have been if they had only had a web browser client interface. They just wouldn’t have gotten popular.

The premise is that rather than seeing Native Apps as competitive to the web, we should instead see them as additive to the web.  They are a different skin on the same HTTPS/TCP protocols, that provide a different value equation. Many of them rely strongly on HTML5 as well.

I think this is the right way to view Native apps in the context of the Web.  And not viewing them this way is the primary reason that so many people have gotten their noses bent out of shape that native apps would:

  • Stifle innovation (just the opposite, refer to Gruber’s post)
  • Stifle connectivity/link-ability (temporary problem, being resolved in different ways on the predominant platforms. But also, linking to the web content that these apps leverage still works great)
  • Ruin the Internet (hasn’t happened, isn’t likely to happen)

Turning to the world of BPM.  Too often businesses look at BPM as a way to build apps that will replace their existing enterprise applications. Essentially, a cool app-building environment that happens to have a notion of business process baked in, in a way that no other app-development-platforms do.  However, another way to look at it is that BPM apps are part of doing business.  They’re leveraging the existing and emergent APIs and information in your business to enable your team to perform better and to get at the information and processes they need.

Don’t view BPM as replacing your system of record or your favorite ERP tool.  BPM is the platform for weaving those tools together, those systems of record together, in a way that is a business process, rather than just a data maintenance application.

 

 

  • Pingback: Mobile BPM Vendors | ProcessRamblings.com()

  • What’s wrong in looking at BPM software as a new application development environment? Every BPM project I was involved in needed some piece of record-oriented functionality to be implemented in addition to processes. The inability of most BPMS to develop plain record-base applications is illogical as well as the obsession do perform all operations through processes. It doesn’t mean that BPM should replace all existing systems of records and COTS systems. Not instantly and not as a pre-condition. But it should give the opportunity to do so at a pace and direction that the customer chooses.

    • The danger in looking at it as a new application development environment is that the practitioners (customers, vendors, consultants) neglect to keep focused on the business processes and value – and just end up with more app software stack to replace old app software stack… and missed the huge opportunity to add value by capturing the processes. Small teams in particular can fall victim to this -building the SOR or record-based application in a BPMS – and then never getting to the process because they get budget cuts or limited funding – and just go into maint mode on the maint app… ugh!

      • Scott, I agree with your vision.

        IMO, other problem of looking at BPM software as a new application development environment is that these systems are very far from being the ideal IDE to do software development. Deep user interface customization, unit and automated testing, and even version control can be painful tasks to do on a BPMS.
        And here is where you fall victim of the situation you mentioned. You spend an incredible amount of time an resources building software that could be easily developed in other systems.

        Instead of using the BPMS to streamline operations, orchestrate tasks, monitor execution, and understand business performance… organizations use it only as a IDE to develop software to automate processes.

      • Also good points. There are BPM software packages that sit alongside traditional app dev platforms quite well. But again, the point isn’t to end up with “just” app dev. (IMHO). You’re naming one of the good reasons – that for some packages they don’t support “normal” development cycle very well. But in addition to that argument (which is specific to the characteristics of the BPMS), the general issue is that you’re taking your eye off the prize!

      • Good point, Filipe! In fact it isn’t exactly the issue of BPM software but rather of any RAD (rapid application development) tool that utilize code generation heavily. It’s hard to test the generated code and it’s hard to apply the version control to artifacts that are not just lines of code.

      • Scott, can’t fully agree with you on this. If people are unaware of BPM methodology and approach to BPM from automation perspective rather than from the business problem, then nothing would help, whatever BPM software they are using.

        My concern is about organizations that embraced the value of processes already yet face big challenges on transition. Current BPMS essentially offer “all or nothing”. The best approach I see is to start from plumbing records-level issues first, then proceed with ACM-style collaboration and finally use cases history to mine the process and implement it in BPMN.

      • to the first paragraph – i think we agree the “problem” isn’t specific to BPM software (as is the case with most methodology related “problems”). My point re: package is that there are some bpm software packages that address the “app dev” features better than others.

        The bottom up approach you describe is probably best practice if there is no expertise on what the business and processes really are, and there are no goals to start with. ie, let’s just “see what processes emerge” and assume those are the ones we want and designed the way we want… vs. designing goals and objectives and making sure processes are designed to achieve those… different strokes for different folks I guess. I can’t say it won’t work – it has for a couple of customers I’ve worked with, and obviously for you. But I’ve also been part of projects that start with process and address record-level issues later in the cycle – and that works really well for our customers also.

  • Hi Scott

    I agree with your point of view but it would be great if you will elaborate the concept behind your post because I am unable to understand the concept behind Native Apps and BPM.

    Thanks in advance