Then, for the next 4 years I was deep into the core programming languages (C, C++, and Java when it started) while we were developing a platform for core applications & network monitoring & management, equivalent of an HPOV or IBM Tivoli. We were, that time (around 2003), talking about Autonomic computing and how virtualization (the word in those days!) would sometime be the norm. We were creating a product suite that was ambitious in the sense that the whole application management infrastructure would be self-healing and auto-scaling. Ambitious that time, because the underlying infrastructure was still just coming together. We did create the product and looking back, I can only appreciate that vision.

Autonomic Computing (courtesy IBM)

And then I had a long stint with BPM (which within me still continues to live as a thought process – from tools/products, to discipline of process management, to technological convergence (still in progress), to hard core practices on running BPM projects &  governance thereof). While BPM initiatives still continue to toy back & forth between “the fast, iterative , singles-and-doubles approach” and “ambitious, long-drawn, home-run attempts”, some aspects of BPM styled projects standout nevertheless. Here are some of the critical success factors:

• The decoupling of the technical infrastructure track and the process / application development
• Modeling driven, “visual” and configuration driven process development over shared-serviced-platform as against a vertically integrated application development project
• Ability for IT teams to stick to project governance and platform delivery and facilitating the business to focus on process management and governance.
• Strong support for the Enterprise architecture at strategy and governance level

I had earlier written about how BPM CoEs and various flavors are expected to provide the soft-support over the platform to deliver the BPM promises. BPM platforms, however, provide the ability to go back and forth between the technology driven implementation and the business driven projects. Too much control offered on underlying wiring, and you need seasoned practitioners.

On platforms front, there’s a key progress which is striking to the seeing eyes, but still not noticed widely. Most people understand the infrastructure story on Cloud computing. However, Platforms-as-a-Service (PaaS) is going to be a norm when businesses start exploiting the huge advantage that it offers – the ability to decouple the Platform Engineering, Platform Governance and Platform Implementation.

Applications PaaS (APaaS, as Gartner refers to it as A Step to ‘Killer App’) provides the visual and modeling driven capability for applications development. It is offered as a service, hence decouples the platform engineering from application development as a model. It is also, interestingly, a High-Productivity paradigm that enables a rapid and business oriented application development (as against High Control Paradigm of General Purpose PaaS that ties in app development rigidly to IT).

This is where I see all the dots connecting – Visual Basic or MS Access style of development, Cloud based Platforms-as-a-Service that is modeling driven and autonomic as a platform, Business Value driven BPM style projects that enable focus on Business Value.

So, looks like we have the technological ingredients for the “White collar developers” or “citizen developers” to develop the applications while core IT can focus on the delivery and governance over underlying platforms. While I still see that IT will, for some time to come, control the buying and maintenance of such platforms, the key to their success also lies in the understanding that they need to focus on the role of platform Engineering and Governance, and facilitate the business value driven applications development. Many forward thinking organizations already understand this difference and those are the ones that are (already or on the way to) reaping the benefits of such platforms.

IT can, driven by APaaS, become a Business Platform Provider and facilitate Business Value, and move beyond being Cost Center.

Process discovery: With Google’s powerful presence in the email & productivity space, combined with the strong tagging and pattern recognition technology, there’s finally a way to auto discover the spaghetti of processes. It uses the groups and aliases given to all the people and tracks down the frequently used labels and combines with who connected with whom most often, to come up with this. There’s also a way to search and filter the communications to trim off the garbage from this spaghetti.

Collaborative Modeling: Now, here’s a blessing. With a cool collaborative technology using the behind the scene syncing technology around Google docs, and a simple drag & drop and tagging interface, you have a collaborative process modeling environment. There’s obviously no match for “all-attend-in-person” process workshop, but there’s so much that happens after you’re out of that “workshop zone” that brings you back to the real world reality. And ability to remotely collaborate over process model is something that is indeed a blessing.

On the Cloud: Google is on the cloud, your process models will be on the cloud, your processes would execute from the cloud. Unless you have outsourced the process participants’ jobs too, people remain in-house with you.

