Better BPM – 1

SUCCESS THROUGH SIMPLICITY

PREFACE

InteractionProfilingvsBiztalkExampleProcessforBlog

In this series of 12 blog posts I will introduce a brand new approach to Business Process Management (BPM). The innovative concepts in these posts have evolved from the numerous business transaction processing and case management systems I have encountered throughout my career. This first post is a high-level overview of a new perspective that offers a radical improvement to BPM automation in terms of simplification, development and maintenance cost-savings and re-usability.

 

I am calling the new design paradigm, “Interaction Profiling“. Actually, the title should be “Transaction Profiling” because that is what it really is. However that term has already been designated for network infrastructure capacity planning by monitoring the resource impact profile of business transactions on network infrastructure and extrapolating resource requirements commensurate with anticipated business growth or shrinkage. Interaction Profiling is a new application system design approach that determines the characteristics (attributes) of business transactions as they relate to the distinct data validation and business processing requirements specifically.  If you click on the graphic below you will see a high-level, conceptual overview of the main pillars of Interaction Profiling.

InteractionProfilingConceptsLinkedInLarge

The set of Interaction Profiles for a given application will encapsulate exactly how any transaction should be validated and handled in BPM terms simply by identifying the subset of profiles that match the transaction. This may not sound that impressive as a concept. However, the significance is enormous, once the full implementation is applied in a real world scenario. I have tested out the new design approach in a hypothetical Sales Order processing application prototype and I will support the designs and estimates as I go along with empirical evidence from the first, fully-working, Interaction-Profiling-empowered prototype system. In the hope of arousing interest in the ensuing blog posts, here is an introductory abstract of Interaction Profiling.

 

Interaction Profiling is a new paradigm that provides a fresh, object-oriented approach to Business Process Management (BPM). The concept focuses on the core types (profiles) of business interactions (transactions) in an enterprise business processing application system and derives the corresponding, table-driven validation rules and BPM tasks (and more) for each profile. Unlike existing approaches, which tend to be process / task – centric, there is no hard-coding of any validation or business processing logic. Based on the first prototype that embodies Interaction Profiling, it is estimated that the new paradigm will halve development times and costs for all future systems, once the first implementation has been constructed. On-going maintenance is estimated to be reduced at least one-third and possibly more, because changes to the validation and BPM tasks and rules really can be managed and controlled by the users themselves, with much less involvement from the IT support group, based on empirical evidence to date . This represents massive savings in development and maintenance costs and provides truly functional, fully-reusable components for any future application system.

 

In addition, organizations benefit greatly because the Users and managers are empowered with the tools to control their own business growth and changing business requirements to a degree never before envisaged. The profile level adds a new, User-definable dimension of marketing and commercial program possibilities to the existing Client and Product levels. This is a truly powerful, business-enabling feature. The re-usable framework in the first prototype application is a highly significant three quarters, approximately, of the full implementation of the hypothetical order processing system. This confirms the order of magnitude of the estimates and substantiates the significance of the savings. This blog is not pure research, but introduces a new design paradigm of considerable significance to all enterprise information systems.

 

INTRODUCTION

 

Existing business transaction processing application systems, which is most of them out there, typically include complex criteria for validating the individual transactions. A significant number of these systems (including all case tracking systems) also include a varying number of associated manual business processes that are required, in conjunction with the automated system, to complete the transaction life cycle. The validation logic and also the workflow aspects of these systems are almost always hard-coded, either directly in an executable program, or using designer-assisted specification facilities that require compilation, possibly XML declarative persistence or equivalent and staging through the ubiquitous develop – test – user acceptance – production staging.

 

The business process management (BPM) of the workflow operations is often provided by relatively complex, runtime, server-based, proprietary software that is usually expensive and requires considerable expertise to implement and manage. Some collaboration software products (Such as Microsoft’s SharePoint) offer designer-based workflow, but they are not truly capable of hosting a custom enterprise BPM application system that performs well and is inexpensive in hardware, software and support resources.

 

Interaction Profiling simplifies the specification, management and control of the validation and BPM logic by identifying the transaction profiles – those types of transactions that require unique data content in some way and / or a unique sequence of BPM Tasks – and associating with each profile the corresponding validation rules and BPM tasks and activities. The user comprehensibility of this approach is considerably increased because the individual profiles exactly model the differentiation that the users themselves apply in their daily operations. If they require, for example, specific and unique data for all retail, large box store Clients, then an interaction profile is required for transactions from such Clients.

 

