Notes from a short technical presentation on IBM BPM
Each circle in the diagram above is a Server. There’s a “special” Server (called the Process Center) that is for Development and all the others are Process Servers (e.g. UAT, Production). Process Applications are created on the Process Center and then (typically) pushed out sequentially to Process Servers (with Production being the last Process Server).
Each Server (Process Center or Process Server) comprises two main components, a Process Server (which does everything to do with Process i.e. most things) and a Performance Data Warehouse (which handles the performance data that’s generated by the Process Server). Having a separate component for performance data helps to optimise the overall performance.
NOTE: Please note the name-duplication of non-development servers (Process Server) and the process-related server component (Process Server).
Each Process Server (on a Process Center or a Process Server) comprises three main components, a BPD Engine, a Service Engine and an Event Manager. The whole thing is relatively stateless (everything lives in the database).
The BPD Engine does all the orchestration work. It pushes cases (Instances) through the BPD models and hands off (via the Event Manager) work to the Service Engine. When these discrete chunks of work are complete, the Event Manager lets the BPD Engine know and it moves on to the next thing in the BPD.
The Event Manager acts as a relay between the BPD Engine and the Service Engine. It picks up discrete pieces of work that are ready to run from the BPD Engine (e.g. System Tasks, Timers) and hands them over (complete with data etc.) to the Service Engine.
The Service Engine is the part that actually does things. While the BPD engine provides the orchestration the Service Engine performs does all the tangible stuff e.g. sends E-mails, calls Web Services etc.
Each Performance Data Warehouse (on a Process Center or a Process Server) comprises two main components, Tracking Data and Database Views.
Tracking Data is created when the Performance Data Warehouse picks up data from the Process Server.
Database Views sit on top of the Tracking Data and provide a richer data set for clients (typically reporting platforms e.g. Cognos).
Interacting with Process Centre / Process Server:
Process Designer (IDE)
Only present on Process Centers, the Process Designer is the Integrated Development Environment (IDE) for IBM BPM. It’s where things are built. You would use the Process Designer to create a Business Process Diagram (i.e. to model a process) or an Integration Service (i.e. to connect to an external system).
Process Center Console
Only present on Process Centers, the Process Center Console is where the things that are built are managed. You would use the Process Center Console to deploy a Process Application to a Process Server (e.g. to deploy into the UAT Environment).
Present on both Process Centers and Process Servers, the Process Portal is where Users do things.
Application Server stuff e.g. defines JDBC connections, LDAP integrations etc.
Admin Console (PS)
Contains all the out-the-box administrations functions (e.g. Process Inpector, Manage EPVs etc.) and any user-defined Administration Services.
Admin Console (PDW)
There’s very little to see here. It will tell you if there’s a problem and give you some high level information about the volume of tracking data being generated.
When you think BPM, what do you really mean? More jargon? A philosophy? A system? What is BPM?
There’s a heap of vigorous discussions being had the world over, but what it really means, is Business Process Management – a way for a business to know & manage what they do, so that they get the results they expect to get all the time. Whether that means that bills come in, processed & paid correctly and on time, or whether its when the customer comes in, orders their coffee & walks out satisfied that they’ve got the kick-start for their day – they are both processes that someone needs to follow (hopefully) the same way every time & there is (hopefully) someone accountable if things go wrong.
You can never replace the people in process – maybe in the future robots might to some degree – but until then we can only get help for some of the parts of processes – systems & technology can help, or they can really disrupt operations & be a right pain. But readers beware…if your manager comes back from a conference & runs in claiming that “I have seen the future & behold it is good…” then starts regaling you with details of a system they saw & how it will transform the business, that would be a good place to pause. Others might say be afraid…be very afraid.
Please, do yourself a favour – before you start to think about any systems (BPMS), you need to optimise your processes first, or else you may end up automating & delivering a bad result faster than you used to! To do that, you need skilled people to help transform the processes.These can be from within your business, or external experts brought in to help, either way you need these types. You want to know what issue you are trying to fix, how you might measure it, what success looks like, and a lot of other criteria – you can use these as your litmus test for your improved processes.
Think about using experienced experts (aka “process tragics“) – they exist – to help kick start the transformation piece and maybe they’ll suggest automating in small increments, but make sure the experts also impart skills to your own people. After all, you’ll want to keep improving many other processes & you need your own teams to make it become “what they do everyday”. Once you’re doing that, all the time, you’ll find that you truly are living the BPM dream.
I attended the Pega Business Process Symposium today in Melbourne, which had quite an impressive turnout considering it was the inaugural holding in Melbourne. The large turnout – there must have been close to 100 people there – is indicative of the traction that Pega has made in recent times in the Australian market.
Other than the excellent attendees (including myself), the event was well organised, and I liked the fact that it was a morning event, and they hadn’t tried to stretch it out too much. It did have a sales pitch feeling, but I guess that is fair enough considering it was a Pega event. Here is my brief summary of the day:
Luke McCormack was the host and introduced the day, gave some insight into what Pega was doing in Asia Pacific, and re-enforced the Pega ‘Build for Change’ mantra. Following a brief recorded message from the CEO, there were a number of presentations.
Business Transformation through BPM Suites – Setrag Khoshafian. Well Setrag was certainly pumped up for this, and he gave a very (sometimes overly) enthusiastic presentation on the Pega BPMS. As always, I thought a bit more time could be spent on how to establish a BPM approach, rather then focusing on the tools. However, there were some points that resonated around the Pega BPMS offering. In particular the need for a toolset to support delivering agility in change. The promise of reduced cost of change is something that is touted by all the vendors, but reality is often very different to what is being sold. The Pega frameworks and implementation methodology have focussed on this over recent years. Simple things like the Pega versioning and unit testing frameworks really assist in delivering change with more confidence. The project management frameworks are a great example of Pega eating their own dog-food, using PRPC based processes and rules to manage BPMS implementation projects.
And having a single platform with all components included does simplify things. This is not always ideal or even practical, but having real business rules support within the BPMS is powerful and keeps it simple. And lets face it business rules and business process are closely related and aligned.
Overall Setrag claims IT productivity increases of between 2 to > 10 greater productivity (greater than OO development) based on some Pega sponsored research. I am not quite sure about the validity of this, not having seen the research, but interesting none the less.
CRM – Rapidly Transform Your Customer Experience – Steve Kraus. The focus is apparently on improving Pega’s business analytics and real-time intelligence. A lot of this presentation was an overview of the Pega CPM modules. Which I do like. The CPM framework is simple, but contains all of the key features of a call-centre focussed CRM. Having a CRM based on the same platform as the processing platfrom used by the back office is something that I like. I may blog about this in the future, and this was also highlighted by Forrester’s William Band in his blog ‘The Top Twelve Customer Management Trends For 2011’ (http://blogs.forrester.com/william_band/10-12-29-the_top_twelve_customer_management_trends_for_2011). Having processes initiated by the front office using the same processes (albeit tailored for the interaction) and platform as the back office keeps it simple, allows for reduction in hand-off points and breakdowns, and allows better insight into the full process. It is not an all singing and dancing CRM, but it does have the features required for the call centre and keep the overall solution simple.
Pega Never Looked so Good – WesFarmers (Mike Efron). I was really looking forward to some insight into the use of the Pega Internet Application Composer. Extending processes to the customer or third-parties self-service channels often hits hurdles with either fit into an overall enterprise architecture or the fit for purpose of ‘generated’ user interfaces (as Mike said for UI design, ‘good enough isn’t’). This normally results in costs or timeframes that erode the original business case or intent of the process improvement opportunity in the first place. However, Mike’s presentation was more focussed on the challenges for bringing a new, white-labelled insurance product into a well established market. This was interesting in itself, but not what I was hoping for. Reading between the lines, I got that Pega worked well for this model as:
- The pega rule inheritance model more easily supports having to white-label in this way. Small differences between user interface, process, and product can be approached in a layered and structure way, without having to re-design or re-write for small differences in the product between brands.
- The Internet Application Composer was able to produce user interface portlets that were suitable for retail consumer consumption, without compromising on the user experience or look and feel.
Unfortunately, I missed the last session of the morning on Pega’s adaptive case management solution. It probably was the session that I would have liked to have seen the most. However, unfortunately, I had to get some processes designed for a client, and sometimes work has to come first.
All in all, it was a worthwhile event to attend. I would have like to have seen more of a focus on continual improvement, and what BPM is really about. But it did give some useful insight into where Pega was, and what their focus is on in the coming periods.
I recently saw the review of AWD 10 from Bruce Silver (http://www.awdbpm.com/bruce_silver_on_awd10_oct_2010.pdf), where he was outlining the virtues of AWD 10. Now to be open I have been bitten by AWD in the past and have some painful memories. These were not necessarily all the fault of AWD, but partially that we were trying to use it outside of its main areas of strength. However, I still have the scars.
AWD has been around for a long time. Originally built by DST to manage its BPO operations I believe it started life in the 70’s / 80’s written in Cobol – and this heritage always remained in the constraints in the fixed length data models. Over its life it was ported to a combination of C and Java and a number of add-ons were bolted on to the side. During the last 5 – 10 years there seemed to be a significant lack of investment in the product itself, and it went from a position of being a market leader to a boundary player.
AWD is used extensively by DST systems for operations processing. This, in conjunction with the joint ventures with State Street and FDI was always the reason why the install base was so large. Used in this way, I have seen AWD being used very effectively for large volumes of transactions.
From first glance through the report, it appears that AWD 10 bolts together all of the components that were emerging as add-ons in previous incarnations – such as the form designer, service designer, and smart forms. These were previously always add-ons, developed separately, and licensed as add-ons.
In the past the challenges that we have encountered with AWD have been based around:
- The complexity of the operating and development environments. The lack of version control and release management capabilities in particular – although this is an area that Lombardi 6 struggled, it has now put these largely to bed with 7.x. It was not clear from the report whether this has been addressed at all.
- Integration into any other portal or technology – for example for presenting tasks lists through a partner portal.
- The number of and integration between add-ons which were not seamless.
- The data dictionary – especially around field name lengths and handling of collections.
When reading the 2010 Forrester Wave Report for BPMS there were a couple of take aways for me, but the main one being the considerations for what is required in a BPMS.
One titled ‘Next-Generation BPM Suites Empower Process Owners, Business Users, And Customers’ and the other on how to select a BPMS (‘Which BPM Suite is right for your initiative’).
In the first the key features that were discussed were:
- Social and Web 2.0 components encoaraging collaboration through the discovery, design, and development
- BPM as a service (in the cloud)
- Data Quality
- BPMN 2.0 helping to standardise modelling notations across tools within large organisations – hence allowing better end-to-end understanding of processes regardless of the toolset in use by different departments.
This lead into the discussion on how to select a BPMS.
If the business plans to drive process transformation, you will want to select a vendor that has strong collaborative process design, prototyping, and shared development capabilities.
So for me we seem to be missing a big part of process analysis – which is about discovery / analysis for processes that have been implemented. What about BAM, simulation and optimisation? Identification and prioritisation of improvement opportunities? The promise of BPM is based on implementing models of continual improvement. Not about one off process implementations.
Not many products seem to actually support the whole life cycle or at least not in a circular fashion. It should be discovery, design, execute, monitor, discovery, design etc.
As a decision maker (assuming a business led initiative based on the promise of continual improvement), I would be keen to know about the products abilities to monitor, identify issues, and feed this back into the analysis phase of the cycle.
In my experience BPM initiatives often turn into BPMS implementation IT projects, and complete at the end of one big business case. This may have delivered one or more process improvements iterations, but has failed to leave the organisation in a place that can deliver continual improvement to their processes.
Am I missing something or is this just a symptom of the levels of maturity we are at in the BPM space, and hence our requirements for a BPMS?