1. Peter Schooff
  2. Sherlock Holmes
  3. BPM Discussions
  4. Tuesday, 17 January 2017
  5.  Subscribe via email
There has been a lot of talk lately of the digital business platform. Do you think it is the future of BPMS, and if so, how is the digital business platform different than BPMS?
Accepted Answer Pending Moderation
Yes, I definitely believe in a future with an affordable Digital Business Platform concept :)

I've written recently here about this:

Digital Business Platform = system of experiences (portal) + system of engagement (process/case engine) + system of records (erp) + system of insights (bi)
CEO, Co-founder, Profluo

Software AG has a 'must - have" list for Digital Business" - seems to me your breakdown provides a good summary of the following

"Change enterprise IT landscapes from inflexible application silos to modern digital platform-driven IT architectures that can deliver the openness, speed and agility needed to enable real-time digital enterprises. Software AG offers the first end-to-end digital business platform—based on open standards, with integration, process management, adaptive application development, real-time analytics and enterprise architecture management as core building blocks"

Enterprise Architecture Management
Business Process Analysis
Governance, Risk and Compliance Management
IT Portfolio Management
Operational Intelligence
Business Process Management
API Management
Streaming Analytics
In-Memory Data Fabric
Transaction Processing

They have a good description of "BPM"


I agree, Karl, Software AG does have (at least on the face of it - I have not seen it live) a consistent set of capabilities.
They do however fall outside my own perception of "affordable".
@Karl, Awesome list and reference to Software AG. Definitely, everybody considering or working on BPMS must have it in primary view.
  1. more than a month ago
  2. BPM Discussions
  3. # 1
Accepted Answer Pending Moderation
The basic idea of BPMS is still great & valid: To cover the whole BPM lifecycle from modeling to automation to reporting. However, if you look at the feature/functionality focus of BPMS products today, customers often perceive them as "application development platforms" or even middleware, i.e. a technical platform that IT people use to build applications. Unfortunately, the business user community only plays a small role in this picture.

In my view, the big difference between a business transformation platform and a BPMS is that it puts the business people back into the focus.

From a lifecycle perspective, the platform has three pillars:
(1) Discussing, reinventing and communicating
(2) Automating/supporting processes - with a choice of different implementation styles (citizen-developer-style / no-code for simpler scenarios as well as developer-friendly / less-code for heavy duty, more integrated scenarios)
(3) Process analytics - both for the workflows that have been implemented through the platform, but even more importantly also for all other processes, structured and unstructured

In addition to the lifecycle dimension, a business transformation platform must not only focus on the traditional process dimension but serve a broader "business architecture" purpose (also covering business capabilities, decisions and application portfolio) as well as the customer experience dimension.
Co-founder & CEO of Signavio
  1. more than a month ago
  2. BPM Discussions
  3. # 2
Jim Sinur
Blog Writer
Accepted Answer Pending Moderation
I certainly believe that work management, including BPM, case management & other forms of process) is crucial to a digital business platform, but certainly there are other key components. These platforms will be much smarter than the BPMS as they will leverage AI or AI will leverage process. DBPs will be supporting distributed activity that will be handled by the IoT on the edge. DBPs will also include significant connections to other ecosystems and other open platforms. DBPs will also contain leveragable solution components, snippets and models. In addition they will include robotic program automation as well. These are all new dimensions that will need to be added or cooperating with an old school BPMS. Is this a BPMS V3? I'm really not sure, but there are parallels. I think a DBP is different myself, but its a hunch that will be played out or not.
  1. http://jimsinur.blogspot.com/2015/10/creating-digital-business-platform.html
  2. http://jimsinur.blogspot.com/2016/04/the-disruptive-rise-of-digital-business.html
  3. http://jimsinur.blogspot.com/2016/08/cognitive-and-process-better-together.html
  4. http://jimsinur.blogspot.com/2016/06/the-role-of-modeling-in-digital.html
  5. http://jimsinur.blogspot.com/2016/07/iot-will-rely-heavily-on-cognitive.html
  1. more than a month ago
  2. BPM Discussions
  3. # 3
