pegaworld – Page 4

PegaWorld: Mashups with IAC

I thought that I should attend one technical/product breakout, since I’ve been covering customer case studies so far, and I wanted to get a closer look at Pega’s composite application development environment for internet applications, Internet Application Composer. I had a briefing on this a few months back, so have some notes and screenshots from that time that I’ll incorporate here as well.

IAM embeds PRPC application gadgets — like a worklist — on existing web pages, allowing SmartBPM functionality to be added directly and securely. This is like having PRPC on the web: actually exposing Pega functionality as Javascript gadgets, rather than just a back-end system that supports a website. This is not a limited set of pre-made gadgets, but the ability to turn a UI created in PRPC into a gadget.

IAC has three main components:

Composite Gadget Manager, which is a Javascript file that you load on your web page that implements your Pega gadgets. It controls configuration settings, plus the attributes, actions and events for the gadgets.
An existing PRPC application, running on a web node (behind the firewall); a web node is a separate PRPC node designated specifically for handling IAC requests, where all functionality is disabled by default unless explicit enabled for the web applications. This makes it possible to globally restrict certain types of access and functions on that node, rather than having to build that into the user interface.
IAC Composite Gateway, which is a servlet (in the DMZ) that manages the HTTP traffic between the Pega gadgets and the SmartBPM application on the web node.

As with most web applications that interact with behind-the-firewall systems, it’s a best practice to have the web application authenticate the user, pass on the trusted session to the Composite Gateway, which in turn passes it to behind-the-firewall web node.

Not only can PRPC gadgets be created and exposed, but legacy applications can be wrapped in SmartBPM to expose them to the web more easily. Since the PRPC application controls the view through the gadget as well as the internal view, any changes to the PRPC UI will be reflected both internally and in the gadget, without changing the web page itself: build once, deploy everywhere.

There’s tighter security than in many consumer mashup architectures: parameters are encrypted and obfuscated within URLs, for example.

The interface within the gadgets is rich, e.g., if one parameter is changed, a related parameter may update without a screen refresh. Gadgets on a page can interoperate, so a change within one gadget may cause another gadget’s data to update, such as showing the details for a selected item: this is enabled with some advanced actions and events, and uses JSON.

We looked at the actual HTML required to add a gadget to a web page: there’s a pretty small block of Javascript up front to set the configuration, then a 10-line block in a <div> structure that actually embeds the gadget.

IAC was released earlier this year, but a 2.0 version is available as of the end of September that includes HTTPS support, support for load balanced web node and gateway, tracing tools for debugging, samples and more. If you’re a Pega customer, you can access a number of in-depth technical articles on the Pega Developer Network about IAC.

PegaWorld: Paul Kompare on JPMorgan Chase’s agile methodology

Paul Kompare, SVP of commercial banking technology at JPMorgan Chase discussed their Pega implementation of a straight-through processing infrastructure for commercial loans. He gave us a brief view of the current environment and the proposed solution, then moved on to discuss their agile implementation approach. Although they refer to this as Agile, it’s still a bit waterfall-like: the sprints don’t result in released code, but in checkpoint demos, and these are the points when the business representatives interact with the development team rather than being a co-located team (which likely would not have been possible since they rely heavily on offshore development resources). However, it’s a big improvement over their old waterfall methodology.

They delivered the project in two phases, each with three iterations:

Happy paths and primary flows
Exception paths and secondary flows
UI, integration and reports

In each iteration, they establish and sign off on the criteria, then use Pega to directly capture objectives and model the processes. With this relatively agile process, they improved project sponsorship as well as getting early buy-in from the business, since they were able to demonstrate something earlier and more frequently. Using PRPC also gives the business managers more visibility into the business processes and their underlying logic, rather than having those processes locked up inside opaque application code. They found that the tools gave them more agility and flexibility during implementation, greater reusability and faster time to market, as well as allowing potential changes to be identified earlier.

They did have some challenges with adapting to an agile approach: this type of approach assumes that changes to the design and functionality of the system will occur during development, and relies on rolling out a phased series of small, self-contained components. From a funding standpoint, it’s almost impossible to issue fixed-price contracts for agile development, since there is not a really fixed statement of work on which to base the proposed price. I’ve seen cases where a third-party services firm doesn’t really get agile methodology, and there is a huge amount of overhead as they attempt to shoehorn their waterfall deliverables into each iteration of the agile development, or they just abandon the agile approach and go back to waterfall.

