Thinking in Rules.

Thoughts and observations about business rules in the real world
by Theresa O'Neil

Why Aligning IT With the Customer Isn’t a Complete Recipe for Innovation

A colleague recently shared an intriguing article from Information Week, "Global CIO: Suicide Strategy for CIOs: Aligning IT With The Business" by Bob Evans. The gist of the article is that (ideally) IT is an integral part of the business and therefore alignment with “the business” is superfluous: IT should be aligning itself with customers. At first glance, the article may seem to be advocating that IT work directly with customers and not worry about other parts of the business.

As Vice President of Business Development, Theresa O'Neil has responsibility for developing worldwide partnerships with ISV, reseller, services, and technology organizations. Prior to joining InRule, O'Neil was an executive at IBM Corporation, where she was responsible for developing the product and marketing strategies for the IBM Content Management and Discovery business. With a focus on growing new businesses, O'Neil has led marketing and strategy for successful software companies of all sizes. She is also a loyal fan of the Chicago White Sox.

But what the author’s really saying is that IT needs to intertwine with the business and then together the business and IT will align with customer and market need: “IT teams [that] are intertwined with the business and are accelerating and enhancing connections with customers instead of sitting back and waiting to be told by someone else what's happening out in the world and what, in turn, the IT organization's reactive response should be…”

A concept missing from the article is how applications are developed and deployed (details, details). In a truly intertwined model, responsibilities for developing and maintaining applications begin to change as IT focuses on innovation and allows the business to take on more responsibility for business applications. As intertwining builds trust, IT can and must increasingly empower business users to directly author and maintain portions of applications.

One of the examples of technical leadership and business innovation is an insurance company that’s launched an online business where customers can customize their own policies. Business rule technology is often used for insurance product customization; it allows subject matter experts (like underwriters or actuaries) to directly author and maintain the underwriting logic that powers insurance policy process from underwriting and pricing to policy issuance, claims management and policy renewal. IT no longer has to spend its time making constant changes to business logic. They are free to focus on deep technology issues—and innovation.

So the story of this insurance company’s innovation isn’t just about IT aligning with the customer. It’s about IT intertwining itself with the subject matter experts and empowering them to take responsibility for key parts of the application development and maintenance process by owning the business logic they understand best. If credit scoring rules change, who is better suited to maintain this than the credit analysts? IT is then free to focus on the technical infrastructure that will support today’s online business and whatever the future may bring. By empowering “the business” to own the logic they understand best, the smart CIO makes applications more flexible and allows his team to focus on innovation.

Intertwine, Align, Empower, Innovate.

How to Leverage Your SharePoint Investment to Manage Complex Business Processes

With more than $1billion in sales and more than 65% of organizations implementing SharePoint 2007 within six months (Microsoft Leads A Fragmented, Growing Content Management Market, June 22 2009, Forrester), SharePoint is moving toward ubiquity.

Many organizations (including my own) use SharePoint for document management and portals. Organizations whose enterprise agreements with Microsoft include large SharePoint licenses are now looking to see how they can leverage their investment in SharePoint beyond simple document management. And Microsoft is eager to drive that deployment in order to grow SharePoint’s footprint.

In the Network World article “SharePoint Solutions: Smart Investments in a Recession” , Susan Hanley lists three reasons to invest in SharePoint during hard economic times. The number one reason is around business process automation.

“Solutions that automate business processes, especially those processes that are designed to replace lost workers, can help organizations deliver value with fewer resources. If an organization already owns SharePoint (and we all know that many do), building an automation solution on the SharePoint platform may be easier to justify than an expensive investment in business process automation software.”

I see the potential of Business Process Automation and the potential of SharePoint. However, I also know that SharePoint is a platform; it’s not a Business Process Management (BPM) solution. In order to manage complex processes, custom programming is required, making the initial deployment and maintenance costly. I’ve spent the last several months exploring how to help organizations take advantage of their SharePoint investment in a way that delivers better time to value and enables them to maintain business processes themselves, without costly consultants.

My starting point was that business rule technology can help streamline complex processes. However, I knew that there was a layer of process automation capabilities that was needed to extend SharePoint’s core capabilities. ShareVis www.sharevis.com is software that builds upon SharePoint to automate document and forms management. InRule Technology has partnered with ShareVis to extend and enhance SharePoint to automate complex processes without custom programming.

Read about the power of this combination Extend and Enhance the Power of SharePoint®and stay tuned for more information.

Business Rule Standards: "Interesting"

Occasionally I get asked about rule standards. Recently a prospective partner, who acknowledged that there were not rule standards today, but thought rule standards were inevitable and imminent:  

“…proprietary knowledge (rule) representation formats will be converging toward a common standard, and this will allow for easy portability of a knowledge (rule) base from one platform to another. A wide adoption of SQL by database engine vendors, or growing popularity of PMML [Predictive Model Markup Language] for representation of predictive models, make good cases for a similar type of standard (for instance derived from the current OWL/SWRL)  to be adopted sooner or later by rule engine vendors.”  

