2009-12-11

The aim of this paper is to match BPM (see annex A for some BPM basics) and the process improvement approach used in the CMMI-SVC v1.2 [1].

The summary is the following:1. understanding of BPM discipline is very beneficial for improving your CMMI processes 2. staring from “defined processes” (capability level 3) it is necessary to use BPM suite software3. moving to higher levels requires the serious thinking about architecting of your BPM system to support your CMMI processes

Next, two overused terms

Service is an explicitly-defined and operationally-independent unit of functionality. Service is a black box to produce some assets. Service is an external perspective of a function. One or many distinct functions can be fulfilled by a service.

Process is an explicitly-defined coordination of services to create a particular result. Process is a white box to produce some assets. Process is an internal perspective of a function. Process is a composite from many different artefacts (roles, rules, assets, functions, etc.).

Remark: Services and processes can be considered to be intimately related since in real terms

all processes are services,

some functions of a service can be implemented as a process, and

a process includes services in its implementation.

So, at an enterprise we may have many elementary nano-services which are organised into a mega-service, i.e. the whole enterprise.

And a very controversial term at the end

Capability is the possession of characteristics required to produce a particular outcome. The latter is a pair “right things” (assets) and “done well” (performance, reliability, etc.) as the result of work of a function (regardless how this function is implemented). So, a capability combines functional and non-functional characteristics (timeliness of outcome, data accuracy, quality of result, efficiency, effectiveness, impact on stakeholders, SLA, SLE, etc.) of a function. Important to note that a capability describes some kind of expected characteristics of a function, but not actual results demonstrated in particular cases. This is similar to normal cars are which capable to do 200 km/h, but they rarely go faster than 130 km/h.

Are capabilities the building blocks (easy to move, reorganize, outsource, etc.) of business? Only if a corresponding function is exactly a service (so, the function is operationally-independent and it can be improved without causing any negative effects).

Functional characteristics are known from a function itself. Non-functional characteristics can be obtain from specifications (as defined in a contract or a description), by measurements (performance testing) or by design. The latter option means that a function (a part of the whole service) can be implemented as a process for which performance characteristics can be obtained from the performance simulation of the process template. In some cases, obtaining non-functional characteristics by design is the most practical way.

A possible scenario

Stakeholders:OK tell us about your brilliant idea.

Future CEO:We plan to provide to the market a product WHAT1 manufactured from WHAT0 with the performance WHY1. This will be fullfiled by function HOW1 implemented via service ServiceHOW1

WHAT1 = ServiceHOW1(WHAT0) // Magic happens here

Stakeholders:Sounds good. But, is ServiceHOW1 capable to operate as required by WHY1?

Business architect:The desired performance of ServiceHOW1 is guaranteed by its implementation via ProcessHOW1. In some way, WHAT1 is decomposed into a set of WHAT2x. WHY1 is decomposed in a set of WHY2x. All together will be coordinated by this process.ProcessHOW1 = {coordination1, HOW2*, WHAT2*, WHY2*, WHO2*, WHERE2*,... }

Stakeholders:Please continue until black boxes become too trivial so they can be bought, rented, outsourced and easily implemented.

2) Advance from just being DNA or “enterprise genotype” (a full nomenclature of enterprise artefacts) to provide a formal link with “enterprise phenotype” (a set of observable characteristics such as performance).

2009-11-06

I would like to introduce you to my new book "Improving enterprise business process management systems" has just been published. This book looks at the following three concepts of BPM:

[the theory]

BPM as a management discipline;

[the tools]

BPM as a software (BPM suite);

[the practice]

BPM as a portfolio of the business processes of an enterprise, and the practices and tools for governing the design, execution and evolution of this portfolio (BPM system).

In particular this book concentrates on the last concept which is often neglected although all enterprises need it. This book will help you to industrialise enterprise BPM systems. It describes a holistic approach to the application of BPM and SOA for improving enterprise business performance, including

1) visit their production to look over the shoulders what they are doing2) choose a group of super-users and train them about BPM and business process modeling3) select a few business areas and do business process modelling with the super-users for these areas4) train their IT about BPM/SOA5) implement with their IT a few operational prototypes for the selected business areas6) present the results to the top management7) listen/reflect their feedback8) tune the used methodology (i.e. my book "Improving enterprise BPM systems") for their needs9) let them improving their processes by themselves10) help/guide them if requested

At present, we have vendor-centric BPM and this is good ... for vendors. At the same time we don’t have a commonly agreed BPM reference model, or a good set of standards (e.g. for exchange diagrams between different tools), etc.

I believe that it is time that BPM progresses from being vendor-centric to become customer-centric. A good example of customer-centricity is the current situation with web browsers – all vendors of web browsers want to benchmark their product against the ACID3 test (acid3.acidtests.org) to demonstrate their compliance with standards. Once such a baseline has been established, it becomes easy to compare the performance of products. I hope that a similar tendency will be established in the BPM field whereby vendors of BPM software will compete in terms of compliance with standards and product performance.

Interesting that the W3C maintain a coherent set of standards for HTML: a) xHTML for structure and content, b) CSS for presentation, c) DOM-based API for dynamic modifications, and d) some other specialized standards.

The business world understood a long time ago that services and processes are the backbones of most enterprise business systems.

A service is defined as "an explicitly-defined and operationally-independent unit of functionality". A process is defined as "an explicitly-defined coordination of services to create a particular result". So, at a process-centric enterprise we may have many elementary nano-services which are organised into a mega-service, i.e. the whole enterprise.

