This Application Development Strategies White Paper (registration required) published by Butler Group about a year ago came by my desk the other day. Three issues caught my eye as they seemed to be related to the use of decision technologies:

Lightweight or Heavyweight Development?

The report talks about how to decide which projects are deserving of more "rigorous" approaches and which ones should focus on time to deliver and agility. It goes on to talk about the need to have more formal documentation and design materials for systems that have a maintenance "tail" as the original developers may well have moved on. It seems to me that this is a little bit of a false choice. Just because a system is needed quickly or that "better is the enemy of good" does not mean it will not have a maintenance tail. How many systems are in your company today, still being maintained and tweaked, that were built as "quick fixes" years ago? Even if you are building systems quick and agile you should build for maintenance. Business rules is a core technology for this kind of long-term business agility and for building "change time" into your systems.

.NET and Java

The report notes that both .NET and Java are being used to development critical systems. It seems to me that keeping your core business logic in code is a bad idea. Let's face it your core business logic would not change just because you moved from .NET to Java so why tie it to one platform or the other? Use of a platform independent business rules management system would let you keep this logic as a corporate asset and deploy it as needed to your various applications.

Rich Internet Applications

The report notes that "Rich Internet Applications" are a likely growth market. In the year since the report clearly this has turned out to be true. Now RIAs can be all about the quality of interaction (drag and drop etc) but they can also be about making the client interaction "smart" and having it act more like an intelligent interviewer than a dumb computer system. Business rules technology can be applied to this kind of problem to build rules-driven smart user interfaces.

There are other reasons, of course, but it struck me as interesting that some of these general trends, identified over a year ago and clearly still relevant, pointed so directly to business rules and a decision technologies approach.

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

1. Rules should be written and made explicit

• Rules are not the same as other requirements
• Rules should not be buried in code or SQL
• Rules your operational systems need should be in a Business Rule Management System

• Rules should be as expressed in language as plain as possible and no plainer (with apologies to Albert Einstein)
• If you can hide complexity to make rules easier to understand, do so

• Don't bury your rules in your BPMS, keep them separate

• Write your rules against the objects you are managing already

• Rules that don't do anything are not very helpful
• Rules can take or recommend action

• Policies, procedures, regulations, strategies
• Remember these should be business rules and so should matter to your business

• Rules need to be managed in a real repository
• A rule repository needs version control, access control, auditing etc

• "One rule to rule them all"

• If you can empower the business users to write the rules do so
• If you can't get the business users to own the rules, make sure they can collaborate on them
• Remember they don't want to write rules, they want to run their business (so make it easy for them)

• Putting rules in a BRMS is the first step. Treating them as an asset to be managed, reused and exploited is where the value comes
• Management requires technology and procedures and policies.

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

I saw this week that Teradata has launched a new Retail Advanced Business Analytics & RFID Lab. The lab is designed to help Consumer Branded Goods and Retail companies analyze data captured by radio frequency identification (RFID) applications across the supply chain and show how their data can be used in innovative ways to derive incremental business value. Focal points at the lab include deep analytics, predictive modeling, data mining, and RFID data analysis. Analytical results are presented using data visualization technologies.

"The lab is dedicated exclusively to addressing the everyday business management issues faced by retailers. Our customers recognize that the ability to find connections between detailed-level data gives them a competitive advantage," said Bill Franks, Teradata director of retail analytics.

All this sounds great but RFID can, if folks are not careful, suffer from the "so what" problem. I can capture huge amounts of data and analyze it to my heart's content but unless I decide to act differently as a result it is useless. Hence "I have all this great RFID data. So what?".

Some of the decisions that might be impacted are strategic in nature and so analysis and visualization are key. This means helping the folks who, for instance, decide on new store locations effectively see the picture created by all the data.

Other decisions, however, are operational and the data collected will not help unless it can be acted on by operational systems or by staff not trained (or event trainable) in analytic techniques. For example a shipment's data stream shows it is running late. Having the tracking system inform the destination of this fact is a simple kind of operational action (typical of a business activity monitoring approach). A more useful operational decision would be to decide how to respond to this fact automatically. This might involve figuring out if any alternative shipments can be sent by a different route to arrive earlier and, if so, ship any such shipment with instructions to make sure it does not go by the same route as the delayed shipment. Meanwhile the system should re-direct the delayed one to a less urgent destination by changing the instructions delivered to the staff who next handle the shipment (perhaps at a trans-shipment point). Al requires an ability to make a business decision, influenced by analytic models of probability and by rules from contracts and shipping companies, in real-time.

