Splicer exposes BPM semantics as type-safe data structures embedded in native mobile apps. Lets take a look at how this extension works.
In researching how “low code” fits with BPM, I found the following article:http://bpm.com/bpm-today/in-the-forum/when-is-low-code-bpm-not-the-best-option . In this discussion, these BPM “thought leaders” define specific functional requirements for “low code” within the BPM domain.
In the discussion, I’m hearing several different perspectives on how “low code” relates to BPM. Nevertheless, it seems there is a desire to use low code as a way to extend BPM capabilities toward developing apps. Ideally, the extension must happen in a way that can be integrated into existing productions systems. To do this means we must a) tap into production artifacts, and b) use BPM extensions to create our own production artifacts.
How do we tap into production artifacts, and then create our own? At Splicer, we developed a “hybrid” option that provides benefits of proprietary “low code” solutions, but can be used by all developers – enterprise and citizen alike. We recently wrote a blog topic that discusses this “hybrid” concept vs. other “low code” tools: low code platform .
Splicer extends server data models to mobile. To do this, our product first derives a server model from existing server artifacts such as a structured (relational) database schema. Then you can pick elements to publish with our Map GUI. Once selected, Splicer generates associated DAOs for Android and IOS, and then serves data to them via our open source server. Essentially, you can not only spin up custom, micro services for mobile apps, but also extend the server model in the form of native client DAOs. This is a generic “low code” solution that enables you to develop the clients in whatever manner you choose. Most importantly, we automate the tedious “infrastructure wrangling” that comprises 80-90% of the cost (as pointed out by John Morris above). Our products allow the “surfacing” of “business semantics” such that the business leaders can produce real, production artifacts. Our tools generate re-usable artifacts that get injected into the engineering system – i.e. becomes part of “the build”.
An alternative to proprietary “low code” My experience over the years is that using “single vendor” for the entire stack always looses to “mix and match” in the long run in terms of total market share. That’s what concerns me the most about these low code systems. Certainly using them for citizen-developed apps makes sense using a “single vendor” stack, but makes less sense for enterprise. Instead, we decided to exclusively focus on applying data models to mobile, which then allows you to mix-and-match other best-of-breed tools.