James Taylor's Decision Management

May 11, 2008 Sign In | About ebizQ | Contact Us | Join ebizQ Gold Club

James Taylor's Decision Management
James is one the leading experts in enterprise decision management, a published author and a principal of Smart (enough) Systems LLC. His blog discusses the use of decision management technologies like predictive analytics and business rules to deliver agility, improve business processes and bring intelligent automation to SOA.

Main

March 20, 2008
Top posts from the decision management blog

I thought it would be fun to highlight my 20 most popular posts from the last couple of years so here goes:

Enjoy!

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Intelligence • Business Process Management • Business Process Outsourcing • Business Rules • Compliance • Decision Technologies • Event Processing • Innovation • Legacy Modernization • Predictive Analytics • Requirements • SOA | Permalink | Comments (0) | TrackBacks (0)

February 28, 2008
Decision Management - another way to get the business to care about SOA

My buddy Joe had a great post this week - Give businesspeople a reason to care about SOA; give them BPM. Like Joe I think business people need something business-oriented to get their attention and that describing the benefits of SOA must use business terms and business problems. Interestingly I spent the week at ILOG's DIALOG conference this week (see my posts live from DIALOG here) and lots of the customers I met there were using business rules and SOA together having found that decision services, built with business rules, offered their business users a compelling business value. Not only were rules-based decision services a great way to deliver business agility - services a business user could actually change for themselves - they were also an effective first service as they acted as a bridge between the legacy applications and the SOA-based composite applications being developed. After all it is typically not the whole legacy application that is needed as a service but some core business decision buried within it. Exposing just this decision as a service while also making the service much easier to maintain using business rules is very effective. Combine this with BPM, as Daryl Plummer of Gartner did in his presentation and you are off to the races.

Posted by jtaylor in Business Process Management • Business Rules • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

January 16, 2008
Legacy modernization, business rules and offshore development

I saw this post on Offshore Architects, Legacy maintenance and modernization and it struck me, again, how valuable business rules and a focus on the automation of decisions can be in legacy modernization. By separating out the high-change, highly volatile rules into self-contained decisions you can:

Reduce the number of changes required to the hard-to-modify legacy code by externalizing the high change pieces as easy-to-change business rules.
Make the core business logic reusable in your SOA through decision services.
Ensure that the business know-how relevant to your core logic stays onshore, even if most of the maintenance work is offshore.
Give those architects who think maintenance is boring something more interesting to do - adopting a rules management system and making the changes to the SDLC to take full advantage of it should be fun enough for the most jaded.
Make re-platforming and the adopting of business process automation or outsourcing much easier by brining the tough business logic under real control

. I am sure there are others but, as I have written about this repeatedly, here's a set of links instead.

Posted by jtaylor in Business Process Outsourcing • Business Rules • Decision Technologies • Legacy Modernization | Permalink | Comments (1) | TrackBacks (0)

December 12, 2007
Another Challenge to Integrating IT and Business

My old friend John Parkinson had a nice post over on CIO Insights today - 5 Challenges to Integrating IT and Business. As usual John makes good points about the challenges of technology in general but four of his five made me think about the challenges and opportunities of decision management technologies in particular:

No clean slate
Adopting SOA, BPM or any other new approach always runs a risk of crashing squarely into the realities of a body of legacy systems and technology. One of the most interesting ways I see organizations adopting decision management is in taking the highly volatile pieces of legacy systems - typically decision making pieces - and externalizing them using rules and other techniques. This allows them to be reused in other parts of the business, and they are often valuable widely, while leaving most of the legacy application intact and ensuring that the highly volatile piece is now easier to manage.
Unrealistic expectations
While it might not be obvious what decision management technology can do about this, I think it is relevant that by bringing the business more directly into the process of managing and updating information systems it can reduce unrealistic expectations. Business users who are doing their own rule writing and testing will have more of an understanding of the realities of technology.
Out of synch strategies
The power of decision management to synchronize the business and IT by bringing both sets of skills to bear on the same business problem. Using business rules to allow business and IT to collaborate is well established and can reduce the gap between the organizations.
Nothing stays the same
Agility, agility, agility. One of if not the defining characteristic of decision management technologies is their ability to bring agility to information systems. Making it easier to tell what change is needed and easier to make the change quickly and yet correctly is both essential and a direct benefit of these technologies.

You might enjoy this post on agility and this one on business user / IT collaboration. May you live in interesting times...

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

August 03, 2007
Boomers are retiring and not just in IT

