You gotta eat, man.

January 8, 2007 – 11:26 am
By Mikael Bergkvist | Posted in Business Automation, WebOS | Comments (1)

I was invited as a guest blogger by Vish Desai who runs this show, which is a very nice and smart guy, and it’s an honor for me that he thinks I might have something sensible to say ;-) .

I’m hoping I’m not going to let him down, but I got a some opinions that I’ve been promoting for a while, and I’m going to go through them all in a single post.

Here goes..

Enough of this debate whether a webos is ‘true os’ or not! The webtop is not meant to fill the same need as a desktop on the pc. The similarities in appearance are deceiving, so it’s partly our own fault, but there should be an element of common sense coming into play at some point.

Xindesk, the webos for which I’m the lead developer, and which is the 9th webos to be featured on this list - http://franticindustries.com/blog/2006/12/21/big-webos-roundup-10-online-operating-systems-reviewed/ - is NOT meant to be the equivalence of a pc/desktop or remote desktop, it’s supposed to resolve a web application development issue.

Get that?

I’m not stupid enough to confuse a ‘real’ OS with that we are trying to do.

When you develop an application, such as an email application for the web, you will hit a certain point when it’s more logical to spawn a completely new app, rather than further litter the interface with more functions that stray more and more away from the core functionality. Like a calendar or whatever.

It would be nice for me as a developer, if I could open this new app from the said email app, since it’s spawned from it, and if these two apps could interact seamlessly with each other, exchanging their data back and forth, without much of an effort from me as a developer.

- The reason for this desire is simple!

The user might want to toggle the two apps, going back and forth between them.

That’s how the brain is wired, it’s not linear like a computer, instead it’s somewhat chaotic, but it gets stuff done nevertheless.

So the user want to be free to customize their workflow. That’s the original appeal of windows, the reason they came to be, and in fact also why the clipboard exists.

How often don’t we cut and paste text from one app to another, like from word to outlook express?

And regarding what I mean with “workflow” - how many of you out there, reading this now, have several apps open right now?
I guess almost all of you.

Some apps are minimized until later, and you decide when and if you attend any given one of these apps, and that’s a “workflow”.

You decide.

On the web today, you need to leave one site, go to another site, then leave that site and go back to the first site, and it’s just a horrible mess.

Windows, or something else creating a free workflow, is a feature that’s almost required if you are truly serious about working online, using the web as a platform, and actually get something done!

And because the webos has made a comeback, virtually back from the dead, this is now possible, because it’s exactly such a mechanism.

And that’s also why window systems relying on iframes totally blows, and to be honest, most so called ‘webos’ apps out there are nothing but window managers relying exclusively on iframes to get the job done.

That’s not good enough.

These apps are not aligned, and you cant cut and paste data between them, and that kinda sucks the wind out of the whole idea.

In a truly shared environment, I can create a unified experience which is completely webcentric, focusing on tasks not related to what one would associate with a local pc, and the funny part is that the user might not immediately benefit from this, or recognize that he/she is benefiting from this, they will just get this cool but partly pointless desktop from their point of view.

No, it’s the development behind that actually benefits, and that will pay of for the user getting better apps for a cheaper price. This is an evolution responding not so much to the users needs, but to what the guys behind the scenes need to respond to the users needs.

You may compare this to Microsoft’s office suite.

In a sense, it’s a single app too, broken up in smaller units which all share quite a bit of code in between themselves, and they shuffle data back and forth in between themselves without a hitch, because they are designed as a whole, not as a set of independent apps.

(Yes they are, the office suit was in fact planned this way from the get-go.)

It’s very smart, because all the apps feed all the other apps with features that becomes very hard to compete with, if all you got is a single app and try to keep up.

That’s why Microsoft still holds the users by their throats, despite better open source apps coming into existence, because they dont fit the bigger picture.

The dont have this advantage of having the ‘family’ behind them, so to speak.

(Yeah, there are some worthy challengers, like the openoffice.org, but you know what? - They are designed in the same fashion.)

The so called “webos” is a similar type of beast, for a more ‘agnostic’ purpose, sure, but in a sense, it’s the exact same thing for all of the apps running on it!

So there are benefits for the developer of services, that cannot be easily ignored, and that’s partly why there are so many of them popping up all over the place.

But there are other aspects too, that tie directly into the business side of things.

The business part of a webos such as those reviewed on the above list is that it’s going to use the free users as ‘testers’ for the professional intranet version, like youos is already doing now.

To have a framework that allows multiple apps to collaborate and share data and files, is a huge advantage for any company, but it’s time consuming and expensive to develop, and a webos is a really convenient way to develop, deploy and test such a structure in ‘real life’ with a lot of users.

And it’s an attractive thing to sign up for it seems.

We already have over 5700 signups for xindesk, and we havent even launched anything yet.

