The Platform For BPM's Second Decade

"I tell you captain, if you look in the maps of the worlds, I warrant you shall find in the comparisons between Macedon and Monmouth, that the situations, look you, is both alike. There is a river in Macedon, and there is also moreover a river at Monmouth."

- Fluellen, in Shakespeare's Henry V, explaining that his hometown Monmouth, Wales, is very similar indeed to the classical kingdom of Macedonia

Last night I had a dream that Fluellen said: "Pegasystems has training. Oracle has a BPMS. And IBM has Blueworks. I warrant you shall find in comparison of these situations with Lombardi, look you, is all alike."

The Welsh do make me laugh, and I did, I woke up laughing.

Normally, I use this blog to talk about industry issues and try to not so much flog Lombardi-specific products as deal with universal issues. But not today. Today is the culmination of hundreds of man years of effort and understanding here at Lombardi. Today marks the end of what I call "the first decade of BPM" and sets the industry on what I think is going to be an all-new course, or more accurately, a much broader and valuable course. And so out of pride, but also because I think that the BPM industry shifted today, I want to write about Lombardi.

Today Lombardi announced major advances in all three areas that determine success or failure in BPM:

• The need to communicate - you have to make business improvement personal
• The need to automate - you have to drive productivity and re-use
• The need for talent - you need to be able to assess risk, plan, and lead

Forget about simplistic approaches to driving transformational change based solely on whether your BPMS (or "BPP" or "PAAS") has a given feature. The so-called "Business Process Platform" as a sole-sourced technological salvation is a hoax. It's a solipsistic approach by technologists to once again say "if I have a better tool, I won't be as big a fool." Go on, stare at your image in the water and try to pawn all this off on simply another development tool or architecture. Instead, you need to take to heart what Toby Redshaw, CIO of Aviva, said a couple of weeks ago (paraphrasing here): If you're in IT and not doing BPM, three years from now you won't have a job.

He wasn't talking about a tool. He was talking about change and changing everything: how we relate IT to the business, how we use tools, and how we manage, nay, lead, change in our businesses through the use of BPM tools and methods.

Today Lombardi re-defined what a BPM platform needs to be; three specific vehicles:

Blueprint (Spring '09): The place your people should go for business improvement conversations. Using a unique approach of combining structured process (BPA) tooling with Facebook-style social networking and wiki documentation, Blueprint helps guide personal conversations about "how I think I can do my job better" into the scalable discovery of practical business improvements. Blueprint puts BPM on every desktop. Some of our customers have made this commitment and are in the process of training thousands of users. Yes, thousands. Want to knock down some walls in your company? Put Blueprint on every desktop and lead people (by example) to make suggestions about their jobs, their tasks, their activities. Even if you're not ready for the automation part of BPM, Blueprint will help you discover your processes, and then improve them. BPM isn't just about "modeling" and "BPMN" or "rules." It's about changing a culture, about embedding technology into the fabric of how we do things. We can learn from social media how to do this. This isn't your daddy's enterprise software, because it isn't 1983 anymore (or 1977, or 1896).

Teamworks 7: What's new about BPM-style process application development? It's the model, stupid. And so why is all the management of models and their internal assets built on top of traditional, decades-old-school-text-based source control systems? Using models, the application development goes faster, but then when you save a version of the model and try to manage it (both at design-time and at run-time), our competitors use traditional notions, or incomplete representations of the model (they might, for example, restore the rule that existed at some point in time, but not the UI's or the integrations).

Teamworks 7 answers this question with a completely new way to manage process models for their entire life - from the beginning of time. We looked at every use case along the entire process application life-cycle and we solved every problem that BPM-style development threw at us. Let's take a simple example. BPM demands iterative development. So what happens at the end of every sprint in agile? You know what happens: you tell people to "stop development for 24 hours" to stabilize the system, to make sure it's going to work. With Teamworks 7 you simply create a snapshot of the working version, then you keep developing, and when it's time for the Playback, with one click you go Back In Time to the Playback version (while all the other developers are still working on the tip), and you play it back. Zero lost productivity, entire model-universe reversion. One click. Back In Time is the biggest advance in iterative/agile development tooling since the method was developed. And you can quote me.

But that's just the beginning of Teamworks 7's repository model management. Dependency management is a problem that is solved, finally, with Teamworks 7. This is the best way to manage dependencies in any SOA development environment. Ever.  Because of this, Teamworks 7 also enables re-use to an extent never before realized. Re-use is the lynchpin of the BPM value prop. And the barrier to real-world re-use of technology assets isn't knowing they exist, it's knowing you won't get screwed by upgrades to those processes/services if they change. With Teamworks 7, you won't get screwed from service or rule re-use. Ever. And yes, you can quote me on that.

Lombardi University: OK, so you have people talking to one another. And you have a platform that truly enables the end-to-end business process application life-cycle. Now what? "How do I sell BPM to the business?" "Where do I find qualified people?" "What skills do I need?" "My infrastructure is maintained in a different group, and they are difficult to deal with!" Although BPM is (relatively) new, it isn't about all-new skills, and it's not about building an empire or creating an "other" part of the organization to deal with BPM. This is about adding the unique aspects of BPM-style development and management to each of your peoples' CV's. Sure, all vendors do staff-augmentation with experts, but there's also skills-augmentation. And frankly, this is what we are hearing our customers and partners want. "I have good people who can (build apps) (lead projects) (maintain infrastructure) but this is a bit different. Teach my people. Help me (or my partner) become self-sufficient in a scalable way."

With Lombardi University, there is now a roles-based way to augment your peoples' and your partners' skills. Roles-based is the key. This isn't simply education on the speeds and feeds of a tool.

And with Lombardi University certification, you can also measure the attainment of those skills and your own maturity as an organization. Have you deployed five process applications? How many people can you rely on to maintain that infrastructure? How do you assess the risk you are assuming? How do you talk about a 1, 2 or 3 year roadmap of skills development? With Lombardi University, there is now a way to do just that.

And not only that, I've talked with CIOs around the world and their #1 talent concern is this: how should I lead my BPM initiative? Who should do that? What does that person look like? Well now, for the first time, there's BPM Executive Leadership courses. We're launching two at the outset. These courses don't teach modeling and products, they teach how BPM is different from other programs - and how it is the same - and gives concrete guidance on how to lead your BPM effort, so that it doesn't become an "other" - that it is mainstreamed into the programatic fiber of your company.

By the way, we can't do all this by ourselves. So we've embraced technology from Saba to help you manage your talent development programs, they're the leader in career development software (in fact, your HR group might use Saba... if so, we can mash it all up and you can manage your BPM careers along with the rest of your career development efforts).

We've also engaged outside faculty. Industry experts like Bruce Silver will be delivering courses available through our catalog. Some of them use Lombardi tooling, some don't. The issue is education, not brainwashing. If you succeed with our help, we'll do fine. Derek Miers and his BPM Focus group will be teaching Lombardi University courses. Same with Dr. John Alden, 30 years with Accenture, co-founder of Terraquest. And Andrew Spanyi, author of probably my favorite BPM book, BPM is a Team Sport. This isn't altruism that we're practicing here, it's about your success. If we assist in that, we'll figure the money bits out. So Lombardi University is attracting the best BPM faculty in the world (if you want to be a part of our Extended Faculty, let me know).

Together, these 3 pillars - communication, automation and leadership - combine to form the basis for the platform for BPM's second decade. Lombardi is that platform. You don't have to do it all at once. Like all journeys, BPM is something best tackled one step at a time. Ping us for more information. I promise that if you do, you won't confuse us with Pegasystems, Oracle or IBM, or any other Monmouth of BPM...

On Technology Security Standards: BPM, SAML, XACML

In a recent post, enterprise architect James McGovern wondered whether BPM products, like Lombardi's, support XACML.

So I replied with a comment discussing BPM and security mechanisms:

With respect to security there are two fundamental issues: who are you? and what do you have access to? In general, the OASIS SAML specification deals with the former, and the OASIS XACML specification deals with the latter.

Lombardi Teamworks explicitly supports SAML as a means of identifying who you are and passing that around. Very few, if any other, BPMS vendors support SAML and it's a non-trivial specification to implement. Lombardi Teamworks does support SAML and as a result, we have many very secure implementations and customers.

Authorization is a bit different. Generally speaking, XACML defines (1) the mechanics of defining a central set of authorization policies, and (2) how a service accesses those policies. That is, and this is key, you want the service being accessed to be its own enforcer, based on policies set in the central policy repository.

You want the called service to ask the calling application for credentials, and you want the called service to be the one that _allows_ access based on the policies. So as we see, the XACML check is done under the covers of the web service that "houses" the resource being called.

BPMSs (not just Lombardi's, but all of them) don't actually house the interfaces to external services, but rather hold pointers to those services. These are held as metadata inside the process definition. For example, the service endpoint address URI is stored, but not the WSDL. Therefore, the [XACML-based] security implemented under the covers of the web service operates independent of the BPMS [or any other client]. However, in most advanced organizations it relies on the SAML (or other) assertion of who you are and what context (application) you are running within. This is why it's the SAML implementation that forms the basis for security in the BPMS world.

James reflected on this in a subsequent post, and in that post he raised a few more questions... so let's continue the conversation...

1) When the BPMS is the service provider (not the consumer)

James says "the rationale for storing policies centrally is more than just one product needing to be its own enforcer. In an integrated world where a BPM engine needs to talk with an ECM engine, the need for these two to have the same access control policies is important."

Yep, I agree. I didn't make reference to it in my post, but of course for any services you expose from a BPMS (or ECM, or ERP or other platform) you should be able to author them so that the centrally defined policies govern who has access to that service. I suspect that all BPMS allow for this.

2) User interfaces, security policies and the BPMS

James says "It is good to see that XACML checks are done to protect web services but they may also be leveraged by UI components as well as access enforcement may require displaying or not displaying a particular feature/function."

Having UI's call the central policy server for presentation-layer rules on what aspects of a UI to show would be an interesting thing to debate. I'm not sure I'd agree with that as a good mechanism. It would be better for the presentation to drive itself based on the types of data that were presented to it (in the same way that device-dependent presentations are derived). That is, you don't want the presentation layer figuring out the security because that assumes the presentation layer has access to everything to begin with. So I guess I would take issue with the premise.

If, however, you want to drive your presentation-layer in this manner, you probably also want the presentation layer up and outside the BPMS. So while in Lombardi's BPMS (Teamworks) you can author UIs, we also give you the ability to easily plug in your own UIs for particular steps in the process. This would be the mechanism to separate the UI from the process definition, and also allow you to drive the particular UI from centrally-defined policies.

3) On BPMSs storing their own users

James says "I think many would agree that a BPM engine should store processes not users."