BPM and ACM, meet each other: A process model designed and deployed through the modeler, process executes through emails, messaging, and the engine that keeps track of a “fixed” and “variable” parts of the process. You obviously cannot do it without detaching the models from the hard definition and single-model-across-instances approach. It works, here, similar to what happens to a Google Doc in a shared mode – while you’re viewing a doc on the cloud it remains the same copy for all. The moment you edit it and make it private for you, it creates a separate process instance so to say – in process world still visible for monitoring and process participation to others. What’s more, you can define which roles can “actually” edit and make the process better. While kicking off a new case/process, one can pick among their favorites. You can like and favorite the process designs you prefer for your group/instance! So, here’s to the process continuum that travels between structured and unstructured without having to pick a separate isolated tool set!

On Mobile: With the Android Apps and (I don’t still know how they did it being two completely disparate organizations even within google) by prebuilding an interface that every Android phone understands natively with Google App Engine, your processes can execute seamlessly from any handset that is powered by Android. It’s also beautiful to know that you can still keep the process going by a single click on the “go ahead” while filling out the detailed forms in parallel. The next participant gets a preview of the task up in their bin while they can wait for the previous form submission from previous participant. Cool!

Social, what social? When you do the collaborative modeling & execution and enable people to participate and subscribe in processes, and you have Android interfaces for capturing the relevant tags and kicking off the process instances, say in customer service; you’re already doing social, aren’t you! Then, you have cool stuff of liking, favoriting and sharing the process templates, Cool!

And there’s a bunch more in sneak-view with google’s marketplace and App Engine based approach that offers the potential to keep expanding the capability without having to fight around whether it is BPM or ACM or Social or mobile or even on cloud or not. Business happens!

I just came back from a good dinner at one of the local restaurants. Every time I visit this place, I always remember the bright smile and an ever-great greeting from this porter, always standing at their main gate, greeting every guest with a handsome salute and a contagious smile. Every time I visit this place, I just can’t help but wonder how he manages to keep doing the same thing, over and over again. And, this guy doesn’t get any tip for doing it, none whatsoever. Never. Zilch.

The answer is simple, he loves doing it. He loves meeting the eye of his visitors and greeting them. I just can’t find any other reason why he keeps doing it without any additional incentive for doing it better, for a paycheck as meager as one can imagine. And believe me, I think about it every time I visit this place. Such is the impact of this guy on me, I wish to tip him handsomely sometime, but you don’t tip people for just wishing you a great time, do you? It’s not in the books, not in the tuition, not in the etiquettes. He keeps doing it every time, still, though. (I just hope his employers have realized his importance yet, and got him a raise by now!)

And, this guy, the porter, is not alone. There are many employees (if you want to call them that) that love their job so much that they just don’t care what the incentive is. They just want to excel at what they do. They just love the work they do. And that’s the kind of employee one should ever want in their team for the right job. No incentive ever helps if the person you employed doesn’t love doing “what you expect them to do”.

You are much better off employing people that love what you wish they do. And no incentive is ever required. On the Corollary, no matter how much you incentivize people to do what you expect them to do, if you’ve got a frog to do an ant’s job, they would never excel in it, no matter how easy or straightforward it could be, and no matter what the incentive. No amount of incentive can ever make up for a bad job-resource fitment. They would only realize the existence of incentive at the end of the quarter, or at the end of the year and wondering – Incentive, what incentive? And What for? and you will be forever left wondering why people can’t fit into their jobs, and do what you expect them to do. Recipe for failure or success, you choose.

I wrote a post in May 2010 on Redux Online, amidst some debates around case management v/s process management. Yesterday, we had a question on EbizQ - Will case management soon take over BPM? I responded with reference to my Own post about the Case v/s process being a culture thing, and not to treat it like a technological debate. Sandy responded with a quick post that resonates with my thought process perfectly, that It’s Not About BPM vs. ACM, It’s About A Spectrum Of Process Functionality!

With the debates continuing, I thought I’d reproduce this post (and the picture) as another gentle reminder…

…

It’s becoming a routine for us to wake up and see new labels, new definitions, and increased decibel levels around certain areas in the industry.

Recently, we have had few on Case Management and unstructured processes. Those may have been triggered by an acquisition or two, or certain technological developments that made case management easier to achieve than earlier. But, it is not new and I have been looking for something to bring forth the point – Case Management flavor of process management has existed all along. Some may argue and say Case Management is indeed different from process management, but that’s not the point. The point is that there are different styles of processes, and the techniques to handle those will have to differ. And all will continue to exist.