EyeOS ( http://www.eyeos.org ) has some 55000 users, and that’s not too shabby, and an interesting test of the system having it handle this many users.

Most of these have no obvious source of income, unless you remember the intranet aspect of this, and the related problems these webos need to solve in order to manage this amount of people with these kinds of services.

The benefit for users of xindesk for example, will be lots of apps, personalisation, an online filesystem/explorer, messages and email, sharing/collaboration benefits, an obscene amount of free space and the ability to write and install their own apps.

The benefit for us is the flexibility of the framework being tested, which in turn forms the backbone for other business, which we will charge actual money for. But the features added to the free version will come both from the business world and from the ‘ordinary’ users, and thus helping us to avoid “inbreeding” - giving us a fresh point of view - and both of these groups will benefit from this in the sense that they will get more than otherwise would have been possible.

This is partly - I assume - why open source has become such a big success, because it’s surviving and evolving in the wild, where the actual needs are addressed and not just what some overpaid suit suggested should be included.

It’s evolution, baby, and it kicks ass!

But business has a tendency to prevail in the end, because that’s a part of life too.

You gotta eat, man.

Random thoughts on WebOS…

December 27, 2006 – 5:09 pm
By Vish Desai | Posted in Business Automation, WebOS | Comments (4)

I came across a review of the best WebOS products out there on the FranticIndustries blog. I’ve been hearing the rumours about the “GoogleOS” along with the rest of the world, but they’ve been lurking only in the backgrounds of my mind… this post brought them into focus, and I spent quite a bit of time yesterday thinking about the implications of a WebOS really taking off… For good or for bad, here is the distillation [I was sober!!] of my ruminations…

First off, what is a WebOS?
Well, it is NOT an “operating system” at all, at least not in the traditional meaning of that term. It is, rather, a web-based application that simply mimics the features we’ve come to expect from a “Desktop OS” like Windows or OS X or Linux - though it does everything inside a browser.

What do I mean by that? Well, a mature WebOS will provide the common features that we expect from an operating system inside the browser window - networking, a windowing framework, the ability to authenticate users, etc., etc… A mature WebOS will, also, allow users to install their software applications and it will run them - the difference being that the applications will all be web-based, with nothing [or almost nothing] installed on the user’s machines.

All right, I know that a pretty broad [vague?] definition of a WebOS, but it will do for the purposes of this post. For a better definition, read this article on Wikipedia and follow the links.

Why would someone want to switch to a WebOS?
The first thing that will come to anyone’s mind is that people can save their work on the internet and access it from anywhere. This, supposedly, increases productivity in exactly the same way that the Blackberry re-defined email access.

Really? I have a “Desktop OS” right now [Windows XP], and a VPN connection into my office. So, in reality, I can already access my work [in fact, the entire HDD on my office computer] from anywhere in the world. True, lack of network connectivity on either end [mine, or my office’s] can disrupt this access - but then, the same caveats hold true for a WebOS too.

I am not sure that the WebOS will be such a boon even for people who work from home and don’t have an office as such… I mean, if you are serious about being able to access your work from anywhere in the world, get yourself a laptop, right? At today’s prices, thats not too tough, is it?

People who want to login and work from home after 10:00 PM [ugh! what a thought!!] can do so right now. People who don’t want to, won’t - WebOS or otherwise.

So why would anyone shift to a WebOS? For people who HAVE to access their work from multiple locations, and cannot do it on a laptop for whatever reason…

One reason is, of course, security - not everyone can harden their computers enough to prevent them from getting hacked. A WebOS provider can, and will, do that by default - so anything stored on the server can be assumed safe [SSL or something else, I suppose, will prevent thievery on the wire].

The second, and a LOT more important [to me, anyway], reason is the cost reduction - SAAS will drive down the costs of software like MS-Office, etc. to a point where an individual does not have to pay significant sums of money to create a simple document or a spreadsheet.

Who will NOT be the “early adopters” of a WebOS?
Most WebOS products on the market right now are giving it away for free - anyone can register themselves and use it. The one WebOS that is already charging money, Glide, is concentrating on the “family”, i.e., the retail sector, which indicates that WebOS providers think that the market is going to be driven by end users, will start small, and then [maybe] move into the data center.

I think this is the wrong idea! I had a tough time explaining to my non-IT friend how to access hotmail - and now that she is comfortable with it, she refuses to move to any other online email provider.

Assuming that 90% of the people using a home computer are somewhere in that state of mind [not computer-savvy], selling the concept of a WebOS to them will be an uphill task. Plus, why would they ever require to access spreadsheets from a friends’ place, or while vacationing?

There are, of course, people who do the SOHO thing. But again, would they ever want to access their personal spreadsheets on the move? I think not! If they ever do use “mobile access”, it is because they need to show off their SOHO-manufactured presentations at a customer site…

“I am comfortable with USB sticks, thank you! And why gamble that the customer is going to give me internet access in his premises?”

So who WILL be the “early adopters” of a WebOS?
OR
The repercussions of my “foot in the mouth” disease - Part I
I am betting that the early adopters of WebOS products will be tech-savvy SMEs - boutique IT shops, technology product startups, etc.

Here is how they will go about it:
1. Spend US$5,000 and buy a server-box.
2. Install Linux, JBoss, MySQL, etc. on it.
3. Dump a WebOS product on top of that configuration
4. Buy the users [sales, marketing, operations, etc.] low-powered laptops with Linux.
5. Teach them how to login into the WebOS and use the pre-installed applications.

Why not? Saves the cost of buying Windows / Office / MSDN licenses for everybody!

Plus, every single document / spreadsheet / email / presentation / etc. / etc. is stored on that server - what a great way to reduce confusion [”who said what, and when?” & “are you sure?”]…

The repercussions of my “foot in the mouth” disease - Part II
OR
What after that?
I am going to stick my neck out and make 2 predictions… One, the second wave of adopters for the WebOS may well be corporates, but in the developing countries. Two, the longer term success / failure of the WebOS will be driven by the end users in Asia & Africa.

My basis for both the predictions is the same - lower cost.

A lot of enterprises in Asia [& probably Africa too, I assume] still work on normal [not networked] PCs, and are yet to taste the benefits of DMS / CMS, etc. I know, from personal experience, that large companies in India still rely of sharing file folders on individual people’s machines to keep track of information in documents.

At some time in the near future [i.e., 3 - 5 years], the IT “revolution” is going to hit these companies - if, by then, the WebOS is a mature concept, they will bypass today’s J2EE / SOA / .NET / Desktop deployments and go straight to a WebOS to avoid paying per-user licenses for office software.

The low rate of computer penetration in a lot of Asian and African countries stems for the high cost of the PC + bundled software [high in terms of local average income, of course]. Right now, everyone relies on pirated copies of Windows + Office to keep themselves running - but with better licensing mechanisms, it will no longer be feasible to do that. The forced shift towards legal software will force people to look for cheap alternatives…

There are already a lot of initiatives in place to produce a low-cost PC… here are the Google search results for +India +low cost +PC. A low-cost PC with free Linux pre-installed is about the best client platform for a full-featured WebOS to take advantage of…

The repercussions of my “foot in the mouth” disease - Part III
OR
What does a WebOS mean for software product companies?
The next 2 points are no-brainers:

Vendors of desktop-based products will, obviously, need to migrate their code-base to a WebOS - possibly, multiple WebOS products till the market shakes out and the usual 2 - 3 leaders emerge.

Vendors of applications servers, databases, WebOS vendors themselves will, obviously, have a party.

Then, it gets interesting… what happens to vendors of “infrastructure software” - ESB, BPM, BRE / BRMS, BI, DMS / CMS, SOA et al?

Assuming that the WebOS is developed with clustering / load-balancing capabilities built-in [an obvious assumption, but still…], the entire enterprise or user community will be working on a single virtual server! As a result:

1. Every document / spreadsheet / email / presentation / chat session that is created / modified / deleted will be immediately visible to every authorized user by default. As a result, the task of a CMS / DMS becomes simpler…

2. The same reasons will simplify the task of a BPM, BRE / BRMS, and BI too. The lesser the requirement for stitching together multiple repositories / systems, the easier it becomes to design / enforce process, policies, and reports…

3. Social networking becomes that much cooler… think about it!

In conclusion…
Having stuck my foot very firmly in my mouth with predictions, I simply want to round off with a few more random thoughts….

WebOS products will NOT evolve the way desktop OS-es evolved. In fact, I am pretty sure that the evolution will be top-down rather than bottom-up.

What do I mean by that? Simply put, the WebOS will not be a “simple” web-based application that will offer more and more applications as the years go by. Rather, web-based business applications will converge into a single platform, and give birth to a WebOS in the future.

Microsoft with its OfficeLive initiative, and Google with its suite of online products will be the progenitors of the WebOS.

Others will play catch-up.

It is not unlikely that a wave of mergers and acquisitions among e-whatever SAAS providers will generate a series of WebOS products.

The day of “one-size-fits-all” Operating Systems is almost over, and so is the notion of just 6 different OS flavors (home, professional, server, advanced server, data center server, etc.).

WebOS will be customer segment oriented. So, the same players will offer a VERY wide variety of “flavors” of the same platform to match the requirements of different customer segments.

We will ALL use some form of a WebOS by the end of 2007 - even if our Desktop OS is still Windows / OS X. Our dependence on WebOS will only increase from then on, and our dependence on the Desktop OS will decrease.

With that, I’ll sign off… Please feel free to give me your feedback, either via email or comments.

Client-side business rules: RFID, Warehouses, Networks, Manufacturing plants, and other things…

December 19, 2006 – 6:13 pm
By Vish Desai | Posted in BRMS, BRE, Business Rules, Business Rules Engines, Business Rules Management Systems, Business Automation, Agility, Manufacturing, RFID, Network, Event Correlation, Client side business rules | Comments (3)

One of my previous posts, “Why are Business Rules Management Systems considered ONLY server-side, and not client-side, technology?” got a response with an interesting use-case for business rules technology from Charles Young.

That comment got me to investigate and see if the QuickRules BRMS [from YASU Technologies] has been deployed and used in similar situations. I actually found two similar use-cases for the product, so I though I’ll post them here.

Case #1: Warehouse security and business rules technology

Suppose you have a warehouse. You are, obviously, concerned about the security of the goods stored in the premises. What are the obvious options?

Video cameras with security personnel continuously monitoring the feeds is, of course, the standard option. However, the high costs associated with this option [cost of the cameras, security personnel, TV monitors, etc., etc.] are a disadvantage, and companies are switching to cheaper alternatives.

In recent years [since 2001, i.e.], RFID technology has made tremendous inroads into this space, and is considered the technology of the future in warehouse security. What does RFID technology do? Well, imagine that every good coming into the warehouse is tagged with a RFID chip [usually a passive one]. In the simplest case, a single RFID monitor placed in the warehouse tracks the exact location of the good, and alerts the security personnel if the good starts moving. The security personnel take the appropriate action whenever the alert is registered - cancel the alert if the movement is authorized, or prevent pilferage in the other case.

However, things start getting complicated when there are multiple RFID monitors placed in the same warehouse, and multiple goods are moving around at the same time. For example, the security monitors start showing something like this:

Monitor #1: Good #1 moving towards Gate #4
Monitor #2: Good #2 moving towards Gate #1
Monitor #2: Good #6 moving towards Gate #1
Monitor #1: Good #3 moving towards Gate #4
Monitor #3: Good #3 moving towards Gate #4
Monitor #1: Good #2 moving towards Gate #1
Monitor #1: Good #6 moving towards Gate #1
Monitor #4: Good #3 moving towards Gate #4
Monitor #6: Good #3 moving towards Gate #4
Monitor #4: Good #2 moving towards Gate #1
Monitor #4: Good #1 moving towards Gate #4
Monitor #2: Good #1 moving towards Gate #4
Monitor #4: Good #6 moving towards Gate #1
Monitor #5: Good #3 moving towards Gate #4
Monitor #5: Good #1 moving towards Gate #4
Monitor #6: Good #1 moving towards Gate #4
Monitor #3: Good #1 moving towards Gate #4
Monitor #3: Good #6 moving towards Gate #1
Monitor #2: Good #3 moving towards Gate #4
Monitor #3: Good #2 moving towards Gate #1
Monitor #5: Good #2 moving towards Gate #1
Monitor #6: Good #2 moving towards Gate #1
Monitor #5: Good #6 moving towards Gate #1
Monitor #6: Good #6 moving towards Gate #1

Essentially, the more the numbers of RFID detectors, and the greater the number of simultaneous movements, the harder it becomes for the security personnel to keep track of what is happening.

Also, all that you’ve done so far is to replace video cameras with RFID monitors. The cost of the security personnel remains pretty much the same, and there is the added cost of attaching a RFID tag to each good. In fact, you’ve made the job of the security personnel tougher - they now have to read the alert instead of just watching the video monitor screens. Using a software to filter the events by RFID monitor is, of course, useless… since all [or at least a lot of] RFID monitors will track all the moving goods.

So what is the solution? The low-hanging fruit is: filter the RFID events, allowing people to see how the good is moving - regardless of which monitor is actually providing the alerts. This, of course, is pretty simple to do - the resulting security log will look as follows:

Monitor #1: Good #1 moving towards Gate #4
Monitor #4: Good #1 moving towards Gate #4
Monitor #2: Good #1 moving towards Gate #4
Monitor #5: Good #1 moving towards Gate #4
Monitor #6: Good #1 moving towards Gate #4
Monitor #3: Good #1 moving towards Gate #4
Monitor #2: Good #2 moving towards Gate #1
Monitor #1: Good #2 moving towards Gate #1
Monitor #4: Good #2 moving towards Gate #1
Monitor #3: Good #2 moving towards Gate #1
Monitor #5: Good #2 moving towards Gate #1
Monitor #6: Good #2 moving towards Gate #1
Monitor #2: Good #6 moving towards Gate #1
Monitor #1: Good #6 moving towards Gate #1
Monitor #4: Good #6 moving towards Gate #1
Monitor #3: Good #6 moving towards Gate #1
Monitor #5: Good #6 moving towards Gate #1
Monitor #6: Good #6 moving towards Gate #1
Monitor #1: Good #3 moving towards Gate #4
Monitor #3: Good #3 moving towards Gate #4
Monitor #4: Good #3 moving towards Gate #4
Monitor #5: Good #3 moving towards Gate #4
Monitor #2: Good #3 moving towards Gate #4
Monitor #6: Good #3 moving towards Gate #4

Thats much better! Or is it? If you have been so careful as to tag each item in the warehouse with a RFID tag, it stands to reason that the badges people wear inside the warehouse will also be marked with RFID tags. Lets assume that goods #3 and #6 are, in fact, people badges.

So, the security log becomes:

Monitor #1: Good #1 moving towards Gate #4
Monitor #4: Good #1 moving towards Gate #4
Monitor #2: Good #1 moving towards Gate #4
Monitor #5: Good #1 moving towards Gate #4
Monitor #6: Good #1 moving towards Gate #4
Monitor #3: Good #1 moving towards Gate #4
Monitor #2: Good #2 moving towards Gate #1
Monitor #1: Good #2 moving towards Gate #1
Monitor #4: Good #2 moving towards Gate #1
Monitor #3: Good #2 moving towards Gate #1
Monitor #5: Good #2 moving towards Gate #1
Monitor #6: Good #2 moving towards Gate #1
Monitor #2: Person #6 moving towards Gate #1
Monitor #1: Person #6 moving towards Gate #1
Monitor #4: Person #6 moving towards Gate #1
Monitor #3: Person #6 moving towards Gate #1
Monitor #5: Person #6 moving towards Gate #1
Monitor #6: Person #6 moving towards Gate #1
Monitor #1: Person #3 moving towards Gate #4
Monitor #3: Person #3 moving towards Gate #4
Monitor #4: Person #3 moving towards Gate #4
Monitor #5: Person #3 moving towards Gate #4
Monitor #2: Person #3 moving towards Gate #4
Monitor #6: Person #3 moving towards Gate #4

To you and me, of course, it is immediately obvious that Person #6 is moving Good #2 towards Gate #1 [and P#3, G#1, Gate #4]. How do you make the system understand that?

You need to put in “event correlation” code… for example:

IF
Person #X is moving towards Gate #Y AND
Good #Z is moving towards Gate #Y
THEN
Person #X is moving Good #Z towards Gate #Y

But what happens if both Person #3 and Person #6 are moving towards the same Gate #4? How will the system know which person is carrying which good? So, there is a need for “location tracking” - so the rule looks like:

IF
Person #X is moving towards Gate #Y AND
Good #Z is moving towards Gate #Y AND
Location of Person #X is the same as Location of Good#Z
THEN
Person #X is moving Good #Z towards Gate #Y

So far, so good! The security log will look like:

Person #6 is moving Good #2 towards Gate #1
Person #3 is moving Good #1 towards Gate #4

Next, you need to add the access permissions of the person’s tag into the system, as well as the movement schedules of the good. This will ensure that the system fires an alert if the person is moving towards an unauthorized area, or the good movement is not in the schedule, or both.

All this is, of course, fairly standard technology - the logic can be captured fairly easily in Java, C#, VB.NET, etc., etc. If only real-life was so simple :-) The challenge comes when this simplistic solution is deployed into a real-world warehouse:

1. What if the person is authorized to move around the warehouse, but is not authorized to move that particular good?

2. What if the authorized person asks someone close by to help him/her move something?

3. What if the person deliberately leaves his/her badge in some place and starts moving around without being tracked?

4. What if 2 different people bring 2 different goods to the same gate at the same time? Will this system still work as advertised, or will it get confused about who brought which good? Clearly, time-tracking is also important.

5. What if 2 people exchange the goods they are carrying? Will this system be able to track that particular event?

6. What if the good is placed on a conveyor belt / automated mechanism? Will the system just keep telling the security personnel that the good is moving on its own? :-)