Yes, I agree. At Lombardi, you don't have to manage users in our store, if you manage them elsewhere (like LDAP or AD). I would say, though, that in the real world we've found that there are attributes you want to use in a process-context that aren't present in your corporate systems. These may be user attributes (like skill level for a particular job) or they may be role-related (a person's relationships to others change depending on the process context).

So in Teamworks, you have the ability to not only use the central user store, but, if you desire, you can also extend the attributes for a user (or role) without mastering that user... sort of a hybrid system. Again, if you manage the attributes centrally then the BPMS will pick them up. It's a matter of choice, and, to some degree, practicality.

We also think this "relationship" issue is bigger than LDAP and AD. Of course, matrix'd organizations have existed for a long time, and these basically reflect that my relationship to people around me change depending on context. For example, the CIO of Company X reports to the CEO of Company X for operational issues, but may also report to the CIO of ParentCompany Y for other things (like use of standard technologies).

As companies begin to measure more of themselves using process as the normalization, then these numbers of "matrix organizations" expands. So we think that organization modeling is part and parcel of the larger BPM discussion... and that these models will integrate with [LDAP or AD], but provide more extensive information. This is an area that I think will really change and expand in the coming decade, as the convergence of increasing security along with increased decentralization of computing resources gets mainstream emphasis.

Conclusion

Securing distributed systems has been long overlooked due to real-world needs to get technology out the door. But this aspect of enterprise architecture is critical to successfully embracing not just distributed technologies like BPMSs, but also important so-called social computing platforms like wiki's. Without good guidelines and well thought out policies, companies just won't embrace these critical technologies. And as a big company, it is critical you be able to embrace these because your smaller competitors are, and they are stealing your most profitable customer and product segments.

Thanks, James, for a good forum to have this conversation.

Technorati Tags: James McGovern, Security, SOA

Lombardi & Google: Partnership of Titans

Just a quick note to give you this link to a blog post on Google's site where we talk about the development of our Lombardi Blueprint product. That product represents a real leap in capability in terms of process mapping, documentation and modeling... the ease of use and business value it provides is pretty cool. And it really couldn't have been done as efficiently without Google's "Google Widget Toolkit" (GWT). So the blog post is on the GWT blog. Since the post went up, a ton of developers looking at using GWT have hit the Blueprint site, and we're really pleased and proud to be the poster child for this AJAX-y technology... which we hope (obviously) becomes somewhat of a standard.

Alex Moffat, the lead engineer on the Blueprint product line, wrote the post and I like how he sums up the business goals for the product:

The challenge handed to us was to create a tool that the average business user could use to document and manage their business processes. It had to be easy to use, encourage collaboration between team members, and provide a shared repository for all of a company's process documentation. Workflow functionality had to be on par with our competitors: Microsoft Visio, IDS Scheer's ARIS, IBM's WebSphere Business Modeler, and other desktop modeling tools. But we also wanted wiki & shared whiteboard capabilities to store information. Editing should use the drag and drop interaction users of desktop apps are familiar with. We ended up with some additional features that really set us apart:

• An intuitive map view as a high level visualization of a process

• Automatic workflow diagram generation

• PowerPoint generation for easily presenting the process

• Online chat functionality

I think this shows how achieving business goals is more and more becoming inextricably linked to the technology addressing those goals. This application simply could not have been developed even five years ago, without an investment 20-50x of today's cost... which obviously means that the economics wouldn't support it. As it is, Blueprint is licensed at the ridiculously low price of FREE for the Personal Edition, and only $50 per month for the team account!

We're doing the same thing with the more traditional behind-the-firewall BPMS integration platforms, today. They are getting simpler to use and this is changing the game of what types of enterprise process applications can be built because they are changing the game on who can build them!

Business Process Management is about knocking down the traditional development skills while retaining the important, traditional development patterns. Blueprint is one aspect of this, and traditional BPMS's, like our own Teamworks, is another angle of attack.

Business process management is not about one or two simple, specific things. It is about the pervasive shift of responsibility over all process-related elements (documentation, compliance, execution, improvement) from IT to the line of business. We're happy to be pushing the envelope on how we deliver all this capability. And thanks again to Google for creating a great framework for us to leverage.

Again, here's the link to the blog post Lombardi Blueprint, Built With GWT.

Technorati Tags: Google, Microsoft, Lombardi Blueprint, Visio, WebSphere

'Cause There Ain't No Cure For The...

Only in the tech world could we be in June passionately arguing about "top down" and "bottom up" and not be in a convertible drving up PCH to Zuma with a cooler full of Pacificas and limes in the trunk. Well, to return to the summers of your youth and live the dream of BPM, now's the time to download this 8-track podcast., set aside Danielle Steele and for the next 22 minutes listen to ebizQ's Gian Tratta interview me about why and how to implement top-down BPM strategy.

"Our view is that business process management is a business function and it is something that should be pervasive to your organization. If you're really going to start viewing your company through the prism of process, this requires top-down commitment."

I know that's pretty steamy but if you can handle it, there's more where that came from. Enjoy...

Technorati Tags: Blueprint, Gian Trotta, ebizQ

SaaS, Modeling-lite, Process Execution, Enterprise 2.0 and Other Words That Google Will Rank Highly

Nathaniel Palmer wrote a review of Lombardi's Blueprint that I thought was interesting. So after my conversation on "Enterprise 2.0" with Sandy Kemsley a couple of days ago I thought I'd go back to that.