This kind of operational decision-making offers great potential for the use of RFID data. Don't let a focus on visualization or back-room analysis blind you to the value of automating and improving operational decisions.

Posted by jtaylor in Business Activity Monitoring • Business Rules • Predictive Analytics | Permalink | Comments (1) | TrackBacks (2)

I was talking to some folks at Sun about Sun Preventative Services' use of Ipedo's EII product alongside the Blaze Advisor business rules management system in their Risk Analysis System (SRAS). This struck me as an interesting use of two technologies - EII and business rules.

The solution is focused on preventive maintenance of all computer hardware and software as a way of minimizing IT costs.  It continuously measures Sun customers’ IT assets, takes preemptive actions when required and provides recommendations for optimizing operations.  This kind of real-time "self-service" means customers need to call for support less often (helping both Sun and their customers reduce cost), have less down-time and have better performance.

Doing this took real-time data integration to combine system configuration data, information on software releases and patches, information on customer support contracts and SLAs, information on current support activities, as well as customer contact and account information. This is where the EII software comes in. It also took the automation of complex decision-making using this information and the engagement of folks who understood the technical problems in the process of documenting the rules. This is where the Business Rules Management System comes in.

Data first. The data used by the system is geographically distributed, with some information coming from Sun’s internal systems and some coming directly from customer systems.  Additionally, it is in multiple formats.  System and patch information is in XML and information on customer contracts and contact details coming from several relational databases.  Ipedo's EII solution pulls data from disparate sources, including rules analysis, and aggregates it.  This includes joining data across XML/Web Services and multiple existing relational databases. A classic EII problem.

Next rules. Aggregating and getting access to the data is just the beginning. You need to take advantage of the information if you are going to maximize ita value. Now you can do this with reporting and dashboards and so on. But if you can use the data to make decisions and recommend/take actions then you can dramatically increase its value. A business rules management system lets you build rules against the objects aggregated by the EII product. In the case of Sun they also built templates to ensure consistent structure of these rules and to allow them to empower non-programmers to collaborate in the definition of the rules. The folks who understand the hardware are technical but that does not mean they want to write code, after all. By taking the expertise and know-how of these folks and turning it into rules, and by running those rules against real-time data from multiple sources, they are able to make the best possible recommendations for their customers.

Now in this kind of system, business agility is key. This means not only being able to change the rules quickly as new experience is gained or new products/patches released, but also means allowing Sun’s customers to change their systems without breaking everything. The EII piece of the puzzle is key in making sure that changes to the data structures are managed separately so that they don't break the decisioning piece. Meanwhile the rules management piece means that rules can be added and changed without breaking anything else. This ensures maximum agility.

EII and business rules management can each add value but they can be compelling as a pair.

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

Beth Gold-Bernstein wrote a piece on Business Activity Monitoring called Speeding Toward Business Visibility. She identified four distinct kinds of BAM solutions:

• Provide real-time monitoring of business events related to Key Performance Indicators (KPIs);
• Provide analytical capabilities and management dashboards;
• Provide complex event correlation;
• Provide predictive capabilities

Now the first two strike me as extensions of Business Intelligence to a more real-time, dashboard-monitoring kind of approach. The others, however, start to move into decisioning. Beth went on to say that "Companies are looking for ways to become more responsive" and this comment made me wonder about the first wave of BAM products. I think they have a problem, what I call the "so what" problem. There is a tendency to assume that monitoring, especially if I can make it more real-time and easier to consume with a dashboard, is somehow an inherently good thing. To this I sometimes say "So what"? If I cannot change my behavior in response then so what? I must make decisions based on this new, real-time, easy to read information for there to be any value in it.

Interestingly Beth goes on to say:

"overwhelmingly the most important was the ability to make the company more responsive and move from reactive to predictive mode – to be able to anticipate problems before they become problems.
This capability requires real-time and predictive capabilities such as neural networks and inference engines."