And I stumbled across this picture that described the “styles” of processes in June 2005. I thought I’d share it and remind all of us that problem space has not changed by much!

And this picture does a good job of basic comparison across various flavors, and is still applicable.

So, one request, can we stick to the known principles and terms as much as possible, unless something drastically changes the problem spaces too (which possibly may be the case with social networking and cloud computing). That will help invest energies in the actual solutioning of the problems (and selling thereof, if you will) and not on explanation of terms and jargons.

I think we need to stop thinking “either…or” based partitioning and start thing “AND” based coexistence and synergy.

What’s the Core of BPM? This may sound like a rhetorical question, especially in this blog. But, seriously, what’s the definitive core of BPM right now? I’m not looking for the definition of BPM, as we have spent sufficient time debating it (as Gary brought to our notice again) and realizing there’s no one single (please all) approach to defining BPM. I just wanted to reflect upon it a little, without being suggestive of the answer one way or the other as I have often tried to do in the past. A prominent answer could help. May be any skepticism around BPM being a bubble could be then erased, apart from help from some other learning that Adam also hinted at from CRM example.

So, What lies at the definitive core of BPM?

Is it the workflow? There’s no doubt in my mind that the workflow (whether you define it systemically or as a concept) has been the core of BPM since its inception and has been. But, then, we had this intriguing debate on EBizQ on this!

Is it the Process mindset? Process mindset – Know the Objective, Define the process, model the process, execute the modeled process, monitor and optimize the process through execution; met huge debates through the last few months with the advent of Agile, Adaptive, Ad-hoc flavors of process management. While we could still debate that an agile or adaptive process mindset also requires respect for the “process” in the first place, what is at the core of this process mindset that BPM cannot do without? Is it Adherence to a defined process or visibility into the executing process or adaptively navigating through the process whichever way the gravity takes you?

Does the answer lie in “a Way of life”? Now, this is a philosophical refuge for most hard core BPM practitioners, including me, since it actually brings out some irrefutable arguments in favor of BPM as a Discipline. But, then the question arises as to what, “in that BPM way of life”, is at the core. What is it that BPM bring out that a traditional Six Sigma approach or even a functional domain such as CRM or SCM is not already practicing “in the sense of a way of life”. Which way of life does BPM dictate that nothing else can bring forward on its own? I have myself pointed out earlier that it’s the culture/mindset, and not which tools or technologies you use, at least between Case and Processes. But, what would be at the core of BPM vis-à-vis all these various ways of life?

Is it the Outcome-Orientation, as Outside-In or Adaptive approach or ACM suggest? I’m completely in line with the importance of the same, the fact remains that it is a very pragmatic approach to “practice that core thing that BPM is composed off”. It all starts from the ultimate need or want of the end customer, and finding out how a particular process or set of actions need to be orchestrated to achieve the same. I’m just trying to figure it out what that “core” is! What seem common among all approaches are People, Interactions, Outcome, and a combination of tools/technologies, but that would be true of any technology that has an interface for the humans. What differentiates BPM?

We have had many peripheral distractions along the way: Social BPM, BPM(S) in the cloud, and blurring with many other disciplines & technologies, but I guess we have had an opportunity to synergize all these and focus on what the BPM as a discipline had to offer. But, when it comes to the core, while I tried to capture in the picture, the multiplicity of these combinations on offer for those who look for a solution have the question staring in their face again. Do I label my initiative as BPM based on what the vendor or the solution provider calls it (Mike calls it the confusion due to the unnatural acts that hijacking of BPM by vendors causes)? Do we, then, elevate BPM to culture sensitive Business Architecture, where depending on how you bring it about (hint: discipline or way of life again) will determine whether we practiced BPM or not? But, then it goes back to where the core would lie again.

At this point of time, what would be the definitive core set which needs to exist in my initiative to call it a BPM, and without a vendor or a solution provider or an analyst requiring to label it as such, and exclusively so?