Services and processes are related in the following way:- all our processes are services,- some operations of a service can be implemented as a process, and- a process includes services in its implementation.

Often, it may be useful to consider a service as a black box where no information about its implementation is available. Alternatively, it may be useful to consider a service as a white box where implementation details of all its operations are available.

Although the relationships between processes and services are unique and rather complex in each enterprise, the use of explicit definitions allows the formalisation of dependencies between them.

If we look at BPM then we can see three different concepts:

1. BPM discipline which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries

2. BPM system -- enterprise portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

3. BPM suite -- coherent set of software tools for facilitating the implementation of a BPM system

At the same time, SOA -- architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services

The relationships are between SOA and BPM are:SOA provides recommendations for the implementation, execution and governance of services. The BPM discipline, by revealing the BPM artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services. Ideally, a BPM system is built with the use of SOA and a BPM suite often acts as a tool to provide composite services.

Business processes are VERY important because they serve as an EXPLICIT implementation of some services thus allowing determine/calculate the performance of those services. So, the capabilities of those services are known, proven and controllable – what the business wants.

In addition, the proper design of business processes and architecting BPM system can add a lot of flexibility into a business system.

2009-10-03

The abbreviation BPMS is assumed to be “BPM suite” -- coherent set of software tools for facilitating the implementation of a BPM system. The latter is a portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio.

So, architecting of BPMS depends on architecting of enterprise BPM systems. In the latter, business rules are building blocks used within business processes.

The relationships between services and processes are the following:- all processes are services,- some operations of a service can be implemented as a process, and- a process includes services in its implementation.

As the result, any enterprise has its own unique structure of services/processes; but there are some common patterns. Please note, that this is a product-independent view which may be different from ESOA.

Actually, services which are fully implemented by processes may be considered as capabilities.

At first, talking about business architecture (BA) is relevant if the business is considered as a system. So, BA concentrates on the conceptualisation and evolution of the form and structure of the top level view of an enterprise as a system for conducting the business.

Remark 1: This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals.

Remark 2: The issues of greatest importance for BA are the following:- the core end-to-end business processes (also known as value streams);- the governance structures;- the core business information (semantics);- the communication with the core business partners.

The abbreviation BPMS is assumed to be “BPM suite” -- coherent set of software tools for facilitating the implementation of a BPM system. The latter is a portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

Remark: Any process-centric enterprise has its own enterprise BPM system. The enterprise BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

So, your enterprise BPM system has to be design in accordance with your BA and BPM suite is a tool (which is necessary, but not sufficient) for implementing your enterprise BPM system.

Sure that a modern BPM suite is necessary, but not sufficient for a good enterprise BPM system - "an aircraft carrier should never operate alone".

In the absence of agreed reference models and proper standards, creating good enterprise BPM systems implies serious architecting efforts. Below I comment your list from the architectural point of view.

1. Your own enterprise "worklist" application has to be considered regardless of a BPM suite "web portal". The users want to handle business processes in conjunction with their business objects, e.g. business cases.2. Business events (receiving an order) are often already available somewhere in your enterprise systems. Just link them with your processes.3. Automatically generated forms are usually considered only for quick prototyping.4. Existing reports are usually considered only for quick prototyping. 5. By definition, business objects as BPM artefacts have to be externalised. Dreaming to keep them within a BPM suite is wrong from the beginning. 6. Audit trails and KPI are other BPM artefacts -- put them out of a BPM suite, by definition.7. Documents are yet another BPM artefacts. Keep them out and do not forget about records management.8. Handling of roles (also a BPM artefact) is usually difficult. I usually recommend to create a set of groups oriented to processes, e.g. process owner, activity workers, etc. and to populate these groups from available resources (processes are useful for that).9. Agree - patterns and anti-patterns are necessary for constructions of complex processes (see my blog http://improving-bpm-systems.blogspot.com/ for some practical process patterns).

I think that any discussion about the architecture of enterprise BPM systems is step from the current vendor-centric BPM to customer-centric BPM.

2009-09-29

A very good list from Michael to which I would like to offer a few additionsa. (explicit) list of events important for the subjectb. audit trails pertinent to the subjectc. (explicit) KPI of how good/bad the subject is governed

2009-08-25

a) historical — workflow was originated within ERP systems to improve their flexibility; but often such a workflow is not visible. Effectively, BPM offers the externalization of workflow, so, BPM and ERP are very complimentary;

b) methodological — in the absence of an agreed reference model for BPM it is difficult to compare impact of different BPM implementations;

c) managerial — popularity of ERP is based in the long-term practices of US management to focus primary on the stock optimization. At the same time Japan was developing process-oriented practices;

d) architectural — re “Of course it’s impossible to say which way is better - a unified system from a single vendor or the integration of various \“best of breed\” systems”. I think, a network effect should be used as a guidance — moving from the former to the latter decreases efficiency and increases effectiveness. So, choose what you need now.

In my experience, there are neither only human processes nor only automated processes. Each automated activity within a process should be encapsulated into an "error-recovery loop" which may include a human activity. For example, a fully automated conveyer at a car factory has some side lines to "do" some cars manually.

A fully "automated" process may have a human task to watch the process - in the same way that an observation window allows one to observe the workings of a turbine.

Each human activity is surrounded by automated activities - similar to a good secretary who prepares documents for a boss and later takes care about them.