The answer to each one of these questions adds yet another IF-condition to the simplistic rules presented above. Unfortunately, when the number of “ifs” reaches a sufficiently high number [ > 3 - 4, i.e.], the Java / C# code starts getting ugly - each additional if added in during the maintenance phase adds another ingredient to an exotic Italian dish inside the code base :-)

In reality, when you are trying to automate something like security and using “events” to do so, there will always be some holes in the captured logic - there is no way a programmer can capture everything the human mind assesses as a threat, and replicate it into the system.

New rules for detecting pilferage, etc. will be discovered all the time - at a very fast clip initially, and at a slightly slower rate later on. For any system meant to enforce security, therefore, flexibility is the most important feature it can ever have.

As a result, you need the security system to be able to do two things:

  1. Display the logic it uses for enforcing security so that human minds can review it and discover any gaps.
  2. Absorb the changes / enhancements made to the logic as fast as possible.

And this is exactly where business rules technology comes in - by allowing people to view / edit / manage the logic that enforces security, it allows the monitoring system to stay up-to-date all the time.

Once that happens, you can really start trusting RFID technology, and cutting down on the cost of video monitors + security personnel…

Case #2: Network monitoring and business rules technology

The second case is similar, but with a different focus…

Assume a large manufacturing plant that has “smart” devices - i.e., control systems that fire events about their usage, current status, etc., etc. into a monitoring mechanism.
OR
Assume a real “network” like a telecom network, or any router-based network…. where each router pumps data into a monitoring mechanism about the current usage statistics.
In either of the two cases, if one of the devices fails, there are two things that happen simultaneously:

  1. The faulty device stops pumping in its events into the monitoring system / it pumps in faulty events into the monitoring mechanism
  2. The devices affected by the faulty device start firing events stating that they are not able to function due to a lack of input from some other device.