I would go ahead and say,… er… um… (almost tempted to blurt out something, but may be later). Whatever I say would meet with some debates anyway! (Hint: For my blurred PoV, look at my attempt from last year and update it a little for the last few months, but that is not an answer too as you can see in the picture as well!)

Over the last few years, I have been witness to many a decision that the CIOs & business apps owners take on putting their money.

We already know about the Capex (Capital Expenditure) v/s Opex (Operational Expenditure) from a financial management front.  Businesses have always been looking for ways to balance out their cash flows by assessing their Capex and Opex needs; by the time it comes down to IT, the Capex-Opex balance is also looked upon from a cost center perspective, making it even more difficult.

However, it also involves the balancing acts between two key aspects of apps management around business need. Various organizations would have different choice of words to describe them –

• Grow the Business (GTB) / Strategic Applications / Innovation oriented IT investments etc. – which has to do with focusing on new lines of businesses, disruptive additions to the functional aspects of these apps, typically boils down to looking beyond the horizon of immediate needs of current business.

• Run The Business (RTB) / Tactical or Operational Applications Maintenance / Keep the Lights On (KTLO) / Business as Usual (BAU) etc. – which has to do with ensuring that the routine business operations are not disrupted, applications continue to be available and performing, the status quo doesn’t change by much from an IT and business routine standpoint.

What’s noticeable is the amount of money and effort that goes into the RTB or KTLO side of Application Management. Recession and hardships in business typically moves the focus to these. This is where all those legacy, technologically outdated applications continue to thrive. No one wants to touch them. And the reasoning goes beyond just disruptive nature of the initiatives that attempt to attack them.

The main problem is that if they are not at the core of the IT operations focus, IT doesn’t seem to have the energy and leeway to care about them, beyond keeping them up, available and running. Sometimes, when the underlying technology is big enough, and gets outdated and has a wide base, there are forced into initiatives to migrate them but that ends up becoming a long hard journey, typically led by the middleware and application development platforms – again translating into high capex.

Among those applications, there’s a breed of applications that can be best described as Long tail Apps. (Chris Anderson famously invented the term Long tail in the context of the new business models around “more of less” as against “less of more” few years back. Read about it here if you want. But, I’d advise not going there since that context can potentially move you away from what I’m driving at.)

I’ve embedded here the slides that I uploaded yesterday on the Long tail Apps – should take five mins, this one I urge you to have a look!

The story is simple yet a little not-so-straightforward –

Platform as a Service (can also read underlying Cloud) enables the application management of all those Long tail Applications that have until now remained a painful ghost set for all practical purposes. And if you notice the visual, business domain focused, rapid development characteristics of the underlying technologies of these Long tail Apps, there’s no doubt that new age PaaS technologies are a boon.

Long Tail of Apps will finally wag, PaaS will enable it, and power it!

My first brush with 3GL and 4GL was way back in the 90’s. It looked like, that time, a panacea to all our programming headaches. Time passed, and here we are, the headaches of programming have increased multi-fold. It’s not only about the empty catch blocks, swallowed errors, misplaced warnings, and leaks of memory – but while those problems continue to remain – the trouble domain has become much more and includes wrong pieces in the stack, overlapping functionality, solutions not working with each other and so on. You will know actually what I’m talking about if you are an IT Manager or a Solution Architect, or did I touch you where it hurts! So much for the (3+)GL dream…!

While IT continued to flourish and expand, the core technical strengths still ruled in technology world. The dream of business-value-driven-development continued to remain distant – more of touch-and-go if you will. It kept rising above water in form of reusable components, off-the-shelf functional modules/products, only to take you along and go under-water again…

Having said that, there are areas that have been less of technical plumbing and more of configuration-driven, for instance, in BI and business rules world. Still, a developer always wants to get the hands dirty and play around with the flesh and wiring. And more importantly, they cannot deliver an end-to-end functional run-time application on their own. Enterprise Apps had a huge chance with their position in dictating the terms, but on the ground there was much more custom-code, hooks, plungers and a whole lot of money to be made through “implementation services”.

But, there are at least two real trends – here and now – that change all that. One is BPM and the other is Cloud Computing (PaaS & SaaS).

And two key reasons they live up to the promise are “Abstraction” and “Modeling-driven-development”.