So there we go - you must be able to become more responsive and more predictive. This is the "what" in "so what". As Beth notes you need to use predictive analytics to help identify trends and to do so not in a report that a person can see but in an executable format that a system can use. Likewise you need an inference engine or rules engine to turn the information you have assembled, and the predictions you have added, into actions - "If this is true and this is true and this is likely to be true in the future then do this and this and this".

Beth concludes with some comments on what's important:

"the most important technical capabilities ... complex event monitoring and reporting was the most important capability (31%), and management dashboards was second (27%). Predictive capabilities and analytics were tied for third with 11% each."

So this ability to process events, potentially complex ones, and (presumably) do something is key. This is why effective BAM needs decision management - you must be able to automate and manage the decisions that are impacted by the data that comes from monitoring these activities.

There's more on this on my other blog here and here.

Posted by jtaylor in Business Activity Monitoring • Business Rules • Decision Technologies • Predictive Analytics | Permalink | Comments (0) | TrackBacks (0)

A colleague pointed me to this article - Southwest Airlines Weighs Assigning Seats - and the comment "Southwest officials have openly considered the idea for years, but the $5 million upgrade of the reservations system will for the first time make it possible".

This is an example, and perhaps an extreme one, of why business agility is so key in information systems. In this case, as it is so often, the determining factor in when a company makes a change to how it does business is not when it thinks it should but when it is able to change its systems to support the new approach. In survey after survey, we find that this is increasingly the case with companies reporting averages of "months" to make changes with multi-year waits not being uncommon.

So what can you do to make sure that the new systems you are building today are not going to be the roadblocks in the way of progress for your company in the future? Several things:

• Architect systems on the basis that they will need to change, because they will. Not every piece of a system will need to change the same amount so try and identify "high change" pieces during the design and architect them to be particularly easy to manage over time using business rules management technology. I blogged about this here and particularly like Roy Schulte's comment that systems must be "built to change" not "built to last".
• Remember that well designed systems are just as likely to need changes as poorly designed ones. Poorly designed ones need changes to correct them but well designed ones get more use and will need changes because the world keeps changing. Maintenance work is not something that only happens to bad programmers.
• Find ways to engage IT and the business in a collaborative process to build and maintain applications. Don't throw requirements or code backwards and forwards across a metaphorical wall but choose technologies and approaches that help them work on the system together. Business rules management systems, templates, good testing and simulation tools and methodologies that emphasise joint development and flexibility (like agile development) are all key. I had a great conversation with Scott Ambler on rules and agile development, reported here.

I blogged about a nice article on the inevitability of change here and about why improving requirements won't help here.

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

Reading Sandy's blog, as I always do, I saw her mention of this Gartner podcast. This made me think about decision management in insurance so I though I would write some more about it.

Insurance has seen a huge growth recently in the move to adopt a decision automation approach. the reason for this is quite simple - insurance people think in decision-centric terms. They recognize that the underwriting decision, pricing decision, claim payment decision and so on are key to profitability. In addition they are trying to increase the number of transactions that can be managed "straight through" and this means automating these decisions. To make these decisions well, and automate them in the process, insurers are adopting two key technologies in combination (as noted in the podcast) - business rules and predictive analytics. The combination of these is known (to some at least) as Enterprise Decision Management.

The technology helps insurers solve a number of problems:

• Collecting the right data the first time is hard because different data is required depending on the circumstances and so as data is entered it changes the remaining data required. It is not unusual to go back and forth multiple times to capture the required data - costly and time consuming. Rules-driven user interfaces, taking advantage of smart forms and AJAX combined with automation of the decision help ensure this is "once and done".
• The decisions are heavily regulated and so not only must each decision follow a large number of guidelines and policies, it must also be possible to show how the decisions taken conformed if/when a regulator asks. To make things more complicated, these regulations are often different by state and country. Business rules technology allows this to be managed and then reported on.
• Tiering and segmentation are key to pricing and risk management. As this has become more and more sophisticated and as more and more data is available it has become impossible for an individual to consider all aspects in a way that allows fine-grained segmentation. Predictive analytic models can automate this complex risk assessment and allow for much finer-grained decisions.