There’s also major changes to roles and responsibilities: the business participants have much greater responsibility during design and as the system rolls out, and having them trained in the design tools is critical.

He concluded that adopting agile development methodologies has been a challenge for them, but that it’s definitely helping them to achieve shorter development cycles. There’s very little here that’s specific to commercial loans, Pega implementations, or even BPM; these same factors would be seen in any organization shifting to an agile approach. However, Kompare made the point that they were driven to consider an agile approach because the Pega tools tend to work better in that environment than with a traditional development methodology.

PegaWorld: George Colony, Forrester

When Pega invited me to attend the conference, I took a quick glance at the agenda and thought that it said that George Clooney would be speaking. I immediately accepted. On second look, I noticed that it was actually George Colony, founder and CEO of Forrester Research.

The somewhat less famous George talked about business technology (BT) in the format of 8 things that he would tell your CEO over coffee:

It’s not Information Technology any more, it’s Business Technology. As he pointed out, you can’t separate business and technology in most businesses, and what we’re now calling “IT” is an inherent, critical part of business.
To get BT right, you need four players: you (the CEO) + technology-knowledgeable business executives (TKBE) + CIO + a techie on the board. It’s no longer cool for a CEO or any business executive to not understand at least some basics of the technology that runs their business, and a techie on the board of directors will help to drive that agenda.
Process + Organization + Technology. He stated it as when technology changes, process and organization must also change, but it’s clear that when you change any one of these, the other two will have to change: these three are always involved in technology implementations.
Technology has changed your customer, and your customer will change your business. In particular, the new generation of customers are focused on different channels such as mobile devices and social networking. This is a generalization, of course, since there’s plenty of us older types who are also using these, but Forrester’s surveys are showing trends in the demographics. If you don’t embrace the channels and technology of this generation, then you’ll lose them both as customers and employees.
Don’t let Hal destroy your business. By “Hal”, he’s referring to the omniscient computer in the 2001: A Space Odyssey; the intent here is that if you can’t let the systems outstrip your understanding, common sense and risk systems. He posits that if more CEOs of financial institutions really understood sub-prime mortgages, then they wouldn’t have allowed the situation to happen at their companies.
Business Technology will enable one of the most important business models of the next 10 years: Bowties to Diamonds. This refers to the structure of economic models: instead of a vendor tapering off their involvement as a product is delivered, then the customer ramping up their responsibility and involvements, the vendor increases their involvement after the initial sale through ongoing maintenance and follow-on services in more of a partner model. Colony discussed how new technology that enables diamond relationships, particularly SOA (which allows vendor and customer systems to be easily integrated) and the extended internet (which supports the communication between vendor and customer).
Great marketing + great technology is the only way forward. If these aren’t both great and working together, you can’t effectively dissolve the boundary between you and your customer.
The only way out of the current financial meltdown is innovation and transformation. Instead of just hunkering down and doing more (or less) of the same, you have to change your business and how you use technology to do it.

He envisions CIOs being absorbed into the business, and eventually more CIOs becoming CEOs, especially in financial services companies.

PegaWorld: Meryl Stewart and Kelly Karlen on Business-IT Collaboration at BlueCross BlueShield

Last session of the day, and Meryl Stewart and Kelly Karlen of BlueCross BlueShield of Minnesota talked about maximizing BPM value through business and IT collaboration. They established a shared business-IT objective of enabling the business to manage their frequently-changing business rules to provide agility, while still maintaining environmental stability by following the necessary change management procedures.

They’ve wrapped some procedures around their projects to explicitly call this out, as well as explicit governance layers for processes and rules. Some of this — a big part — is about well-defined roles and responsibilities, such as a business rules steward. They categorize these procedures and methods by collection, execution and optimization stages, and walked us through each of the roles in each of the stages.

In the collection stage, they have a pretty structured way to create business rules and shore them in an enterprise repository; this is independent of their BPM technology, since not all processes end up being automated.