The idea of rule portability and a standard language is indeed an appealing one. There are a few standards currently in development; the front-running standards for business rules metadata are RuleML and the Semantics of Business Vocabulary and Rule (SBVR).  However, the way in which these standards are being developed indicates that their being the standards vendors will adopt is highly unlikely.  

Compare the birth, evolution, and adoption of RuleML and SBVR with that of SQL and PMML.  

SQL was developed by IBM, a leading information management vendor. Another vendor, Relational Software (now Oracle) saw the potential of relational database management systems and SQL and released its own SQL-based database. IBM and Oracle invented and developed a market for products based on SQL. They, along with Microsoft, remain market leaders.  

PMML is developed by The Data Mining Group (DMG), an independent, vendor-led consortium. Full members of the group include IBM, MicroStrategy, SAS, and SPSS (soon to be part of IBM); Microsoft, Oracle, and SAP also participate in the group.  

By contrast, RuleML is an academic body. Most of the participants are from prestigious universities, not vendors. IBM, always a leader in technology standards, does send a member, but he is from the TJ Watson Research Center, not Websphere-ILOG. None of the major business rule technology vendors—Corticon, FICO, IBM-ILOG, InRule, Oracle—participate in RuleML.  SBVR is being developed by the Business Rules Group within OMG. The Business Rule Group members are primarily consultants who work with business rules, but, again, none of the members is from the leading business rule technology vendors. Likewise SWRL (which I’d never heard of and doesn’t seem to have had any activity in 5 years) has no vendor participants.  

Technology standards must be developed and driven by the leading vendors in the space or they will not be adopted. Not because we vendors are smarter, but because vendors will develop and adopt standards that will benefit our customers and help grow our businesses. Vendors don’t drive and adopt standards just because we’re good guys, but because it helps growth our business: it’s strategic.  

Business rule technology vendors are constantly introducing new capabilities to benefit our customers and grow our businesses. And while rule standards are “interesting,” they just haven’t bubbled up to the top of most customers’ requirements list. When the market is ready, business rule standards will emerge, but they will most definitely be driven from the vendor community.

The Rules for Beautiful, Flexible Business Processes

Jim Sinur’s insightful blog entry BPM Not Only Saves Money: It is Visually Appealing states one of the more guttural appeals of BPM: “I think deep down we find BPM visually appealing.” BPM is like the guy who goes to the gym every morning while we’re checking email: muscle-bound and handsome.

As business users define processes, they may find that defining all the permutations around decision points can create a workflow that is unwieldy, both in terms of understanding and ability to maintain, execute, and optimize. The process can get—well—ugly. Suddenly, Mr. Fitness is extremely inflexible from too time in the weight room (and orange from too much time in the spray tan booth, but that’s a whole ‘nother topic, as they say).

For example, a workflow may be defined to execute the very complex logic that determines eligibility and pricing for insurance. With the permission of my good friends at ShareVis—whose software helps you create, deploy and maintain very beautiful processes (www.sharevis.com)-- Figure 1 shows how such decision logic, when embedded within a workflow, can make a process very complex.

For example, a single, high-level decision point called “Determine Eligibility” will encompass many underlying decisions and calculations. Figure 2 shows how this high level decision point within the workflow reduces the complexity of the workflow shown in the previous graphic. In this case, the ShareVis process calls InRule to manage and execute the decision logic.

By embedding every decision point within a workflow, organizations are not only making ugly processes, they’re unintentionally embedding decision logic—thus moving away from the vision of SOA. To help streamline business processes, organizations must identify decision logic and manage it differently from flow logic. By externalizing the decision logic from the workflow, a business rule engine can simplify a workflow and make the logic easier to update. Using business rule technology with your BPM tool can help renew the youthful beauty of your most complex business processes.

The underlying rules, logic, and calculations that drive that decision point can be maintained separately from the workflow, by the subject matter experts. Business rule technology, like yoga, brings flexibility and deep thought to complement the power of BPM.

Flexible, beautiful business processes brought to you by the Yogi of IT: Business Rule Technology.

Namaste.

Not Your Father's ETL

As a veteran of the early data warehousing years, I’ve come to think of Data Warehousing for IT and Business Intelligence for the business, with ETL (Extract, Transform, Load) belonging in the realm of IT and programming. Have times changed!!

In today’s dynamic world, the definitions that govern data transformation are not static. They change frequently as new codes, new regulations, new business scenarios are defined. Whether for data warehousing or business process integration, some data transformation definitions are best managed by business people.

For example, a trading transaction may need to be transformed into multiple general ledger records, based on certain codes or code combinations. New codes are always being introduced, which means that some trading transactions will fail the transformation process because the rule governing the new code doesn’t exist. If you’re thinking in code, this means putting an application change request in and waiting, waiting, waiting…until a developer can use an ETL tool to update the transformation definition.

If you’re thinking in rules, transactions with unknown codes or code combinations are sent to a queue where business analysts create new rules to govern the code in the future. Business Users create new and update ETL Definitions as needed, without custom programming.

For truly dynamic business process integration and data transformation, think in rules.

Now download the InRule White Paper Collection! Request White Paper