Deborah Perelman wrote this nice little piece over on CIO Insights today - 7 Ways to Protect Legacy Systems When Boomers Retire. The article's focus was on the boomers who work in IT retiring but that's not your only problem. IT boomers might be the only ones who understand the innards of a systems but what about the boomers who understand what the systems are supposed to do? These business people are retiring too. In many ways this is a similar problem - these folks have skills and understanding that you cannot afford to lose. Yet many of them also perform roles for which you will not be able to hire replacements - look at the trouble insurers are having hiring new underwriters, for instance (check out this post on the coming "experience gap"). This means taking this expertise and putting it into the information systems you are going to use going forward. Interestingly this matches item #6 in Deborah's list:

6. Institute a formal program to regain intellectual property; technology and IT training is comparatively easy. IT must guard against the loss of business knowledge accumulated over years by these retiring workers

The difference, perhaps, is that the business knowledge is being captured not as static documents or in a wiki but as executable business rules that drive system behavior. Not only does this approach "save" the knowledge, it also helps streamline processes and systems by automating decisions. Replacing the code in your legacy systems that implement this business logic with a decision service can also dramatically reduce the cost of maintaining the application as many people find that most of the change requests relate to this business logic, now separated out into an easy to maintain environment. You can, in fact, give your mainframe a new brain.

Deborah also quotes Phil Murphy of Forrester, about whose work I have blogged before - Business rules and the application knowledge deficit and Here's one way to strengthen weak application maintenance processes.

Technorati Tags: agility, BRMS, business rules, legacy modernization, rule management

Posted by jtaylor in Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

July 19, 2007
Support your local sheriff

Russell Keziere wrote an interesting little article this week - BPM Sherriff Rolls Into Town. He took aim both at old-style monolithic applications and at the potential "wild west" of uncontrolled components. I wanted to focus on a couple of key points. First he said

"Monolithic computer applications, which only a software programmer can change, promise to do everything but end up solidifying or creating silos within business departments"

and later he added that

"ERP applications will be with us for years to come"

His suggestion was to use a BPMS as part of the composite application development process and to help IT get control of its own governance processes. While this sounds like an excellent idea, I wanted to return to the idea of using a BPMS to do the composite application assembly needed to truly exploit SOA. If your BPM sheriff is not able to call on effective decision services then you won't really be able to generate true decision services - your process will be easier to change and your services more self-contained, but only a focus on decision making services as a distinct class of services is really going to get it done. Not only do decisions require a different approach, it is important not to over-synchronize them with your processes if you don't want to create a new monolithic process! Over on my other blog I talk about use of decision services for the last decomposition of the application. A focus on decision services also allows you to use decision management to complement ERP and use SOA, BPM with your Enterprise Applications.

Technorati Tags: agility, business agility, business rules, decision management, decision service, service-oriented architecture, SOA, enterprise application

Posted by jtaylor in Business Agility • Business Process Management • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

June 05, 2007
Decision Management and Smart (Enough) Systems

As some of you know by now I have been working, with Neil Raden, on a new book. As the files shipped to the printers today I thought I would take the opportunity to shamelessly plug the book here on the blog. The book's premise is that much of today's existing technology has the potential to be "smart enough" to make a big difference to your organization's business and that current business trends are forcing you to build smarter systems. Like this blog, the book discusses how focusing on decisions as distinct opportunities for improvement, you can use established technologies in a new way to solve problems and create competitive advantage.

You can pre-order it here from Prentice Hall (there is even a blog discount coupon code TAYLOR7962) or from amazon.com here (amazon.com has not yet decided what price it will charge).

The book has a companion site too - http://www.smartenoughsystems.com where you can subscribe to news about the book/authors and read the testimonials we got. Over time we will add more useful links to the site.

