Interview with IBM BPM Chief Architect and Former AS/400 Architect

Interview with IBM BPM Chief Architect and Former AS/400 Architect

In this second in a series of articles on Business Process Management (BPM) for IBM i, I spoke to Phil Coulthard, an IBM Master Inventor and Chief Architect of IBM BPM and SOA tools. He was also one of the original AS/400 architects and thus offers some particularly insightful comments for IBM i developers and managers.

Q. What was your role in the AS/400 for IBM?
A. I worked on the AS/400 since day 1 of the box as a developer on SDA, and my last role was architect of the tools and compilers we do here in Toronto. For example, RPG and what’s now known as RDi (Rational Developer for i). I grew up on AS/400 and it’s still deeply in my blood.

Q. What’s your role now?
A. I’m lead architect for the tools in IBM Business Process Manager (IBM BPM), and a member of the BPM and ODM CTO Office in IBM, which has architectural oversight of these products. ODM is Operational Decision Manager, or business rules and business events, both of which are excellent complements to IBM BPM.

Q. What is BPM and IBM BPM?
A. IBM BPM is the product from IBM, and business process management is the discipline that it supports. There are tremendous gains to be made just by clearly articulating your business processes in the form of visual process models so all the participants and stakeholders can agree and execute with a common understanding of the process. Further, by visualizing a process, you can usually see where there’s room for improvement, and some simulation can often be used to see, for example, where there are bottlenecks.

Q. In what situations is BPM an appropriate application platform and where is it not?
A. You would consider a BPM application when your application implements a business process of some kind. Business processes typically involve multiple users who each must do a specific task, and calls to services to do work such as retrieve or update data, update an account, et cetera. Each user task is one or more screens that an individual end user interacts with, typically to present and collect data from them. Over time, some of the tasks done by humans eventually get automated and become services, and so ultimately, in some cases, you’ll have some “straight-through processes” that have no user tasks at all as they are totally automated. But they’re still considered a process because they’re orchestrating calls to services to achieve a business result. However, if you’re writing a simple single-user data input application or a number-crunching application, BPM may not be appropriate.

Q. If you compare the development and architecture of a typical RPG application to a BPM application, what are the important differences?
A. The key difference is that traditional applications must be fully coded by the developer to achieve the desired functionality. Of course in RPG, historically this meant a large monolithic program that does it all—though with ILE and RPG IV we’re hopefully building more re-usable service programs these days. Still, the focus is on the code.

In BPM, you rely on the system to do much of the lifting. You visually model and define your process flow, and deploy it to the system that will run it for you. That means putting tasks in the in-basket of the participants, invoking services, and passivating to disk while the system waits for a human or an asynchronous service call. Further, the BPM system is tracking progress of your processes, and at any time the process owner can see what process is behind or who has too many tasks. The process owner can take action as required, such as re-assigning tasks to others and reprioritizing work. So because the system takes all this work for you, the focus during development is on the process itself versus how to code it; or if you will, the focus is on the problem domain versus on the code to address the problem domain.

You’re not thinking about how to code your app; you’re thinking about how to model the process to achieve the desired business outcome. That means you’re talking to the line of business to understand the details of the process. What roles are involved? What’s the happy path? What exceptions can happen? What metrics are desired? In fact, you’re constantly doing “playbacks” with the business so they can experience the process to ensure it’s been properly modeled. For example, during playback they’ll see how the flow goes from Sam who collects loan information from the customer, to Sally who makes a decision on whether to grant the loan based on the collected data, to Bob who makes a final decision for certain types of customer or loan. And they’ll see that if Sally doesn’t have all the information she needs, the process needs to handle going back to Sam who can re-engage the customer. It’s a magical moment seeing IT and business sitting together and running the process.

The key difference is that RPG programs are a series of executing lines of code, while BPM applications are processes executed by the system and which, in turn, are executing an orchestrated series of user tasks and service calls. You don’t develop code per se; you develop processes. This is a fundamental shift and cannot be overstated. It doesn’t just change your architecture; it changes everything. Now IT and business are focused together. There’s nothing quite so exciting as a room that is half full of IT folk, asking detailed business questions to the other half of the room. In the first such meeting, typically they’re introduced to one another for the first time. I’ve never seen anything good come from business folk looking at my RPG code.

Q. Reliability has always been a key virtue of the IBM i. How does the BPM platform compare?
A. IBM has been at this a long time, and we sit on top of the WebSphere rock-solid base underneath us, which gives us among other things high availability via clustering. Among our spectrum of customers, we have large and demanding customers that make darned sure we have a solid enterprise scale product, else they rightly take us to task to fix it. This is not at all unlike IBM i customers.

Q. Does IBM BPM run on the IBM i?
A. I think a compelling vision for many IBM i shops would be to retain the IBM i database platform and move to BPM for their applications. IBM BPM itself doesn’t run on the IBM i operating system, but you can run it on an AIX LPAR. In addition, it runs on Intel Windows and Linux as well as on z/OS and z/Linux. The Advanced Edition comes with an adapter for invoking RPG and COBOL on i, which is built on the toolbox for Java. Or, easily enough, you can just call RPG code via stored procedures.

Retaining the IBM i database and platform while moving to BPM for some applications allows for an efficient way to complement and evolve the IBM i investment. It’s a very reachable step on an enterprise modernization path.

This article was originally published in IBM Systems Magazine.

/ AS/400, BPM, RPG

Share the Post

About the Author


Comments are closed.