These problems are often found in less decision-centric industries and these are adopting the technology more slowly. It's a pity as the insurance industry, not typically an early adopter, is really showing the benefits of automating these key decisions.

There is more on automating decisions in insurance on my other blog where I also posted on the value and usage of location intelligence.

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

Quick note to say that I have started tracking my podcasts. There are three but one seems particularly relevant to this blog (if a little long) - SOA and business rules for Officer Outlook

If you want to track my podcasts over time (and there will be more but not likely soon), then subscribe to the podcast feed at Decisions Podcasts.

Enjoy.

Posted by jtaylor in Business Rules • SOA | Permalink | Comments (1) | TrackBacks (0)

In The Mustang Meets the Rhino: Scripting in Java 6 John Ferguson Smart discusses how JDK 1.6 / JSR-223 allows for the scripting of business rules. This made me think about the relative merits of scripting and business rules. Let's start by considering some of John's comments:

Scripting languages such as PHP, Ruby, JavaScript, Python (or Jython), and the like are widely used in many domains, and are popular because of their flexibility and simplicity. Scripts are interpreted, not compiled, so they can be easily run and tested from the command line. This tightens the coding/testing cycle, and increases developer productivity. They are generally dynamically typed, and have expressive syntaxes that allow an equivalent algorithm to be written much more concisely than in Java. They are also often fun to work with

Well perhaps. What about the total cost of ownership of a portfolio of systems developed this way? Scripts are hard to manage across the enterprise (they tend to be very local), hard to control, and so even if they make maintenance easier (by being easier to change and by being expressive), one has to wonder if they really help in terms of the overall maintenance burden for an organization (as distinct from the maintenance workload of an individual programmer). He goes on to give examples of when scripting is a useful approach:

providing extensions to your Java application so that users can write their own scripts to extend or customize the core functionalities. Scripting languages are both simpler to understand and easier to write, so they can be ideal to give (technical) end users the possibility to tailor your product to their needs.

But what about less technical ones? And how would you manage this extension process? What if it impacted an area of your business with tough compliance requirements - would the individual edits with scripts stand up to regulatory scrutiny?

Embedded JavaScript can be used for a variety of purposes. Since it is more flexible and easier to configure than hard-coded Java, it can often be used to code business rules that may change often.

Now we are at the meat of the problem - should I use scripting to implement business rules, because they are rapidly evolving or not? He goes on to give an example:

The following example illustrates the premium calculations for an imaginary insurance company. Any driver less than 25 years of age will pay 50% extra. If a driver over 25 has a no claims bonus, the company offers a 25% discount. Otherwise, the standard premiums will apply.
This rule could be implemented using a JavaScript expression as follows:

        ScriptEngineManager manager
                   = new ScriptEngineManager();
        ScriptEngine engine
                   = manager.getEngineByName("js");
        engine.put("age", 26);
        engine.put("noClaims", Boolean.TRUE);
        Object result = engine.eval(
            "if (age < 25){ " +
                        "    riskFactor = 1.5;" +
                        "} else if (noClaims) {" +
                        "    riskFactor = 0.75;" +
                        "} else {" +
                        "    riskFactor = 1.0;" +
                        "}");
        assertEquals(result,0.75);
    }

Well this certainly looks better than Java. But would it still look good if you had hundreds or thousands of such rules - typical for an insurer (see this case study for example)? How does it compare with a typical business rules management system's syntax (Blaze Advisor used here):

Customer's age = 26;
Customer's noClaims = TRUE;
aYoungDriver is any Customer where age <25;
if Customer is aYoungDriver then Customer's riskFactor=1.5;
if Customer is not aYoungDriver and Customer's noClaims = TRUE then Customer's riskFactor=0.75;
if Customer is not a YoungDriver and Customer's noClaims=FALSE then Customer's riskFactor=0.5;

This is only one way to implement it but not only is it clearer as is it would also allow templates to be created to make it even easier for business users to maintain these rules and the rules would be stored in a versioned repository. The use of an inferencing engine would ensure that the rules that were relevant were evaluated and not those that were not, improving performance when large numbers of rules were present.

So would I recommend using scripting for managing business rules and business decisions? Well, no. I would recommend using a business rules management system. It seems to me to have many of the key benefits of scripting with some additional ones:

• The separation of decision logic from mechanical implementation gives you more flexibility to make changes with minimal or zero impact on basic systems operation.
• The syntax is even more understandable to business-level people, leading to better business/technical cooperation, reduced implementation times, and fewer opportunities for interpretation errors.
• Business rules management systems have predefined rule replacement features to handle system updates without interrupting service to application users.
• Rule management templates can be created to let users update, view, or create rules in a controlled manner without knowing anything about syntax or code.
• The rule engine can quickly look through large sets of rules, finding the proper ones to apply based on case-specific conditions. No code is required to specify which logic should be fired in which order.
• Last and most importantly, rules are stored in a rule repository allowing them to be managed, shared, versioned and controlled.

Scripting tools have their place. Automating business rules and business decisions is not one of them.

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

I recently saw this interesting post on the EDS Next Big Thing Blog - Effective Re-Use - Using SOA to Preserve and modernize your IT Investment. It made me think about the reuse potential of business rules. I thought I would start by editing their graphic to show where I think business rules fits:

As you can see I think business rules offer the potential for both project-level and enterprise-level reuse. Clearly rules can represent core business decisions, this is their most valuable use, and as such belong in an enterprise governance framework for reuse at a business level. They can also offer the potential for project-level productivity gains by allowing standard or common rules to be reused more tactically.

I believe that business rules offer a unique combination of reuse and business/IT collaboration that enalbes them both to make IT more effective at a project level and the business more effective at an enterprise level.

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

There was a nice write up on business rules in Computer Business Review - The importance of business rules - and I thought I would highlight some of its key points for those of you perhaps less familiar with business rules and their value proposition.

Essentially business rules are the language for making an organization's strategy actionable. Business rules differentiate a company's services from its competition, make it easier to manage what decisions were made when and provide "intelligence" to your systems and processes.

Why is this good? Well, complex rules are not only difficult to code into applications, they are also a nightmare to maintain using traditional coding. Likewise if you have lots of rules, rules that change often or rules that require domain expertise to understand then writing traditional code can be a big problem. Write rules in Java or C# and you are just creating tomorrow's legacy code, even if you do embed it in a service.

That said, implementing rules has to be accompanied by organizational change management, where both sides accept the balance of power. You are moving from an environment where the business "throw requirements over the wall" to IT, to a collaborative one where they work together. As the CIO of Egg, a UK-based online bank that has implemented BRMS technology from Fair Isaac, said

"The biggest single issue we faced was that of ownership: convincing the technology community that business rules could be treated much the same as content and managed by the business users and not IT"

The other key factor and this is really the point of the whole blog, is to think about business rules management systems as part of a universal decisioning backbone for an enterprise, not as just another programmer productivity tool. Only by focusing hard on operational decisions and figuring out how and why to automate them can you maximize your return.

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

I saw this interesting piece of research by Gareth Herschel over at Gartner - How to Tackle 10 Excuses Not to Invest in CRM Analytics- and it made me think about the excuses I get given for not adopting decision technologies and automating operational decisions. In fact they were so similar I decided to ruthlessly steal Gareth's ideas. Here goes.

1. I would like to invest in decision automation, but my manager just doesn't get it
   This typically comes because "decisions" are too generic to focus on. Instead, focus on how it can help with more precise pricing, customer retention or cross-sell offers, better consistency when coping with staff turnover or multiple channels, better agility when trying to change to respond to competitors or new marketing campaigns?
2. We tried it, but didn't get any results
   Over-hyping of decision automation along the lines of the old expert-system fiascoes is still out there but more problematic is misuse of the technology. You can get the business and IT to collaborate on managing the decision logic and you can inject the results of analytics into decisions to improve them and you can manage decisions as corporate assets. You can also use business rules as a programmer productivity tool, regard analytics as something you use to generate reports and treat rule reuse as something for another day. Get these things wrong and you won't get results.
3. We tried it, but didn't get the results we expected
   This excuse gets used when no-one managed the change implications of automating a decision - how will it change call center rep training or the website, how will the business users be engaged in managing business rules and how will IT integrate testing and deployment with rules being edited by business users? As Gareth notes, data quality and availability often derail the analytic component.
