How far the future? The Road Ahead.

Futurists look to the horizons of time to predict and prognosticate about the conditions that will prevail for the next generation. These predictions are certainly of interest, but useful? When Futurists inspire businesses to look forward--to take interest in things beyond today's bottom-line--these pictures of the future are useful; but no further. Our clients make money not by looking to the horizon, but by keeping their eyes on the road just ahead.

How far ahead? In our business, advising and executing on business enablement through technology, we focus on a time just at the edge of a potential project's implementation span: between 3 months to 3 years ahead. This time-scale may not seem like the stuff of Nostradamus, but this scale defines the zone where businesses may capture the greatest total value by taking the least risk (see NPV). Looking to this time-scale allows us to launch initiatives today that are appropriate for tomorrow--appropriate meaning that the technologies involved are ripe and that the business environment is staged for competitive advantage. In our unique position at KR, we travel both of these roads, who better to accurately predict their intersection?

The Democratization of IT

On inauguration day here in the US, it seems apropos to publish on the topic of democracy, at least from my point of view. In our industry, I am seeing the emergence of a profound macro-trend--the convergence of smaller distinct trends that compliment each other to create new, far-reaching implications--that I call the democratization of IT. Let me explain.

In the 80's when Pegasystems was born, the term 5th Generation Language was conceived to tag methods of programming computers to solve problems by providing a set of constraints that would applied flexibly to a wide range of data inputs without predefinition of all possible outcomes (see AI). Now, however, it is coming clear that the 4 Generation Languages (Java, C#, etc.) are not being supplanted by AI concepts, as was once imagined, but by graphically-oriented tools that allow less sophisticated users to instruct machines in data processing tasks. Indeed, it is clear that Alan Trefler's vision for PRPC is to make the tool so natural for business people to use that programming--as we know it--will simply be irrelevant. I think he has a long way to travel before the vision is realized, but the pace of change is accelerating. It is also clear to me that Alan is not alone in pursuing this vision. Indeed, many BPM tools intend to do away with the priestly-caste of programmers who have classically interceded between the end-users and the end-processors. The world of application development is accelerating toward that common goal.

Simultaneously, the other bastion of technical obscurity, the server room, is also being rethought with simplicity, scale, and flexibility in mind. The evolution of utility computing--loosely defined as:

"the packaging of computing resources, such as computation and storage, as a metered service similar to a traditional public utility"

is making it possible for the provision of computational resources to end-users over the Internet with the specific details of those resources obscured and divorced from their end-uses. Consider it the extension of your current browsing experience to the enterprise software domain: do you have any idea where the web server providing access to this posting resides or what brand of hardware or software is being accessed? Why should I care? I don't. Similarly, why should an end-user in the back-office at Citibank care whether the contract they need to review was requested through IBM's OnDemand running on a IBM P-Series machine using AIX as an operating system and an array of RAID-controlled magnetic disks made by EMC? Snore. Snooze. Why should they care? They don't.

Now witness the convergence of these trends. I have 'dial-tone reliable' access to enterprise-class, computing resources pumped into my life through a fibre-optic cable and a programming paradigm that leverages my business savvy more than my geek-fu. Things are getting interesting.

So, how do we play? In the short-term neither the application development nor the cloud computing infrastructure is living-up to the promise yet. The gap must be filled by people willing and capable (read: Knowledge Warriors) of navigating both the business and technical waters. In the short-term, packaged service offerings and value-added configuration tools will make the convergence more accessible. In the long-term, the world will need better process consultants NOT better technology consultants...with one notable exception: security technology. With armies of bitter programmers displaced by these new technologies, you know damn well that someone will try hacking your Process-on-Cloud solution. So, this year, we will begin taking conscious steps and preparing ourselves and our business to be front-row for the democratization of technology.

Two key cross-training initiatives:

1. 
   
   Design for Six Sigma - structured methodology for identifying, implementing, and improving key business processes to drive quality improvement.
   
   


2. 
   
   Info-Sec - tools and techniques that hackers use to extract information from systems and the weapons to fight them.
   
   

Rapid deployment of simple processes

R.D.O.S.P. isn't a very compelling acronym. It is a compelling concept. 40% of job activities are ad-hoc in nature according to a 2004 report published by McKinsey (the report refers to these as tacit tasks). 40% of processes are currently unaddressed/underaddressed by "Big BPM" software players like Pega. Organizations are 'making due' with band-aid applications: the competition in this space is email and Excel. What leaves these 40% unaddressed by more rigorous solutions is that their impermanence makes them hard to target:

• Following a traditional project lifecycle, by the time the requirements are understood, the need may have passed or the focus radically shifted.


• The short duration of an ad-hoc process's lifecycle also makes an ROI-based, project justification difficult--for a 2-week long process, payback can't be justified over 2-years.

These problems can be addressed. There is a single barrier to overcome: deployment time. To address this untapped, we need the Domino's Pizza Guarantee--forget 30 day implementations, we need 30-minute implementations--or your process is free.

[ < time < money < risk ]

Now, back to the R.D.O.S.P. (Rapid Deployment of Simple Processes) concept. How would we achieve the rapidity and simplicity required to address the ad-hoc processes that make-up a substantial portion of the world's work in a cost-effective and profitable way?

Rapidity requires two key ingredients:

1) friction-less instantiation of an development/processing environment and

2) digestion and implementation of process details inside of a New York minute.

Frictionless instantiation is becoming more feasible with advent of Cloud Computing and Platform as a Service (PaaS) movements [Pega is introducing it's own answer to PaaS into PRPCs next release].

Simplicy requires two additional key ingredients:

1) a scaled-down definition of what constitutes an 'adequate' solution and

2) the unearthing of workable assumptions and the prebuilding widgets to allow processes to be 'mashed-up'.

Naturally, we would find applications for an RDOSP capabilities in traditional 'transactional' process fullfillment as well. Consider that an organization might start the journey toward automation by first taking a single, simple step. A multi-generational approach is certainly more palitable to certain organizations because it allows for ongoing organizational learning and a faster path to short-term value. Look for more on these ideas in months to come. As always, I am interested in hearing your impressions. Happy New Year.