In this case, the monitoring mechanism needs to correlate all the events pouring into it in order to decide:

  1. Where is the problem?
  2. What is the problem?
  3. What can be the cause of the problem?

Only after the diagnostics have been run can the monitoring mechanism alert the user with the information he/she requires in order to fix the issue. Again, in this case, the monitoring mechanism needs to be capable of changing all the time. For example:

1. A new device is added, affecting the configuration of the network. As a result, the alert correlating and error detection logic need to be changed.

2. A device is retired / taken out of the network

3. The network is reconfigured for improved performance / throughput / etc. Suddenly, the whole event correlation requires some serious updates…

4. New causes for failure are discovered - combinations of events previously not taken into consideration caused a failure and required manual investigation. The system needs to be updated in order to ensure a faster recovery the next time the same failure occurs…

The key thing to note here is “flexibility” - event correlation and cause-of-error detection logic, if captured using business rules technology, can be kept up-to-date very easily. This ensures that the monitoring mechanism is as efficient as possible.

Can’t Get No Satisfaction? The disconnect between IT and the Actuary departments

December 14, 2006 – 1:29 pm
By Vish Desai | Posted in BRMS, BRE, Business Rules, Business Rules Engines, Business Rules Management Systems, Insurance, Underwriting, Business Automation, Finance Technology, Compliance, Offshoring, Outsourcing, Actuary, Risk Management | Comments (0)