Accepted Answer Pending Moderation
As with everything it depends how you look at it. From the platform provider the benefits seem to definitely out weigh the costs of building a BPM suite. However, there is an element of risk involved with relinquishing control and letting others develop on top of your platform.

The current speed of business almost requires large software enterprises to take this route because they can't compete with the speed of startup dev. teams. Also, it allows you to remain focused on your company goals and roadmap.

For the app/plugin/add-on developers they can can work must faster, for cheaper, and reach a much larger audience. However, they have the risk of having their entire operation shut down at any time.

Finally, and most important, is the customer. Here is where the real question lies. Are digital platforms better than a suite of tools? The answer is - it depends. Apple's App Store is a great example of how to provide a digital platform while mitigating risk as much as possible. The App Store has not hurt the Apple brand. If anything, the opposite has happened.

However, that example is from the B2C world. In the B2B world things may be more complex.
  1. more than a month ago
  2. BPM Discussions
  3. # 4
Accepted Answer Pending Moderation
Yes in fact vital for future delivery of digital Services. The S attached to BPM has in my view caused much puzzlement. Is it Software, Solution or the original Suite? Frankly I would abandon all as I would favour BPM being the powerful discipline to help thinking how to deliver required outcomes using a Digital Business Platform "DBP" oops another TLA...

The essential attributes of a DBP must be readily understood how it works and supports easy change by users and I would use the already established Adaptive tag to be associated with the end working solution. As for a key differentiation from "old S" ways is that DBP is complete platform including UIs and all back office support/collection of data etc AND the orchestration of legacy...NOT integration so to allow planning of retirement of old clunky legacy! This DBP should be a low / no code environment which will significantly reduce costs and aid transparency.

The use of a DBP driven the BPM discipline will be the start of a new journey delivering a future proof investment in Adaptive systems recognising how business really works focusing where all operational information is created and putting people first. As for BPMS .. RIP...?
  1. more than a month ago
  2. BPM Discussions
  3. # 5
Accepted Answer Pending Moderation
The fundamental mission of BPMS system is to stay on top level of enterprise IT hierarchy and streamline enterprise operations from a business viewpoint. Exactly for this reason, it is unlikely that BPMS as such will be ever able to become a universal digital business platform for process execution.

Real enterprise environments are always versatile. This is simply inevitable due to concrete application systems, software and hardware involved into concrete business due to its low level specifics and operations. This versatility increases with business size. Large companies always have hundredths and thousands software titles and application systems on their IT landscape. This versatility also increases with progress of digital platforms due to new devices and equipment with new interface standards and protocols appearing every day. There is no chance that any single BPMS system will be ever able to implement and host all this abundance of technology and standards.

In this situation of constantly growing complexity of digital technologies the only real chance for BPM to hold and strengthen its leading role in business improvement and transformation is staying on higher visionary and aggregation level by managing metadata and master data, rather than low level transactional data of digital platforms themselves. In this sense, the future of BPMS is in wide connectivity and supervision of principally plural digital business platforms of a modern diverse enterprise, rather than in merging and dissolving in any of these platforms.

@Boris,,, You raise an important point " ..no chance that any single BPMS system will be ever able to implement and host all this abundance of technology and standards"

I agree, with the caveat that we should avoid widening the definition of BPMS to attempt to complete with, for example, the Software AG capabilities I listed above.

I have a bit of a problem with '. . .fundamental mission of BPMS system is to stay on top level of enterprise IT hierarchy and streamline enterprise operations from a business viewpoint".

I would be happier with "fundamental mission of BPMS system is to stay at the core level of enterprise operational IT hierarchy and streamline enterprise operations from a business viewpoint"

It seems that "Case" needs to be at the top of enterprise operational IT hierarchy, given the need to accommodate any mix of structured vs unstructured work.

We know that BPM is core to Case, so I am really not objecting to anything.

The issue is that with Cases being a mix of structured work and unstructured work plus the fact that most people work on more than one Case at a time, where each Case, at the extreme, could be using a common template, the key requirement seems to be able to accommodate Resource Allocation, Leveling and Balancing (RALB) at the operational level.

This is why many "efficiency" initiatives fail - i.e. the sum of wait times between process template steps can rival, even exceed, step performance time. Then we have "S" curve where each interruption requires some dis-engagement time and later, re-engagement. Of course, things can go the opposite way where too much concentration on one thing brings the user to where their productivity suffers.

