Your business processes make up an essential part of your business. They incorporate your intrinsic intellectual property and make it available, consumable, and usable by your workforce. Although it is evident that BPM promotes and provides continuous improvement, business agility, and process visibility, there is a price to pay for such benefits. The simple act of exposing your processes and data to your users implies a substantial responsibility to protect and track that data.

From a governance perspective, a CoE must indicate how your data and processes are protected and how process actions are recorded and can be audited for both legal and business requirements. A CoE must establish the infrastructure and practices that will protect your intellectual property from both internal and external threats.
 
Table 3.4.4/1

Table 3.4.4/2

The shared infrastructure group should also be responsible for how process applications are deployed to various runtime environments (including production). This responsibility includes defining procedures for acceptance, processes for approval to promote into each runtime environment, best practices for these actions, and clearly defined roles around them.

In addition, from the perspective of CoE platform support, a goal is to have well-behaved process applications deployed in environments. A well-behaved process application requires little to no support from the platform team, does not exceed its projected capacity estimates, and does not affect other process applications. Instilling a basic set of coding and process architecture best practices can help in meeting these goals.

One of the overriding goals of the platform team is to promote self-reliance for the process teams. The less the process teams have to ask the platform team for information or access to resources, the more efficient the process teams can operate.

Define the release criteria for the delivery team to follow so that a process application can be deployed on an available runtime environment. These criteria might include minimum standards such as installation instructions, use of an export file, standard unit test results, standard business information about deployment packages, and so on.

What are the steps that must be followed to deploy a candidate snapshot (build) of a process application into a target runtime environment? In some cases, this deployment might involve certain approval steps from both business and IT. Deployment might also involve prerequisites. For example, deployment to user acceptance testing (UAT) might be prohibited until after the process application is deployed in QA and accepted by the business process owner.

In certain cases, an executed deployment might need to be rolled back because of unforeseen issues, which might be technical or business-related. In these scenarios, a defined process must be in place for rolling back a deployment into its last accepted state. This definition again might require approvals from both business and IT, certain acceptance criteria, and perhaps a break-fix environment to replicate the offending condition that caused the rollback request in the first place.

Auditing process applications can take various forms. The shared infrastructure element of the BPM CoE is responsible for determining which audit types are required for the organization, and then to mandate the appropriate design, development, deployment and operational best practices to ensure compliance.

This type of auditing is also known as application-level logging, which differs from system logging. Application-level logging logs data from a business perspective and contains information such user name, process name, process instance, process step name, task ID, and associated relevant business data.

Without application-level logging, finding the problems, understanding process flow, or auditing user interactions can be difficult.

This type of auditing is typically used to satisfy legal regulations regarding who did what, when, why, and who approved it. Often, to remain compliant, applications that fall under SOX or other federal regulations must be able to produce audit logs of significant events.

Interjecting business log records into the system log is not appropriate:

• System log records are probably not meaningful to the business developer.
• System logs might contain sensitive information about the system or even other process applications that are running on the same platform.
• System logs might be inaccessible to the developers.