- augment it with appropriate process management methods,-- In addition to production (or horizontal) processes, I recommend to develop some controlling (or vertical) processes; the latter helps people to validate execution of production processes.

- define proper rules for process managers that don’t only cover system functionality but also address process results,-- controlling processes may signal potential problems to humans as well as propose some adjustments. For example, an assurance company guarantees that each claim is processed in less than N days (i.e. there is an SLA) and claims over 50$ are checked manually; when this company receives a wave of claims, a controlling process by detecting this wave may propose either to increase the staff for checking those claims or to adjust a limit (from 50$ to 100$) so more claims will be treated without manual check.

- responsibility and accountability should play equal parts in process management jobs and should address clearly defined processes,-- who is responsible for a process template, a process instance, a process activity.

- don’t design your processes for the sunshine case only – also look at process risk management issues.-- fault-tolerance, error-recovery, comprehensive traceability, etc. are important for BPM design and execution; actually, the power of BPM helps us to address those issues in different ways, e.g. if a problem is caused by a user then a super-user may receive a task to resolve this problem.

In the broadest sense and as already mentioned, an architect is a person who translates a customer’s requirements into a viable plan and guides others in its execution.

In the case of enterprise, the "roles" from this definition can filled in the following way: “customer” = top management, senior executives “wishes, dreams and expectations” = creating a new company, merger, changing of unit’s internal structure, survival in heavy competition, cost cutting, modernisation of legacy applications, outsourcing the whole unit or just its IT environment, portfolio rationalization, etc. “others” = the whole enterprise

An enterprise can be, for example, a business unit or department, an entire corporation, a government agency or a collection of businesses joined together in a partnership. An enterprise can be considered as a system whose parts are people, processes, information and technology. In general it is a complex and dynamic system of systems.

I use a term “enterprise business system” for the top level view of an enterprise as a system for conducting the business. This top level view may concentrate on how the business is structured, what it does and what it needs to do to meet its goals. The issues of greatest importance for enterprise business systems are the following: • the core end-to-end business processes (also known as value streams); • the governance structures; • the core business information (semantics); • the communication with the core business partners.

Architecture of a system is, in some sense, the main tool to work with the system. Architecture comprises two inseparable parts: descriptive (nomenclatures of artefacts, relationships, etc.) and prescriptive (rules on how to evolve this system). Both of them may be implicit or explicit or somewhere in between. Both of them are used together in “what if” analysis of different changes.

So, “architecture of an enterprise business system” or “business architecture” -- coherent and proven set of principles, recommendations, practices, and tools which provides guidance and practical help for the design and evolution of enterprise business system to achieve enterprise vision and strategy.

2009-08-12

