DaveBirchall.com on Business Technology

Archive for the ‘Business Rules Engines’ Category

The Innovation Triangle

I’m not going to claim that this is my idea or my concept, that belongs to my good friend and collegue Brett Raven. He has been talking about the innovation triangle for some time now. Its such an easy way for clients to get their head around the partnership needed in order to be successful on any project. It forms a large part of our conversations with clients so I guess its worth sharing via the blog.

This is largely common sense but it’s worth really giving this some thought if your evaluating relationships and capabilities around software engineering (internally or externally). I’ll explain this firstly by going through and discussing the three elements, then I’ll talk about what happens when people get this wrong. That’s the really interesting bit.

• Finance - Software projects take time and time usually means money. Unless your in the position where you can develop the software yourself of course. Its not just the development that bleeds your bank balance dry however. The new solution to be marketed even if its an internal project (its then called education). The project needs to be thought through from conception to implementation and adoption and you need to put realistic figures around what that will cost. Do try and get value for money but don’t try and boot strap the development, it just never works and you lose in the long run.

• Domain Expertise – You can have all the money in the world and you might have won ‘king coder of the month’ for the last three months running, but unless you know enough about the domain that the solution is intended for, you’re the equivelant of a ship without a rudder. Your sailing in no particular direction but hoping you will hit land. This, I believe is the most important element of the triangle because the other two piece of the puzzle can be acquired from else where. To be a domain expert, you need to have an indepth knowledge of the problem you are trying to solve and business goals and drivers you need to meet.
• Software Engineering Expertise – Okay so your building a software solution so you need to bring some expertise to the table in the form of dedicated software engineers. No surprises here I am guessing for most people. Why is it then that people get this wrong so often? Successful software projects involve so much more than writing code. Think about it. If the only barrier to entry for every wannabe facebook owner would be to buy a copy of PHP for dummies then there woul be alot more millionairres out there right now. In the real world, there are a multitude of  factors to consider – What methodology is to used. What project management skills does the team have? Do you have the set up and infrastructure such as continuous integration to be able be efficient in the build?

So hopefully by now you are starting to get an idea of the team that you need to put together in order to be successful. I have never met an individual that possesses all of the attributes to be able to cover all of these success factors. I have however a great deal of respect for the entrepeneurs that I have met who understand their limitations and bring in the neccesary expertise to get the job done. Often they are commercially savy domain experts who understand how to engage a software development team.

Why would you rather be?

Imagine you wanted to start a new web based technology business and you were looking to build a team. Who would you rather be?

1) Lots of capital, no domain expertise, no software engineering talent: While this is a nice problem to have (of the three) , its not sustainable. You can fund a development, your software team will gladly help you spend it but what result can you get without good domain knowledge

2) Software engineering, no finance or commercial awareness and no domain expertise: We meet these people all the time. The open source world is full of them. Back bedroom coding experts who spend so much time thinging about the solution that the business never gets a look in. The best we can hope for here is that they partner with someone who can level them out and stop them writing code for codes sake and also find a domain expert who can tell them honestly what is in scope and what’s not.

3) Domain expert, no finance, no technical expertise: The domain expert can bring in a third party for commercial direction and capital raising. Money is easy to find if you know where to look. They can also engage the services of a professional software development team who can systematically extract the requirements of the solution from your knowledge of the domain.

Its about team spirit

Don’t get me wrong I love clients who have money to burn, but thats only part of what we need to get a successful project over the line. If you also want to be a happy customer, you need get involvedwith your team and often. If you’re the domain expert then we need to get the requirements from your head and let the technology experts do their job.

Hands up!

Hands up? Who reading this owns a software programming business? My guess is not a lot of you right? Now hands up if your a business owner or director of a company that isn’t a software engineering business but you hire developers. Yeh you not so keen to admit it now are you but I know your out there. I talk to you every day…