They wanted to make execution more efficient, so combined their RUP methodology with Pega’s RUP-like methodology and lightened it up to create a more agile “RUP Lite” (although as they walk through it, it doesn’t feel so light but it does have fairly frequent code releases). Within that methodology, they have a number of additional roles to work on the business to technology transformation of the execution phase, and definite rules about who can do what types of changes and who does the associated testing. There’s a level of semi-technical analyst who can do a lot of the non-coding changes.

The optimization stage is where business agility happens, but this was addressed pretty quickly and seemed to be some sort of standard change management procedure.

This definitely shows some good software development practices, but there’s nothing particularly innovative here that can’t be replicated elsewhere as long as you can get the collaboration part to work; collaboration is primarily a function of finding people on both sides of the business-IT divide who can see over the wall to the other side, and maybe even straddle the divide somewhat with their skills.

They’ve applied the methodology to a couple of projects and have seen positive ROI, and very few coding changes since most of the process tuning can be done by business users or the semi-technical analysts. In one process, they’ve had 11 rule changes in 4 months with resultant savings of $820k in the improved processes; if IT were to have been involved in these changes, only $126k of the savings could have been realized in the same timeframe due to IT project schedules — a good measure of the value of agility provided by allowing the business to change business rules. Fundamentally, they changed an 8-week IT build cycle to 10 days or less by allowing the business to change the rules, but still following a test and deploy cycle that keeps lT happy.

That’s it for today; there’s a reception, then dinner and a cruise on the Potomac to view the monuments by night. The esteemed Dr. Michael zur Muehlen will not be joining us in spite of being right across the river in Arlington; when I invited him, he gave some lame excuse about just getting back from Seoul. 😉

PegaWorld: Rod Dunlap on BlueCross BlueShield Claims

The second breakout this afternoon was on improving claims throughput by Rod Dunlap, director at BlueCross BlueShield of North Carolina. Their main driver was to reduce the percentage of claims requiring manual intervention from an initial rate of 17% to a mere 2% by the end of 2009; this didn’t quite turn out to be realistic, but they are headed for 4.5% by the end of 2009. This four-fold performance increase will result in $20M in annual savings, which buys a lot of Pega licenses, but more importantly, this is seen as the implementation of transformational change that will change the corporate culture.

The obstacles are pretty typical of what I’ve seen: middle management in this conservative company was risk averse and threatened by change, with a predisposition to failure from some of the key business management. There was a history of trying to use any new technology as a silver bullet, which typically ends in some sort of disaster. Furthermore, they had a traditional waterfall development methodology governed by an enterprise project office that tended to get in the way of innovation.

To address this, they developed a number of innovations:

Business people writing business rules: about 180 rules so far. As with any model-driven design, this eliminates translation errors, increases accuracy and increases time to delivery. The problem, of course, is that business people don’t understand programming basics, and Dunlap admitted that Pega isn’t quite as easy to use as the brochures claim. 🙂
To resolve this, they built their own claims optimization framework. Claims could come in in any format, and rules (written by the business) causes the claim to be routed to the appropriate area for processing or rejected to the old process if it couldn’t yet be handled by the framework application. The framework appears to be a set of common services such and logging and reporting, plus a configurable application layer. They’re using IPD as their workflow engine currently, with Pega being used primarily as a rules engine, but in some cases the claims do not have to hit the workflow engine at all since the rules can determine the disposition of the claim. They plan to replace IPD in the future with Pega’s BPM.
Implement Agile/SCRUM concepts in an iterative development methodology, with 30-day sprints that result in a code release every 30 days — no schedule slippage allowed, although features may slip into the next version. Features within a sprint are prioritized based on business payback, effort and dependencies. They’ve moved away from use cases and into user stories (scenarios and personas): this is the best practice for modern user design interaction. The combination of prioritizing features by payback and the use of personas allows some edge-case features to be completely dropped off the schedule.

They co-located the business and IT people on the project — key to success in Agile projects — and keep the teams small. They kicked the project off in December 2007, and completed their first sprint in February, with the framework delivered in July 2008.