Apparently, Sarbanes-Oxley is forcing the actuaries and the techies to collaborate and develop processes for conducting financial calculations. The senior members of both the IT and the Actuary departments from the top 30 insurance companies got together to brainstorm for ideas on how best to achieve this - you can read about it here…

Essentially, what are the challenges?

1. No one system / product captures all the different ways of analyzing the data. As a result, people are forced to use multiple products, get the results from each one of them, and then simply use a “best guess” methodology for the “real” figures.

2. New regulations, changes in the business, and the introduction of new products force the models to change frequently. Actuaries feel that a process to maintain models more effectively is a BIG challenge that needs to be addressed asap - while 60%+ of the actuaries are aware of the SDLC, only 12% of them actually follow it.

3. The final challenge is co-ordination between the IT and the Actuary departments - insurance companies are thinking of setting up “dedicated resources” [scheduled meetings, contact personnel, etc.] in order to ensure that every one is kept on the same page.

“I think the insurance companies are spot on when they got down to identifying the problems, but I am not very confident that they’ve hit on the right kind of solutions.”

To put it in a nutshell, what is the proposed solution? Get IT and Actuary into the same room at the same time periodically. The assumption here is that, if the IT team knows what the actuaries want, the IT systems will get better and better as time goes by…

I believe this assumption is flawed! I will state that, even if the IT team knows what business wants, and gets the budget to implement the changes, it will have very little effect in improving the reliability of the financial models!!

Why is that? Simply put, the number of changes to be implemented.

Changes in the business environment, changes in the regulatory environment, and the introduction of new products will alone contribute to several changes a year.

Additionally, each actuary might want / have tweaks to the financial models that are specific to, and used only by, him / her. This is not an uncommon scenario - each actuary will have a spreadsheet, desktop-based tool that he/she has tweaked over several quarters to get it working more or less the way he/she wants. Now, the companies are forcing all the actuaries to move towards a “standard” model that is the same across the enterprise. Naturally, IT systems need to be personalized to suit each actuary’s taste - at least within the bounds of this new policy.

So, all in all, how many changes is the IT team expected to implement every year? And in how many systems? If you look at your own organization, you’ll understand the futility of trying to get IT to implement all the changes requested for in time-frames that make business sense.

My second problem with the “coordination will solve problems assumption” is that of assigning responsibility. If the actuaries hand over business knowledge to the IT team once a month and expect a perfect IT system 2 weeks later, they are simply dreaming very big pipe dreams…

The only way this *might* work is if the developer already has a “feel” for what the business wants and the requisite skills for programming it in. But again, ask yourself the question - how many developers do you know who stick to the same IT system for years on end? Of the developers who have done so, how many are really coding, instead of leading teams that do the actual work?

Oh, and I keep forgetting… there is also this “new” phenomenon called outsourcing, right? Well, well, well…. so how many *consultants* do you know who stay in the same place for years on end??

