Most of you will have seen recent news about GEICO being sued for discrimination - Blacks Sue GEICO For Race Discrimination In Auto Insurance Rates for example. For those of you who aren't familiar, GEICO is being sued for discrimination on the basis that its use of education and occupation in determining insurance rates means that Blacks are often charged more than whites with the same driving record. I don't want to comment on the case but it does illustrate one of the key reasons why business agility is so key, especially in regulated industries.

Let's say that the suit is successful against GEICO, or even that it looks like it might be. If a company has hard-coded its use of education or occupation or any other property of a customer that has a significantly different distribution between races then it is going to be under the gun for changing its code. All the places in the code where that's used must be found and it must be removed. Statistical analysis must also be done to determine the impact on rates etc. One imagines that anyone continuing to use such measure if and when they were found to be illegal would be doubly exposed.

If, on the other hand, I have coded these potentially regulated rules in a business rules management system so that I have them in one place, managed as a corporate asset and structured to allow those with business/legal expertise to edit them, then I am in a much better place. I can quickly find the rules that are impacted (using repository tools increasingly common in leading products) and change them without any IT involvement before pushing them rapidly through testing and into production. Business agility enabling compliance.

This also illustrates why compliance is not something that can be assumed to run on a legislative schedule. Just because the law changes only slowly or periodically does not mean that a court case cannot force you to change your rules of doing business more or less instantly.

One last thing - you want to make sure that any business rules management system you use let's you control what kinds of things can be used in which rules so that you can make sure not to allow business users to accidentally include checks that are illegal. This requires some kind of templating and edit control approach not just a business rules free-for-all.

I have blogged on similar topics on my EDM Blog a few times - notably here and here, though the second one is mostly a link to an ebizQ article - Is business agility an Oxymoron?

Posted by jtaylor in Business Agility • Compliance | Permalink | Comments (0) | TrackBacks (0)

Tower Group's Jerry Silva recently published on ".NET vs. J2EE: Does the Future of Service-Orientation Hang on Myth and Misconception" He has some great data on platform preferences in various industries, especially banking, and about how people perceive the two platforms.

The key message to me though was that about 50% of those surveyed either had no preference or expected to use both platforms. Additionally, of the 50% committed to one platform or the other, more and more companies seem to be assessing the platforms more coherently and are showing a willingness to consider either for a given project or department. As Jerry says 'the reality will have to be not".NET vs. J2EE" but ".NET and J2EE" in the coming years'.

So where does this leave developers when it comes to decision management? Well one of the key benefits of managing decisions as a corporate asset is the ability to deploy the same decision across all your channels and touchpoints - consistency is the touchstone. Partly this means focusing on business decisions as separate entities from proceses, websites, systems etc. Partly it means externalizing the definition of how you make a decision into a business rules management system or similar. However, to really get the benefits you need to be able to push the decisions out to all the platforms you are using.

You can do this by using the ability of Java to run on virtually everything, by using a service-oriented approach and defining your decisions as services or by using one of the new breed of business rules products that support deployment of the same rules to multiple platforms.

What you should probably not do, however, is let your first project drive too much. The platform of the first application for which you are automating decisions or the BPMS you are going to use to automate the first process that needs automated decisioning cannot embed the rules you are going to use - you need to be able to manage them across all your platforms, systems, processes if you are to get the maximum value out of automating them. Sandy had a great post on this as it relates to BPM and rules back in February.

Posted by jtaylor in Business Agility • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)

I read a lot these days about managed IT in one from or another - managed systems, managed processes, managed management and so on. So why manage decisions?

First let's be clear what a "decision" is in this context. A decision, or more precisely a business decision, selects from alternatives, typically to find the one most profitable or appropriate for the organization and/or the customer. To do this various facts or pieces of information about the situation and the participants in it must be considered. Finally an action is taken - decisions are not just about knowledge being added to what is known. Decisions are taken by enterprises at every level – from strategic decisions taken by the CEO to the intensely operational ones taken by customer service representations or store workers. Decision Management is largely an issue with these operational decisions. If we want to automate these kinds of decisions, and we do, then we need to consider Decision Management as a separate discipline, not just part of systems development.

Automating decisions involves embedding know-how into operational systems. Often this know-how is specific to your organization so buying a package has limited value - the package vendor does not know how you like to take decisions. Traditional coding approaches tend to separate the expert from the process - most business experts don't read code very well and so have a hard time editing it or even reviewing it for accuracy.

In regulated industries - and let's face it most industries are more and more regulated these days - compliance is another issue with decisions. Will you be able to show that this decision was taken in a compliant way if you automate it? Do you think the regulators will be able to read that code? Will you be sure exactly which bits of the code executed for each transaction and can you log that?

Decisions also represent one of your key areas for competitive advantage and distinctiveness. In an era of standardized forms and increasingly best-practice focused processes, how you decide things makes a real difference to how you are perceived. If you decide to take on high risk customers (for a price) or to decline certain kinds of requests, these decisions affect how the market sees you. Managing the decision you take interacting with customers is thus key to your market perception.

So operational decisions must be automated differently and can be key to your business. They deserve to be managed as corporate assets and this requires new technologies, new approaches, a new mindset. More on this as the blog continues.

Posted by jtaylor in Business Agility • Compliance • Decision Technologies | Permalink | Comments (0) | TrackBacks (0)