With what they’ve accomplished so far, 86% of duplicate claims are handled automatically, saving 20 FTE; 48% of corrected claims do not need manual intervention, saving another 18 FTE. They’re still working on the goal of 4.5% manual touches on claims by adding automated claims adjustments and building new types of claim repairs. Then, they’ll expand beyond claims to bring the rules technology to membership, billing and finance, and start implementing BPM.

PegaWorld: Martin Venema on RBC Customer Service

This afternoon is all breakout sessions, and I started with Martin Venema of Royal Bank of Canada (the bank is a customer of mine, although it’s so huge that I’ve never dealt with his group) as he discussed improving customer service through rules-driven case management. Unfortunately, the wifi doesn’t extend to the breakout rooms so posting may be delayed, but at least I found a power outlet in this room. Also, he was introduced by someone who knew how to pronounce “Mississauga”, for extra bonus points.

RBC has implemented 3 different Pega applications, although Venema focused on only one of them, for handling client requests.

Their case for change came from problems dealing with client requests: someone in a branch can’t answer a client question, and needs to pass that question along to someone in a back office fulfillment group. However, there were 21 different ways to get to those back office groups — email, e-forms, fax, phone — and since there was no way to track the requests once they’ve been sent off, there was a 20% duplication rate. A new branch employee had to figure out which group to send it to, how to send it and which form to use: a daunting training task.

Their goals were to improve their clients’ experience, but also to make it easy for the front-line staff to manage and route client requests. For the first goal, they wanted to be able to provide clients with a service commitment that allows them to track their request and anticipate the future steps and parameters in the request process. For the second goal, they wanted a tool that could just figure out where the request should go, and provide notifications and tracking of the requests.

What they ended up with was a system that provide a single point of entry for client requests, which then used business rules to automatically route requests to the correct group for resolution. In the fulfillment groups, it provided standardization of processes (woo hoo! someone else who says “proh-cess” instead of “praw-cess”), workload balancing across geographies, and skill-based routing.

Cost reduction, cost avoidance, increase revenue and intangible factors all contributed to their business case; interestingly, the cost factors weren’t enough, and they needed to bring in the increased revenue factors such as enhancing customer loyalty in order to justify the initiative.

Under cost reduction, they considered:

Reducing staff costs, by reducing manual interventions as well as internal tracking phone calls and emails
Increasing productivity/improving efficiency by reducing rerouting by sending requests to the right place based on business rules, reducing duplicate requests, and integrating back-end systems to auto-populate information into the request form
Reducing error handling by removing paper processes, adding validation and coaching tips (to help front-line staff to use the tools and potentially to resolve the problem on the spot), and standardizing the processes across geographic regions

Bill payment investigations, for example, was able to eliminate 4 FTEs; other processes saw similar gains due to cost reduction factors. Due to the high turnover rates in the fulfillment groups, they didn’t need to do any mass layoffs for the first phase, although the subsequent phases may cause deeper cuts.

RBC’s marketing analytics group has some pretty good measures on how customer loyalty translates to revenue increase: a top score on loyalty (willingness to recommend) leads to a 6% increase in client profitability. Furthermore, a top score on problem resolution generated more profit since the customers are less likely to move financial institutions, and may even increase the number of products that they hold with RBC. That means that even if there are problems with a client, if it’s resolved to their satisfaction, then the client loyalty (and therefore profitability) will increase; if not, then the client is much more likely to change banks.

He went through some pointers for how they engaged the business stakeholders, then discussed their incremental implementation approach. Their first implementation of CART (Client Action and Request Tool) was a single e-form that could initiate 18 different processes for personal deposit account problems. This took about eight months to develop, and was rolled out to 30,000 users in the branches and call centers, and impacted two fulfillment groups when it was rolled out in May of this year. The next phase will ramp up to about 500 different processes. He admitted that they had a typical waterfall development methodology in the past, and had a bit of trouble moving to a completely iterative and agile approach right away; he believes that they need more of a hybrid approach to do this successfully, which is the same as I see in many organizations that have a long history of waterfall-style development.

Their early results:

20,000 new work objects created each month with no performance issues (I would be incredibly surprised if there were performance issues at this relatively low volume)
Early adoption rate of >60% of staff with no formal training
20% reduction in number of requests reaching the fulfillment centers through elimination of duplicates and some requests being handled by the front-line staff member

