BPM.com
  1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Thursday, 24 May 2018
  5.  Subscribe via email
Microservices were another big topic at this year's bpmNEXT. So would you say microservices are the future of BPM?
Accepted Answer Pending Moderation
A microservices architecture is one tool that a provider can use to make its hosted as-a-service proposition cheaper and easier to develop, test, operate, scale and change without service disruption. Business process app technology platform providers (a) shifting to a hosted delivery model and (b) going for a 'pure aaS' model (rather than single-tenant hosted platform) are likely to adopt microservices architecture for this reason.

But that's not the same as answering "yes" to your question :-)
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
Yes.

It is in the end just an easier way to deploy and configure units of software. It is a concrete expression of the agile spirit into the dev-ops world. Nothing to do with BPM -- which is just one of many application domains -- but all about how you get programmed capabilities from a keyboard of a workstation to a server run-time environment.
References
  1. http://social-biz.org/
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Accepted Answer Pending Moderation
The principles of Microservices are absolutely the future of DPA/BPM. However, down the road I don't see a catalogue of microservices as the new DPA/BPM but rather a complimentary capability to be leveraged. There are too many critical definitions and elements wrapped around DPA/BPM and the value of DPA/BPM platform brings discipline and structure to the design and implementation of business capabilities. Having a multitude of micrsoservices which come with a multitude of patterns to compile into a full application is counter to making application development more business friendly. Where are today's standards of Microservices? hhhhm. Isn't the world moving to put more capability into the hands of the business without the business having to dive into the bowels of coding? OK microservices eliminates a low level code effort however, bringing those services together is like stitching together a patch work quilt. It requires smart technical folks. No question microservices will be valuable. It is just a matter of whether they will become the construct of the future and that gets to the question of standards. I would argue that platform vendors will still rule given the premise that the ultimate goal is to shrink the technical coding and put more capabilities in the hands of the business thus more complete capabilities center on business metaphors. At this stage, Microservices will be an underlying component fitting within the vendor platforms.
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
It is actually completely opposite – BPM is the future of microservices.

There are two main problems with microservices: 1) granularity of microservices and 2) complexity of microservices-based applications.

BPM solves these two problems naturally.
1) BPM decomposes a process or group of processes in to a set of artefacts: roles, rules, screen, scripts, data, documents, audit trails, coordination, etc. Each of these artefacts is to be implemented as a microservice – thus boundaries of microservices are business-driven.

2) in BPM, a process-based solution is an assembly of its microservices (see item 1). Thus all relationships between microservices are well-known and well-managed by BPM-suite tools (of course, a process is a composite microservice).

Only one step is necessary -- the vendors of BPM-suite tools must destroy their monolith approach to BPM.

See [1]

Thanks,
AS
References
  1. http://improving-bpm-systems.blogspot.com/2017/05/beauty-of-microservices-ebanliing.html
Comment
Absolutely amazing and incredibly relevant observation!
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Asking about microservices and the future of BPM is like asking about oranges and the future of trees.

Don't get me wrong -- the question (either arboreal or technological) is a good one. It throws light on the interdependence of two systems components.

Oranges = work & outcomes = microservices
Trees = infrastructure & orchestration = BPM software


How are microservices and BPM related? If BPM software is "the software of the work of business", it turns out that that orchestrated work is realized via a boundary node with external systems, i.e. in this case via a microservice.

But BPM as work orchestration can connect to all sorts of interfaces. So, what's special about microservices?

Microservices are just a formalized and disciplined approach to encapsulated business semantics. What "objects" and SOA were supposed to be, but never quite achieved. As I mentioned last year on BPM.com, microservices very much map to the responsibilities of business analysts. And we hear a lot about the so-called "API economy"; microservices are a primary technical enactment of the API economy. Like BPM software-defined processes, microservices are technology artefacts with much higher levels of instantiated business semantics, and are thus directly interesting to, and of concern to, business leaders.