This book (http://michaelpoulinssite.homestead.com/My-Book.html) perfectly reflects the current way of advancing in the computer science – the author is debating a lot of topics with a lot of people. Quotes are thoroughly analysed and supplied by contra-arguments. The whole book is a dynamic discussion similar to the work of an SOA consultant who should be able to discuss any question and any opinion about SOA. Logically the book is stimulating the reader to follow the same rule – debating the author’s position. I found this great. Anyone who is touching SOA should read this book to derive his/her own opinion.

For example, I don’t agree that process is “just implementation” of services – the former are also explicit and executable and understandable by the business. Executable process is the way to make bigger services from smaller services.

Another point – the definition of SOA from OASIS RM which, in my opinion, is more applicable to the modern economy than to construction of software-intensive systems. It is well-known that the business world understood a long time ago that services and processes are the backbones of most enterprise business systems.

Finally, I wish Michael to publish soon next book with his experience about the implementation and evolution of SO enterprises.

I would use the following pattern:8.3.11 Decide, Execute, Control – DEC patternThis pattern (see figure below) covers the case where a parallel branch complements the normal working activities. This branch provides a control mechanism – it comprises a human activity which allows somebody to watch what is happening with a particular process instance (in the same way that an observation window allows one to observe the workings of a turbine).

The evolution of some artefacts and the relationships between them is necessary to accommodate typical changes in enterprise policies, enterprise priorities, compliance, technology, laws, etc. So, to be agile and responsive in business, it must be easy to modify all artefacts and their relationships without causing any negative effects (e.g. unexpected delays and undesired consequences) in any part of the BPM system.

I think that the four main architectural principles are necessary to achieve a high level of flexibility:1. All artefacts must be versionable throughout their lifecycle.2. All artefacts must evolve to become digital, externalised, virtual and components of clouds.3. All relationships between artefacts must be modelled explicitly.4. All models must be made to be executable.

More relationships are explicit and executable –> more knowledge about functioning of the enterprise -> more predictable results -> more rational decisions -> more comprehensive optimisation.

The best example of explicit and executable relationships between business artefacts is process -- who (role) is doing what (objects and activities), when (coordination of activities), why (rules), how (activities) and with which results (KPIs).

I think this approach follows the discussion, especially the previous post from Michael.

2009-07-06

Re "... a much more complex process architecture" I offer the follow fragment from my docs.

<quote>1.6 Your flexible BPM system will become an enabler for business innovations

A typical task for a BPM system is to balance the final added-value of the product against the overheads associated with restructuring and/or tuning the enterprise business system to create this added-value. Today market success is often based on offering personalised products for less overhead. This book is not about how to make your products better, different or more attractive for the market – this is for you to decide. What this book can offer is to help you reduce the overheads in doing so – your flexible BPM system will become an enabler for your business innovations.

Imagine that each product is handled by a personalised and dedicated “virtual” business micro-system. The micro-system is optimised for a particular product and evolves together with the product lifecycle (see figure below). As a result, any exception becomes the norm. Instead of reducing the number of variations and considering exceptions as a loss in productivity (“20 % of the work takes 80 % of the time”) all products are treated equally. Of course, this is already the case for the manufacturing of expensive products such as aircrafts, cars and, to some extent, computers, but such an approach is also applicable to a wider range of commodities, especially those treated/handled with software-intensive systems.

2009-07-03

I think that both Anatoly's diagrams are anti-patterns. Previous comments gave a good explanation about the second case. Also, there are many different considerations (e.g. be ready for future changes, avoid mixing of added-value and mechanical activities, etc.) to present some work currently done by the same "person" into a set of activities.

I would like to use the first diagram as a "stress test" for BPMN - how a middle-man management can be expressed as a process. This pattern (called MMM) is an example of decentralised coordination. There are four participants who/what share the coordination: buyer(B), manufacturer (M), middle-man (MMM) and a common-sense procedure for mutual agreement (AGREE). Each participant has his/her/its own pool which contains participant's view of this process.

From the picture, it is obvious that MMM does no useful work -- just dispatching events+data others.

2009-07-02

Sure that classic EA frameworks create some kind of “enterprise genotype” (a full nomenclature of enterprise artefacts) which is not yet well connected to “enterprise phenotype” (a set of observable characteristics such as performance). This is one of the reasons for current difficulies with the construction of business systems which match clients' expectations. (I would like to have EA as good as an applied science).

2009-07-01

To debate efficiently, I would start from definitions of three different concepts under BPM "umbrella" (see also http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html)

BPM discipline, noun discipline which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries

Remark: At present, the BPM discipline is the best way to implement process-centric enterprises.

BPM system, noun portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

Remark: Any process-centric enterprise has its own enterprise BPM system. The enterprise BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

BPM suite, noun coherent set of software tools for facilitating the implementation of a BPM system

So, in accordance with these definitions, business process automation (BPA) is an integral part of the BPM discipline. We implement BPA within enterprise BPM-systems with the help of BPM suites.

4.6 Avoid the trap of the selection of “top-down” vs. “bottom-up” – use the “pinball” style

Another typical symptom of getting stuck in the design phase of your BPM system is the existence of endless discussions about the necessary “granularity” of the services:

“If we select a top-down style then we will create coarse-grained business-related services, but we are not sure whether such services are implementable or reusable. If we follow a bottom-up style then we will implement too many fine-grained services for which the business value is not obvious.”

Actually, any such discussion is misplaced at this stage. What should be discussed is how to build future flexibility into the enterprise BPM system which will allow the rapid and painless adaptation of services to increase or decrease their granularity. Small and agile improvements may be required in different layers – rather like the multiple refinements of a ball trajectory in a pinball machine.

This pitfall is extremely common, so take care! We think its root is in the traditional (vs. agile) development practices which aim to provide a perfect system straight away – in such a system all services shall have the “right” granularity.

2009-06-30

The classic EA is some kind of “enterprise genotype” (a full nomenclature of enterprise artefacts) which is not yet well connected to “enterprise phenotype” (a set of observable characteristics such as performance).

I think that a formal link between can be done via “enterprise executable model” – EA enhanced by BPM and SOA.

process, noun explicitly-defined coordination of services to create a particular result

Remark: Services and processes can be considered to be intimately related since in real terms • all processes are services, • some operations of a service can be implemented as a process, and • a process includes services in its implementation.

BPM discipline, noun discipline which allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries

Remark: At present, the BPM discipline is the best way to implement process-centric enterprises.

BPM system, noun <enterprise> portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

Remark: Any process-centric enterprise has its own enterprise BPM system. The enterprise BPM system may not be perfect (e.g. some processes may be only documented on paper, some details are only “located” only in the minds of certain people, etc.), but it does exist.

BPM suite, noun coherent set of software tools for facilitating the implementation of a BPM system

SOA, noun architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services

The relationship: SOA provides recommendations for the implementation, execution and governance of services. The BPM discipline, by revealing the artefacts (roles, events, rules, object, KPIs, etc.) and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services.

You are right – BP modelling is important. Obviously, each person models in his/her own, but a good modelling procedure can help different people to find out same artefacts which will be implemented via reusable services.

2009-06-24

I think that content and processes are complimentary: - processes help to generate better content (integration, security, collaboration, SLAs, quality, etc.) and - content help to make better processes (serving needs of a person who is carrying out a particular task, smart routing, KPIs, etc.)

What mixture of content and processes you need in each particular case -- all depends. And this is a very dynamic balance - each time the point of most leverage may change.

I think that a properly architected BPM can significantly improve PLM.

2009-06-03

Richard,All depends. I recommend each time to find the point of most leverage -- it may be in automation of existing processes or in changing them.

Often the business people know what is wrong – some kind of “performance errors”. For example, the decomposition of such complex human activities into a mixture of automated and simple human activities not only saves work time and improves the quality of operations, but can also open up the possibility to delegate certain of the new simple human activities to less-qualified staff members. In one particular enterprise in which this decomposition was carried out for the activities of one group leader, we economized their time by about 1 man-month per year.

Sure that any of principle is just an advice. It is quite normal to break any them if you know the reasons which are behind a particular principle and how they do match to a particular situation. For example, in the chess game is it recommended to novices do not exchange the queen vs. a pawn, but such an exchange can be a part of a combination which leads to the checkmate.

2009-05-28

Interesting post, because understanding of relationships between elements (i.e. BPM, SOA, and EA) of a system is the way to understand these elements. A few comments.

I define BPM and SOA slightly different.BPM, actually, covers three different concepts (see Should we consider third (forgotten) BPM?):1) BPM as a discipline or methodology 2) BPM as some software, i.e. BPM suite3) BPM as a system for managing of business processes with an enterprise