Okay I’ll get off my judgemental high horse for a second or two. I’m not saying that every company should outsource their IT but I am saying that you should really have a think about why you want to do it. It costs money to own a software engineering department so why not share that cost with someone else?

Outsourcing has come a long way in the last few years. If you can have a team that is outsourced on paper but feels in every respect like they are part of the company, then why wouldn’t you do it?

Many software companies have targeted the insurance industry with a software product offering in the last few years. These software products are able to be taken off the shelf and seemingly dropped into production.

The apparent speed of deployment can be appealing to a business that is striving to get things done and kick goals in the shortest time frame possible. The lure of such a solution can be all the more appealing when the other option is a custom software project which (as reputation would lead you to belief) can take several months to design build and then test. Although the custom software approach would inevitably lead to a better fit for the business, efficiency is sacrificed for the sake of apparent speed of deployment.

This view of insurance industry software is to my mind far too simplistic and fails to take into account a best of both worlds approach which has been developed and refined in recent years.

Every insurance company is different. By their nature, they need to be different in order to gain competitive advantage over their competitors. The way risk is calculated, premiums and pricing are calculated are all highly specialised and are often updated and refined on a frequent basis.

BA’s, Risk Managers and Actuary’s need to be able to make changes to such calculations without having to add to the work load of IT managers. Long and convoluted change management processes simply become an unnecessary stumbling block for a department focused on getting things done. By the same token, the IT team can be hesitant to give untrained personnel access to business logic in a business critical system.

The solution lies in using a Business Rules Management System (BRMS) to seperate out the business logic and make it accessible to the people that need it. Rules or sets of rules can be locked down using role based security to prevent unauthorised changes to business logic. As well as speeding up the change request process, a collaborative approach to business logic can then harnessed allowing the business to catapult into a new realm of business agility.

In addition to all this, the software development cycle is significantly reduced, allowing insurance businesses to reap the benefits of their investment sooner.

A BRMS approach to insurance industry software allows you to enjoy the benefits of off the shelf software (rapid deployment, stable code base,) with all the benefits of custom software. (efficiency, fit, usability, performance)

To find out more about how BRMS can work for you, register for our forthcoming the webinar at

http://www.solentive.com/software-events.html

Earmarked for the 6th March, our online event takes insurance industry IT management through some of the concepts of using Business Rules Management Systems.

By separating some of the business logic into a rules engine, Insurance companies can take greater control of their IT and fast track the process of change management and save money along the way.

The insurance industry is also able to make use of the theory of Complex event processing, which we also hope to cover off.

Registration is free but limited to

1) Business Analysts
2) Senior IT Management
3) Risk Managers
4) Actuarys
5) Finances

To register, visit

http://www.solentive.com/software-events.html

Create and Edit Business Logic in Plain ENGLISH

Just a quick note of thanks to all those that joined us online for the webinar earlier in the week. It’s been great to see the level of response and interest around BRMS.

If you missed the session or if you would like to go through it again you can view it at

http://www.solentive.com/webinar-create-details.html

The quickest way to get an appreciation for why Inrule is such a revolutionary bit of kit to think about business logic as a set of rules or conditions that are held in a centralised repository, (for the sake of argument) similar to the way that content is stored in a content management system. Rules are managed by non-technical business users in a collaborative, organisational fashion. Software engineers no longer need to be engaged in the management of business logic and so the business benefits both from cost saving as well as the reduced time to market to deploy the rules. The software engineer is freed to work on more challenging tasks.

In short the BRMS does for business logic what CMS does for web content (ie puts the business in control) .The company is now enabled to ‘think in rules’. This is a unified collaborative approach to the way that rules are controlled and managed within an organisation.

Such technology calls for an entirely different approach to software development, one that InRule call ‘dynamic decisioning’. In essence, Software can now be designed in such a way that business technology could be changed ahead of a change in the business environment.