You see, I agree with Nathaniel's assessment that platform-level BPM-SaaS   (or any other integration-intensive platform) is a non-starter (for the relevant future, anyway).  Like any new technology (for purposes of this discussion, let's assume "SaaS" is new and that it's a technology, both of which are bad assumptions but that's another discussion) it will be mis-used by existing players and only new ideas will bring out its primary benefits.  Remember the move by the mainline DOS players to Windows?  They all died because they viewed this new thing as just a re-swizzling of their old thing... when in fact a new design approach was required.

So if you want to look at the BPM market I think there are 3 or 4 "buckets" that a process platform addresses.

- Modeling
- Execution
- Monitoring
- Reporting

I suspect we could quibble at the edges but generally that's what there is to this thing.  Each of us vendors make implementation choices that we can debate, but the functional buckets are pretty much those four. Let's take a look at what's required for each of those, and where new technology or services could make a difference:

Modeling doesn't require integration and it benefits from collaboration.  Now, there are advanced use cases where integration into and introspection of existing systems will help build scenarios for simulation, but in general, the bulk of the work done in the front-end of the modeling life-cycle looks like an OK fit for something delivered over the web. SaaS is not simply about a scalable way to deliver functionality, it facilitates collaboration if you tap into that part of it. The web allows people to get together to do their human-based work. If the tool you are providing also is easier than competing alternatives, structures data and puts in an accessible place and can hand it to you in a standardized format, then SaaS gives you a very scalable way to deliver this capability. That's where salesforce.com excels: doing something that was already being done but in a better way. In addition to that, if there are new concepts in this tool, then even better. At Lombardi, we think Blueprint is both easier to use than modeling alternatives (like salesforce.com) but also we think there are some new ideas (like integration with our behind-the-firewall BPMS). Easy access at the beginning, and tightly-coupled standards-based round-tripping when you move to execution.

Execution is different.  The aspect of BPM process execution that I find most interesting is the execution that is done to make existing alternatives more flexible.  BPM isn't a rip-and-replace thing where you should be building a new application. In fact, a BPM system should host as little system-of-record data as possible (other than the intrinsic SOR data that execution and monitoring spins off, process analytical data about the process performance... which I think is the most interesting aspect of BPMS-based execution!) If you aren't integrating to legacy systems, then all you're really doing is building a workflow application. Been there, done that, more silos, more support headaches for IT. That's not the process problem for the Global 3000. These companies have significant dollars invested in their systems and now those systems are holding them back.  They can't dump them, their whole business depends on them.   At the same time, these big systems just can't be changed fast enough.   SOA alone isn't the answer, because the problem is not that the system-to-system transactions aren't working... it's the patchwork quilt of systems and humans that want to work together in new ways that aren't able to move fast enough. So service-enabling legacy systems as a part of a larger SOA is a Good Thing, but it's a Good Thing so that you can consume them in the new human-facing processes unified across the new business initiatives. BPM (and SOA) is a part of that.  A BPM layer can be inserted and extended... it is more flexible for new things, and it masks the old thing while making the whole process seamless across the multiple systems.  Well, anyway, the point of all this is that integration of the process platform into your business BPM is heavy, heavy lifting.   If it's not heavy lifting (the low hanging fruit of unintegrated workflows) then all you have is a portal, a form and a workflow engine... you're not doing BPM. Unintegrated workflow applications using SaaS? Sure. Core-process BPM execution? Nope, not well suited to SaaS. (Of course, you could see a path from modeling to unintegrated prototype - one that "executed" - and then a transfer into a behind-the-firewall platform, but to me that's just modeling, so I'd put that up above...)

Monitoring.  This part of BPM gets very interesting and sometimes not well understood.  Not only should BPM offer up technologies that are agile, but BPM is the conduit through which we make business decisioning more agile.  In fact, my experience (from many years pre- and post-BPM) is that being able to make informed business decisions is the longest pole in the tent of agility.  And having good information is getting more difficult because of the morass of systems and silos (Ex-hell, as a customer calls one popular spreadsheet silo...).  So monitoring complements execution and is equally important to execution for almost any process of consequence.   You probably won't execute all of a core business process, but you will have to monitor key parts of it to provide the process-oriented "perspective" to management so they can know when, where, what, who and why of improvement.  The reason is simple: any core process will already have some systems in place to support it. They may not be great (hence the need for BPM) but they will exist, resulting in more integrations, therefore not a candidate for SaaS (again, in the relevant future).

Reporting.    The results of execution and monitoring need to be visualized.  I think interesting Saas-based work may be done here around real-time collaboration and real-time data visualization.  This is an area where a lot of vendors will be tempted to simply put their BI tools into SaaS.    That won't do much in the market.  But there is opportunity here, I think, to use the SaaS platform for something very interesting... the integrations required for reporting databases are so standardized these days - and the performance of modern data warehouses is so good - that some of the technical hurdles that we talk about in the execution and monitoring sections, above, don't exist (although the political hurdles of data access still do).  I am watching this space for interesting developments, though... things like what businesses (like IBM) are doing in Second Life fall into this category, for me. In addition, I certainly would consider a future where a product like, say, Blueprint, might want to visualize the execution artifacts of a product like TeamWorks. Now wouldn't that be Enterprise 2.0'ish!