SOA is architectural approach for constructing software-intensive systems from a set of universally interconnected and interdependent services (service is an operationally independent unit of functionality)

Relationship between BPM and SOA :BPM discipline, by revealing the artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services.SOA provides recommendations for the implementation, execution and governance of services.

To build a good enterprise BPM-system, others (BPM discipline, BPM suite, and SOA) are necessary, but not sufficient. A good architecture is mandatory.

BPM and SOA are more than views of enterprise architecture (EA). Classic EA gives only "enterprise genotype” (a full nomenclature of enterprise artefacts) and it does not provide “enterprise phenotype” (a set of observable characteristics such as performance). A possible way to achieve a formal link between "enterprise genotype” and “enterprise phenotype” can be enhancing of EA by BPM and SOA which are able to define "enterprise executable description”.

2009-05-18

A short answer - there is no a commonly agreed BPM reference model which can give a context for BP notations.

An explanation by example. In my BPM reference model, BPM discipline allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries.

The main difference of the BPM discipline from previous process-centric methodologies is the need to have a single formal description of the business processes which can be used to model, automate, execute, control, measure and optimise them.

Agree with Ricardo, that expressing of business processes in any notation should serve to communication between people. But, I believe, such a notation should be also executable to validate that communication. (just a sidenote -- I think that any program code should be written to communicate a solution between people.) So,• A BPMN-like modelling notation should use a standard execution semantic which can be validated and which guarantees the adequate interpretation of models by different software for different uses, e.g. for functional testing, performance simulation and execution. (I think, this is similar to Brian's post).• It should be possible to represent the same business process model with different levels of detail, e.g. a high-level view for a normal user, and a more detail for a business analyst.• There should be a modelling procedure which guides different people how to use these different levels.• Details of the execution of business processes should come from a coherent set of standards, similar to that provided by the W3C for HTML: a) xHTML for structure and content, b) CSS for presentation, c) DOM-based API for dynamic modifications, and d) some other specialized standards. (At present, W3C works also on some recommendations for HTML5 which include several API for Web application, i.e. the execution environment.)

It seems that W3C standardisation approach for HTML is rather solid. I like it as a good example of customer-centricity which is proved by the current situation with Web browsers – all vendors of Web browsers want to benchmark their product against the ACID3 test (acid3.acidtests.org) to demonstrate their compliance with standards. Once such a baseline has been established, it becomes easy to compare the performance of products.

I think that the current BPM is still vendor-centric and we have to make customer-centric BPM.

Situation:A “non-BPM” project for replacing about 30 separate publishing systems by a more modern electronic publishing system. The particular difficulty in this project was the project members’ perception that their business processes are so special that it is not possible to find a single system which is suitable for everyone. As a result, the project did not progress at all despite two years’ of heated meetings.

Task:Unblock the project.

Action:Together with the project members, we carried out a quick BPM modelling of the most important business processes and derived an agreed list of about 20 common services which covered the majority of needs for everyone. The difference between many of the processes analysed was only in the logic of using those services (e.g. different sequencing, different routing, etc.).

Result:This agreed list of common services and the ability to easily combine services into processes were used as selection criteria for a new electronic publishing system. The project was completed and the new electronic publishing system has been selected.

Note:You may say that this is not a good example of BPM. I think, that without a commonly agreed BPM reference model it is not possible to compare BPM projects.

2009-05-05

I use a modelling procedure which I think avoids some of these pitfalls. The purpose of the modelling procedure is to analyse a building block (what it is supposed to do) and to synthesise its implementation (how it does this) as the explicit coordination of other building blocks (processes or activities). It is an iterative procedure – we can apply it until we have left only indivisible building blocks (i.e. activities). During modelling, we collect and refine different artefacts (including data, rules, roles, KPI, etc). We consider that building blocks are constructed recursively, like Russian dolls, to avoid getting bogged down in detail.

2009-04-27

I would approach the “BPM in the cloud” topic from a) a BPM reference model and b) an architectural framework for improving enterprise BPM systems.

At first, it should be clear the definition of BPM. I think, the most important BPM is “enterprise BPM system” which is a portfolio of business processes of the enterprise, as well as the practices and tools for governing the design, execution and evolution of this portfolio as a system. Well-known BPM as a discipline and BPM as software are used to implement this “third” BPM (see http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html).

The BPM reference model tells us that any enterprise BPM system is a complex and dynamic set of interconnected and interdependent artefacts: events, processes, rules, roles, objects, services, etc. The evolution of some artefacts and the relationships between them is necessary to accommodate typical changes in policies, priorities, compliance, technology, laws, etc. So, to be agile and responsive in business, it must be easy to modify all artefacts and their relationships without causing any negative effects (e.g. unexpected delays and undesired consequences) in any part of the BPM system.

The architectural framework defines the four main architectural principles necessary to achieve a high level of flexibility.