The point I am trying to make is, giving business knowledge to IT departments may improve the systems marginally, but I would not bet on it. If you don’t believe me, ask yourself this question: What was the automation rate for claims processing in the health insurance industry, say, 1980? And what was it in 1999? Did it really improve all that much across the industry as a whole? Why (yes, or no)? And what do YOU think will be the effect of outsourcing / offshoring in this scenario?

I am sorry, Mr. CRO and Mr. CIO - sitting in the same room at the same time once a month or fortnight is not going to solve this problem. Take a look at what wikipedia says about “transaction costs“, especially the parts about IT’s relation to transaction costs and the blurb on coordination costs.

What you need to do is to assign yourself responsibilities of a different kind…

Here is an idea…. how about this for splitting responsibilities?

1. The IT team develops systems that use a common database for ALL actuaries [as required by Sarbanes-Oxley, etc.]

2. The IT team enables personalization of the business layer of the IT system - essentially, allowing actuaries to capture their individual customizations of the modeling logic.

3. The IT team captures the basic financial models [as mandated by the enterprise] the first time, and hands off the system to the actuaries.

4. The head of the actuary department becomes responsible for maintaining the financial models - changing them, extending them, et al as required.

5. Each individual actuary is responsible for adding in specific customizations, and maintaining them as required.

6. The head of the compliance department is responsible for capturing the policies that validate the financial models. Essentially, compliance business rules that validate the business rules comprising the financial models.

7. The compliance department has read-only access to all the models - the base enterprise model, as well as the customizations. It uses the data to ensure compliance, and flag off errors.

8. The compliance department is responsible for maintaining the compliance business rules.

9. The IT department gets into the maintenance act if, and only if, a technical change to the system is required - data model changes, version upgrades, application of service packs, etc.

Splitting the responsibilities this way ensures that the actuaries are responsible for the financial models [which they should be], and the developers are responsible for the technical details [again, as required].

The question is, can this be done? Oh, definitely! Business rules technology is capable of enabling all of this, and more… it’s been around for a while, so any commercial BRMS vendor will be able to give case studies of such implementations!

Architecting an Agile Solution using BPM, BRE / BRMS, and BI: A simple primer for the newcomer

December 13, 2006 – 5:18 pm
By Vish Desai | Posted in BRMS, BRE, Business Rules, Business Rules Engines, Business Rules Management Systems, Business Automation, Business Process Management, Workflow, Business Intelligence, BPM, BI, Agility, Primer, Business Agility Primer | Comments (7)

I’ve been reading a lot of articles / series of articles from a lot of people in recent weeks focusing on what agility means, what are the types of business rules, what decision automation means, and how to find out if you are ready for becoming agile in some way or the other, the business rules codex, etc.

What about the newcomers, though? BPM, BRE / BRMS technologies are “approaching the chasm”. What that means, essentially, is that a lot of people are going to be searching on the net for information on how best to use them in their own enterprises, right?

Thinking about it made me notice that there is a requirement for connecting all of these different article series… basically, to give an overview of how to go about architecting a truly agile line-of-business IT system that makes use of business process management, business intelligence, and business rules management…

So here is the theme for a series of articles: Using BPM, BRMS / BRE and BI together effectively, for the newbie! I will try to put this “theme” across in the next few articles I post on this blog - collectively categorized under the “Business Agility Primer” label… What I will focus on documenting is:

1. What are their functions?
a. Business Process Management (BPM),
b. Business Intelligence (BI)
c. Business Rules Management (BRE / BRMS)

2. What are the inter-dependencies?
a. Business Process Management & Business Rules Management
b. Business Rules Management & Business Intelligence
c. Business Intelligence & Business Process Management
d. BPM, BRE / BRMS, and BI, all together

3. Architecting an “agile” line-of-business IT system
a. Frameworks available, advantages / disadvantages
b. An example of “agile” architecture
c. DFD for the agile architecture

4. Implementing an “agile” line-of-business IT system: Some suggestions
a. The User Interface
b. The N-Tier infrastructure layer
c. The database

5. A case study: An example of the agile line-of-business IT system
a. Technology case study
b. Business benefits

Since I need to do a fair amount of research myself to find relevant links, etc., this series won’t be “an article a day” kind - however, I’ve promised myself that I’ll finish them before the middle of January :-)

Please do leave a comment or email me if you find something missing in this TOC [and want to see it in there], and I’ll try my best to modify it.

Why are Business Rules Management Systems considered ONLY server-side, and not client-side, technology?

December 13, 2006 – 1:29 pm
By Vish Desai | Posted in BRMS, BRE, Business Rules, Business Rules Engines, Business Rules Management Systems, Call Centers, Mortgage, Loan Origination, Insurance, Claim, Underwriting, Business Automation, Finance Technology, Compliance, Business Process Management, Workflow, Business Intelligence, BPM, BI, Client side business rules | Comments (6)

One of the things I’ve noticed is that most people assume that BPM, BI, and BRMS technologies are essentially “server-side” technologies. Something in the term “business” seems to be conjuring up visions of multi-processor server boxes linked to a SAN with huge databases operating on RAIDs somewhere in that mix…

I’ve been continuously surprised by the fact that BRMS technology is also bundled along with BPM & BI, and relegated to the back-end… so I was pleasantly surprised to read this press release where business rules are featured prominently as part of the front-end.

Q. Why is business rules technology not confined to the server-side?
A. Because…

  1. business rules also apply at the “edge of the enterprise”.
  2. decisions need to be taken by the outward-facing employees in real-time.
  3. outward-facing employees do not always have to collaborate with others when taking a call on something.