Well, those are my thoughts on when and where SaaS innovations may play a role in BPM in the next couple of years, and also on how Enterprise 2.0 (so-called) might transpire. Enterprise 2.0 is, to me, about the merging of the public and private delivery platforms accessible by a person in their worklife. By merging these platforms and leveraging each one to its fullest, we can do a better job of delivering the right stuff to the right person at the right time at the right cost. Enterprise 2.0 isn't Web 2.0 because the relative importance of "me" is reduced. As someone pointed out in Sandy's conference the other day, "this isn't communism, we have to think about corporate profit." And as I pointed out, it's also not about anarchy. It's about looking across the landscape of the enterprise and using every technical asset at our disposal, and leveraging it to the fullest. Where BPM comes into play is that it directs the order in which you create this leverage. It is the basis for understanding your business. If you marry these two ideas, BPM directing the Enterprise 2.0 leverage, then you'll be more quickly on your way to closing the gap between your PE multiple and Google's!

Technorati Tags: Enterprise 2.0, IBM, Sandy Kemsley, Nathaniel Palmer

On Business Programming

Much is made about how BPM is “going to change the way businesses are run” by having “the business” become involved in the development, optimization and evolution of these process applications. This is a cause for consternation by experienced technologists who are [understandably] worried about having the business “run amok” with programming tools. There are enough shoddy applications that contribute to IT’s maintenance nightmare; we don’t need more of them, we need fewer. Maybe, then, “don’t let the business harm the business” should be included in the hypocratic oath of BPM.

On the other hand, the business is clamoring for tools. Tools to help them take control of their own business processes. Tools to help them emerge from under the “iron boot” of unresponsive IT departments. Tools to let them be productive in groups - like Microsoft Office has allowed them to be productive individually. Prospects tell me that “our customers are making demands on us - we have to move faster! We know technology can help us, but it takes so long to do anything, we question its value.”

So here's the dilemma: on one hand, IT needs to be more agile to respond to the marketplace at a faster pace than ever, and on the other hand, much of the clumsiness is a result of "just doing something" which resulted in all these silo'd systems (and people, too).

It's the irony of our times that the very systems that have allowed business to scale have become so complex they are the obstacle to scaling further, faster.

How do we get the power of people doing business in agile, de-centralized ways, baked into our technology? Or, stated differently, how do we embed technology so deeply into the business, that business programmers can take over without doing harm to themselves?

What can we agree on?

First, let’s find some common ground. To do this, I’d like to look, say, 30 years into the future and propose that:

• Business people will be smarter about technology than they are today.
• Tools will be easier-to-use than they are today.

I don’t think those are too controversial. That's certainly been true over the past 30 years. If you agree, then you'd probably also agree that at any point along that "30-year path", there are incremental improvements.

People getting smarter: It's difficult to plan for the increased savviness of the work force, but it happens. It's usually the result of fundamental shifts in technology. Whether it's the Walkman or the web, everyday people get smarter about using technology in their daily lives. And while we can't really affect the timing of this, technical literacy rises over time and it is what it is (or will be). So let's simply assume a line that depicts the rising technical capabilities of line-of-business people over time.

Tools getting easier: As to the second assertion – that tools will be easier-to-use – hopefully we can agree that the state of these tools is going to get a lot better. Bill Joy, in his famous speech to The Commonwealth Club a few years ago, pointed out that the difference in energy between a matchhead and an atomic bomb is about 10**12 and that with the advance of hardware and software technology, that’s about the power differential of personal computing between 2000 and 2030. The impact this will have on user experience and accessibility will be staggering. By then, we'll be negotiating contracts via Second (or Third or Fourth) Life, directly with our customer's avatar and the result of the negotiation will be represented in the process model, a contract will be generated, triggers based on the agreed SLAs will be established and a choreography will be instantiated. And you won't have to know a damn thing about "process"...

So tools get much easier to use, over time, as this chart shows:

This trend started with the first personal computers and VisiCalc, through to today's Microsoft Excel and Google Spreadsheets; from WordPerfect to Microsoft Word 2007. Today's business is "programmed" by end users in ways largely unimagined 30 years ago. This steady advance in usability will continue, unabated.

This trend is now moving from personal productivity applications to enterprise applications, and will continue until the very business is “programmed” by business people, so that the business’s processes – like today’s documents – are directly manipulated by them. It is simply a matter of time. Is it 30 years? 10 years? How much will the line move over, say, the next 36 months?

Business Programming will occur. Lombardi’s mission is to accelerate that capability for our customers. If you believe that pushing the levers of agility closer and closer to its users (the business), then every advance in tools accelerates the benefits that result from business programming, as the charts below show.

There is a role for IT