A BPM environment comes with the expectation (not just promise) that the implementation will be modeling driven, and the platform would have handled the technical nitty-gritty and kept them abstracted out for modelers and developers. While BPM doesn’t always lead to Zero-code development practices due to the nature of integration and the way many an implementation is driven today (IT driven), it is possible to deliver processes modeled and executed in an abstracted-out manner. That is, if you have the right intent, and you follow some of the basics. (Elise Olding from Gartner asked this question few months back on Linked In, some of the answers are revealing enough in this direction – Has BPM evolved into just tweaking and incremental improvement? …How do re-introduce innovation in process design?)

The other trend, Cloud Computing, especially SaaS & PaaS definitely change the equation in favor of business-value-driven abstraction. You see that happening in multiple ways and at multiple levels. There are products in the market that actually can deliver solutions of a larger scale through largely modeling and abstraction. The beauty of such products is that they come pre-integrated with the layers required for the application to work, are abstracted out at the functional level, and the onus of managing the platform lies with the platform provider.

Finally, “White collar Developer”, you can smile. Will you?

PS: If you have read my blog in past, you know that I don’t mix my employment interests here. However, I will also always tell you something that I come to know. And from the point of view of emphasizing how it is being done, all I can say for now is that OrangeScape PaaS platform has been able to do an end-to-end ERP implementation for Government with an abstracted-out and modeling driven approach, without coding. White Collar Development fits there so well, it would be only appropriate to call it out!

Vendor Lock-in. Proprietary Technology. Switching Costs. I feel these phrases are thrown out there much too often, more often than they need to be, without giving much of a thought to what the “real” concerns could be.

It is indeed important to be cautious when one’s building systems that would actually run your business. You don’t want someone else to be in a position to just pull the plug from outside. But, how cautious one needs to be and should we be asking that question every time a good option pops up? And more importantly, is the so-called vendor lock-in or proprietary software really that bad?

Consider Microsoft. We have lived through decade of whining around (so-called) proprietary software that Microsoft built. And it has not only lived through it, but Enterprises and individual users alike have made it one of the strongest brands for the last two decades. The reason: “users” of these products didn’t need to get to the APIs, and to worry about the openness of their system. They needed their work done, and it did decently well on functionality (not fantastically but well enough in absence of strong competition). A good question would be on backward compatibility and support, which actually needs to be asked though.

Consider SAP or IBM. They, and some other Enterprise App vendors, built the spines of core enterprise solutions for decades. They have been successful. Reasons: One, enterprises were not savvy enough on technology and they often looked at technology as a sourced-in component of the business. And Two, it did make the “business” run better than otherwise. Three, these worked as self-encapsulated systems that did most of what was required. Integration options opened up when they were needed.

Consider Sony and Bose. Sony uses the vendor lock-in strategy for the peripherals and additional components, ex. Memory card for cameras. In TV and sound systems, they have equivalent examples. Bose uses patented technology, and often terrific, to deliver the quality of sound that people are “ready” to pay premium for. No one’s complaining among consumers. People who complain are the techies in media that want to rip the components apart, do some other stuff with it too.

I think that for a COTS product or platform to “really” provide the value for customers’ money, it needs to have the internal technological strength and some unique ways to address customer problems. And, that shouldn’t be looked upon as proprietary, just because how it actually works is not completely transparent. One needs to differentiate between a closed system and a proprietary technology.

So, here are the questions one needs to actually be asking, and not just throw the vendor lock-in and proprietary software question out there –

• What functionality am I expecting the product to provide? Does it solve it for my needs for say, next 3-5 years?

• Is the technological and functional roadmap of the product clear enough? [Are they going to still have the critical functional and technical capability you’re buying them for]

• Do I anticipate the product or platform to integrate with other systems? What kind of integration capabilities am I expecting? And at what all layers or components, in the order of priority? Are “those” plug points open and accessible enough?

• Is the (business) data produced by the product accessible? Through APIs, through database access, or through extraction? [For DR, Biz continuity, Reporting, Analytics, Security]

• To what extent do I need the metadata access? Is it really important for me to have the access the metadata? For what purpose? [mostly this is just a hunch and there may not be a use case]

• What’s the key technological strength of the product that I’m paying for? Will exposing the underlying technological complexity of the product be counter-productive and counter-functional for the vendor and for me?