They did learn that an iterative approach does work best in terms of selecting small, manageable deliverables. They’ve seen an increased demand for other BPM solutions now that they have something successful in production, and since the infrastructure costs are front-end loaded, subsequent implementations will be lower in cost than the first phase. Venema believes that they waited too long to involve Pega and their partner professional services, and could have accelerated the project further with earlier involvement. He also sees that they were somewhat unprepared for the second phase, and could have started some of that project work during the rollout of the first phase. They’ve created a center of excellence to ensure consistent practices and standards, including user interface standards, to allow for greater reusability.

Eventually, they’ll add in requests for other product lines, and expect to handle 3M work objects per year; simultaneously, there are other Pega projects happening simultaneously within RBC. They are training up some of their own staff for Pega development, and are using Pega professional services as well as a Pega partner. Their biggest staffing challenge, which they’ve had to supplement with external resources, is with finding or training Pega PRPC developers; they’re also finding gathering business requirements to be very time-consuming and want to move to the Pega methodology of directly capturing objectives instead of a more waterfall requirements process. He sees a big challenge going forward on the business side in terms of optimizing the processes so that they’re not just paving the cowpaths as they automate the processes.

PegaWorld: SmartBPM Vision

The morning finished with a session on Pega’s SmartBPM product vision by Kerim Akgonul and Russell Keziere. Due to overruns in the earlier sessions, they had to try to cram a 30-minute presentation into about 8 minutes.

They covered off some of the keys to BPM success within organizations:

Create a vision for a transparent path to success: enablers, methodology, communications, culture, etc.
Deliver a dynamic and compelling user experience, a common theme with many BPM vendors right now
Share and collaborate across the enterprise
Give BPM to anyone who needs it, anywhere

They then mapped some of the new functionality of SmartBPM against these requirements:

Platform as a service, allowing for new BPM deployments to be rolled out with much less infrastructure effort through a multi-tenanted architecture that allows a new instance — complete with pre-configured processes, rules and best practices — to be created in a few minutes
Distributed business edition, including:

Integrated Work Manager, a composite application portal environment for accessing multiple SmartBPM instances in a single environment, including a consistent UI and cross-functional prioritization of work
Virtual Enterprise Repository, a library of reusable processes, rules, services and other software assets, to encourage reuse and enable governance
Business Intelligence Exchange, allowing SmartBPM data to be consolidated into existing BI environments for analytics and reporting
Multi-cluster Autonomic Event Services, which provides performance monitoring and optimization across all of the SmartBPM clusters within an organization, based on advanced diagnostics and SLAs

Flexible layouts and UI enhancements to enrich the SmartBPM user experience with some AJAX-y goodness. Some of this is as simple as automatic alignment when components from different sources are combined on the same screen, plus a number of new rich controls such as tree structures. There’s also support for mashups, although they didn’t elaborate on this.
Using BPM as part of the BPM development methodology to create an accelerated software enabled methodology that shortens the implementation cycle and optimizes BPM resources, using:

Application Profiler to directly capture objectives
Project Management Framework for organizing, assigning and monitoring tasks as well as tracking changes and providing an audit trail

Pega continues to innovate and create tools for deploying BPM, but some of the complexity around the methodology and the system itself can give potential customers pause when they’re comparing it with systems that (appear to) have a shorter learning curve.

They ended up taking most of the intended 30 minutes anyway, but with a long lunch break up next, it should all shake out by afternoon.

PegaWorld: Customer Panel on Building for Change

Abbie Lundberg, editor-in-chief of CIO magazine, chaired a panel on what it means to “build for change”, including Carol Rizzo (CTO at Kaiser Permanente), Tom Vicknair (SVP of centralized transactions operations payment strategy at JPMorganChase) and Carole Berndt (managing director, global head of client delivery at Citi). It’s great to have a panel that is 75% women at a BPM conference, where usually the best part of the gender split is that there’s no lineup in the women’s restroom.