Of course, there is and will forever be a role for technologists – people inside the organization who focus on the hard bits of technology. In the same way that increasing computer power enables ease-of-use, so it will also enable complexity (and evil, according to Bill Joy, but that's for another post...).

The pace of change of networking technology will continue to increase and, for large organizations, there will be an inherent advantage to having technologists on the leading edge. Technology - in whatever form - will be a competitive differentiator for many companies, at those edges where innovation is occurring.

At the same time, more configurable technology will be used by a wider audience. Look, for example, at cell phones. They are easier to use than ever, and more people use them, but there’s a lot of technologists at phone companies keeping the dial tone on. What we’ve done with cell phones is push out the “business use” of the infrastructure to simple devices at the edge of the network – and hidden the complexity of the network from the user of those simple devices. Those simple devices aren't only doing simplistic things, they are just simple to operate, and operate with very evolved interfaces into the core network which, at, say, Sprint vs. Cingular is different, and people with special technical skills and experience are required by each of those companies.

I was at one customer recently who has an investment in their core systems which measures in the 10's, if not 100's, of billions of dollars. That infrastructure isn't going away in my lifetime! Yet, their need for agility and the ability to compete using those systems - indeed, leveraging those systems as assets and not liabilities - is the key to profiting in this century.

Hiding this complexity, enabling process control and visibility, and working in partnership to foster change is the issue. And in order to do this, it's going to take all the technical and business expertise available, focused on the important problems in your company. If there's competency in the business, let's grab it!

What does this mean?

So in order to facilitate the move to business programming, BPM technologies need to strongly evolve in the following areas:

• Business Strategy: Massively easier-to-access tooling, and easier-to-use UIs for business users, to get started quicker, without IT involvement, and specific easy-to-understand ways to collaborate on "final mile" issues that require IT.
• Collaboration: Embrace the highly collaborative post-internet world, beyond simplistic ECM and into wiki’s; beyond simple, structured ad hoc routing and into sharing; beyond over the web and on the desktop to an access anywhere, anytime, well beyond the connected-only world of Web 2.0, and into the mobile world we live in.
• Modeling: A more expansive view of modeling the business, not simply modeling a process. Mixing modeling with process execution to a degree not seen before, recognizing that “simulation” and “historical data” must be mixed in order to truly model an organization; and moving models well beyond process diagramming and into living entities that are on a par with running processes… because modeling the business is a real-time, production effort and the asset – visibility – is more important than the assets of, say, ERP.
• Governance & Behavior: Better tracking of governance (maturity) and behavioral (motivation) models so that the enterprise competency of BPM can be grown, made visible, and incented.
• Infrastructure: Hardening the vertical communication touch points, but not the paths. Ways to control the interfaces into the legacy network must be provided so that business people can easily discover previously-used data, and also facilitate the collaboration between business and IT when new data requirements exist.

"If you aren't first, you're last"

BPM is the technology for these times because it's the only enterprise technology that embraces the technological "perfect storm" you are competing in: the convergence of highly distributable technologies, a highly connected world, and a new majority of users in the business who are capable and eager proto-technologists. And because it does it in a connected, heterogeneous way instead of being "rip and replace," it's a technology you can actually use from large business to small!

So next time you think about BPM, think for a moment about these trends and about what you want to enable over the next few years at your company. Business programming is coming, and like Ricky Bobby said, "If you aren't first, you're last." Whatever that means.

Technorati Tags: 21st Century Process

Too Cute for Words

Bruce Silver's post about process optimization garnered a comment by Fair-Isaac's James Taylor. Bruce has recently spent a lot of time with Lombardi's product (TeamWorks) and presumably with Savvion and BEA. I don't know if James has seen any of these products (I know he hasn't seen Lombardi's optimization technology). James suggests that human-based process optimization built into these products might be "light" predictive analysis and that they sound "cute." Sort of like the (probably apocryphal) old country song where the guy doesn't know whether to commit suicide or go bowling, I find myself of two minds. If we give some pretty deep insight into big problem areas for our customers, and it seems so simple, that's a good thing... but methinks James is suggesting this optimization stuff is simplistic, not simple. So I'll take exception...

It might be useful to understand what the business problem is, and then discuss the technology being delivered... if something solves a business problem, and it does it in a "light" way, I would think that would be preferable to solving the same problem in a "heavy" way, yes? We (Lombardi) take pride in the fact that normal, non-technical people can use our optimization tools and gain value... (the deep thinking is built in... making it "light" because we've done the "heavy" work that's required to make any hard problem seem simple). We think it's an example of where a platform can be more than just an engine, because it understands the context of what it's being used for, and leverages that understanding through innovative tools for the business.

The problem we saw is that in human activities, there hasn't been any scalable way to understand the behaviors inside that black box of an activity without doing all the hard work James refers to. Our customers confirm that previously, they've spent lots of money, some of it mis-spent, trying to gather the data, build the ontologies, etc. to help discover, define and implement rules to make human-based processes more efficient. And getting the data was the most time consuming bit in many cases.

With a good BPM platform, at least that part of the problem can be solved. We know the structure of the data that passes in and out of every human activity... that's a big step forward. Additionally, we understand the context of that data with respect to the process. Putting these two pieces together (strcutured data that is constant for every activity of every process authored in the BPMS) we can give new, deep insight into correlations that _seem_ to be occurring inside the process. Of curse, as James says, we don't necessarily have _all_ the conext, for example, legal regulations. Additionally, we don't know whether this is, indeed, a correlation or a coincidence. Human rigor is still required once a possible correlation is found, but now it's highly directed rigor. This doesn't make the analysis less valuable, less heavy or, even ugly. It means it solves the first part of the longer process of understanding and implementing new business rules. Indeed, we call this capability the discovery of non-obvious business rules.

The analysis can give information about correlations that are occurring (e.g.: on Fridays, when the order is from customer x and the amount is above y the outcome is <this> 98% of the time). You can apply various complexity levels, you can set various thresholds of numbers of instances required to be valid, etc.

It all seems easy because first, it's a structured system... the ontology exists, if you will and the users don't have to deal with any of that. To them, they just look at the process drawing. But inside the system, that is a rich, structured semantic that can be put to use. Second, we are limiting our understanding to what our system knows.... obviously, in the real world, people then use this new insight to focus what they then go look more deeply into. Today, without this insight, the further ("heavy"?) thinking is either mis-directed because you don't have statistical backup for what you're doing, mis-spent because you work on stuff you can instead of working on stuff you should, or in the majority of cases, simply isn't done because nobody knows where to even begin.

By the way, we don't believe the world is anywhere near ready for so-called autonomic business processes (in this human activity area) for the very reasons James talks about. There are too many unknowns (read: contexts) to make changes in real-time, on the fly. Using our optimization technology, though, you are able to kick off a process to work on the optimization(s) that are suggested once thresholds have been met.

Using the new data and the built-in context that the best BPMSs are generating to provide solutions and insight to business problems, or to make the understanding of those problems more focused is a Good Thing. You could even call it _very_ cute.

Technorati Tags: BPMS, Bruce Silver

Zero-Sum Thinking

Kudos to Bruce Silver for an even-handed response to the "SOA vs. BPM" debate that's sure to capture some blog readers, but unfortunately does not clarify the issue for thoughtful people (see Christopher Koch at cio.com and Joe McKendrick at ZDNet [sidebar: when will we quit using military metaphors when we're talking about something like Services Oriented Architecture... this is not life-threatening stuff, guys]).

