Reasons to love Metastorm BPM 9 - Part 2: Loose Coupling

Jerome_Pearce

The Metastorm BPM 9 architecture has changed dramatically from previous versions. Apart from being built on a .Net platform with C# code, there has been a significant change in abstracting the database access layer into Business Objects, and code and Visual Script modules are far more easily shared through libraries.

This has not been fully appreciated, we feel. Having made extensive use of such functionality to develop loosely coupled components, we decided to share our findings over the last year using version 9 in earnest to build solutions for customers.

The Problem

We offer a great many Metastorm BPM solutions that can be used by any Metastorm BPM system. Our goal is that they are usable as is, out of the box, and without configuration apart from that required to meet integration needs.

If this approach is not taken, and we have noted that it rarely is, systems lack a simple upgrade path, and maintenance becomes problematic at best and impossible at worst. Such a system either forces the customer into one particular configuration, or must be maintained individually for upgrades and fixes. This makes for poor agility, maximises support issues and creates long turnaround times for fault-fixes and upgrades.

The problem we have faced in building systems that avoid this problem is that it is very hard to build all our solutions to match all possible system usages. There may be Oracle or SQL Server, there are a hundred different ways to manage user names, etc.

In Metastorm BPM version 9 we have recognised the ability to build discrete components that are interchangeable. This allows us to manage a large number of different potential configurations without modifying the central solution itself.

In developing the solutions we sell built on Metastorm BPM version 9, we have developed a design methodology which builds all interfacing components into separate libraries. In this way we are able to maintain proper upgrade paths as new functionality is added, or issues fixed, much more easily than we were able to in earlier versions.

There are three main areas where we have identified elements that benefit significantly from this design model:

Interfacing Components

Many of our systems are built as integrated but separate systems. As an example, in our Business Management system, we have a Business Planning module where department goals are identified, strategies to meet these goals defined, and activities to be undertaken and tracked in order to follow these strategies. Obviously this is very dependent upon the Department data, and it is maintained in that system.

In the same group, we have a Risk Management module for identifying, assessing and managing risks. Plans and activities are set and tracked in order to reduce each identified Risk. Much of this, inevitably, relies on the Department data we may have captured in the Business Planning module.

So how can we use one without the other? The answer is quite simple. When we provide the Risk Management module as a stand-alone module, we also provide a basic Department data module that captures the minimum required data for the Risk Management module to function. All references to the Department data are made through this library.

When we provide both modules, the library provided refers to the actual data stored in the Business Planning module.

The really clever part is, however, we can (normally) quite easily create a basic library that accesses any existing Department data that may exist in your organisation. That could even be used for both modules. This gives you the ultimate flexibility possible regarding configuration.

Extensibility

Often, we find that we need to interface to existing systems without knowing what they are, exactly. A Good example is the Document Management component of our Document Creation & Printing solution we sell for legal firms. Here, we have to interface with some kind of document management system, but we cannot know in advance what that system is, or how it will work.

What we have done is to remove all document management functionality from the process itself, and built a separate component, with an interfacing Library, to manage all such interaction. The default ones available are the standard Metastorm ‘Attachment’ functionality and a simple file store. In addition to that we have several components to interface with a Document Management system such as Interwoven Worksite.

If customers require us to interface with another EDMS, we merely need to build the required basic library. The main system itself requires no modification whatsoever.

This once gain gives us the most robust model possible, allowing us to seamlessly provide upgrades and fixes to existing customers with little or no disruption to their EDMS integration.

System Configuration

Every Metastorm BPM system is inevitably configured differently. There are no real guidelines on how to manage this, although we have certainly built our own after configuring Metastorm BPM systems for over ten years.

A very good example of this is how to manage user data. Metastorm BPM stores the user id and email address, but there is typically a great deal of additional information that needs to be stored. This usually involves data such as an account creation date, last used date, phone number and full name (for readability).

We have our own User Management system that stores all this data where we think it should be, namely in the Attribute table. Not only does it manage updates using the web client, it also keeps a full record of what was changed, when, and by whom, unlike the admin tools that merely allow changes to be made. It also allows change requests to be submitted for approval and implementation through managers and administrators, so reducing the burden on Metastorm Administrators themselves. No Auditor we have discussed this with would accept anything less, in fact.

However, even though we supply this User Management system, we have no illusions that all our customers will use it in order to use our other systems. That would be unrealistic. Many customers have user names in the Distinguished Name field of the User table (even though this should be used for directory synchronisation, but that seem to be rarely used). Many do not have user names stored at all and just employ the user id, and some have completely separate systems, even using Active Directory.

As such, we have to handle all possible situations. In order to do this, we have built a library that will get user lists, based on roles, name filters, user id filters, for example. This list is typically a name / value pair list, but the way we have employed it we can return a simple list as well.

In addition, proving the extreme flexibility of the Metastorm BPM 9 architecture, we have been able to fix a constant problem faced in previous versions: How to display user names as opposed to Ids in a grid. The obvious solution is a name value pair dropdown. The issue with that is where the user list could be exceedingly long, such as one customer we have with over 10,000 users!

The solution we generated to solve this was very simple, at least from a usability perspective. We created a function that accepts the Business Object for a grid and the name of the user id field, and it builds a list of all the user ids and names (in a name / value pair list), and only those names, that exist in the grid. This is achieved through one SQL statement, thus minimising performance impact on the system.

These are demonstrated in the free Tasks Solution we provide, along with three sample User Utilities libraries accessing data in different ways.

More can be added to suit just about any possible scenario, thus avoiding the need to adjust the main Solution in any way to accommodate new configurations.

Conclusion

The Metastorm BPM 9 architecture offers very configurable and robust designs to be implemented. The issues with previous versions in forcing tight coupling between components have been overcome, and now we are able to design systems with loose coupling in almost every situation.

The increases in flexibility, when added to the generally robust data access abstraction layer introduced with Business Objects gives us the ability to deliver truly maintainable systems to multiple customers without modifications.

The promised integration of the Business Objects with Web services and possibly even other data sources will only make this abstraction layer even more beneficial.