4. We're doing fine as we are; why fix what isn't broken?
   The core decision automation benefit that is being overlooked here is agility. Even if everything is going fine, how quickly and cost-effectively could you respond to a competitive issue, new regulations, a new channel, or some other major change? Decision automation technology like business rules helps reduce the odds that a change will derail you.
5. We just bought an operational system and want to get that established first before making any new investments
   Why establish processes using the new system that involve time-consuming, costly, imprecise manual decisions? Why implement a brain-dead process? Inject decision automation now to streamline your processes, make the most of the data you have and reduce future data quality and completeness problems.
6. Employees wouldn't know what to do with decision automation if they had it
   Decision automation must be delivered in the context of the employee's work. If there is not a good "cognitive fit" for the decision automation then it won't help. If the decision automation is used to deliver better decisions when employees are looking for them, then it will.
7. We are too busy this quarter - maybe in the next planning cycle
   Decision automation can refocus energy from maintenance work to new development. Investing now can free up resources in all the subsequent quarters so you can actually start getting ahead, rather than further behind.
8. It takes too long to get results
   Nope. Spoke to one of my customers last week who went from 100% manual review of auto policies to 1% manual review in less than a year. Start with low-hanging fruit and show the benefit.
9. We already automate decisions
   In code (that the business can't read), script (that IT cannot manage) or what, exactly? Is the logic that makes decisions externalized and managed? Can you find it and reuse it?
10. We are totally in need of decision automation, but it is someone else's problem
    The team of programmers is available but the budget to invest in decision automation is not. It is easier for some projects to write the next generation of legacy code rather than fix the decision automation problem. Establish the true cost of the "old way" and create an urgent need to change.

Decision automation works and if you are working with systems that handle interactions with customers, you should be going this.

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

This article on modernizing COBOL Code Rebuilding the legacy -- modernizing mainframe code caught my eye recently. While there was much to like, a number of comments made me think about how different it would be if the companies worrying about COBOL maintenance and modernization would think about business rules. For instance...

"With a shortage of Cobol programming talent looming in the next decade and a clear need for greater software agility and lower operating costs, IT organizations have begun to make transition plans for mainframe applications. The trick lies in figuring out which applications to modernize, how to do it and where they should reside."

Now if you knew about business rules, you would know that not all parts of an application are created equal when it comes to agility and maintenance work. Some pieces of an application have lots of rules, complex rules, rules that change often or rules that need business expertise to understand. These pieces need to be modernized if you are going to deliver agility and reduced maintenance costs. Others do not - they can probably be left just as they are. The question then is not "which applications to modernize" but "which pieces of which applications are giving me pain and costing me maintenance dollars" and should therefore be upgraded to reduce my TCO.

"An increasingly common strategy for these applications is to leave the Cobol in place while using a service-oriented architecture (SOA) to expose key interfaces that insulate developers from the code."

Well maybe. SOA has lots to recommend it but most legacy applications are absolutely not structured so as to make good services. You probably don't need to reuse the whole application. Often the piece that needs to be shared is the business decisioning piece so why not modernize that, expose that as a service and go on from there?

"very few of his clients have been successful at completely rewriting large-scale applications."

Well duh! Everyone has seen this in action. The bigger the project the harder the problem. So why not reduce the size of the modernization project and only focus on the pieces that will show an ROI - the high maintenance, high change pieces?

"Doing a rip-and-replace is a big thing. There are things you can't afford to re-engineer, and they will probably always sit in the place where they were developed."

Absolutely. But just because the application needs to stay where it is, it does not mean you have to tolerate huge maintenance costs for making changes. Find the pieces that need changes often, make them easier and cheaper to maintain with business rules and go from there.

"While there is a shortage of highly trained mainframe programmers, many existing Cobol applications are very stable and don't require much maintenance"

But what about the ones that AREN'T stable and do require maintenance? I need to modernize those don't I? But why would you want to replace legacy code with the next generation of legacy code by simply re-writing them on a new platform? Wouldn't I want to change them to require less maintenance work, to empower the business to collaborate effectively with IT in the change of thoese systems, to build them, in other words, to change rather than to last? I would. Wouldn't you?

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