About "Architecture"

I noticed that the word “architecture” is used more and more in the meaning of “architecture of a complex system”:

- The big bosses from G20 (“thanks” to the financial crises) are talking about “international financial architecture”.

- Just before the Copenhagen meeting we can hear about “Toward a post-Kyoto climate change architecture”.

- Recently, the Europarliament was talking about “a new global security architecture”.

So, there is growing understanding that any big (just bigger that yourself) “endeavour” should start from its architecture.

Thanks,
AS

Linkedin: Process Consulting ! Steps / Tools / Input / Output

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=113496&discussionID=8252361&commentID=7342881#commentID_7342881" />


1) visit their production to look over the shoulders what they are doing
2) choose a group of super-users and train them about BPM and business process modeling
3) select a few business areas and do business process modelling with the super-users for these areas
4) train their IT about BPM/SOA
5) implement with their IT a few operational prototypes for the selected business areas
6) present the results to the top management
7) listen/reflect their feedback
8) tune the used methodology (i.e. my book "Improving enterprise BPM systems") for their needs
9) let them improving their processes by themselves
10) help/guide them if requested



Thanks,
AS

Linkedin: Are we overdue for a BPMS shakeout? Or is the large number of software vendors offering tools in this area a good thing?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=73876&discussionID=7700343&commentID=7157602#commentID_7157602" />

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.

Wish that we can have something similar in BPM.

Thanks,
AS

Linkedn: Is there more to modern application architecture than SOA? How do we include BPM, data management and Web 2.0?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36604&discussionID=7512884&commentID=7157050&goback=.anh_36604#commentID_7157050" />

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.

Thanks,
AS

Linkedin: Architecting BPMS Platforms...

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=36248&discussionID=7932821" />


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.

Thanks,
AS

Linkedin: What is the connection/relation between Biz Architecture and BPMS?

<discussion ref="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=84758&discussionID=7932497&sik=1254599906913&commentID=7082844&goback=.anh_84758.ana_84758_1254599906913_3_1#commentID_7082844" />


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.

Thanks,
AS

Blog: Demo vs. Production BPM-based Systems

<discussion ref="http://mainthing.ru/item/212/" />

Bravo, Anatoly. This is an excellent overview of some problems originated in mixing of "BPM as software" (a.k.a. BPM suite) and "enterprise BPM system" (what is implemented within an enterprise to manage its business processes). See also --- http://improving-bpm-systems.blogspot.com/2009/04/should-we-consider-third-forgotten-bpm.html

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.

Thanks,
AS