If there are corresponding, specific BPM tasks for such transactions, the same profile can be applied. Essentially, an Interaction Profile is required for every type of interaction (transaction) that requires a distinct validation rule set or a distinct set of BPM tasks (or both). To enable an application system to apply these profiles automatically, the criteria that define each profile needs to be determined and stored in the application database.

 

There are different ways this can be accomplished, but a logical approach is to identify the characteristics / attributes of each profile that clearly define what that profile represents. As clarification, if we require a “Large Box Store, Retail Transaction” profile and assuming we have identified that we need a Trade Type (Retail / Wholesale / Charity…) and Customer Type (Corner Store / Large Box Store…) in our new, state-of-the-art Order Processing, or whatever, application, then both of these application fields would become Profile Attributes and our Large Box Store, Retail Interaction Profile would be defined using two criteria – Trade Type = Retail and Customer Type = Large Box Store.

 

Profile Attributes may be dynamic in nature as they may change during the processing of an individual interaction instance (transaction). A good example of this kind of attribute would be “Age in the system”, which often drives exceptional processing of some form to address transactions that are not being processed as fast as is desirable. A common business rule could be, “any transaction that has taken X days or more to process should be flagged for exception processing”. The Age in System Attribute would be used to define an “Overdue Transactions” Profile and the exceptional processing would be identified against this Interaction Profile. Thus the set of profiles that match a specific transaction can and will change throughout the lifetime of the transaction. The set of BPM tasks (and validation if pertinent) will vary accordingly, which is encapsulating within the system the business intelligence needed to ensure all transactions are automatically processed correctly throughout their lifetimes.

 

The design must accommodate multiple profile attributes for each profile in a many-to-many relationship. In this manner, an application will contain the full set of profiles and their definitions, so that the system can determine the exact validation logic required for every individual transaction and also the specific sequence of business processes that are required to process the transaction to completion. We need to design the capability to persist the validation rules and BPM tasks and activities in the database. In order to validate the data, we will need to include the application field metadata in the system. It is not necessary to include every single field, but any field that needs to be validated and / or used as a Profile Attribute must be included in the metadata.

 

In practice, this will not be as onerous as it may sound. The existing prototype system is representative of a small to medium-sized system (51 database tables) and contains 23 different Interaction Profile data rows, 15 Profile Attribute rows and 43 Application Field rows. It is likely that a large application system (over 100 tables) could require 50 or more Profiles, between 100 and 250 Application Fields and possibly 30 to 50 Profile Attributes. This is small potatoes in terms of database space and performance overhead.

 

We also include our Users, Organizational structure, the Roles that are required for security purposes to perform our business processes and which Users belong in which roles. If we tag our BPM data in the database with the roles required to perform our BPM tasks, we have now enabled our Interaction Profiling empowered system with the possibility of automatically routing transactions to those users who can perform the specific tasks. Furthermore, if we use Service Level Agreements with our Clients to promise completion times based on some kind of priority scheme, or if we use a priority scheme internally, it makes sense to include the target duration for each BPM task in the metadata. Now the system can tell exactly how to validate each transaction, the specific BPM Tasks required, their sequence, how long they should take and precisely which set of Users can perform them.

 

This extends the capabilities to include the possibility of workload balancing to optimize operations and spread workload evenly across the User community. Now we have enabled productivity reports, trends, gap analyses, bottleneck detection, more accurate completion estimation and more, which will seriously improve our operational management awareness and effectiveness. All of this can be achieved just by applying Interaction Profiling and some minor, sensible design additions. The next blog post will take a look at how we could design a reusable application framework that provides the preceding functionality, generalizes the Interaction Profiling concepts and can be re-used for all future business transaction (interaction) processing information system development projects.

 

Note:  The graphic image that heads each of the Interaction Profiling blog posts (including this introduction) is explained in more detail in Post #5.  Although it is comparing apples and oranges to a certain extent, it does portray the potential simplicity that could be achieved using an Interaction Profiling framework, either in conjunction with, or instead of, existing, diagrammatic, BPM workflow products. BPM software, such as BizTalk (as in the graphic), usually do considerably more than just transaction workflow management. Interaction profiling focuses specifically upon transaction validation rules and business process workflow and management.

 

Next Post: Better BPM – 2  Generic Interaction Profiling Definitions and Design.

 

Leave a Reply

Your email address will not be published. Required fields are marked *