Deploying business rules engines at the edge of the enterprise certainly gives a lot of benefits to the company. For example:

  1. Life insurance companies can cut down on the time and effort required to underwrite a policy if the quotation engine applies the rules governing the insurance product upfront. Think of the benefits to the broker network in terms of time savings, for example.
  2. Health or P&C insurance companies can reduce the time-frames required to settle a claim if the adjustors know that the data is correct & complete before they get their hands on it.
  3. Mortgage companies can process loan applications faster if the underwriting phase does not involve getting back to the prospect multiple times for more information, or clarifications.
  4. Real estate networks can spend less time in qualifying a prospect and assigning the “correct” realtor to a lead, reducing the time required to close the deal.
  5. Call centers can provide accurate, up-to-date information to customers who call in, improving customer satisfaction levels. This is a cross-vertical benefit of business rules technology, since call-centers are a feature of any B2C enterprise landscape.
  6. Human Resource managers across the board can filter out most of the resumes for a particular job posting in real-time based on business rules. Think about the time and effort they put in to service a request from a hiring manager, and the benefits become obvious.
  7. By ensuring that accurate and complete data is collected upfront, business rules technology can also bring in significant reductions in compliance related efforts.

Essentially, all the above are examples of either campaign engines or filtering mechanisms… Typically, campaigns & filters are tasks that are executed by a person working without the benefit of collaboration in real-time - think HR manager, and think call-center executive on the phone.

Relying on training and experience nearly always results in a higher error rate when a decision needs to be made - lack of experience, lack of awareness of the latest policy changes, lack of knowledge about the newer offerings, errors in uderstanding the customer’s requirements… the list of reasons why errors occur are endless.

On the other hand, campaign engines powered by business rules technology can be quickly configured to run up-sell / cross-sell campaigns, reducing the time-to-market and increasing the effectiveness of marketing campaigns. The same engines could be used in the call center, on the website, at remote broker / partner offices, etc. - ensuring consistent messaging across the customer base regardless of the channel of interaction.

The same benefits hold true for filtering mechanisms that incorporate business rules technology too. Take the case of the HR manager - automatically filtering out the resumes that do not match reduces the burden on the HR team when submitting resumes for approval, and setting up interviews, etc.

The best part of using business rules technology is that the “filtering rules” or the “campaign rules” could become the responsibility of the hiring manager / marketing manager - placing responsibility for the hire where it belongs, and ensuring that the task is implemented according to its spirit and not its wording.

So, why aren’t more companies rushing to embrace the concept of a business rules engine on their call-center desktops, disconnected sales-force laptops, etc.?

  1. One of the challenges in the past has been about deploying business rules to the edge of the enterprise - especially when said business rules change very frequently… In essence, the very reason why client-server applications were replaced by web-based systems
  2. The second challenge has been security - if your business policies are floating around on a lot of people’s machines, a breach and subsequent loss of confidential data has a higher probability

I believe it is time again for enterprises to re-look at the option of deploying business rules technology on the client-side. In the .NET world at least, both these problems have been solved - smart client technology, click once deployment, and the DP API address exactly these issues. While Microsoft positions these technologies for binaries and data, there is no reason why business rules cannot be treated as both for the purposes of deployment.

PS: Does anyone know what are the J2EE equivalents? If yes, please do post a comment / send me an email.

Delivering a first-class service…

December 12, 2006 – 3:59 pm
By Vish Desai | Posted in BRMS, BRE, Business Rules, Business Rules Engines, Business Rules Management Systems, Insurance, Claim, Underwriting, Business Automation, Compliance, Business Process Management, Workflow, Business Intelligence, BPM, BI | Comments (0)

I came across the text of the speech given by Richard Ward, the CEO of Lloyds on improving customer service processes…. interesting read about what customers want, what they are getting, and how to bridge the gap.

What are Lloyd’s customers saying they need from insurance companies?

“The key areas customers want us to improve remain: speed of policy documents being issued; keeping customers informed of progress on claims; and speed of settling those claims.

Brokers also said they would like to have even greater access to underwriters, with more information on their availability and waiting times.”

So what is Lloyds doing to address these issues? Here it is, from the horse’s mouth:

“As Lloyd’s CEO, my first priority is to deliver efficient business processes, such as placement, claims and accounting and settlement, that will enable us to grow.“

Aaaah… there we go again :-) Business Process / Business Intelligence / Business Rules technology ensure a good customer experience! Read the full text at your leisure…

Do we need pilots, or not?

December 12, 2006 – 2:15 pm
By Vish Desai | Posted in Uncategorized | Comments (2)

Seth blogs about the diminishing needs of pilots in running airlines, and uses it as a metaphor for running businesses, with the conclusion that pilots are on the way to becoming extinct.

Here is the rejoinder to the post from a different site :-)

Anyway, will we need pilots or not in running corporates in the future? I think we will, at least till we have robots equipped with positronic brains doing the job for us lazy humans. Here is a list of reasons why:

1. Ideas are all good and fine, but we need execution! I mean, what is the point in having a bank full of ideas nobody wants to use because everybody is busy filling up some more lockers with ideas?

2. Execution, unfortunately, means schedule-monkeying, riding roughshod over people’s egos if they are being lazy, smoothing ruffled feathers, and other, similar, “mundane” tasks.

3. In a world where ideas are a dime-a-dozen, the execution requires a steady mind, good communication skills, people-management skills, the ability to discriminate between bad ideas, good short-term ideas, good strategic ideas, and the conviction to carry out those ideas.

Pilots, or captains of ships, get where they are because of exactly the same skills… there is / was / will be a requirement for such people in any organization.

I know this is not about business rules, but since I work for a small-ish organization, I understand the value of execution and its relative importance to idea-generation at a very basic level… My $0.02!

Requirements gathering with use-cases…

December 11, 2006 – 5:36 pm
By Vish Desai | Posted in BRMS, BRE, Business Rules, Business Rules Engines, Business Rules Management Systems, Business Automation, Business Process Management, Business Intelligence, BPM, BI, Requirements, Use cases | Comments (4)

Came across the “Where to start with use cases” blog post by Seilevel - it talks about how to decompose a proposed IT system into manageable chunks [process decomposition] that can be given off to the architects / leads / programmers for further development.