All artefacts must be versionable throughout their lifecycle

.

All artefacts must evolve to become digital, externalised and virtual

.

All relationships between artefacts must be modelled explicitly

.

All models must be made to be executable

.

The second principle can be extended that, finally (see figure below), the artefact should be able to exist somewhere in a “cloud” (i.e. somewhere on the Internet without any knowledge of, expertise in or control over the technology infrastructure that supports it) and should be available whenever needed. Although the concept of cloud computing is still in its infancy, our experience shows that the best use of this concept requires botha. a customer-centric (i.e. not vendor-centric) “cloud” andb. the internal preparedness of an enterprise to put its artefacts into the “cloud”.

I think, that this approach can reduce the cost of moving to clouds, because it considers a possibility to use clouds from the architecture of the system. Also it can help to define that SLA should be required for a particular “clouded” service, because explicit and executable models provide enough information to evaluate how the availability of a particular service contribute into the availability of higher services.

2009-04-20

I agree with Anatoly's diagramms and think that they can be more explicit -- namely, by separating humans' added-value work and administrative work to "animate" the process. So, there are 4 pools, as shown below:

Both human participants -- candidate and HR manager -- follow their internal processes (COOR02 and COOR01 respectively). The latter carry out the coordination (some kind of choreography). Those processes are "the main thing" to be made EXPLICIT by a business analyst.

2009-04-17

I propose to give a context first. My sequence of concepts is the following:

1. Improving enterprise business performance is a permanent imperative and a daunting task these days.

2. Evolving of an enterprise as a complex system requires its rational construction.

3. The best (so far) approach for such a rational construction is process-oriented enterprise. [The business world understood a long time ago that services and processes are the backbones of most enterprise business systems. ]

4. The best (so far) method for the realisation of process-oriented enterprise is BPM (as a discipline -- allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries) [other methods for continual performance improvement -- BPR, TQM., ISO 9000, lean, TPS, Six sigma, etc. well contributed]

5. Each process-oriented enterprise has its own "enterprise BPM system" (portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio) [it may not perfect, but it does exist, e.g. as ISO 9000 quality management system].

6. A specialised class of enterprise software -- BPM suite (coherent set of software tools) -- is used for facilitating the implementation of an enterprise BPM system.

7. As a rule, BPM suite is necessary, but not sufficient for good implementation of an enterprise BPM system -- other information technologies (EA, ECM, SOA, BI, BAM, BEM, ITIL, etc.) to be considered together.

1. The legacy of process disciplines is a great asset which should be used correctly. My advice is “How you do something may be more important than what you do” – customise the message to the target audience.

2. Agree. Terminology is a pain and there is no agreed reference model yet. Hope that bpmnexus.ning.com can improve this situation.

3. Don’t think so – in my experience if the third BPM is architected / designed / implemented correctly then it becomes a disruptive technology with many advantages.

4. It is never late to do good things (especially at your own home!).

5. It is well knowna that the mentioned technologies are very rich and overlapping, so they should be used partially and with critical understanding. Actually, explicit use of the third BPM simplifies the enterprise business system because BPM guides how to use other information technologies.

7. I think, the dot-com crash had a positive effect also – I saw dot-com architects moved to classic environments where they found issues from the real production.

8. Agree – at present BPM is vendor-centric. It should move to become customer-centric.

9. People is the most difficult aspect of the third BPM - “How you do something may be more important than what you do”.

10. BPMS is not the most critical part of the third BPM. Start small and adjust your tools as needed. Good architecture will help.

I believe that people in enterprises and projects should consider by themselves where modelling stops and execution starts -- not tools.This would be the fisrt step from vendor-cenric BPM to customer-centric BPM.

2009-04-02

<discussion group="BP Group">Does the world need a BPM Manifesto ?I have to ask, with all the furore the Cloud Manifesto has created, does our world need a once-and-done framework to finally define the who, what, why, where, how ?</discussion>

2009-03-16

Agree with Ilia - terminology is needed, as well as, a BPM reference model and a few BPM reference architectures. Those (of course, commonly agreed) are the base to explain to any customer how BPM can address his/her concerns and how BPM can change his/her work for the better.

I believe this is a way to transform the current vendor-centric BPM into customer-centric BPM.

2009-02-04

Jean-Jacques,I like you approach to look wider than just BPMN vs BPEL and consider a multi-layer architecture for process-centric composite applications in which many of existing technologies would co-exist. Do you know a (maybe, virtual) place where such a wider scope can be discussed? Topics for discussion, for example, are: BPM reference model (offer my contribution http://www.slideshare.net/samarin/bpm-concepts-de-base-presentation ), BPM reference architectures, etc. I think they should lead us to a commonly agreed architecture for process-centric composite applications.

2009-02-03

I am glad that this discussion turned to the description of a better BPM. I like your list and believe that such a list should include more BPM functionality, not just modelling.

For example, my list of essential requirements for the ideal process development tool (which is an extension of the modern process modelling tools).

• A BPMN-like modelling notation should use a standard execution semantic which can be validated and which guarantees the adequate interpretation of models by different software for different uses, e.g. for functional testing, performance simulation and execution.

• It should be possible to represent the same business process model with different levels of detail, e.g. a high-level view for a normal user, and a more detail for a business analyst.

• There should be a modelling procedure which guides different stakeholders how to use these different levels.

• Details of the execution of business processes should come from a coherent set of standards, similar to that provided by the W3C for HTML: a) xHTML for structure and content, b) CSS for presentation, c) DOM-based API for dynamic modifications, and d) some other specialized standards.