• What’s the upgrade policy of the vendor? Is the contract going to cover the support for existing installations for previous versions? How far back are they ready to go for support? [This is one of the strong reasons for the cloud approach to take off, as the upgrades are transparent to the customers]

• What are the Exit options, if at all an acquisition or financial risk comes into picture, for the vendor to support the existing installations? How sound is the company background and strategy? [Validating and relying on this, for all we know, could still be futile exercise. We have seen companies like BEA, Compaq and EDS taken over]

• And this may be happening as well. Are you too scared of making a decision now? What can actually go wrong once you buy the product? Are there ways to address those differently than cutting through the skin?

If you want some real functionality and technological strength for a price, prioritize that and do not confuse a proprietary & strong enclosed technology with a closed & rigid architecture. Asking the right questions is very important. Everything, that is standard today, was once proprietary in our minds until it eventually became common, universal or functionally indispensable.

And also think about the vendor lock-ins that you have for the last 10 or more years because you actually loved them. Or think of your car(s)!

I’m sure all have been witness to broken processes, sometimes as victims of those.

For instance, it’s not uncommon for customers requiring to call up and follow-up on a pending service request. It’s also not uncommon for organizations failing to make payments just until the point it starts hurting them in the form of penalty, if any. What is pretty uncommon though is for an insurance company making every attempt to close a claim in the fastest possible manner, the same organization that would want to close the sale in minutes if they had their way.

You probably may know by now what I’m getting at. This is one of those process management rants, but let me boil it a little bit…

Business Processes are a sequence or set of activities. They are also typically a bunch of transactions. Transactions are give-and-take, with one party as beneficiary of something – a service, payment, delivery or such. And organization will have business processes of all kinds, with transactions in every process area. In some of them they act as beneficiary, in some they don’t – directly or indirectly.

When a business process culminates in a transaction that has the organization as the beneficiary, they will find a way or the other to keep track of it, and keep making progress. In other words, not let the ball drop. They will have the notifications, escalations, and metrics set up so as to not let the process break. And that is regardless of whether they have automated their process execution through a BPMS.

On the other hand, it’s surprisingly common for the same organization, and same management, and same departments to turn their backs to the processes that may not be directly associated to an output that adds to their measured performance or coffers. And despite the fact that they have automated the process execution, the process may end up as broken. Priorities are not just set up to get those tasks float to attention.

It’s a matter of priorities and not presence of technology. Technology can add value where organization is focused. You can teach and preach Process Management, but you cannot force customer orientation. It’s another matter that organizations continue to harp on customer orientation “as means to” achieve market leadership, but you see that’s the point – as means, not an end. When you see a broken process, problem lies mostly with focus and priorities; not with their ability (technological or managerial) to manage processes.

In the last couple of years, through the recession, we have seen most organizations adapt to the changing ground reality. These quick changes have been targeted toward operational efficiency and cost-cutting.  Some of these are one-time decisions that are quickly rolled back as soon as the business bounces back.

Many decisions, though, are actioned through changes in systems and processes. And such changes – and effects thereof – are often longer-lasting and go much beyond the recessionary cycle. I wonder if all organizations actually realize that some of these non-reversible changes actually end up as the key determinant of the longer term direction that “organizational culture” takes. If these decisions are not intended that way, organization suffers in the longer run and it becomes almost impossible to rectify those, and many times even to diagnose.

I had earlier written about how organizational silos come into being and how incentive alignment could help organizations make people work together rather than in silos. I have a similar take on how systems need to actually be designed in order to drive the culture that organization really wants to pursue. And these should not get permanently dented by the recessionary cycles or any other immediate business pressures if organization is really looking at decades of existence.

Most organizational decisions affect people because they work in the system day in and day out, and when taken with cost cutting in mind there are some decisions that affect them negatively and directly. Not only in terms of the loss of jobs but more so in terms of impending compensation structure, performance management systems and career progression related policies and systems. And there’s no doubt that the organizational culture is primarily driven by how systems and policies drive people.

When tweaking systems and policies for shorter term goals, do not lose sight of the longer term effects on culture and mindset of people working in the organization. Systems and Policies of today are the organizational culture of tomorrow!