BPM is not SOA, but that doesn't mean they oppose one another. They are distinct yet complementary platforms that, used properly, can help everyone in IT and "the business."

The way I say it, SOA defines the way IT assets can be easily consumed by the business, and BPM defines their consumption. In Bruce's words, this is the "model-down" approach.

There's a lot of other things that the platforms do (think governance), but in essence, they provide the ability to better align interests by presenting purpose-built interfaces to their primary constituents (business and IT), providing more portability across that "line" while also serving the distinct managerial and leadership issues that the two communities properly have. As for IT, the benefits for the adoption (and promotion) of BPM are huge.

First, assuming the business gets involved in modeling, and goes down the BPM path, there will be absolute fidelity between what the business asks for and what they get. This is the benefit of model-based definition. It's also why the model as defined by the business is king (as opposed to a BPEL-based articulation, which is a part of the SOA infrastructure). Being able to share the model in a transportable format like BPDM - truly sharing the model - is important, too.

Second, by embracing BPM and a model-driven definition, IT is insured of a proper prioritization of services to provide. At Lombardi, we've run into situations where SOA-vendors led customers down the path of "service enabling" a ton of legacy systems, only to find out after building, say, "1,000 re-useable services" that only a few were needed by the business, that some that weren't built really were needed, and that changes to what was built - to align the service's outputs to the process need - were required. A lot of time and money was wasted.

Third, IT will benefit from a business that is more deeply involved in requirements gathering and solution definition using the collaborative BPM tools. This common set of tools, and language, will increase the "velocity of communication." Like increasing the velocity of money increases the overall money supply in an economy, increasing the velocity of communication between business and IT will increase the "solution supply." By promoting the use of BPM technology, solution delivery is no longer a zero-sum game.

As the business world evolves its use of technology and moves toward a more embedded model, IT will increasingly be responsible for the provision of steady-state services for the business to consume. Those companies that get to this new model quickest will be the winners this century. And SOA provides the basis for the exposure of these technology assets. This model requires the hand-in-hand deployment of a new type of technology - human-facing BPM technology - to complete the picture.

BPM is not SOA, but they're not competing interests. This is not a zero-sum game.

Technorati Tags: BPM, Bruce Silver, SOA

"Hey, that Salieri guy's Google numbers are way up!! Mozart must suck."

What it must have been like when instant gratification wasn't so instant...

