2010-02-26

Linkedin: Is BPMS Just the new name for Application Development?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=70120&discussionID=14249147&sik=1267196069489&trk=ug_qa_q&goback=.hom.anh_70120.ana_70120_1267196069489_3_1" />


Agree with Max that the goal is to be able to improve processes by the business without the existing burden of application development. To reach this goal it is required to architect the flexibility of enterprise BPM systems (BPM system is a portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio).

In many cases, an enterprise BPM system is a historical set of applications and each of them dilutes and mixes processes, events, rules, data, services, KPIs, etc. With the help of BPMS (software) and other modern tools we can externalize, make explicit and implement via DSLs those artefacts. This considerably increases flexibility – improving of processes will be assembling of better compositions from better artefacts. So, BPM (as discipline/concept, software and system used together) is disruptive innovation vs. application development.

Thanks,
AS

...


Thanks Mark, I will try to be more explicit ….

An enterprise is a complex, dynamic and self-evolving socio-technical system which consists of many artefacts. Some of them: processes, services, events, data structures, documents, rules, roles, data, documents, activities, audit trails, KPIs. Those artefacts are interconnected and interdependent. Because of new policies, priorities, compliance, technology, etc. we have to change the enterprise. Implementation of such changes necessitates the evolution of some artefacts and the relationships between them. It must be easy to modify all artefacts and relationships without causing any negative effects.

With the traditional application development the majority of artefacts is implicit (because they are coded in, for example, Java) and cannot be modified by their owners thus making the whole enterprise difficult to evolve. Principles for creating creating flexible systems are:
- All artefacts must be evolved to become digital, external, virtual and components of clouds
- All artefacts must be versionable throughout their lifecycle
- All relationships between these artefacts are modelled explicitly
- All models are made to be executable

Business process is the best example of a relationship between other artefacts: who (roles) is doing what (business objects), when (coordination of activities), why (business rules), how (business activities) and with which results (KPIs). So, business processes should be explicit and executable and this is done by BPM suites (or BPMS). Other artefacts are handled by different technologies/tools, e.g. ECM for documents, BRM for rules, MDM for data, etc. Now, instead of developing applications, we can assemble (of course with the help of SOA) artefacts around business processes thus increasing flexibility.

As processes (and services) are the major artefacts of this architecture, the use of BPM (as a discipline for using processes to manage business), BPMS (as a tool) and BPM system should be aligned. Sure, those three concepts can be used in separation – good processes are implemented in a Java program or BPMS as the only tool which includes all other technologies. But this still limits the agility of the enterprise.

A few extra resources are in my blog http://improving-bpm-systems.blogspot.com/2010/02/bpm-reference-model-fragment-01.html

Thanks,
AS
Post a Comment