It started with each of the panelist giving a brief overview of their business and the challenges that they are facing (that can presumably be solved, at least in part, with BPM). Vicknair got a big laugh when he drawled “we’re expanding…the government’s helping us”, but also pointed out that they’re the biggest payment transfer processor in the US because they have a 97% straight-through rate and are constantly looking at how they can reduce that remaining 3% using tools like Pega. Rizzo’s challenges are focused on government regulations in the health care industry and the integration of new biomedical devices onto their network while dealing with a widely varying base of constituents; Berndt’s are about the globalization of their business in providing service to multinational clients.

Despite the differences in their types of businesses, all are facing increasing demand to partner with their customers, providing them with better access to information and system; that level of transparency also requires agility to meet ever-changing customer needs. They all rank customer-centricity as their #1 priority, especially in an economic downturn since it’s even more critical to keep all those customers happy (even if they’re not as wealthy as they used to be).

Berndt sees room for improvement in Citi’s agility, and that the biggest hurdle is the organizational change required to get the various silos to collaborate around improving the customer experience. She also discussed the problems with moving a large number of divisions onto the same technology platform, which meant that some people end up with less functionality than before the conversion, and how they had to focus on the people/culture as well as the processes. JPMorganChase is also sold on the idea of one system for any given function, which has been an issue over the years of mergers and acquisitions as they moved from 3 down to 1 deposit system.

Rizzo says that although Kaiser Permanente is top in the processes and systems used by hospitals and doctors for diagnosis and treatment, they are working to improve the processes around health plans. Also a product of some mergers and acquisitions, they see different processes across different regions, making it more challenging to support with a single technology platform.

In response to a question about how budgets are tightening in these economic times, Vicknair pointed out that they have a $7B budget for IT and operations, and they’re going to spend it one way or another, so it’s best to push on with the BPM projects that can make a big difference in their agility.

As always, it’s difficult to blog about a panel since the conversation meanders around quite a bit. Lundberg did a good wrap-up at the end, with the focus mostly on people issues, including getting executive buy-in.

PegaWorld: Mhayse Samalya, Farmers Insurance

The next keynote was Mhayse Samalya, EVP of Farmers Group and president of Farmers Business Insurance, discussing how to create agility in small business insurance. They write a lot of insurance business in the US, operating under various brands including Farmers and Zurich. They’re better known for their personal insurance and larger commercial business, but have been building their commercial lines for small businesses of less than 50 employees: a $96B opportunity that is not dominated by any particular insurer. Samalya took this as a challenge to become #1 in small business insurance through a number of factors:

Good product lines
Expertise in the small speciality businesses
Predictive analytics to understand and model the market
Improve underwriting sophistication relative to small business
Create targeted offerings by agent segments (captive versus independent)

A big part of this was creating the right agent experience: simplifying and demystifying it with pre-filled forms that eliminate some questions, and automate the pass-through rate with automated underwriting decisions and automated pricing. This dramatically reduced the time required to achieve a bound policy, and freed up the underwriters’ time for dealing with more complex interactions.

They focused on incremental success, and achieved a number of significant milestones in agent expansion and new business growth during 2007 and 2008:

Restaurant product: reduced time to bind a policy from 14 days to 14 minutes
Auto product: increased close rate by 5%
Umbrella product: increased new business by 70%
1000 new agents writing commercial business

Next, they’re focusing on improving efficiencies by rolling out endorsements and renewals processes directly to the agents in the coming quarters, with an expected pass-through rate of more than 60%. It’s important to note that they focused on building their business first, then on efficiency.

Their lessons learned have relevance far outside of insurance, and could be applied to any BPM initiative:

Focus on the desired business results
Eliminate the non-value added business steps, noise and red tape
Put business change in the hands of the business
Rapidly prototype and iterate the targeted solution
Test, monitor and respond quickly to the market

They found it critical to build the right team, with a single empowered owner across business and IT (they had a VP-level position here that was actually part of the team, not a distant oversight position), a dedicated cross-functional core team, and in-depth participation from agents and underwriters. He also alluded to a relationship with Pega that had part of their compensation linked to Farmers’ business success metrics (e.g., pass-through rate).

The result: small business commercial insurance has gone from being a non-starter to the fastest-growing, highest-profile product line at Farmers; they’ve moved from a 2% market share to a 3-4% market share, which ties them with the biggest players in this market.