This post by Kushal on the problems with too much process decomposition also refers to pretty much the same thing - that too much decomposition is a bad thing, and you need to stop somewhere. His viewpoint is - the whole system is greater than the sum of its individual parts…

The question I asked myself is, if I had to go to a customer site tomorrow and start the requirements gathering process, how would I go about it?

Would I still try to capture everything in a document [Word, Excel, Visio, PowerPoint, etc. - all count as documents!!], get it signed off by the users, and THEN start the process of generating UML diagrams? Or is there a better, more modern, way of going about it?

First of all, what does “better” mean in this case? IMHO, if possible, the requirements gathering should happen in such a way that:

1. The complete process, the sub-processes, etc. all the way down to the elementary processes are captured in a single place - double-clicking on a node in a higher process expands that node and shows you the sub-process, for example. Think “project plan”, and sub-project-plans under that - business processes should be captured in exactly the same way.

2. Expanding a process node should show you three things straight away - the input data format, the output data format, and either the entry point for the sub-process(es) or the business policy(ies) that drive that node - essentially, the complete decision making apparatus underlying that part of the process.

3. This whole diagram (process, sub-processes, decision-making policies) is test-able, i.e. any sample data that the business users have (spreadsheet data, or the data warehouse) can be pushed through the diagram and the resulting outputs can be verified against expected outputs.

4. The tested diagram can be packaged and sent off to the design leads, programmers, etc.

5. The programmers should be able to use this diagram as-is, i.e., integrate it into the actual codebase without modifying the diagram itself. The business data model will, of course, need to be mapped to something in the diagram…

6. The diagram, with the business data model linkages, should be deployable to the runtime environments.

If the requirements could be gathered in this fashion, it would eliminate a lot of effort - communication gaps between the business team, the requirements team, and the development team, to give just one example. Requirements coming in fully tested will cut down the effort at the unit testing stage initially, and regression testing at maintenance time…

But, but, but…. what about changing requirements? As anyone in the software industry knows, that is the killer - the root cause for implementation delays in 70% of the cases! So, the definition of “better” should also include things like version-ability and rollback…
So, now the question is, is this possible today? First of all, if there is such a software around, what would it look like? My best guess is that it would:

1. Allow the creation / maintenance of a “meta-data-model” - it could be simple as a list of business terms, or something as complex as a complete knowledge base.

2. Allow the creation / maintenance of process diagrams, including sub-processes all the way down to the “elementary processes”. Ideally, these would be BPEL compliant.
3. Allow the creation / maintenance of business rules / rule-sets, to automate human decision making. Ideally, the business rules can be captured as RETE-style statements, Decision Tables, Decision Trees, Sequential Rules, etc., etc.

4. Allow the creation of reports. Ideally, it would be a full-fledged BI tool, too… with reporting and predictive analysis built-in.
5. Allow the mapping of the meta-data-model to columns in spreadsheets / database tables in order to allow unit / regression testing.

6. Allow versioning of both the process and policy diagrams at a fairly granular level, enough to make rollbacks nice and easy.

7. Allow the meta-data-model to be hooked up to the real data model, i.e., Java / C++ /.NET objects, or XSDs, or database tables, or WSDL schemas, or something.

8. Allow the mapped process to be deployed to a commercial BPM / EAI / ESB / BRMS product.

So, back to the question - is such a software available today in the market? Based on what I know, here are some likely candidates:

1. MS-Office (of course): Has Word, Excel, Visio, Infopath, and Binder. Is already used for BI by a significant number of people. Has an add-in model which is becoming easier to work with with each release of VS.NET. Now has Sharepoint, and Rules for Office, getting it closer to a Workflow / BRMS. So, can someone write an Office-based application to do everything I’ve mentioned above? Definitely!

2. JBoss: jBPM + Rules are already there. Can you add in a BAM / BI kind of a solution to the middle-ware stack? Sure, why not? Plus, they have a console on Eclipse, so you have the UI also there… This is definitely a good candidate.

3. NetBeans: Sun’s gone down the BPM / BAM / EAI route with their acquisition of SeeBeyond. The UI is, again, open-source, pluggable, and ready to go. All that is required in that stack is a BRMS. For someone else, taking the existing stack and integrating an open-source BRMS is definitely feasible…

4. VS.NET: Why not? WWF acts as both a Workflow and a BRMS engine. You need a BI tool… but VSTO can take care of that, I think.

5. Websphere: IBM’s kicking up a fuss with the WebSphere process server, their MQ series of tools, etc. So, again, all they need is a BRMS, which their Haifa labs has been working on for a while. So is there a BI somewhere around? Personally, I do not know, but I will not be surprised…

6. Oracle: Definitely! Need I say more?

7. Pegasystems: Again, definitely!

8. Other BPM / EAI / ESB / BRMS / BI vendors? If they collaborate, definitely yes!

Thats my take! Of course, on a topic like this one, I’ve missed out on plenty of points and viewpoints…. please comment and let me know!

10 “Best Practices” for Product Development…

December 7, 2006 – 6:31 pm
By Vish Desai | Posted in BRE, Business Rules, Business Rules Engines, Business Rules Management Systems, Insurance, Claim, Business Automation, Compliance, Business Process Management, BPM | Comments (0)

Philippe’s “best practices” list for developing Insurance Products… Notice the points he makes on how technology can be used to help insurance companies beat the street…

  1. Separation of “products” from “process” - not hard coding the product in a legacy system
  2. Ensuring completeness: Insurance products are NOT simply pricing, but also include underwriting policies, information gathering questionnaires, etc.
  3. Collaboration is key - use technology to enable it
  4. Technology platforms should support the latest industry standards… ACORD & SOA for example

Go through the article. Without naming it explicitly, I think he’s made a good case for business rules technology - should be obvious to anyone who is familiar with the BRE / BRMS technology space.