So, in my world of huge shifts between structure work and unstructured work, Case is the top level of IT hierarchy for operations, BPM and RALB are core to Case and IT also needs to have a top level of IT hierarchy for strategy and, here, I would say that is "free-form-search Knowledge bases"

I am working on an interesting initiative right now where we want performance to be zero i.e. protection from intrusions at industrial sites - here we hope never to have to engage any processing and if we do, we hope to never need to run an engaged process to it's end.
@Karl, Excellent notice! Of course, "core" is the right word here, not "top", which I ve used. I was actually thinking this way but misspelled finally. Please refer also the picture in my earlier post where I show BPM in core, rather than on top, graphically.

Case is extremely important. I can only agree with your every word here. Not accidentally, we have "Case" in our company name. We always stress this aspect in discussions with clients. Cases serve very much as process' atoms.

Also, balancing processes around zero equilibrium is of utmost importance from optimization viewpoint. Funny enough, a tiny handful of managers can precept real value of zero balancing. Probably, they have never read really on neutral portfolios. Zero is the universal ground from where you can only measure true process efficiency. I am keen to hear more about your advances in this direction.
  1. more than a month ago
  2. BPM Discussions
  3. # 6
Accepted Answer Pending Moderation
In my typology of platforms [ref1, ref2], digital business platform is actually Corporate Unified Business Execution (CUBE) platform. BPM-suite tools is an essential component of such a platform to enable agile/extreme delivery of solutions. If BPM done correctly then a lot of existing "enterprise" applications are implemented as a set of processes.

The CUBE platform pattern enables synergy between diversity and uniformity thus it is critical to address some uber-complex systems domains such as e-government [ref3], healthcare [ref4], IoT [ref5], smart-home [ref6] and smart-city [ref7].

  1. http://improving-bpm-systems.blogspot.ch/2015/12/typology-of-platforms.html
  2. http://improving-bpm-systems.blogspot.ch/search/label/%23platform
  3. http://improving-bpm-systems.blogspot.ch/2014/10/e-government-reference-model-gegf2014.html
  4. http://improving-bpm-systems.blogspot.ch/2014/07/technology-enabled-healthcare.html
  5. http://improving-bpm-systems.blogspot.ch/2016/11/thing-as-system-reference-architecture.html
  6. http://improving-bpm-systems.blogspot.ch/2016/12/smart-home-as-system-of-systems.html
  7. http://improving-bpm-systems.blogspot.ch/2014/07/smartcity-project-proposal-call-for.html
Alex, as discussed briefly when we met, your CUBE reference is spot on :)
Thanks Bogdan, hope that BPMS vendors will listen out for it at one moment.
  1. more than a month ago
  2. BPM Discussions
  3. # 7
Accepted Answer Pending Moderation
Here is how I would articulate what a Digital Business Platform needs...
• Process engine - to ensure all works to plan.
• Rules engine - reflecting real world ofwork and compliance.
• Calculation engine - automating system work.
• State engine - Real time feed back from any point.
• Workflow - everything connected in right order.
• Audit trail, events, escalations - = control with empowerment.
• Rapid prototyping - user involvement in build no need for a final spec
• Time recording - supports activity based costing.
• Real time reporting - becomes predictive.
• Build mash ups - one screen multiple data sources.
• Linked intelligent Ajax grids - enter data only once.
• Roles and performers - people and machines recognised.
• Management hierarchy - see who does what and when to reallocate work
• MDM Orchestrating legacy with business processes as required - recognition of valuable legacy data and functional systems
• Call Web Services - wrapped up in a process.
• User interface dynamically created linking people, roles, task type and data via forms for specific instances.- supports adaptive capability
• Content handler and in memory work capability - to ensure high performance.
• Pre-built templates for custom documents, letters, e-mails, messages etc dynamically populated with instance specific data and edit capability in browser - recognition of external communications documents etc
• Process and task versioning control – ensures minimal disruption, if any, to implementation of changes
@David, awesome reference list for a platform. However, I m not sure, if we should go so low technical level, as mentioning, e.g., AJAX. Technologies change too often. It is also hard to assume that all these components will optimally live inside a single BPMS system. As @Karl pointed out above, BPM is rather the core than an implementation of all these functionalities.
Well we managed it and you need all these to deliver on the BPM requirements.Yes quite accept such as AJAX will be improved bettered etc that's why you need an architecture that can readily absorb such capability into the Platform.
  1. more than a month ago
  2. BPM Discussions
  3. # 8