I work a lot with insurance so found all this to be fascinating, but Samalya made it interesting for everyone. If this is an indication of the caliber of presentations that we can expect at PegaWorld, it’s going to be a great conference.

I really like the presentation screens: most of the screen is taken up with the slides, but there’s a window near the top with the live video of the speaker in case you can’t see him directly at some point. This will also make it easy for Pega to publish these presentations with slides and video feed; it would be great to have some of these publicly available on demand.

PegaWorld: Alan Trefler keynote

I’m at PegaWorld in Washington DC for the next two days, back at the new and enormous Gaylord National hotel where the Gartner BPM summit was held a few weeks back. I think that the attendance here is more than at Gartner: I’ve been told that it’s 850 and Pega is claiming this as the largest BPM industry event, although not sure how many no-shows there will be with the recent economic downturn. The presentation of the conference needs a bit of a facelift: the loud rock music and flashing lights at 8:30am is so Bubble 1.0, and seems out of place these days, as well as being an unwelcome assault on the eyes and ears first thing in the morning.

Alan Trefler opened the day talking about change, picking up on the theme of “build for change” that we’ve been hearing from analysts and vendors for the past months. He started out, however, with a retrospective of Pega’s 25 years. We heard about their first offices in an older building in Cambridge, where they had to hoist their VAX 750 up an unused elevator shaft since the building no longer had a working elevator — having worked with 750’s in that same era, I immediately gained respect for these guys, since those were about the size (and elegance) of an industrial washing machine. He talked about how they’ve done a complete rewrite of the product 4 times over the years, keeping it fresh for new customers while supporting old ones; it’s a good measure of the company’s ability to do this that one of their first customers, Citi, is still with them after 25 years. I plan to spend some time listening to their customers this week to get a better idea of how well they’re really doing with that, since older vendors are often at a innovative disadvantage due to the efforts required to support their legacy.

He also highlighted their partners, which include — surprisingly — OMG: how can OMG afford to sponsor a vendor conference, but can’t afford to pay expenses for the speakers to attend their own BPM Think Tank? Or even, until some arms were twisted, not offer free Think Tank admission to the speakers?

He’s had time to tune his talk for the financial market disasters of the past few weeks, discussing how BPM is both pragmatic and strategic in new business, customer relationship management, the transaction servicing backbone, and risk, fraud and compliance. He discusses BPM as being made up of processes, rules and user intent: this last point is key, since I’m seeing a stronger focus by many vendors on the user experience of process participants. Pega’s paradigm for getting to a BPM solution is in three steps:

Directly capture objectives, as opposed to the creation of lengthy user requirements documents. I completely agree with this, since having business people trying to invent a new world for themselves when they don’t even know what the technology can do, then agree to no changes without a change order, is a ludicrous practice that should be banned. Pega advocates a much more agile methodology that takes advantage of a model-driven environment. I wonder what some of their large partners think of the idea of scrapping the entire (lucrative) process of business requirements gathering.
Automate the programming, including both the process logic and the user intent, by dynamically binding processes, logic and the user experience. In other words, have the process and logic models generate the user experience, yet still have that user experience be customized for the customer’s environment.
Automate the work, which seems like a rather obvious part of the BPM equation.

He moved on to Pega’s commitment to continuous improvement and innovation, and how they’re integrating both customers and their own sales/delivery team to bring new ideas back into product development. They have a very specific implementation methodology that they see as a competitive advantage by shortening the implementation cycle, and they’re working to streamline that cycle further. He touched briefly on some of their new stuff: the platform-as-a-service offering that was announced a few weeks ago, their Internet Application Composer for integrating BPM capabilities into existing websites, their Web 2.0-type Integrated Work Manager portal, the Business Intelligence Exchange for accessing their somewhat opaque data structures, and the Virtual Enterprise Repository that will be particularly important for sharing across instances when the PaaS offering is rolled out.

Trefler’s a great speaker: very relaxed, informative, engaging and just funny enough. Of course, it’s easier to be relaxed when you’re at the top of both the Gartner and Forrester BPM evaluations.

Logistics summary: there’s wifi but no power.

Disclosure: Pegasystems is paying my travel expenses for me to attend PegaWorld, but has no editorial control over what I write while I’m here.