Business Process Discovery: The Key to Mainframe Modernization

Business process discovery avoids the risks of traditional business process re-engineering efforts and yields immediate end-user benefits

by Stuart Burris

The mainframe continues to defy the best predictions of the pundits. Instead of becoming extinct, mainframe use is growing. By some estimates there are still 250 billion lines of COBOL code running, with another five million lines of COBOL code being written every year.

That said, however, the mainframe is changing. New capabilities allow the mainframe to be a more flexible platform. Modern applications running in Linux partitions (including an application servers), coupled with SOA to service enable legacy applications, provide a mechanism to blend the old with the new.

The mainframe does present some difficult challenges. The average age of all that production COBOL code is 13 years. Understanding what the code does (or more importantly, how the business users are using the mainframe capabilities) is paramount to successful maintenance and extension of those systems.

With ever-changing business conditions and technology, maintaining mainframe systems requires more than fixing code. It’s about extending the capabilities of the applications to meet business challenges. Traditionally, this has meant choosing between large rip-and-replace projects and very large modernization initiatives to completely reface and SOA-enable the mainframe.

Here’s a compelling project-failure statistic: small projects (less than 6 months long) have an amazing 55 percent chance of success, while large projects (18 months or longer) have only a 15 percent chance of succeeding. While there are certainly many factors involved, one of the most key is that business processes change. With the pace of business, the likelihood that the challenge your business faced over a year ago is still the challenge it faced today is small. Just as business conditions change quickly, so, too, do business processes. The day after they are documented, approved, and delivered, requirements start to drift out of date.

The approaches that work with legacy modernization bear this out: the smaller targeted projects that are focused on business process improvement are successful from both a technical and business perspective.

The traditional approach of an enormous, risky business process re-engineering effort requires extensive work on process mapping, process analysis, and making one-time, large changes. Business process discovery (BPD), however, creates an environment where it’s very natural to make smaller incremental process changes that yield immediate return, and repeat the process in a continuous improvement cycle. This creates an environment where business users continuously see benefits and the majority of the IT budget is spent on creating benefits, not on documenting business processes.

Small, incremental projects were traditionally difficult to execute, due to the challenges of traditional process analysis and the inflexible IT architectures which made it difficult to perform incremental improvements. A service-oriented architecture (SOA), however, is fundamentally changing that inflexible paradigm. SOA allows organizations to be able to rapidly adapt and incrementally improve their processes. This architectural change to the way IT systems are organized and deployed removes the technological constraints to an iterative, incremental improvement cycle.

The Key to Success

The key to success with SOA is to effectively define the appropriate granularity of the business services. BPD complements an SOA approach to solve this problem by having services emerge from this bottom-up analysis of the business processes, then increasingly implementing those services required as part of the process-improvement initiatives.

Key to the successful delivery of these small targeted programs is a complete understanding of the business processes and their deficiencies. The traditional manual approach to process definition is based on structured interviews, with a small sample set of business users. Iterative process design and review sessions lead to increasingly complex process maps, with a growing number of process exceptions. Of course, once you put the system into the hands of the users, the real business process finally materializes with even more complexity and exceptions. What starts out looking like an easy, clean process ends up a mess.

This traditional approach absorbs 70 percent of the total project’s budget in just understanding the business processes. Even with that level of investment, the approach remains incomplete and error-prone. The good news is that there are tools to shrink that 70 percent effort and allow the quick discovery of business processes.

Most business processes today are technology enabled. Users leave electronic footprints of the process through the IT assets supporting the process. By examining the footprints the users leave as they execute their process, the business process can automatically be discovered and documented in near real time.

Business process discovery is an emerging field that discovers the business processes based on examining the activities of the users on the IT assets that support the business processes. Coming at the business process “bottom-up” from the detailed facts of process instances provides a detailed depiction of the business process, complete with all the nuances of the process, detailed statistical information on how often different variations of the process are executed, how long it takes, what data conditions give rise to process variations, the variations between different users or groups, etc. Also, as BPD is an automated process, the business process can be perpetually kept updated.

Having a near-real-time view of your current business processes yields dramatic returns beyond improving application development. Once the typical business process is understood, monitoring it for deviations introduces a proactive business process monitor that has immediate applicability for IT operations management as well as compliance and security. A self-documenting business process allows the IT staff and business users to always be on the same page. Help desk support staff can immediately understand the business process (or its deviation from the business process) of a specific user. This allows a proactive investigation and response to the deviation, whether it’s a user-training issue, systems availability issue, or just an unusual business situation driving the workflow.

Perhaps the best thing about BPD is that getting started is easy and bears extremely low risk. The promise and benefit of BPD is to be able to quickly, easily, and automatically derive business processes based on an examination of the business user behavior. In our experience, within just a couple of weeks we’re able to target several business process improvement opportunities based on detailed process maps that our BPD tool provides. This creates quantified process improvement opportunity, not based on estimates or anecdotes, but rather based on the solid facts of user behavior.

Stuart Burris is president and CTO of OpenConnect. He is responsible for overall management and its technology vision and strategy. He has been instrumental in the development for the company’s mainframe-to-Web product architecture. You can contact him at