Accepted Answer Pending Moderation
I think, pertaining to Peter's question, that it makes sense to add one thing in the mix: a Digital Business Platform of the future will hopefully exhibit the stack described above by the various responders, however, at any given point in time, the same DBP may choose different products to make up the stack, depending on the customer situation / preferences / vendor affinities.
Thus I believe that a monolithic BPMS that does it all out of the box may become less relevant (and more toxic) over time.
So the DBP may not be the future of the BPMS race, but rather an entirely new species.
CEO, Co-founder, Profluo
RE "rather an entirely new species" From the architectural point of view, yes. Although some modern BPM-suite tools have a lot of functionality which is needed for CUBE-like platform.
  1. more than a month ago
  2. BPM Discussions
  3. # 9
Accepted Answer Pending Moderation
Re David's line item "Content handler and in memory work capability - to ensure high performance" . . .

A practical example of the need for content/in-memory work capability is corporate knowledge bases where there is an expectation of being able to view stubs for thousands of documents at one screen and navigate the "sheet" as a giant bit map.

See the images in my 2014 blog post "3D Strategic Planning – What you need to know about it" that features a US State Dept Country Profiles demo database (all countries, business, travel, law enforcement, narcotics, terrorism, etc.)

An example of the demo kbase in use is documented at the 2nd URL. " It’s Time For You To Get Your Big Data Organized"
  1. http://wp.me/pzzpB-FX
  2. http://wp.me/pzzpB-x8
See McKinsey's 2011 prediction on "big data"

"Big data will become a key basis of competition, underpinning new waves of productivity growth, innovation, and consumer surplus—as long as the right policies and enablers are in place"

Looks like an update to that 2011 report see http://www.computerweekly.com/news/450410461/McKinsey-finds-hard-work-to-do-in-Big-Data-Revisited-report?utm_medium=EM&asrc=EM_EDA_71253437&utm_campaign=20170118_McKinsey%20finds%20hard%20work%20to%20do%20in%20Big%20Data%20Revisited%20report&utm_source=EDA

Seems more difficult...but operational business is about small data......much better to put resources into this now much easier and quicker deliver of business knowledge and intelligence as to what is actually happening real time?
Thanks, David..

Very interesting update. I suppose we should always be mindful that no one focus is sufficient (i.e. we need to look at strategy/operations; big data/little data; data mining/AI).

I would love to get to where we don't have to map out operational processes. Start with some basic templates that go "start -> end" and then, via data logging at Cases, see what real-time variations users generate and build up processes on the basis of statistics (i.e. at step 3, they engaged sub-path 3a 60% of the time and 3b 40% of the time).

Strategy, however, remains a connect-the-dots exercise where if you don't have dots you cannot connect them. This takes us to Donald Rumsfeld's "known knowns, known unknowns, unknown knowns and unknown unknowns) which I see as the foundation for strategic decision making. (intelligence + knowledge -> information)

The best example of connect-the-dots I can think of is a law enforcement investigation where the authorities receive thousands of "tips", most of which turn out to be bogus.
  1. more than a month ago
  2. BPM Discussions
  3. # 10
Accepted Answer Pending Moderation
It's worth asking what domain we are in when discussing the question of the future of BPMS in a DBP.