I have been trying to find the exact quote that's attributed to Bill Gates about how technology always takes longer to catch on than you first expect, and then has a bigger impact than you expected. It's very true. It turns out that in order to really change something... to introduce a new thing... takes hard work and more time than you thought for everyone "to get it" (I used to use that phrase so much... and it's such crap...). A good idea, sure, but then it requires a lot of self-criticism, change and relentless execution. For longer than you want or expect, sometimes.

A couple of days ago, Ismael Ghalimi wrote a piece that said, basically, "SOA's Google numbers are up and BPM's are down. BPM sucks." He then goes on in a weird sort of way to suggest that BPM sucked because it has the wrong word in its title, or that it wasn't "cool." We need "Web 2.0" or "Office 2.0" to make "BPM 2.0" the Next Big Thing. Heck, if we mash it up enough and make it really, really cool maybe it'll even score a 2.1... maybe a 3-pointer from the half-court of Google's Calendar!!!! LeBron would endorse "BPM 3.0 Maaaasssshhhhhhhh-UPPPPPPPPP!!! I can hear Joe Tait screaming now. Or that soccer announcer... GOOOOOOLLL GOOOOOOLLL... BEEEEEEEPEEEEEE-EMMMMMMMMMMM THREEEEEEEEeeeeeee.

To fully tie off the pretzel, Ismael's logic then was something to the effect of how no vendor in the space has crossed the $20 million chasm, therefore the space was dead or dying or, well, who knows.

I don't know where he gets his financial data, but it's wrong. I don't know where he gets his "cool" data, but it's irrelevant (SOA isn't "cool", either. Most business folks I know think ROI is pretty cool, though). I don't know how he interprets his BPM data, but he's interpreting it wrong.

For example, I did my own Google analysis. Search for "service oriented architecture" you get about 80+ million linked items. But search on "business process management" and you get half a billion. Um, BPM 5x the size of the SOA market? Wow, SOA sure does suck... These numbers, like any other, have little relevance on the markets of SOA and BPM... they just show that data from Google is very difficult to turn into information without a LOT of other context.

That is why a man with numbers
Can put your mind at ease
We've got numbers by the trillions
Here and overseas

Two times two is twenty-two
Four times four is forty-four
When numbers get serious
They leave a mark on your door

- Paul Simon, When Numbers Get Serious

We Don' Need No Stinkin' MISO!
The competition is tough. The large stack vendors have lot's of marketing cash to throw at a problem, and it's sometimes in their interest to confuse the market. They do this by doing what they do, the triple-double of marketing: "we're almost there and by the way you don't need it anyway." So what? I assume that we're not going to actually argue over whether a company can effectively compete against a bigger company solely because it's hard.

Because, what if the market does need the new thing?

Look, this is not simply about technology. If it were, then regardless of his faulty facts, Ismael could be right. If this were a technology-led problem, then this market would not take off.

So let's not lose sight of what's really driving all this, which has nothing to do with any technology vendor or product per se (although it is largely about change writ large by the internet build-out). It takes no great insight to predict that over the next 10-20 years all of the following will be true:

• Companies will manage to their capabilities (i.e. "processes") more than to their functions. Functions will continue to play the HR role they play today, but the business will be run based on metrics against capabilities. This means massive investment in new tools to reflect this change must occur, new tools will be built. Why do you think Microsoft and Oracle have BI tooling so high on their list of strategic areas of investment? Because new business insights are needed to support the new business supply and delivery capabilties. But they are beginning to understand that it's not just the front end tooling... it's the data on the back end that also must be aligned to the new way of thinking. And that data is generated from a BPM-driven point of view (which, therefore, also requires tooling).

• Companies will build for CHANGE, not for a given product or service. And in order to change, companies will require massive new real-time VISIBILITY. Some so-called BPM companies, and all the big companies, would have you believe that BPM is about a computer language. Or about a "service orientation." Or about some other technology-based depiction. Wrong! The basis for the company of the 21st century is about gaining VISIBILITY into the levers of the business, so that CHANGE can be effected faster. The technology portion of these two demands, with twists and turns along the way, will largely play out as the pure-play BPM vendors see it playing out. There will be integrated environments with graphical views of discovering, developing and executing processes, and round-tripping of real-time process data fed back into those views. The key enablers here are CHANGE and VISIBILITY. If you're hung up on BPEL, or any other technical thing, you're onto the wrong thing. BPM is about CHANGE, and it's about VISIBILITY.

• Change is the result of faster visibility, even more than faster technology. There's a big debate about BPEL and BPMN round-tripping. This will become irrelevant as BPEL becomes known for what it is, which is, at best, the SOA orchestration language. Nothing to do with BPM. The real interesting BPM-based round-tripping will be about round-tripping real-time process instance data into modeling simulation and optimization tools. That's interesting because it serves the business, not the technologists. It sheds light on the real purpose behind BPM... to change how we manage processes! This is where ROI will be defined, measured, and improved. The whole hubbub around process tools is ultimately a means to the end-game: the real TLA that's driving BPM is ROI, not SOA.

• Companies will incorporate technology much more heavily in the business, while also erecting more defined interfaces into the part of the business's technology that is complex. Think of the telephone network as an analogy. All the infrastructure will be in place and maintained by technologists, like today (the technology won't be like today's, but the management of it will). While at the same time, tools, like phones, will be given to the business to do with "as they please." That is, as the tool allows.

An Analogy Worthy of Tom Friedman
In this world, BPM is the phone, and SOA is the infrastructure. BPM must provide a highly agile "device mentality" upon which the "last mile" of enablement is given to the business. You might think this sounds trite, for example you have a simple device (say, an Outlook-based way to define a process flow)... and that's feeding your BPM-based process intelligence system. It's like a telephone that can easily be configured to take high res pictures or low res pictures. The telco doesn't care what you do with that phone, because the interfaces to the hard bits are defined and locked down.

But it can also get very complex there in the last mile. For example, Blackberry is a huge platform yet RIM has no access to telco infrastructure... it just uses standards-based pipes. BPM isn't a toy any more than the BlackBerry and its BlackBerry Enterprise Server is a "phone."

The point of this is simple... Business Process Management is the technology piece of a long-term shift in how businesses run themselves AND how they embed technology into themselves. SOA isn't "the answer" any more than one of today's pure-play BPM vendors is "the" answer. We are all pieces in a puzzle, and the puzzle's a long way from being finished. We're on a journey, but even at this early stage, it is clear that SOA and BPM have two very different goals: SOA is about the [re-]orientation of technology to reflect today's (and hopefully tomorrow's) consumption patterns. BPM is about defining that consumption. You can choose to do SOA, but if you choose not to do BPM, you'll not get that last mile.

People in the blogosphere are way too impacted by the raw data of some random Google statistic. But the world at large isn't. At Lombardi, we're seeing a healthy interest in learning about how technology can help with the change that's coming. Our customers don't really buy into a lot of the mumbo jumbo of "the market;" they're more interested in the real world, as it is. They ask: How do your tools help us deal with the changes we're faced with? How does this "new" model play out when tested against the immutable business principles demonstrated from Adam Smith to Peter Drucker, through Al Sloan and up to Welch? Where does today's BPM fit in that? And what does tomorrow's BPM - whatever it's called - look like?

It takes a long time to change the world. But it's a lot of fun. And it's pretty cool.

So wrap me, wrap me
In the shelter of your arms
I am ever your volunteer
I won't do you any harm
I will love you innumerably
You can count on my word
When times are mysterious
Serious numbers
Will always be heard

- Paul Simon, When Numbers Get Serious
(recorded at about 72 BPM) (oops, I just skewed another statistic, didn't I....)

Technorati Tags: 21st Century Process, BPEL, BPM, BPMN