Which brings us to the question of economics. Phil Calcado, when he was Director of Software Engineering last year at @DigitalOcean, made a marvellous presentation on the topic of the economics of microservices. (He bases his analysis directly on economist Ronald Coase, especially Coase's 1937 insights on business organization and transaction cost.)

https://www.slideshare.net/pcalcado/the-economics-of-microservices-2017-craftconf
http://philcalcado.com/2017/06/11/calcados_microservices_prerequisites.html


There are lots of technical things to say about microservices. But let's take microservices technology as a given. The interesting thing now is the adoption and impact of microservices technology. And it is a technology that must deeply involve business analysts. Microservice scaleability will also help drive the definition business service boundaries. Microservices is a perfect nexus of technology-meets-economics-meets-governance. As for BPM, I agree with @Alexander that, in my words, microservice exit points are the future of BPM software technology.

More opportunity for BPM technologists and champions!
Comment
With BPM which defines microservices, are we ready for #BizDevOps?
  1. John Morris
  2. 6 months ago
  3. #5373
Excellent invocation of #BizDevOps, Alexander. It's a centrally important (and even novel) topic. The topic overlaps #EA (#architecture), #business analysis, #capability development, #businesstransformation (pick a definition) - and a theme I like to emphasize, which is business opening up the #blackbox of #process and #work and taking responsibility for the "previously assumed".

In a discussion of BPM, the idea of #BizDevOps would be an extension of the idea of "business concepts as first-class citizens" of a technology programme.

I describe BPM as a technology where the business concepts of work are built-in to the technology (i.e. you don't have to code process orchestration etc.). Working directly with reified business concepts as technology artefacts is essential to productivity and to beating complexity.

BizDevOps could therefore be seen then as "first-classness" extended. Business analysts of the world unite! Transformation awaits.
  1. David Chassels
  2. 6 months ago
  3. #5377
Well said John......we only waited 2 decades as we were ridiculed and ignored....but it will happen!
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
Microservices in BPM from an architectural point of view, as proposed by some BPMS vendors, do make sense in terms of optimizing a given infrastructure. Also, it has the potential to reduce development efforts, allow for some agile development methodologies, lower risk exposures and so forth. However, these effects are decreasing and can even start to work against you, with growing process complexities and process portfolios. Having an ever growing amount of independent and unconnected microservices behind a multitude of department bridging processes, will produce redundancy and become counter effective to SOA at some point.
Same goes for looking at mircroservices from a process solution point of view. It sure will add agility when looking at a couple of very specific processes but become complex to handle when you have a portfolio of some 100+ complex processes.
For now, I would encourage determining a balance between focused microservices, SOA components and custom developments per process.
I do think however, these services do have a place in BPM.
NSI Soluciones - ABPMP PTY
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
Just wondering whether microservice "devices" typically keep a log of transactions received, processing done, output sent back.

If yes, that is not going to work well under GDPR EU679 which comes into effect tomorrow, May 25th.

The basics of GDPR are share only on a need-to-know / permissioned basis and as and when you share, keep a record of what was sent, when, to whom.

There are derogations so it's not as simple as this.
References
  1. https://kwkeirstead.wordpress.com
Comment
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Brian Reale
Blog Writer
Accepted Answer Pending Moderation
It is interesting to see that very few people in this post interpreted the question in the same way. To get into a healthy microservices debate, we would probably need to frame the question quite a bit more precisely. Nonetheless, I'll add my comments.

As many on the forum know and as everyone at bpmNEXT saw, ProcessMaker recently launched a microservices BPM offering. At bpmNEXT we showcased the offering and did a demo of a DSAR (Data Subject Access Request) handling process built on our new technology. For me, one of the more interesting pieces of feedback came from a comment by someone from Redhat who questioned why we felt we had the right to even call what we were doing a microservice. That was an interesting comment. Basically, we have put an entire bpm engine (Fully BPMN 2.0 compatible) up in the cloud for use as an API-as-a-Service. There are no interfaces, modules, inboxes, designers, etc. at all in the product. It is a pure API-as-a-Service offering. In relation to the normal BPM bloatware that is being offered in the market, we certainly think about this as a microservice. But, the guy from Redhat was also correct. His criticism was basically - how can a whole engine be "micro." Micro for him implied a single service delivered through a single endpoint (or perhaps just a few endpoints). I could certainly understand his criticism. The funny thing, however, is that in relation to a BPM Suite, what we are offering really is a microservice because bpm and the idea of a "digital transformation platform" is a truly macro, i.e. bloated service. So, is a microservice something subjective and determined only in relation to something else? (No doubt that J. Derrida would say "yes";).

We released our Api-as-a-service product initially as a sort of MVP of our next generation of ProcessMaker. As an open source company, we generally follow a mantra of release early and release often. So, since we were designing an API first product - why wait? Why not just release the engine and make it fully operational and fully consumable in the cloud? And, bingo - it is. You can sign up right now at processmaker.io and start firing up instances and hitting the API for whatever use case you might have. It is a real BYO product - Bring your own forms, bring your own designer, etc. A truly liberating experience.

But let me get to the punch line. The typical BPMS tries to be too many things to too many people. This can be useful some of the time, but I predict that it will be less and less useful in the future. The best analogy I can give you is the Set Top Box. Do you remember those? They were popular for a brief moment in the late 90s, but they completely failed as a product. Why did they fail? It was real simple. The STB producers would role out a product with their best designs of interfaces, memory, cpu, and storage. By the time it hit the market, people already wanted to change out the parts - more memory, faster storage, etc. The form factor did not permit this kind of configurability. The PC, on the other hand, did. So, the STB inevitably failed. The same thing is starting to come back around in BPM (everything is a cycle). Look at how many BPMS suites look old and tired in the market. It is just too hard to keep gutting and replacing fast enough to keep up with the changing flavor of the month as technologies come in and out of vogue. Does anyone today want to be locked in to a particular front end technology? A particular database? Of course not. How about a particular process designer? Probably not. It has been said at lots of other times in the history of technology, but we are once again in a moment where less is more and customers will want to get particular services from particular vendors and mix them with other services from other vendors. (PC era vs. Apple era?) So, for this reason, those vendors that can breakdown their BPM offering and offer more micro sized bits of service will be more adaptable and better able to thrive. The BPMS certainly won't die, but there are going to be more and more use cases where someone wants to use a lightweight workflow engine API in the cloud from one vendor, forms from another, a designer from yet another, and mix it in new and interesting ways to create a completely different type of product.
Comment
Re: "vendors that can breakdown their BPM offering and offer more micro sized bits of service will be more adaptable and better able to thrive"

There are examples in the healthcare industry of "integrated" EHR systems (some qualifying as BPMs in that they had/have run-time capabilities for hosting compiled process maps at Cases), of serious maintenance problems.

Example: the ones that embedded EDI formatting (400 different payor EDI formats in that space before clearing houses came on the market). Each time any of the 400 made a change to their format, the vendors had to roll out a new version of their EHR executables.

Vendors who build EDI engines capable of hosting scripts did not need to upgrade either their EHRs or their EDI executables.

  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
This microservices tag has puzzled me as to what exactly it is. I found Alexander's link very helpful so it sounds like sets of software functional units or tasks which can quickly deliver a specific business outcome and can be used to build in such as a Dev Ops environment? Our core research some 20 years ago established that business logic was simple and we identified less than 15 task types which addressed all business needs. It strikes me when configured they become a microservice and when linking can very quickly build any custom process without coding. It could be just a few tasks linked become a stand a lone microservice but the opportunity exists to think of bigger picture and as such this opens a new door for BPM?
Comment
The purpose of microservice architecture is to deliver an application as a set of microservices. Thus BPM is business-driven way to define granularity, API, relationshsips for microservices which construct process-driven applications. Some of such microservices will be DSL-interpreters for which somebody has write a program in a DSL.
  1. David Chassels
  2. 6 months ago
  3. #5376
Yea all makes sense and as you say architecture important which can orchestrate as required. Our approach uses declarative from model which avoids programming.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Microservices is a technology, which enables creation of enterprise applications from small functional blocks distributed across heterogeneous server environments. Microsrvices gain popularity due to increasing cloud adoption across organizations undergoing digital transformation.

Due to their principal positioning as interoperable blocks of business logic, microservices win an increasing attention among BPM professionals as a valuable resource of business automation. However, microservices are not unique in this respect. Interoperable aggregation of business objects dominates development of corporate IT during all its history. Nearly every notable digital business platform offered its own paradigm of distributed interoperability. Microservices are just a manifestation of this long trend on the current level of technology.

As any growing ecosystem of business objects, microservices principally require systematic structuring and maintenance achievable through BPM. Without delimited methodology, dedicated modeling and precious planning complex corporate systems of microservices can easily fall apart burying costly and time consuming IT initiatives. BPM is principal facilitator and enabler for microservices universe.
Comment
  1. John Morris
  2. 6 months ago
  3. #5379
In other words, time for business and technical leadership to "step up". Microservices is a technology (1) that works, (2) that meets important technical needs, and (3) that is enabled by BPM process automation technology. But what I'm also reading Boris is that if management doesn't "step up", that there is a real risk that any programme that relies on microservices will fail. There's no free lunch.
@John Morris, Thank you. That's exactly the point. Without BPM involved, it all risks getting into another unmanageable spaghetti havoc, even despite devised and crafted for success and flexibility.

  1. David Chassels
  2. 6 months ago
  3. #5381
Another good explanation but does raise the question who creates such tags? RPA in same category of not actually reflecting what they actually do. No wonder business people despair of IT where the language used does not reflect the detail of capabilities. In microservices expectations would be a small application ready to deploy for a business outcome yet it is now clear they are pre coded building blocks which is exactly what we created but would never have applied such a term. Anyone know who started the marketing of this tag....? Maybe BPM.com should bring common sense and reality to tags which help deliver the BPM supporting solutions?
  1. John Morris
  2. 6 months ago
  3. #5382
+1 Boris "unmanageable spaghetti havoc".
  1. John Morris
  2. 6 months ago
  3. #5384
David, good point about "marketing tags", e.g. "RPA".

Let's go further, on the basis of your suggestion. Starting from the idea of "technology tags" (or names), if we broaden the discussion out, let's consider the idea of "human-comprehensible" labels for technologies and technology artefacts.

When one builds with software, one is building a "vocabulary" of technology and business. And thus a "language" which enables discussion of technology and business. A poor language cannot support a great discussion.

Going even further, as BPM is also about "manufacturing new business tool artefacts", we encounter the idea of "first-class citizenship", i.e. that business ideas become directly addressable when instantiated as software technology artefacts. This is the whole justification of BPM -- the concepts of work are first-class citizens of a technology. And we build even more of them with BPM, e.g. "Underwriting Process No. 03".

All this might seem terribly abstract, except for the fact that the alternatives are worse.

You have to do the same thing with code, except one has just added layers of mediating complexity. Insofar as business "steps up" to take responsibility for the technologies of the work of their business, they will succeed. No black boxes. No free lunches. But a place for all the hard-won knowledge of every business person. BPM software waits to be used to drive more business, more efficiently, more effectively.
@John.. Re "BPM software waits to be used to drive more business, more efficiently, more effectively."

Do you mean "waits" or "wants"

Either way, orchestration and some governance provided by background BPM at Case run-time workflow/workload management platforms is key to operational efficiency and effectiveness.

The "some" caveat simply highlights that some governance has to come from corporation level "rules" that are not likely to be in individual Cases

e.g. Corporate directive to reduce cost of all initiatives that have costs of more than $1MM

This would cause a red flag to display at each eligible Case as and when Case Managers load such Cases.
“Interoperable aggregation of business objects” – fortunately, the pair BPM and MSA creates a high level of abstracts by specialization of business objects, i.e. not only business objects, but also, events, role, rules, processes, audit trail, reports, etc. As John said “BPM is also about "manufacturing new business tool artefacts”

Obviously, all these artefacts have their own trick and techniques. By understanding them, process-based applications may evolve very fast. Thus new IT darling “evolutionary architecture” from ThoughtWorks is already available.
  1. John Morris
  2. 6 months ago
  3. #5395
@Walter -- good question re: "waits" or "wants". My original intent was that BPM process tech is "waiting" to be used -- the promise of BPM process tech is not yet fully reailzed.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
From the answers above, I sense there's a fuzzy alignment of what microservices actually mean. Defining the boundaries of microservices requires an on-going architectural effort, in many cases missing from the focus of incumbent BPM consultancies.

For example, we at Profluo are taking a non-pretentious incremental approach, evolving microservices from "BPMN on steroids" to "autonomous executable business worklets". The amount of architectural work that needs to be embedded into the platform is staggering as we want to further automate integration/delivery. But it's the only way to reach that ever elusive sweet spot between agility and cost.

(relax, it's just an example, not a shameless plug - you guys are not our target customers :-) )

So, yeah microservices and BPM are made for each other - correctly architected microservices are perfect for BPM consultants, while process/case engines are perfect for microservices orchestration/choreography.
CEO, Co-founder, Profluo
Comment
Hmm, I think your last sentence may be reinforced - BPM creates (slice and dice) "right" microservices which encapsulated business artefacts. Because the business thinks about evolution as changes of their business artefacts then BPM+MSA enable the business agility. The trick is to know life cycle specifics of each business artefact.
  1. John Morris
  2. 6 months ago
  3. #5396
Maybe not "pretentious" but certainly "poetic"! And compellingly so.

As for the "amount of architectural work that needs to be embedded into the platform is staggering", this is a powerful comment. And coming from Profluo, one has to accept.

The implications though are huge. "Staggering" has to be a proxy for "cost" and a synonym for "complexity". It's difficult to imagine that "staggering costs" and "rapid adoption" can coexist. The solution is inevitably technical, but only made possible by economics. In other words, open source, shared development costs, syndication, channels and partners, the entire software ecosystem conspires to overcome staggering challenges. Profluo is there.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.