Consider that our domain for the question is the domain of "software product lifecycles", which includes both the question of the "definition of software product", "management of software product lifecycles" and "product management, product marketing and sales and marketing of software products". (Let's ignore the question of SaaS, which is only a distinction concerning delivery.) These concepts are explored for example by the folks at the Software Engineering Institute or at Pragmatic Marketing.

So, what can be said about BPMS and DBP considered as a question of software product definition and management?

The answer to this question is important, because you can't sell something that you can't define. And I submit that a DBP lacks the specificity required as a defined software product. Here's a facetious definition of DBP: "Everything but the kitchen sink" or how about "All technology that has ever been built for management".

At the same time that DBP is a hyper-generalized and amorphous concept, we lose the real business value that is expressed by the irreduceably unique business technologies that make up a DBP, including for example BPM, business rules, analytics, UX etc. etc. Especially considering that we are discussing this question on BPM.com, the loss of attention to BPM is especially a concern. BPM automation software is powerful and repays business user attention for full value realization; between BPM technology maturity, BPM sales issues and BPM user adoption issues, the full promise of BPM technology has not yet been achieved.

The decision by end-users and business leaders to buy a software product is the flipside of selling a software product.

That buying decision also implies buying into the investment necessary to make the use of that product a success. So the question of software product definition is also a question about business buying decisions. Does our software product definition and packaging make it easier for business people to buy? Again I submit, as with the sell-side question, that DBP lacks the buy-side specificity required for efficient software product sales. It's difficult decision when you are offered a choice of "buying everything but the kitchen sink".

Let's look at sell-side and buy-side software product definitions. The combinations of technical modularization, sell-side packaging and buy-side packaging significantly drive technology evolution. Here are three helpful examples:

1) MANUAL AUTOMOBILE TRANSMISSIONS FUNCTIONALITY -- The percentage of automobiles sold with manual transmissions has fallen dramatically in the last decade, with the improvement in automatic transmissions and the change in consumer technology culture. It no longer makes sense to highlight the manual transmission as part of most automobile sales. TECHNOLOGY NO LONGER PART OF MARKET DISCOURSE

2) BPM SOFTWARE FUNCTIONALITY -- BPM software technology is not yet mature (despite the recent claim that BPM engines are commodities, a claim that can be contested) and success using BPM software technology is widely variable depending on attention and investment. TECHNOLOGY CAN STILL BE PART OF MARKET DISCOURSE

3) ACCOUNTING SOFTWARE FUNCTIONALITY -- Accounting software is about as commoditized as it is possible to imagine; and yet accounting software (perhaps realized in a larger ERP system etc.) is still a unique part of any business DBP and the subject of an entire ecoystem of professional attention. TECHNOLOGY CAN STILL BE PART OF MARKET DISCOURSE

My concern is that the real technical and business value of BPM (realized as BPMS) will be lost when mashed into DBP blobs.

Maybe a follow along question could explore the implications of the idea of DBP in terms of economics, market concentration and market power. Another follow along question could be whether or not DBP delivers emergent functionality, i.e. real software power that is greater than the sum of component parts, or where DBP is only a reification of individual components (which itself may be still valuable in terms of discourse).
I would argue that to a buyer a platform must be complete ready to use and avoid the complexity of mixing components or as you say "blobs" ? The vendor must do the work to deliver the simplicity so that their platform is complete? Otherwise not a platform?
  1. John Morris
  2. 3 years ago
  3. #3150
David, your point is well taken. You are highlighting the risk of integration and the cost of assembly if one doesn't go with a DBP. On the other end of things though, with DBP there is the risk of lock-in, the cost of the platform, and the risk that individual components may be substandard, and these risks may not decline with time. Major vendors are betting the farm on DBP comprehensiveness; but customers may perceive it's a reservation at the Hotel California -- you can check in but you can't check out etc. Pop-culture references aside, for some corporates DBP is absolutely a good play, for sure, depending on IT strategy. On the other hand, I have highlighted the fact that some technologies are not mature. Especially this is true of BPM. My fear is that BPM via BPMS-embedded-in-DBP will be second rate BPM, with all the attendant frustrations and sub-optimizations with which the BPM community is familiar. It may be too early.
You make a good point about lock in that's why the buyer must have tool set in his control to effect any changes. Our early experience saw buyers want access to the core code no problems but after a few years they realised did not need it as the Platform covered all needs. As for too early we were couple of decades too early!....Howevet we stuck with it and such debates show the market is now ready but yes challenges in the minds of buyers as articulated are still there....
RE "My fear is that BPM via BPMS-embedded-in-DBP will be second rate BPM" As I said, CUBE platform or DBP is not a product but a pattern, enterprise architecture pattern. Either a client develops applications which are sitting within a BPM-suite tool (which is a programmable monolith) and gets a perfect lock-in. Or BPM-suite tool works together with other "enterprise" tools to deliver solutions in an architected, planned, incremental and "snow-ball" way.