For example, if a change in legislation is thought to occur which had a knock on effect on the business processes within the organisation, those changes could be written in advance, tested then activated on the passing of the legislation so that that the business transitions seamlessly.

How would your business benefit from ‘thinking in rules’?

What is a BRE?

The Business Rules Engine (BRE) is a software system that executes one or more business rules in a runtime production environment. A BRE can be used in Business Process Automation to significantly streamline the operational efficiency in a business.

A modern BRE is best thought of a rule management system. The rules of a business can change as the business grows or evolves. Certain rules may be applicable within a certain timeframe for example and therefore Business rules need to be updated and managed with the changing needs of the business.

The BRE can be used as a vehicle to translate ‘business logic’ into information workflows.

What are Business Rules?

Rules are everywhere. In fact a good business is valued or assessed on its systems, policies and procedures. These can also be known as business rules.

Business rules are visible in all businesses from SMB to Corporate. If you are able to document and map your business rules, you stand a good chance of significantly increasing the efficiency of your business through software and automation of some of your business processes.

The following table provides examples of some of the rules that might effect decisions in various industries.

You will notice that all business rules can be summarised into two categories

Either IF – THEN statements or IF – THEN – ELSE statements

The IF – THEN statement is also known as an inference rule and can be used to look up make decisions such as ‘Should this customer be approved for a mortgage?’ by executing rules of the form “IF some-condition THEN allow-customer-a-mortgage”. They can also be used to create fact tables which may allow the system to statements such as. If the conditions are ‘wet’ and the vehicle is over 1.5 tonnes, then the maximum permitted speed is 40 kph in populated areas.

The other condition, the IF – THEN- ELSE statement is also referred to as an ‘Event Condition Action’ rule.

Modern Rules Engines can really be considered rule management systems. For instance our rules engine provides a rule authoring environment, as well as a server, testing environment and library. Effectively a library of rules can be written, reused, activated and deactivated over time.

The rules are no longer in the control of a programmer but a business analyst who can write or modify the rules in Domain Specific Language (DSL). This means that the rules are written in a language that is industry specific rather than code.

How can is it used?

Our BRE can be used as part of a customworkflow solution or a part of a Service Oriented Architecture (SOA) in unison with Biztalk.

A interesting application for a BRE could in the automation of a help desk functionality. Where a large knowledge base exists, the BRE can be used to understand where the knowledge base is applicable through rules.

More reasons to use a BRE…

Every business is different Our rules engine is may deliver some or all of the following benefits.

·
Drastically
reduce development time and costs

o
From
5000 lines of code in C# to 150 lines of code in the BRE.

·
Significantly
reduce maintenance cost.

·
Change
business rules on the fly – less change requests and less programming!

·
Build
a faster more reactive business systems.

·
Protect
data consistency by using a BRE to handle complex calculations.

·
Remove
manual Processes where possible

·
Allocate
human resources to more humanistic tasks.

·
Free
up your overstretched IT department.

Need to know more?

If you need to know more or have any questions about how BRE can help your business, feel free to contact us.

Where were you?

The first ‘meet up’ was a bit of an experiment so it was great that a small but targeted group turned up to see what I have been banging on about The group ranged from ‘hardcore technologists’ to people with much more of a business related interest.

If you want to join us next time around, then join us at

http://ia.meetup.com/65/calendar/8164216/

Business Rules Engines

Its how we make sense of the world and crucial to the way we run our business. Without our systems, policies and procedures can we really say that we have a business?

So if we can understand our business rules, you can not only take control of your business but can take steps to automate it. This is approach is by no means new. The term business process automation has been around for some time. The problem has been that in todays ever changing business environment, the technology can’t always keep pace with the change.

Imagine if a technology existed where rules could be changed on the fly and set free to evolve as the business grows. Image the possibilities and the effect it could have on you business if you could automate major parts of it.

Business rule engines are one of the most exciting technologies of the modern age. I hope to meet people as excited this concept as I am.