If you are not yet convinced that you need to read the book, why not try the digital shortcut "Why you Need Smart Enough Systems". You can buy it online from Prentice Hall for less than $5! If you need to be convinced that you need to use decision management to make your systems smart enough to be useful (or if you have colleagues or customers who don't understand why they should apply the techniques we talk about on the blog), you will find this a good read.

</shameless commerce>

Technorati Tags: adaptive control, business rules, data mining, decision, decision automation, decision service, decision service, EDM, enterprise decision management, optimization, predictive analytics, Smart (Enough) Systems, smartenoughsystems

April 02, 2007
Business rules and the application knowledge deficit

Phil Murphy of Forrester recently published The Application Knowledge Deficit (subscription required). I won't reproduce his numbers here - it's not publicly available to non-subscribers - I would make two points:

Almost no-one relied on reading the source code to understand an existing system
This contrasts with the use of a business rules management system that allows far better understanding of what is being done with business users, as well as analysts, able to read and understand the business logic.
Very little code mining or transformation is being done
Part of me wonders if this is because the target system is still being coded by hand. If the developers knew that they had a way to manage the business rules in the new system, would they be more interested in finding out what the business rules were in the old system?

If organizations are going to free up any budget for innovation they must reduce their maintenance costs. While not all the code in a legacy application should be replace with decision services, some should be. Doing so not only allows the possibility of keeping large chunks of the legacy application working longer (because the high maintenance cost pieces are now managed properly), it also takes advantage of more modern thinking by using the right kind of technology to build each kind of service. "You can't code your way into the future" as a Gartner analyst once said. If you build the new systems the same way you built the old systems, nothing is every going to change. I blogged about business rules in the context of another of Phil's pieces here and about how Application Maintenance can be improved with business rules here. I have also blogged about using business rules to improve old applications on my other blog.

Technorati Tags: application maintenance, decision service, Forrester, legacy modernization, SOA

Posted by jtaylor in Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

March 30, 2007
Extracting UML from Legacy Applications

I saw this nicely written article - Extracting UML from Legacy Applications by Richard Soley and Mike Oara over on SOA Magazine. While they do a nice job explaining how you can use legacy modernization tools and UML to modernize applications, especially in terms of what you can and cannot automate, the lack of rules in UML is a real limiting factor. Without a way to represent business rules clearly in the UML diagrams you extract, I think one of the key drivers of the code you have (your business rules) will be hard to extract. For instance, Richard and Mike say of requirements:

While the current system may implement business requirements, they may not appear explicitly in the code, but rather in the form of fulfilled requirements

This is even more true of business rules. The rules are most unlikely to be explicit in your code - that's one of the reasons I recommend the use of a business rules management system for implementing business rules - they are also not requirements and should not be managed as such. For instance, use cases should refer to business rules and not embed them so that the rules can be managed, updated and reused across use cases (see this book for more on this).

I also have to take issue with something the authors say about completeness. They say:

As a legacy application is modified and enhanced over the years users often lose a complete understanding of how the application functions. For example, in a pension system the rules for computing the pension can be spread through numerous government and corporate policy documents. This knowledge is already in the code, which is more complete, precise, and concise than what would come from user interviews.

Here I disagree. In general, relying on code to accurately represent policies and regulations is a poor alternative, just like interviews. The actual regulations and policies are the place to go. The code is useful for telling you what is currently being enforced (or not) but it is often over-used as a source of business rules. Barb von Halle provoked a fairly spirited discussion this on my other blog if you want a variety of opinions.

This is why I chair an OMG standards group and why I am working with other vendors (including ILOG, Corticon, Tibco and IBM) to develop a production rule standard (known as the Production Rule Representation) for business rules. Then legacy modernization to UML could include building the production rules you have in your system and managing them properly.

Technorati Tags: BRMS, business rules, legacy modernization, requirements, UML

Posted by jtaylor in Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

February 19, 2007
You need to free up some money for innovation

Ian, the other blogger over on www.edmblog.com, sent me this little snippet today:

68 percent - Proportion of the IT budget that average North American companies used to support existing software and hardware in 2006, according to Gartner. About 19 percent went to adding capabilities to keep up with company growth, and 13 percent was spent on technology to propel the company into new markets or sell products and services in new ways.
Source: Baseline

Wow. So if you actually need to deliver any innovation from your systems, you need to free up some of the money you are spending on application maintenance. Part of the problem here is poor maintenance processes. The use of business rules to modernize some of your legacy applications can be very effective. A great example of this was the California DMV who reduced the maintenance cost of a big legacy system by renovating just part of it using business rules.

Technorati Tags: application maintenance, business rules, innovation

Posted by jtaylor in Business Rules • Innovation • Legacy Modernization | Permalink | Comments (0) | TrackBacks (1)

February 14, 2007
Here's one way to strengthen weak application maintenance processes

I saw this Forrester piece on CIOs: Attack Weak Application Maintenance Processes That Stifle IT Productivity by Phil Murphy. He makes the great point that systems were built as if they would never have to change (instead of being built for change time) and that the current rapid pace of business change causes equally rapid systems change. Phil talks about the maintenance backlog winning the battle for application development resources and so limiting the ability of the IT department to add value. While I liked the paper, I felt that there was too much focus on the whole application - often there is a very variable level of maintenance between different parts of the application and I have discussed before a basic process for pulling out these high maintenance pieces and modernizing just them. There is a great customer story about renovating just the high maintenance/high value component from the DMV here in California. In general I think companies could well use business rules to improve application maintenance and that this could help particularly when modernizing legacy COBOL applications.

He made a couple of observations and recommendations I thought I would repeat:

Poor Knowledge Transfer Techniques Increase Maintenance Costs
True. One of the attractions of using business rules to modernize legacy applications is the increased readability of business rules over code.
Use Tools And Technology To Leverage Greater Staff Productivity
Could not agree more. You need to spend money to save money and, in this case I think companies could spend on enhancing some of their applications by moving the high-maintenance part over to business rules.
Streamline Maintenance Processes To Increase Innovation Capacity
Build new systems to reduce future maintenance by using business rules to avoid write-only code

Technorati Tags: application maintenance, business rules, legacy modernization, Forrester

Posted by jtaylor in Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

January 22, 2007
Pragmatic Decision Services

A recent Zapthink piece on pragmatic SOA made me think of pragmatic decision services in this context. Taking four of their pragmatic areas I had a few thoughts:

Pragmatic Reuse
If you are focused on pragmatic reuse you might want to consider decision services. One of the attractive features of a rules-based decision service is that reuse is possible not just at the service level but also in terms of rules within the decision service. Business rules management systems allow you to reuse rules between services and this can be a very effective way to get reuse. Indeed, many BRMS also allow you to push rules into non-service oriented environments allowing reuse between SOA and non-SOA components.
Pragmatic Legacy Enablement
Jason made the point that only 20% of a legacy application might be worth service-enabling. My experience is that not only is only 20% worth making into a service but this is likely to be a decision service. The 20% is likely to be rich in business logic and decision-centric. It is also likely to be the 20% you have to maintain aggressively - if it was not changing it is probably pure legacy code that can and should be left as it was. Decision services and business rules can effectively manage application evolution.
Pragmatic SOBAs
Jason discusses Service-Oriented Business Applications and that they are only valuable for some processes. I agree and would again point out that some processes can be made agile and precise by embedding a decision service into an otherwise non-service enabled process to build decision agility.
Pragmatic User Empowerment
Business rules allow a business user to maintain the key decision logic in a process. Often that is the only part of a process that changes often and so a complete SOBA rewrite is not worthwhile but empowering business management of the critical decisions might well be.

Decision Services and business rules to build them with can be an effective but pragmatic approach.

Technorati Tags: BRMS, business agility, business rules, decision service, SOA, Zapthink

Posted by jtaylor in Business Rules • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

January 02, 2007
IT, Risk and Decision Management

I saw this nice piece by David Kelly on Managing IT Risk and it prompted me to think about decision management in a risk context.

For instance, David says:

Compliance is a risk that has received a huge amount of attention over the past few years, as organizations strive to meet new regulatory requirements and enable faster, more efficient audits of all types of business processes.

And he's absolutely correct. But compliance can also come with a requirement to show that systems behave in a compliant way - approving loans correctly or treating customers similarly regardless of race. Using business rules to automate decision logic can be a very effective way to show that systems are compliant with regulations. I have blogged before about the case for rules in compliance and about the relationship between COBIT, SOX and rules.

An important part of building a risk mitigation plan is to understand the impact of the different types of events or risks that an organization can encounter.

Business risks should not be forgotten either. The use of risk models, a kind of predictive analytic model, is becoming increasingly common in systems that manage the business to ensure that risk, credit or fraud risk for instance, is properly managed. This is not the same as business analytics or reporting but is about embedding insight gained from data into operational systems.

IT risk management plans that provide disaster recovery, business continuity, as well as assurance that an organization is equipped to successful handle a wide range of potential problems.

All true. But what about the need to respond quickly to crises? What if I have to change the logic in my systems quickly and accurately and be able to show what I did and why after the fact? Decision technologies like business rules can make this much more likely, allowing business agility even in regulated industries and in a litiginous society. Rules also allow for what-if scenarios to be planned and rules developed ready to go into production when they are needed. Really agile risk management. Enjoy.

Posted by jtaylor in Business Agility • Business Rules • Compliance • Decision Technologies • Legacy Modernization • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

November 13, 2006
Build, buy and decision automation

I saw this Build v Buy Workbook over on IT Toolbox (written by Craig Borysowich). I liked the basic approach here although I do think that a Service Oriented Approach allows for build v buy or both and that the future is in a composite approach to assembling applications (See Gartner's approach to the future of application development for example). If you take the approach that each service component can be bought or built then you might use the workbook a little differently. Some specific comments:

Having a competitive advantage
I don't think that competitive advantage comes from applications as a whole. Many times most of an application is just backbone stuff that offers no competitive edge but some part of it might well do. For instance, a call center application might not offer much differentiation but the ability to do cross-sell well in that context might well do. Hence the service focus rather than the application focus.
Ownership/control of source code
Although this is one aspect of "ownership" I would add "Ownership/control of business logic". Often the use of a business rules management system allows a company to own the business logic that will drive the behavior of a system and this can avoid the need to own the source code of a process or data collection applicaiton. I control the decisions in my systems not by controlling the code but by controlling the business rules. Focusing on the various ways to automate decisions (7 ways to build decision services) is one way to do this.
Retaining current procedures and processes
Even if retaining current procedures are important, I would want to track future needs to change the procedures. I might want to retain them but make it easier to change them in the future.
Reducing maintenance
A core benefit of a business rules approach is to drive down the cost of maintenance over time by empowering the business users to control some of the logic.

I also think that the 5% of a business that is unique is decisioning and that most of the top 10 excuses for not doing this are easy to refute.

Technorati Tags: BRE, BRMS, business agility, business rule, business rules, composite application, decision automation, EDM, Enterprise Decision Management, legacy modernization, service, SOA

Posted by jtaylor in Business Agility • Business Rules • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (2) | TrackBacks (0)

November 08, 2006
Live from webMethods - Customer innovation awards

I am attending webMethods Integration World this week and blogging live from the sessions. Day 2 had the customer innovation awards. These will be listed on the webMethods site I am sure (with videos) and were fascinating.

The first one was Johnson and Johnson Health Care talking about how their supply chain has gone from low urgency (shipping to warehouses) to an increasingly just-in-time deliver of medical supplies to doctors for procedures. Use webMethods to measure end to end supply chain, monitor it and respond quickly to problems and issues. Indeed able to be proactive fixing problems with deliveries before customers notice and to increase awareness and understanding of all their supply chain related processes.
The second one was Genentech. Integrating applications to make it easy to support rapidly expanding businesses while still reusing compliant pieces so as to avoid having to re-start approval from the FDA etc. SOA, standardization and simplification were crucial to establish expansion to be supported by IT. Focused on reusable code and have had some success with developing core services and getting high levels of reuse. Adaptability has been improved by building a flexible architecture which they see as important given how constant change was and is. Decoupled manufacutring, new product introduction etc from IT needs. Want to move dollars from IT to research.
The third one was Ahold, about whom I blogged yesterday. Great comment that when you start with innovation and change you don't have many friends but when you succeed, you have many!

I am speaking at 2:45pm on "Automating High-Volume Business Decisions within an SOA"

Technorati Tags: business process management, CRM, innovation, legacy modernization, service, SOA, supply chain, webMethods

Posted by jtaylor in Business Process Management • Innovation • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

October 25, 2006
Using decision technologies to manage application maintenance

My old colleague John Parkinson had a nice column over on CIO Insights today - "How to Manage Application Enhancements". There's some good general purpose advice about how to manage application enhancement but on the second page John touches on some areas where decision technologies, especially business rules, can really help. John says:

"First, recognize that a lot of these requests are for things that users could do for themselves if they had the right tools, a little training and support and a "clean" information environment. Changes to reports, even changes to web pages and transaction screens can often be handled by the requestor, if the information management environment is robust, the platform architecture is solid and the right tools are deployed."

Absolutely right. When it comes to applications business users don't want to wait in a long queue for their day to day changes in particular. One of the right tools for this is the use of a business rules management system to manage application logic. The use of a business rules approach makes the logic more accessible to the business users and allows them to change it independently of the rest of the application for many kinds of changes. Examples include changes to marketing program logic, retention offers, pricing, bundling etc. Be warned, however, that business users don't want to change code, they want to change their business so IT will as John says need to make some invests in a suitable platform.

"IT departments don't seem to want to take this route very often (at least I have seen a great deal of resistance to it) because the necessary cleanup efforts almost always require medium or large changes to be made, and there's no budget for such efforts (or willingness to admit that they are needed)."

My experience also. However, many customers find that the investment in a business rules platform pays for itself very quickly - a bank in the UK for instance felt it recouped its investment in just 6 months through savings in maintenance costs and improved decisions while the DMV here in California reckoned to save 13,000 hours of maintenance work a year(I presented on this at a recent conference too). Getting IT to buy into this approach can be hard but mostly, once they see how many of the annoying updates are being done by the users and how much more time they have to focus on meaty projects, they come to like it. As John says:

"But the productivity gain from an effective self-service strategy is significant, and the improvement in customer satisfaction equally worthwhile. In addition, doing some things themselves soon teaches users to assess the real value of everything they ask for."

So if you have a business users don't want to change code how do you tell where to apply business rules. Well John has this to say:

"Secondly, many small changes cluster around specific sections of application code, so an investment in improving these code sections to aid understanding pays big dividends. Application understanding is the largest single engineering task associated with making a small change to an installed application. Over time, the engineering effort can be reduced by up to half."

And I would agree. This is the kind of application logic that can be effectively replaced by a business rules approach to net a great return. Rather than just understanding and cleaning up this code, you can replace it with a decision engine that can be maintained by the business. In an era where agility matters more and more, this could be the difference between growth and failure.

Enjoy.

Technorati Tags: agile, BRE, BRMS, business agility, business rule, business rules, legacy modernization, ROI

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

October 18, 2006
Live from Delphi - Driving Business Agility with Decision Services

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go. Next up was yours-truly on "Driving Business Agility with Decision Services". I won't comment as I was, as usual, brilliant. Attached the slides I used for you to enjoy. If you want to know more about the California DMV, about whom I presented, you can check out my other blog for this article on DMV.

Powerpoint to download BPIS2006.ppt or use Slideshare:

Technorati Tags: business agility, business rule, business rules, decision automation, EDM, EDM, Enterprise Decision Management, legacy modernization, government

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

October 17, 2006
Live from Delphi - When Your Business Knowledge Goes East

I am attending the Delphi Business and Process Innovation Summit this week and blogging as I go.

Christian de Neef was next up on When Your Business Knowledge Goes East... Key Risks and Benefits of Offshoring Business Critical Applications. Christian gave an overview of various markets for outsourcing and showed how large top-tier companies are moving more and more jobs offshore. One interesting note is that he and several audience members felt that approximately 1.5 jobs are created for each job outsourced thanks to the process style, asynchronous communication etc. That said, many of the companies in India, for example, have strong process maturity around Six Sigma, ISO 9000, CMM etc. Very disciplined on process but this can produce well managed rubbish if you don't watch it. He outlined how outsourcing started with infrastructure then application development now increasingly vertical. Knowledge Processes beginning to be outsourced also. I am not sure I buy this - I think companies are automating these kind of processes rather than outsourcing them (see this section on Business Process Outsourcing (BPO) on my other blog for instance).

His case study was on Axa and their attempt to reinvent themselves by using very fined grained segmentation, targeting with new product packaging and loyalty management (typical insurance strategy - see this section over on the other blog about insurance). They wanted to use a product factory (software to build insurance products), tariff engine (rating engine) and rules engine. But getting the rules right by analyzing code was hard and was outsourced. In this situation the outsourcer said yes too much (underestimated complexity, not enough Axa resources, quality of rules poor). The lesson learned was not to leave the rules in the hands of the outsourcer - well duh! That would be why you should put it in a rules engine! Then your business people can control them and the outsourcer can run the process.

This was more of a case study in how NOT to manage legacy modernization and all these problems are typical when folks try to get legacy rules into a rules engine without thinking about it enough.

Christian was an excellent presenter and I am not saying that just because he gave out Belgium Chocolates! I am speaking tomorrow.

Technorati Tags: agility, BRE, BRMS, Business Rules, decision technology, legacy modernization, BPO

Posted by jtaylor in Business Process Outsourcing • Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

October 03, 2006
Business process, business rules and legacy modernization

I saw this article on bpm.com - Modernizing Legacy Applications. There was a lot to like in this article but I felt like it glossed over some critical issues in legacy modernization using BPM and SOA. Let's consider some of the quotes that struck me

"Legacy systems contain vital business rules embedded within the source code"
"Though programming languages have come a long way the emphasis is still on technology related artifacts rather than business rules and requirements"
"But as important is the fact that many business rules are manual actions by people involved in the process and not programmatic code"

All this is true. But the answer is not to put these rules into a BPM tool but into a business rules management system. Doing this allows them to be managed, coded and maintained at a business rule level. It also allows for business owners to be engaged in managing rules and yet retains the flexibility to package up these rules into various services (in an SOA) or more traditional components (such as COBOL code).

This latter is important as sometimes it is the framework or process implementation in a legacy system that should be retained and logic within that framework that should be exposed as a service and managed as business rules. The California DMV's experience is a classic in this vein - the process of issuing registration has no changed in 30 years but the rules for fees change all the time. Keeping the legacy process, updating the fee calculation engine to use a business rules management system and then deploying these rules not only to the legacy system but also to other, newer systems as a service worked wonderfully.

So do think about business rules in your legacy systems, and about processes hidden within the portfolio of systems, but don't assume you must modernize the process. You may be able to just modernize the decisions.

Technorati Tags: agility, BRE, BRMS, Business Rules, government, legacy modernization, services

Posted by jtaylor in Business Rules • Decision Technologies • Legacy Modernization • SOA | Permalink | Comments (0) | TrackBacks (0)

September 20, 2006
Live form Brainstorm - Business Rules and Requirements Management at the IRS

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

The folks from InScope and SAIC presented next on Business Rules and Requirements Management at the IRS. Now the IRS' rationale for change involved a number of things, all pretty typical except perhaps for the rule engine one.

Cost and schedule overruns
Inconsistency
Decreasing maintenance budget (by 80%)
"rule engine frenzy" - used the technology without understanding rules
Communication problems, often very late in the schedule

Technorati Tags: BRE, Business Rules, government, legacy modernization

To make this work they created an office, methods, standards, tools etc. Did they have any experience first? They tried some pilots to show success and tried to learn themselves also not just use consultants. Also set up a requirements management office but merged them into one as there was too much overlap. The separation between them did not help and having one office, taking a holistic approach and maintain common models and traceability. They had to help the IRSunderstand difference between business rules and requirements. This is something about which I have blogged repeatedly. The presenters argued that there is similarity - both trying to extract business knowledge to help build the right system. That said, they are quite different, and the presenters two key differences seem right:

Requirements describe the system required where business rules declare the approach the business should take.
Business rules live based on cause - regulation, policy etc. Requirements live with the system.

They decided that to make this work at IRS they needed to adapt the existing methodology to handle business rules, something I think is a best practice. Business rules still need a proper project and systems framework. They also focused on organizational, location, process and rule models as a set. On the rules side they built a hierarchical model (not sure that works but it is probably OK for a logical model), dependencies (although this is mostly documentation as rules are declarative so modeling dependencies can be redundant), conceptual terms etc. They then linked to the process model but this seems to make the dependencies redundant. They also needed to put out a Requirement Statement so figured out how to produce one.

Was the management of requirements and rules a cause of confusion?

The presenters had some good advice for introducing new approaches like this:

Change management was, of course, a big issue. Need to build relationships, take the time to introduce ideas gradually to key people helped promote the ideas.
Staged, planned introduction of idea with multiple ways to communicate and included successful projects as part of the communication.
They also had to handle the "been there done that" mentality that this is just another new idea and will go the way of the last one. Need to show you have learned the lessons and take the time it takes.
Don't try and make the method/approach perfect before starting to use it

The approach seems to have helped the IRS get a grip on some of the duplicate work, reuse artifacts across projects, improve review quality and done well enough to get new projects to want to take the approach. It is still a very manual process and no automation yet but it seems like they made some good progress.

Posted by jtaylor in Business Rules • Legacy Modernization | Permalink | Comments (0) | TrackBacks (0)

September 19, 2006
Live from Brainstorm - The vision for Business Rules

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Next session was Barbara von Halle (who occasionally blogs on my other blog) on The Vision for BRS: What You Need to Know In 2006

Barb starts by pointing out that rules can be developed, even though nothing has been defined by asking about baseball. She points out that a phrase like "3 strikes and your out" implies all sorts of things like what a "strike" is, who this rules applies to etc etc. She then walks through the example to show how you harvest rules e.g. all the rules for a batter being out, and that although baseball has a very complete and consistent rules most businesses will have contradictions and omissions. The end of the process should be a complete understanding of how the business operates.She goes on to talk about a recent KPI study that found 5 motivations for business rules:

Agility (see the blog section on business agility)
Knowledge Retention
Compliance (see the section on compliance)
Consistent Decisions
(After the fact) A stronger Business-IT partnership

and four approaches to using business rules which she illustrated with some great examples.

Business rules harvesting and then input to the SDLC. Often by mapping use cases to business rules as described here
Business rules harvesting and then input them into a Business Rules Management System
A case study for the first two of these found that some 70% of the rules were "wrong" - the code ran wrong and was worked around, the code did what was intended but there was a mistake.
Business rules harvesting from legacy systems for legacy modernization (see this section on legacy modernization)
She noted here that thousands of rules found in the code for one client mapped to just 150 "real" business rules and that legacy mining is really only a good idea when there is no alternative!
Business rules harvesting and business transformation by changing just manual processes or by telling IT to make changes
Can be done very fast to show the value of focusing on rules. The case study for this showed that this worked and helped generate interest in business rules management.

Interestingly some of these involve business and IT and some only require the business. Barb wrapped up this section talking about the Rule Maturity Model and how most companies working towards Agility (level 2) and Consistency (level 3) which require both a focus on business rules and some technology. She also emphasized that rule management can fail on the business side (not the right rules) or technical side (not working right.

Barb has a model of some 10 types of business rules tools. Personally I think this is a little extreme - I would not separate authoring, analysis, testing and execution into 4 tools as I think these are all tightly coupled parts of a real Business Rules Management System. I do think that having a way to manage strategy and map it to rules and a way to map rules back into the requirements process is useful. Rule Mining is clearly a separate tool, as are analytic tools for deriving rules. I might say then that there are four:

Business rules management system with authoring and repository
Strategy and process management tool
Rule Mining tools (code and data mining)
Rules as requirements management tool

Barb went on to talk a little about how decisions, and rules, can and should be mapped to multiple processes and use cases to emphasize the importance of traceability.

Technorati Tags: agility, BRE, BRMS, Business Rules, legacy modernization, rule maturity model, RMM

Posted by jtaylor in Business Agility • Business Rules • Compliance • Legacy Modernization | Permalink | Comments (2) | TrackBacks (1)

Live from Brainstorm - Integrating Architecture into Development

I am attending the Brainstorm BPM/SOA/Rules event in Washington DC this week and blogging as I go.

Second session was Richard Burk from the OMB (Office Management Budget)on Integrating Architecture Into the Development of Cross-Agency Lines of Business. Dick leads the development of a business and technology framework for e-gov.He is focused on getting different agencies to use common elements of enterprise architecture across the large IT budgets involved in government. He noted that he has a Board of Directors of 535 (House+Senate) which explains a lot :-) Seriously though, he went on to explain how priorities tend to be set politically and how this has implications for architecture as these priorities drive 10,000 programs that can easily be isolated and so create problems. Most current issues in fact cut across agencies and involve cooperation between agencies, state and local government and commercial bodies. Rarely does an initiative or bill manage this, hence the OMB architecture work on Enterprise Architecture to make these things work together. He recommended "Enterprise Architecture as Strategy" by Ross, Weill and Robertson as an overview of this approach.

One of the first issues is one of semantics about what everyone is talking about. He introduced the Federal Enterprise Architecture reference models - Performance Reference Model (what am I trying to achieve), Business Reference Model (what do I do and for whom), Service Component Reference Model (what services do I need), Data Reference Model (what data for these services)and Technical Reference Model (technologies to enable all of this). A functional view of the federal government based around the Zachmann Framework (albeit slightly simpler). He explained some architecture principles that drive overall choices for federal government programs - these were great, nice and high-level but good guidance e.g. "the federal government is a single, unified enterprise" or "the federal government focuses on citizens". Seemed very "well, duh" but I liked them as it amazes me how often this kind of stuff is not written down or agreed. Most companies could take a lesson from the Feds here. Dick gave some great examples of how a simple statement drives behavior by drilling into the "federal architecture is mission-driven" and showing how it leads to things like only monitoring improved (not as-is) processes for instance. He also talked about how architects must focus on the line of business - what is your business?

To "eat the elephant" they drive down into various service areas - business services that support an agency inside and citizen services that face out (each agency is impacted by some citizen services) as well as cross-service facilities like records management or security. These can then be applied iteratively to the agencies and their lines of business and work both top-down (adopting standards) and bottom-up (driven by needs in specific areas) to derive an Architecture Portfolio. Specific investments are made in the context of these architecture outlines to create an Investment Portfolio. Planning results in a Transition Strategy and all of this must have end to end governance. Separating the architecture from the budget process and getting it up front to guide everything and focus investments was key and took a while, especially given the desire to hang on to money allocated to specific initiatives. One of the nice things he talked about was various aspects of initiatives to see how well they are going. They were:

Completeness (how much of it is done)
Usage (who uses it, for what, what percentage)
Results (what return on this investment)

I liked this as it seems to me to be a great set of measures for any initiative. This year he has a lot of cross-agency initiatives (24) and they are developing a catalog to show how these support the services each agency uses while giving each agency 6 months to apply it and figure out how to request the money they want for NEXT year. OMB has to verify that the investments match to the architecture so that the budget process is linked with the architecture. This stops the architecture from becoming an interesting experiment and makes it part of how agencies build and use budgets. Very cool.

This did not really fit with any of my categories but I thought the legacy modernization was the best, given how effective his approach seemed likely to be as a way to manage large scale legacy update