Hope that, at one moment, DBP will become a product - when the business architecture is executable and the whole enterprise is software-defined.
RE "so that their platform is complete? Otherwise not a platform?" Any modern mobile phone (the simplest analogy of platform) is complete because it has some level of functionality and not complete as everyone enriches his/her phone with many apps.
  1. John Morris
  2. 3 years ago
  3. #3155
Thanks Alexander for emphasizing the correct approach here. You are certainly right to highlight that a platform is not a product but an architectural pattern (e.g. per CUBE).
In retrospect I realize that my note was off target, with a focus on product over platform (I haven't changed it). I do note that products and platforms are different sales artefacts; generally speaking a licensing or subscription contract is going to be for a product -- the platform is only implied. One could engage a consultant to implement a platform approach, a different beast entirely.
I do think my note though does correctly capture the importance of distinguishing technology domains and product packaging issues. The DBP "platform" question too easily leads to magical thinking. The question of DBP is a very, very big question, and only works with serious architectural support.
And my last paragraph is useful - the DBP question is (a) on the sales side very much about market power and (b) on the technology side, very much about the question as to whether there is any real emergent functionality with a DBP, beyond the technologies we already have. If there is emergent functionality, then we are back to product!
Surely a Platform is an environment which enables the creation of a a custom requirement. A product is an prebuilt solution ready to deploy? In software a platform will have indeed must have an architecture which enables the build of any custom requirement. Our research established that business logic never changes nor will. Sure delivery advances gadgets / IoT are built but the underlying process logic never changes. So build that logic into the architecture ready to be configured and you have a platform ready to build the required "product"? I am very concerned business people will be confused and not understand an architectural pattern....detracting from the power offered by a Platform which simplifies build of adaptive custom requirements as the end product?
John, "If there is emergent functionality, then we are back to product!" Hmm. I would say that it is normal to add to a platform-of-interest a product with emergent functionality without "breaking" platform. For example, some BPM-suite vendors add RPA to their product. Important that the product with emergent functionality adds only that emergent functionality and re-uses available functionality available from the platform.

Also, it is normal that a solution on top of a platform may bring some innovative functionality which can be later incorporated into the platform.

See http://improving-bpm-systems.blogspot.ch/2011/04/enterprise-patterns-peas.html
Alexander your last comment mirrors how we evolved once the core process capability built. For example being client server in original design we created web capability was then incorporated into the Platform - and in such a way it is easy to upgrade existing systems/products There will be more to come but that core business logic never changes thus need for coding removed. It's the vendor's job to take complexity and simplify for business users to understand and take control of their processes.
David, " but the underlying process logic never changes" - Do you mean that an enterprise's mission (and, to some extent, its value streams) is slow or never changing? Agree. But "classic" business processes (including their flow-charts, rules, roles, etc.) can be changed rather frequently. (Look at the football or any sports rules - they are changed to make the game more interesting and fair).

Considering that BPM-suite tool is an essential component of such a platform then the platform's diversity and uniformity is achieved by assembling of solutions from various artefacts - existing, modified (versioned) and new ones.

RE "It's the vendor's job to take complexity and simplify ..." sure. Although my current mobile phone is much more complicated then the first one, the former is much more simpler to use than the latter.

More on “. . .It’s the vendor’s job to take complexity and simplify”

Yes, but many do a very poor job.

In healthcare (USA), they did a particularly bad job, but to be fair, much of the direction was set by government MU incentives.

I did not do myself much of a favor in healthcare by re-naming “Meaningful Use” to “Meaningless Uselessness”, but if Obamacare goes out the window tomorrow I may have a “last laugh”.

The main impact of MU seems to have been to convert docs into “data trolls”.

Contrast this with pro-video, where IMO vendors have done a superb job over a short period of time going from bulky box camcorders to what today (e.g. Panasonic GH5) looks like an “ordinary” DSLR but is actually an extraordinary 4K movie-making machine with the ability to do still photos. The innovation is not confined to cameras. Only two days ago I saw a 7 inch HD monitor coming on the market at $200 (excluding accessories) compared to $700-$1,000.

In pro-video, the platform for a video company varies according to whether the focus is on run-and-gun, stage performances, documentaries etc. Some companies do all three. Basically, you load up a truck with everything you have and set up a custom platform on site. It would be disastrous for any one vendor (light, camera, sound, NLE vendor) to try to build one platform.

Curiously, we continue to see 30-year-old technology at sports events that seems to work just fine.

Anyway, the notion of “platform” makes much more sense to me than ‘product’ for BPM. I like Alexander’s “Or BPM-suite tool works together with other "enterprise" tools to deliver solutions in an architected, planned, incremental and "snow-ball" way.”

Within our group, we tend to market “development environments” – our Kbase “product”, for instance, loads up with a blank screen. It has absolutely no functionality until you start dragging and dropping data points. How you connect them or do not connect data points is strictly up to you.
Re John's concern, "loss of attention to BPM "

I don't see a DPB causing a loss of attention to BPM unless DPB vendor go out of their way to prevent BPM from being a core (i.e. in-your-face") component
  1. John Morris
  2. 3 years ago
  3. #3173
Walter your question is a pressing one, concerning whether BPM would be lost in DBP. It's also a difficult question in multiple dimensions. Consider just two unresolved questions:
(1) EXISTENTIAL QUESTION -- Does a DBP actually exist? Is DBP actually sold? In other words, "is there a there, there" . . . i.e. functionality which is more than the sum of individual parts, including the "glue parts", formerly known as ESB and/or SOA? Oh, and add to DBP "consulting services", which quickly lead to "environmental uniqueness". One could argue for or against the proposition that DBP is just the natural evolution of ever more powerful software technology, but that there isn't any specific, emergent, unique functionality that comes with the acronym DBP.
(2) MORAL HAZARD -- BPM is unique and important technology, which is central to business (as I've argued in the Paper Series, "BPM As Revolutuionary Enabler"). To be successful, BPM technology also requires pioneering levels of management commitment. In the rush to achieve "business transformation" however, which is the promise of DBP, it is almost inevitable that both vendor and user alike will defocus from BPM-as-core. Especially where consulting services are involved, this defocusing is almost inevitable.
  1. more than a month ago
  2. BPM Discussions
  3. # 11
Accepted Answer Pending Moderation
Anyone still here?

Maybe we need to think of a Digital Business Platform as s corporate asset comprising a selection of closely-coupled functions, mainly for reasons of convenience and efficiency, plus, via inter-operability, another collection of loosely-coupled functions?

e,g, for the work I do, Case is my operational platform of choice and I expect BPM, RALB, CRM, ECM and FOMM to be within easy reach.

Not so for CPM because I only need/want to perform ES-EF-LS-LF calcuations for once-through projects, so, here, I am willing to shop around for a CPM environment, make sure it has some way of taking in input other than via keyboard and that it has some way of exporting calculated results. Let's not forget that I also have to do the linking.

For closely-coupled functions there is, of course, interoperability, but it is hidden. I don't see it, I don't need to understand the details of the mechanism.

I am willing to put up with some minor irritants relating to the platform.

Up to a point.

The thought of blocking off native functionality and having to write parsers/formatters and manage data transport/encryption makes me stay with my platform. More than, say, three awkward interface issues, though, and I will be in the market for a new platform.

The big question is "if you build it, will they come?" and part of the solution involves corporate culture, with another part being willingness to hone the UI so that it truly makes work easier for users to log in as opposed to not logging in.

Industries that have "no verbal orders" policies have an easier time.

Here, the users get a user ID, and with a few simple policy statements in place, they quickly realize that the easy way for them to get work done and to gain access to work done by others is within the platform.

Run templates of the core BPM processes, deviate to a reasonable extent, but if you go rogue and go out of your way to perform a sequence of steps NOT using an available BPM process template, you quickly get hit with a number of pre-processing alarms as you present with missing data the process sequence would have ensured would not be missing.
  1. http://www.kwkeirstead.wordpress.com
  1. more than a month ago
  2. BPM Discussions
  3. # 12
  • Page :
  • 1

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