• Different types of artefact should be easily accessible from a business process development environment.

• It should be easy to plug additional DSL-like tools for the explicit definition of relationships between artefacts into the business process development environment.

• It should be possible to reduce and eventually eliminate the need for the explicit use of intermediate formats such as BPEL and XPDL.

• It should be possible to offer some techniques for improving the comprehensibility of business processes by all stakeholders.

I believe that it is time that BPM progresses from being vendor-centric to become customer-centric. A good example of customer-centricity is the current situation with Web browsers – all vendors of Web browsers want to benchmark their product against the ACID3 test (acid3.acidtests.org) to demonstrate their compliance with standards. Once such a baseline has been established, it becomes easy to compare the performance of products.

I hope that a similar tendency will be established in the BPM field whereby vendors of BPM software will compete in terms of compliance with standards and product performance.

But, as the first step, we need an agreed BPM reference model, of course.Thanks,AS

2009-02-02

I would compare your shock with a shock of a person who looked first time at a human’s internal organs in live (I saw a beating heart once - not nice). Personally, I want to say huge thanks to Intalio for making a lot of BPM internals FREE, EXECUTABLE and EXPLICIT. Of course, some poor-man solutions are used so far. For example, all data messages are synchronous – an extra exchange is required to implement asynchronous communications, use of two languages (BPMN and BPEL), etc. Sure, Intalio is not perfect and they had some strange ideas (e.g. zero-code). Fortunately, they consider some critics with Business Edition and Developer Edition.

Returning to the diagram – it can be done by an analyst in the following way:

Also, the current Intalio implementation of human tasks is not a “fault” of BPMN, but the result of the usage of BPEL. At the same time, Oracle SOA Fusion invented some macros to hide this complexity in their BPEL. WebSphere (not IBM Designer) has a very comprehensive human task manager and a human task is a single “block” in their BPEL (because Websphere uses extra SCA/SDO layer).

Concerning Sandy’s “...consider people as first-class process citizens.” – it is an old story (after some problems in some industries) about automation of human work. “It does not mean that the goal is to replace humans by programs. On the contrary, the human is in command as he/she is responsible for the outcome. Any automation is to help the humans to carry out their work.”

Finally, all depends how you organise the work between business analyst and other people within the team - who should produce which artefacts. With Intalio you may have more choices.

2009-01-31

ProcessCafe blog -- Five Simple Questions, No Easy Answers - The process versionOnce again I defer to Amber Naslund over at the Altitude branding blog for her excellent post entitled Five Simple Questions, No Easy Answers.

It prompted me to see if there are similar questions that could arise in the process world

1. If you could change something about the way process management is tackled as it is right now, what would that be? Why would that improve things?

2. Give me a definition of 'process management' for a newbie, and you can’t use the words “BPM”, “Software as a service”, "process" or “tool”.

3. I’m a successful company, and I’m not yet looking at managing my processes or defining a process management capability. Why should it matter to me if what I’m doing isn’t broken?

4. Tell me the real challenges I’ll encounter as a business when I’m starting managing my processes. Now tell me why I should bother overcoming those when I have enough issues to deal with already - especially in this current economic environment.

5. Take 'process management' out of the sandbox. Tell me how else it moves business forward, operationally, culturally, otherwise, and how I can justify the cost of doing this.

What other questions are bugging you? (I have one more)

6. If people keep talking about BPM as something that is tool based, does it mean that I can't do this without spending money on equipping my organisation with these tools?</post>

1. There are two major enablers for carrying out the optimisation of the enterprise as a whole:a) tools and pertinent information to help people in better decision making, andb) a guarantee that the enterprise is capable of implementing the necessary changes at the required pace.

2. BPM discipline allows you to model, automate, execute, control, measure and optimise the flow of business activities that span the enterprise’s systems, employees, customers and partners within and beyond the enterprise boundaries

3. There are two ways people use their cars – change each 3 years or use them up to complete break then buy a new one. Check what is the way of the majority of Management Board and follow their arguments.

4. Architecture. Thanks to the current economic environment even the G20 understood that a complex arrangement should start with its architecture.

5. Done correctly, BPM will add unprecedented flexibility and will become an enabler for your business innovations.

6. There are BPM discipline, enterprise BPM system (portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio) and BPM suite (coherent set of software tools for facilitating the implementation of a BPM system). You may implement your enterprise BPM system without a BPM suite, but the latter can simplify such an implementation.

2009-01-27

Research by World Health Organization ("New England Journal of Medicine" 2009 Jan 14, doi:10.1056/NEJMsa0810119 ) shows that use of a simple 19-point peri-operative checklist - checks immediately prior to and during surgical operations - reduced complications by one-third (from 11% to 7%) and deaths by 40% (1.5% to 0.7%). The results, from a large statistical base (c.7500 cases) were much the same in rich and poor countries. The English-language version of the checklist is at www.who.int/patientsafety/safesurgery/en . What equivalent 'peri-operative' checklists could we develop for enterprise-architecture and business-architecture? What results could we achieve with such checklists? And how would we verify their value? (Discussion posted to both The Enterprise Architecture Network group and Business Architecture Community group.)

</question>

My client has a checklist for the technical architecture -- each IT project should present such a list before the technical evaluation (which is before the financial evaluation of the project). The main reason is to prevent surprises in deployment and maintenance (e.g. high disponibility requires a special configuration of Oracle). Typical topics are: • Architecture générale • Support et maintenance • Exploitation • Architecture poste de travail • Middleware • Architecture base de données • Services business intelligence • Services éditiques • Services Génie Logiciel • Services gestion documentaire • Services sécurité • Métier • Interopérabilité • Réseau

As there are some dependencies between items of this checklist, we provide a simple configurator which uses many (business and technical) questions and some rules to derive the actual checklist.

2009-01-26

lt;question group="BP group">Designing a business to be 'flexible' - what does that mean and how would one go about it?I started a discussion a few days ago about the 3 P's of a professional organization. There were many thoughtful responses and I have enjoyed hearing from everyone. Nice group of people. Several of the responses referred to the idea of having a flexible company or needing to be able to quickly adapt. I am old enough to know that when people use words they may mean something very different than what I am thinking. So my question to you is What does it mean to be a flexible comany? What does that look like? I need tangibles, not ethereal explanations. I would like responses to tell me exactly what I would need to do if I were CEO of a company to have it be flexible, capable of adapting to unexpected events. Looking forward to hearing from you. www.stankirkwood.com

</question>

I will talk about flexibility of the enterprise BPM systems as an architect (this is from the book "Improving enterprise BPM systems" www.improving-BPM-systems.com).

It is considered that each process-centric enterprise has its own BPM system -- a portfolio of business processes of the enterprise, as well as the practices and tools for governing the design, execution and evolution of this portfolio as a system.

Our experience shows that the business usually wants separate requests for change in the IT environment to be implemented quickly. These changes are typically small (from the point of view of the business staff) but unpredictable (from the point of view of IT staff). The current practices of software development have failed to provide a good solution to this challenge. • “80 % of software life cycle costs occur during the maintenance phase”, and• “80 % of maintenance is due to unmet or unforeseen user requirements”.

Actually, any BPM system is a complex and dynamic set of interconnected and interdependent business artefacts: events, processes, rules, roles, objects, services, etc. The evolution of some artefacts and the relationships between them is necessary to accommodate typical changes in policies, priorities, compliance, technology, laws, etc. So, to be agile and responsive in business, it must be easy to modify all artefacts and their relationships without causing any negative effects (e.g. unexpected delays and undesired consequences) in any part of the BPM system.

A characteristic of BPM systems is the high level of non-trivial linkage between different artefacts. This requires a focus not only on individual artefacts (breaking a system into constituent parts), but also on how these artefacts are interlinked between themselves and with the external environment. The importance of relationships is based on the approach (based on systems thinking) that the individual parts of a system can be best understood by looking at them in the context of their relationships with each other and with other systems, rather than in isolation. An example of a complex relationship is a process template which is an aggregation of events, human and automated activities, roles, objects, rules, audits, etc.

Because a particular improvement (created as a set of modifications) may be spread between different parts, different processes, different stakeholders and different technologies, to achieve transparency and a general comprehension, it is necessary to have a coherent set of guiding principles which are mandatory for all parts of the enterprise business system. These are architectural principles from a architecture framework for improving enterprise BPM systems. • All artefacts must be versionable throughout their lifecycle• All artefacts must evolve to become digital, externalised and virtual• All relationships between artefacts must be modelled explicitly• All models must be made to be executable

The architectural framework is not about how to make your products better, different and more attractive for the market place – this is for the top managers to decide. What it offers is to help enterprises reduce the overheads in doing so. The reduction will come from continual improvements in the BPM system itself – each new project will be carried out under the same architecting and implementation guidelines and practical help, thus aligning people’s understanding and different practices, tools, methods, processes and services. At one moment, your flexible BPM system will become an enabler for your business innovations.

2009-01-23

What do you (your company or clients) use Enterprise Architecture for? Think of Enterprise Architecture in action (from experience), how it is used and for what.I know it sounds like a strange question, but I want you to think - what is EA really used for... to understand the enterprise form all perspectives? to use as a tool to explore and discover opportunities for change? to facilitate change?...or to guide change? (there is a difference between these two) to define transformation? to empower project/program contributors and stakeholders? to manage projects? to facilitate managerial decision making? to manage growth? to facilitate strategic decision making? to enable cross-functional/domain integration? to present how IT domains relate to each other? to drive IT strategy? etc.....I'm sure there are lots more uses, especially beyond an IT centric approach Not looking for explanations of, or references to TOGAF, Zachman etc. Please make this practical...for what (and how) is Enterprise Architecture used in your experience?

</question>

A client just created a EA unit which provides the following services:

1. Validate a solution's architecture at different stages of the project - EA unit requires use of approved architectural components for the technical part of a solution - EA unit recommends a few prototyping environments (one of them is base on the BPM discipline and a BPM suite) for the business part of a solution

2. Guarantee coherence of architectural components

3. Optimisation of architectures for future needs (e.g. having solutions more adaptable)

4. Internal consulting

We recommended this client the following:

Definition: The EA unit is a group of like-thinking minds responsible for proactive evolution of the architecture of the enterprise.

Mission statement: The mission of the EA unit is to provide guidance and practical help for the design and evolution of IT and business to achieve the enterprise vision and strategy.

Objectives: The EA unit (together with a forum of architects) develops and maintains a comprehensive set of recommendations, models, patterns, examples, tools and training materials.