Trigonometry Operators

Marta Byrski  10 August 2010 10:34:45 a.m.

Trigonometry Operators

• Comments [0]

Extending the Metaphor: Carole-Ann Matignon - blog post and Idiom response

Mark Norton  7 August 2010 11:00:08 a.m.

Carole-Ann's Post:

Have you ever wondered why you should be using one business rules engine or another? Granted each product has its own specificities but it is amazing how many people care about the algorithm that the product implements.

It may be a feminine trait, but I do not care to understand what a V6 or V8 engine is.  I don’t really care what engine is in my car to tell you the truth as long as it gets me from point A to point B in a safe and clean way (as clean as it can be unfortunately).

I was a lot more enthusiastic about the RETE algorithm when I got to uncover the miracles it does many years ago.  It was quite useful in fact to start my Business Rules journey as a tools specialist.  As a user, it avoided me a few pitfalls but I do not believe that it is mandatory to learn the “How” of the various engines.  Let the tools manufacturers worry about it so that you don’t!

Why you should not care

To be brutally honest, you should only care that your engine does what you want and does it sufficiently well — regardless of whether your criteria are speed, functionality or anything else.

People that worry too much about the low-level stuff sometimes forget the big picture.  So many false “best practices” have been going around because of a micro-benchmark that was unknowingly biased.  Knowing the algorithm may help you get out of those traps but, yet again, it may make you worry too much about over-analyzing your performance.  A strong design for your rules — often driven by the techies — could prevent you from achieving the flexibility you needed; the flexibility that ironically drove you to purchase a rules engine in the first place!

Here’s one guideline you may not want to push to your business users…  RETE starts with a discrimination tree for each class being referenced in your business rules.  So all the conditions on Customers are linked together.  If you start with the most frequent conditions first — let’s say “State = CA” – and then least frequent — “Age is between 25 and 26″ –, you will be able to reuse that very node more often.  Your resulting RETE network will be smaller in number of nodes.  This is something you could do as part of a test for your own benchmarks but asking your business users to worry about condition frequency may be overkill.  Especially not knowing what your business rules will be tomorrow.  What if you get a bunch of rules for those 25-26 year-old customers?  Will you ask your business users to rewrite those rules?

The second reason is that the possible performance gain is typically tiny.  Your rules may execute a tiny bit faster but you are very unlikely to make a difference that way.  Your time will be much better spent working on improving the I/Os of your system.  Never mind the fact that your rules engine might include some optimizations on top of the original RETE algorithm that take care of those internal network optimizations for you behind the scene.

What matters then?

I have been talking about the RETE algorithm as it is the most popular engine today — originally created by Charles Forgy.  Other algorithms have been used in the past by non-inference rules vendors as well as a complement to the inference engines in the market.  In some cases, one algorithm performs better than another one (sequential versus inference).  It would highly depend on the number of rules, the number of objects you process in your transactions and the nature of those rules (whether or not they “refer to each other”).

The reality is that people pick one engine and they stick with it.  As a result of a tech support escalation, they may end up trying another one.  Back to my car analogy, even if you were given the opportunity to change your engine whenever you wanted, would you do it?  Would you have the economical engine for going to the store and switch to the high performance one for your longer trips on the highway?  Well, I know I would not.  The hybrid engine is perfect because it does the switch automatically for us.  If it was manual, I doubt that all drivers would use it appropriately for every traffic condition.  I am sure that a few would love to do that but the masses can’t be given that responsibility.

What matter most is what you need and how you will use it.  Wenger introduced this ridiculously feature-rich swiss army knife.  87 tools!  I suspect that a couple of tools would likely suffice most of the time.  Although the giant swiss army knife might look cool in display, it may not be the most usable / convenient thing in the world.  

Think of your rules engine the same way.  You need to find one that is good for your most likely needs in a way that will be convenient to use.  Be realistic about what features are worth your time.

Idiom's response: Extend the Metaphor!

Carole-Ann, you suggest that looking under the hood for engine size may not be useful for customers, provided that function and performance is adequate. Perhaps this could be extended to suggesting that you do not need to even buy a car if there is a better and more effective solution – move beyond the big picture to the even bigger picture, one in which the algorithm is neither visible nor relevant. It is always about the requirements. No point in discussing engine size if a car is not what you want.  The fastest way from London to Heathrow is not by car, so discussing engine power may not be relevant.

Maybe the question is not about the ‘algorithm’ at all. Not so long ago an industry analyst told me that all Rete based rule engine vendors now offer sequential processing algorithms, but that none of the sequential algorithm vendors have introduced Rete. Further, no new Rete based rules engines have appeared in recent years (I confess that I have not verified these assertions personally). So I do wonder whether Rete is the most popular algorithm today as you assert. Similarly, I would be intrigued to understand what pitfalls you avoided by understanding the ‘miracles’ of Rete; more importantly, would these pitfalls be of any interest to a business person who is automating their decision making?

Maybe not just the specifics of the algorithm, but the whole concept of the algorithm has passed its use-by date. In most systems, the cost of executing a process switch to a discrete rules server and back is likely to exceed the cost of the rules execution itself; or, if the rules are tightly coupled, business agility is compromised. Either way, the algorithm is not the issue.    

Much more important are the issues of direct business oversight and control of decision automation; linkage between business strategy and operational decision making; auditability and rule transparency; and overall business agility. The concept of Rete is irrelevant to these issues.

I think the bottom line is that the ease with which the business domain expert can create and prove business rules independently of IT technical assistance or implementation consideration (particularly algorithm but also including language, execution platform, OS, performance, etc ) is the key, and that any industrial strength implementation that achieves utterly reliable results within acceptable performance parameters is OK for the runtime – why would the business care otherwise?

• Comments [0]

Using the Idiom Decision Centric Development Approach™ to build a brand new system with outstanding business agility in 80 days (Part 4)

Mark Norton  4 August 2010 03:59:44 p.m.

This post is the fourth in a series. We are now at day 77 of our 80 day challenge and counting. It has been nearly two months since our last post (sorry, we have been seriously busy!). It now seems obvious that we are not going to squeeze our final delivery into the 80 working days that we set ourselves. So is this failure??

Such a conclusion would be unfair to the agile approach - two things have happened that could reasonably justify some extension.

Firstly - some scope expansion, indicated by the doubling of the database tables in the last period. The angel customer is so impressed with productivity that new complexities are being included in the scope, and even now some requirements are still being accepted for development. This is the power of 'agile' - requirements remain open virtually until transfer to production. Contrasting this with a traditional approach, we can easily imagine that a formal requirements phase alone could have taken this long for a project of this size. In a later post we will publish the actual system metrics for comparison across approaches.

And secondly, the running system has been demonstrated to prospective new customers, and sales negotiations are now under way with several. Note that the system was sufficiently sophisticated and operationally complete at day 63 for 'real-world' sales demonstrations to take place and obtain genuine customer buy-in, resulting in ongoing and positive negotiations re system purchase and/or investment.

You can read the earlier blog posts here: Part 1  Part 2  Part 3

To recap, our goal is to use the Idiom Decision Centric Development Approach™ to build an industrial strength platform for investment and superannuation funds management that incorporates a substantial decisioning component as 'business content' within the platform. This decisioning content is the basis of outstanding business agility. It also allows decision models to be shared across many application instances on the one hand, and allowing bespoke customer decisioning on the other.  

Data Architecture

As noted in the previous posts, we first scoped the study area, and built a conceptual data model. This model was expanded to form the basis of the Plex generated database. It also provided a conceptual framework to guide the development of the decisioning schemas being developed by the Decision Designer. So the Plex and Idiom components were built up independently from a common conceptual framework.

The Plex defined database is now stable, but still subject to completion and related changes. The database design size is now in the order of 86 tables, more than double the size at the last post. Our original post anticipated 100 tables, a guess which looks increasingly accurate.

Decision Models

A generic component has been implemented within the Plex application to dynamically integrate decision models. The Plex application simply passes a context key and the name of the required decision model to the generic interface, and the new component does the rest. From a Plex perspective, adding a new decision model to the application requires only that the Plex developer makes this simple call.

From the decision model perspective, the decision designer has a little more work to do. Besides actually building the decision model, they need to map their decision schema to the database using the Idiom Mapper. Then they need to publish the mapping and the decision model into the new Plex component for the decision model to become operational.

Following the execution of the decisioning process, the component notifies the Plex application that made the call that the decision model has completed. All decision updates are posted directly into the database for subsequent use by the Plex application. This approach can be used synchronously or asynchronously - note that some decision models may run for an extended period, for instance, hours if they are processing all members of a large fund; others may process a single entity, in which case the execution time will be reduced to millisecond timeframes.

We are now in the process of transitioning the early stage decision models onto the latest version of the database. This is a natural step in the methodology:

• The decision models were originally built against the context provided by the conceptual data model, rather than against completed data design (because the data design did not yet exist).
• The schemas developed and validated by the decision models were then used to guide and validate the evolving physical database design. This data design was also fleshed out by other external and/or decision driven functional requirements.
• Now that the data design is at a high stage of completion, the decision schemas need to be re-aligned to the final database design and the decision models tweaked to align with any new terminology and data structures.

This final step is now underway. So far, our experience is that the logic defined in the decision models that were built in the early stages of the project is very stable, with most changes being driven by schema (more terminology and a lessor amount of structural) changes. Only a small number of decision design changes have occurred because of a more advanced understanding of the problem domain. This tends to emphasise the value of decision modelling as an early stage project activity - the requirements as captured by decision models are quite stable within the overall set of project requirements because they do represent the 'essence' of the business - they are not inherently mutable. Understanding the decision model at this early stage also clearly assisted with formulating the later stage data and functional requirements, while at the same time segregating out considerable complexity - this simplified the overall development, with the effect of reducing cost, risk, and time at an exponential rate (according to Capers-Jones).

Plex Models
We would categorise the Plex development as now entering a 'closing phase' in that new requirements and requirements changes are being actively suppressed and the design is rapidly stabilising.

There is still a reasonable amount of work to do to complete integration with the various subsystems and external interfaces, some of which have only recently been confirmed in a design sense. Amongst these is a subsystem for inbound capture, management and auditing of legal documents, and an equivalent system for generating, managing and auditing outbound standard letters and other formal documents. These two subsystems will also demand a significant workflow component.

Despite the work still to do, we expect the system to be available for QA this month.

77 days in and we are behind our initial target delivery period - but with new customers engaged at this early stage, and more sophisticated functionality already built into the system, the vendor remains pleased. See you in a few of weeks!

• Comments [0]

Decision Model Iterator

Marta Byrski  3 August 2010 10:00:13 a.m.

Tip: Repeating Rules via the Decision Model Iterator

There is now an option to designate the decision group as a ‘Repeating/Non-Repeating’ decision group. If a decision group is designated as ‘Non-Repeating’ then the decision group will be executed as per current functionality. If a decision group is designated as a ‘Repeating’ decision group then the decision group and its attached decisions and sub decision groups will repeatedly execute until one of the attached decisions returns ‘Exit Decision Group’ or ‘Abort Decision Group’.

The valid iteration points of exit are:

•  ‘ExitDecision’ operation
•  ‘ExitDecisionGroup’ operation
• ‘AbortFlag’ flag on the child Decisions/Decision Groups
  
  

Create a Repeating Decision Group

1.        Right click on the Decision Model Pallette

2.        Select ‘New’ from the menu.

3.        Select ‘New Decision Group’

4.        Drag context from business document onto the new decision group to set the Decision Group context

5.        Right click on the decision group and select the ‘Repeats’ option

6.        The decision group should now show a repeating icon to denote it as a repeating Decision Group

Exit from Repeating Decision Group

1.        For a Repeating Decision Group on receiving an ‘Exit Decision Group’ instruction, Idiom should behave as it does currently, by stopping execution of the decision group and returning to the calling Decision Group or Decision Model.

2.        For a Repeating Decision Group on receiving an ‘Abort Decision Group’ instruction, Idiom should behave as it does currently, by stopping execution of the decision group, rolling back any decisions and actions and returning to the calling Decision Group or Decision Model.

• Comments [0]

Managing Literal Values

Mark Norton  2 August 2010 03:55:40 p.m.

Tip: Managing Literal Values

A literal is a value that is hard coded into a Formula or UDO. An example of a literal is a string value that is returned from formula for population into an error message.

Viewing and Editing: In order to view and edit a Literal Value, access the Literal Operations Management tab via the Tools menu and right click on the Literal Value in question. The corresponding Formulas and UDO’s can be accessed via this method. Editing a Literal Value in one Formula or UDO will impact all other associated Formulas or UDO’s.

Changes to Literal Values via the Literal Operations Management tab will perform automatic changes across the entire repository to all operations that contain that particular Literal Value, providing an efficient way for users to maintain hard-coded values in their Formulas and UDOs.

For ease of use, clicking and dragging a Literal Value onto the Formula Palette will drop the Literal onto the Palette.

Users are also able to filter Literal Values according to its Data Type.

• Comments [0]

Dynamic Business Applications, Forrester blog post

Mark Norton  8 July 2010 12:37:35 p.m.

http://community.forrester.com/message/6856
John Rymer wrote:

"I'm working on research to further define "Dynamic Business Applications", an idea we first published in 2008. I'm beginning to think that the acid test for dynamic applications is being able to change the underlying schema on the fly. I mean adding fields, columns, attributes, and even entire tables without taking the application down and certainly without waiting for a DBA to make the required changes.
 
Three questions for you:
 
1. Do you agree that changing schema on the fly separates the chaff from the wheat in dynamic applications? Which other dynamic characteristics more important?
2. Do your users ask for the sort of rapid data changes I've described?
3. If so, how do you accommodate them?
 
I appreciate any and all thoughts on this topic!"

Mark Norton replied:

"John, I am assuming that by dynamic business applications you are discussing applications that can be changed by business level administrators or business side analysts – that is, the system is designed to be business changeable without requiring the intervention of the SDLC because of changes to the underlying system image. I promote the idea that the key component of dynamic business apps is the ability to change the rules (specifically, the rules that define business decision making) within apps. To the extent that the decision making is dependent on data, this implies that the data might also need to change, thereby supporting your premise. But note that the business can change the rules to gain business value without changing the data structure; the inverse is not plausible - if the business changes the data without changing the rules, how have they created more value?

Furthermore, I think that your premise infers the ability to ADD data rather than just change – that is, extensible rather than changeable. For instance, it is invalid to delete data that is being used, and deleting data that is not being used does not add agility. Similarly, needing to change the normalized structure of existing defined data (ie a ‘change’ without addition) is likely to be the result of incorrect structure in the first place, and is an IT issue not a business one. So we are left with adding data. So why would you want to add data? There are 3 possible reasons: it is needed in decision making; it is needed for an entirely new process or capability; or it is needed because an external influence compels it (eg SOX).

I will suggest that when we are discussing ‘dynamic business apps’ we are putting significant weight on the first reason above. Building entirely new process capability is certainly a requirement for agile development, but this is not normally managed in the business domain.

The data implied by this topic is the data that describes something external to any given process – and it is both tangible and finite (I will assume that any working data required inside the process is not relevant to this discussion – this should be extensible). We can conceive of gathering all data that is relevant to a domain (for example, standards like Acord, HL7, MDDL, etc try to do this) in which cases the schema is a superset of all data that could be required, and so the schema will not need to change in the normal course of events – we have already defined it all!

In the larger problem domains, such omnibus schemas are impractical for internal processing or business use in my view due to their extreme size. With millions of nodes defined, the designer needs a multi-year apprenticeship just to be able to locate and understand any particular node with certainty. For the smaller domains (eg if I sell bus seats the total domain data is very small compared to managing a hospital patient episode), it may be practical to collect all available domain data, so the likelihood and importance of data changes to achieving business agility is much reduced.

So the bottom line is that I would re-factor the premise to say: is it important for business administrators/analysts to be able to extend the range of data that is being collected to support decision making if the decision design requires it. And this implies not just a change to the schema, but to the process populating the schema, including GUI’s and data interfaces. Data interfaces can be made more agile by applying data integration tools that are useable by business analysts or administrators (eg Talend). Agile business defined GUI changes are less easily resolved.

This is now a much more localized problem. I would suggest that it has an 80:20 feel to it: 20% of the decision model changes require new data, but they represent 80% of the added value proposition of what we tend to think of as ‘business agility’. Idiom has many customers who have gone for years changing rules (eg costing rules that are limited to the available data by definition) without changing schemas. While this is definitely construed as delivering business agility, we do acknowledge that any significant lift in the value of the overall process increases the likelihood of needing some new data.

There are many ways that you can achieve this. All examples below are ‘business agile’ applications being developed in response to a need to support dynamic changes in automated decision making.

·        Model driven development tools are very forgiving of changes to data schemas (we are now using CA-Plex to achieve this on one project in the funds management space – documented here http://bit.ly/9e6Oz5);

·        Document centric development environments also do not constrain the range of data that can be captured (we are currently using Lotus Domino to implement a variation on this approach);

·        Our own Idiom Forms is a UI that can be extended at design time to include new data in schemas for immediate deployment along with the rules that require it – this is used to build insurance products by business analysts ;

·        And by building an interface that responds to the schema meta-data, it is practical to make them responsive to business administrator/analyst level changes. This is the approach Idiom is currently taking to automate a clinical pathway, using the Vaadin toolkit to build a dynamic meta data driven UI.  

All of the above allow business administrators/analysts to change decision rules – rules agility is the core of the business agility concept; all examples except the first also allow business administrators to implement changes in the scope of data being collected, so that UI extensibility is also an important subset of the overall business agility concept for these examples.

So, in answer to your question, I agree with James – the ability for the business to change schemas is not an acid test, but it is an important factor. Its lack certainly reduces the potential scale of business agility that can be claimed or achieved."

• Comments [0]

Making Strategy Stick - conversation on Linked In 1 Australia - Australian ICT Professional Network

Mark Norton  29 June 2010 12:46:15 p.m.

Posted on Linked In by Barbara Nowak-Rowe Director at Leader Group International:

"Even the most brilliant strategy is worth nothing if it isn't executed well, especially by your front line — the employees who interact daily with your customers. Unfortunately, these employees are regularly asked to execute strategies that others developed and that they may not understand, never mind feel committed or connected to. In fact, according to Robert Kaplan and David Norton, the founders of the Balanced Scorecard, only 5% of employees understand their company's strategy. This makes successful execution nearly impossible.

Above is short extract from article by Amy Gallo.
Please let us know what is your strategy for making strategy stick?"

Idiom Replied:

A technique many of our customers use for dealing with strategy implementation is to identify aspects of decision-making within the strategy and automate them. This binds strategy directly to front line systems. Examples of the sorts of decision making that we find defined at the strategy level include: customer acceptance and approval, product selection and recommendation, risk acceptance, pricing and discounting, staff authority, audit and regulatory compliance. Decisions in support of these topics are always governed by strategy even if they are not directly described within the strategy. For more discussion on this approach you might have a look at http://bit.ly/awwW2V .

• Comments [0]

Using the Idiom Decision Centric Development Approach™ to build a brand new system with outstanding business agility in 80 days (Part 3)

Mark Norton  13 June 2010 06:21:50 p.m.

This post is the third in a series. We are now at day 39 of our 80 day challenge and counting. It has been 17 days since our last post.

You can read Part 1 here and Part 2 here.  

To recap, our goal is to use the Idiom Decision Centric Development Approach™ to build an industrial strength platform for investment and superannuation funds management that incorporates a substantial decisioning component as 'business content' within the platform. This decisioning content is the basis of outstanding business agility. It also allows decision models to be shared across many application instances on the one hand, and allowing bespoke customer decisioning on the other.  

Data Architecture

As noted the previous posts, we first scoped the study area, and built a conceptual data model. This model has been expanded to form the basis of the Plex generated database. It also provided a conceptual framework to guide the development of the decisioning schemas being developed by the Decision Designer. So the Plex and Idiom components are building up independently from a common conceptual framework.

The Plex defined database has now reached a degree of maturity with regards to both the Customer and Administration functions, and the underlying funds management functions. Database size is in the order of 42 tables. The decision models have not yet been formally reconciled with the database. This is now a function of the next timebox.

Decision Models

Good progress has been made on the decision models. Next week these models will start to be integrated into the underlying platform.

The Contributions Model implements a broad set of Australian legislative requirements. It is a complex model that was iteratively developed over 2-3 days by the Subject Matter Expert (SME) and Decision Designer who formed the decision modelling team. Testing has been done and the model is now ready for integration as a robust and complete implementation of this legislation.

The Benefits model has been extended to include rollovers, cash-out, retirement, and preserved/non-preserved/restricted no-preserved money.

The Unit Price Validation model is now 95% complete.

The SFP Unit Pricing model has been built to support Super Fund Unit Pricing but is still pending some design input at ~50% complete.

Unit Trust Fund Pricing - model established for unitised and interest investments.

Unit Trust Client Pricing - not started.

AML CTF is now under construction.

Rebates is 95% complete.

These models are now being developed and maintained directly by the SME, with Idiom consultants providing support as required.

Process Models

The XSOL Process models continue to be built out with the end Customer, capturing various requirements to be fed into the Plex development and reconciled with the Decision Models.

Plex Models
We have completed the core components of the system, and completed two iterations to upgrade the UI approach for these. In the first iteration, Plex patterns were introduced which overlaid the system with menu and navigation metaphors. In the second iteration the UI paradigm was altered so that child windows open in the context of the parent window, and once open, they remain live to the parent, changing context as the parent does. For instance, if I open a window for customer addresses from a customer list window, I see all of the addresses for the selected customer. If I select a new customer, then the address window automatically updates to present the new customer's addresses.

At the same time, the Customer and the Vendor have both adapted to the power of agile development, and the number of design requests has risen sharply in the last 2 weeks, with the total number of specific documented requests doubling in that time. This is the critical time in an agile development. In a traditional development, the system boundary is defined in the inception stage, and is rigidly enforced subject to change requests. This introduces all of the downsides of the requirements phase as documented here. Instead, the agile approach uses a combination of functional targets and timeboxes to create boundaries. This means that the development team needs to start applying constraints where the customer does not otherwise see any - the system boundary is defined and applied dynamically. This is now occurring.

The Vendor has now started this process of drawing this dynamic requirements process to a close. At this time we transition into the consolidation phases of the development. The last major change in the customer and administration area will be to introduce a new over-arching 'Involved Party' table to provide a generic entity to represent a system party. This follows a doubling of the number of roles to be tracked by the system over the past 2 weeks, and an increasing realisation that relationships between and across the parties are valuable and useful. This is a normal feature of an agile development - it is fair to say that the customer has been able to grow their perception of their requirement in line with the evolving system. This is a major benefit of the agile approach - provided that the process can be slowed and drawn to a conclusion gracefully and within the development fiscal parameters.

Following this phase the Plex development will focus on integrating the Decision Models, and then consolidating all of the functionality. After that, system level testing will become an increasing focus. But please note, this is not testing as you find in a traditional development, for 2 major reasons:

• The decision models have reduced by an order of magnitude the overall system complexity, and these have each been independently validated and tested within the 'decision development cycle'.
• The Plex generated code per se does not need to be tested. We are left with functional testing of the system as a whole.

The Plex development has progressed apace in advance of the decision models by focusing on the standard components - the parts which are not business differentiators, like security and menu systems, reference data tables and support systems, and client administration. These parts are being poured as 'electronic concrete', but with a model driven tool like Plex driving it, it is still very agile. By the 11th June, the sole Plex developer has extended the client and administration subsystems, comprising 42 database tables and 76 application screens, and released 2 distinct and progressively more complex iterations of the entire system, with one more major iteration now planned for the coming week.

Now the Plex development is moving into the area of back end support for the core funds management area. This will be reconciled with the evolving decision models in the next timebox, and adjustments made to the database and/or decision model schemas as required.

54 days and all is well - see you in a couple of weeks.

• Comments [0]

Decision Designer - is this a career move?

Mark Norton  2 June 2010 09:13:41 a.m.

This post is a brief discussion that will attempt to position the role of 'Decision Designer' - who and what they are, and why you might want to be one.

There is a lot of general discussion regarding the relative position of business and IT. The CIO of a large local company recently clarified to me that in his organization, they do not see this distinction – that in fact IT is as much ‘the business’ as is any other department.

In this post, I will refer to the business with a more explicit meaning – the 'business' in this context is the source of truth - the person (usually person, not department!) who is authorised by the business to modify the business rules that define the business value proposition. For insurance sales this may be the chief underwriter; for claims acceptance, the claims manager; and so on. Each business will have many such domains. But the business in this context can only be the IT department if it is a matter of IT policy – for instance the rules governing computer access.

So for the sake of clarity I will not refer to the business in general terms. Instead I will coin a new FLA (four letter acronym), the ASME – the Authorised Subject Matter Expert. This is the person who is responsible for the consistent, correct and complete application of business policy with regards to the particular aspect of the business value proposition (the domain). This differs from the more usual SME, who is somebody who can be considered to know a lot about the domain in question but who may not have the authority to make forward looking changes – to actually modify the business value proposition.

By the above definitions, only the ASME can be the authoritative source of a decision design - for this reason they are usually at management, if not executive level. The question is whether they should also be the Decision Designer – the person who actually builds and test the decision models.

The key is to not have to translate the ASME’s authoritative domain knowledge through a 'requirements' phase - especially narrative - to get it to somebody who can codify it (Modern Analyst recently published an article I wrote on this). The typical development cycle transits through a requirements phase that is at best an expensive source of errors. The ideal is for the ASME to capture and test the rules themselves – they are synonymous with their rules, and in fact the rules should be thought of as the ASME’s proxy. But frankly, few have the inclination to do this. The perfect person to do this is an analyst who interfaces directly and closely to the ASME - like an 'embedded reporter' in an army. This person can absorb the requisite decision model design by interacting directly with the ASME – conversation and whiteboard scribbles translated directly into decision models in collusion with the ASME and tested on the spot. This process not only avoids the pitfalls of capturing the rules in some intermediate format, usually narrative, for later misinterpretation but it usually also helps the ASME to confirm and clarify their own understanding of the domain. The outcome is a robust, error free rules capture at a fraction of the cost of a more traditional requirements based development cycle.

But it does require a tool that can act independently of the development infrastructure – it needs to be a business oriented tool. Furthermore, by being independent of the development environment, it can be used to capture and maintain the rules that define business knowledge for the life of the business – not the life of the system.

I have fielded the concern in the past about whether Idiom is a career move for a developer or BA. My response is that it has nothing to do with Idiom; the person who uses Idiom becomes an SME by definition – in fact, they become the expert - not necessarily someone who can authorise change (yet), but someone who understands in detail the current state of the business knowledge more than anybody else. It is this concentration of explicit, targeted knowledge that is the great career move.

For instance, I know intimately the rules regarding capital contributions for Australian Super because I captured this legislation in Idiom; similarly with the WEIS rules for hospital funding. Each of Idiom’s consultants has become an expert in multiple domains by helping customers to codify their core knowledge – and this knowledge is complete and detailed.

If this person is in the IT department, then the IT department is truly becoming the repository of business knowledge and practice, and this is goodness if planned well. But the IT department must be clear that it needs to keep the rules repository outside of any specific development platform. If it does not, then it is explicitly locking the business into a platform vendor at the most strategic level. On the other hand, business rules managed within the business units risks being managed at too local a level. Perhaps the ideal is a new organizational concept – a strategy department that is the custodian of all of the business knowledge that defines the core business value proposition, independently of any specific technology platform or application.

We think that being an analyst SME at this level would be a great career move. Idiom may help you to do the job, but it is just a tool, and represents only a few days learning to be proficient – other tools may suit as well. But the role itself is the career move, not the ability to use the tool. You will learn over a period of years - not days - the intricacies of insurance, airline logistics, superannuation, health funding, clinical pathways or any of the other domains that Idiom consultants have dealt with – and this is far more valuable than a couple of days tool use.

• Comments [0]

Using the Idiom Decision Centric Development Approach™ to build a brand new system with outstanding business agility in 80 days (Part 2)

Mark Norton  25 May 2010 04:59:20 p.m.

This post is the second in a series following our post on the 8th of May. We are now at day 27 of our 80 day challenge and counting.

You can read Part 1 here.

To recap, our goal is to use the Idiom Decision Centric Development Approach™ to build an industrial strength platform for investment and superannuation funds management that incorporates a substantial decisioning component as 'business content' within the platform. This decisioning content is the basis of outstanding business agility. It also allows decision models to be shared across many application instances on the one hand, and allowing bespoke customer decisioning on the other.  

The Idiom Decision Centric Approach™ involves the following development phases and responsibilities:

• A domain scoping study that identifies the Sponsors core IP and identifies the set of extended features and functions that are required to support this core IP. From this study an assessment of candidate decision models and supporting host application technologies can be made.
• Development of the core decision models to the point of tested completeness.
• Development of underlying host applications and/or integration components.
• Integration and system testing.
• Handover and user acceptance testing (UAT).

There are various impacts of the approach that affect the working relationship between the IDIOM project resources and the Sponsor:

• The approach is very short cycle and transparent to the Sponsor – progress can be reviewed on a continuous basis. The decision model development is usually performed by a Decision Designer working closely with the Sponsor. The Sponsor is responsible for providing subject matter ‘know-how’, and later, valid use cases to validate that the decision models correctly implement that know-how.
• When the decision models are sufficiently complete, the Decision Designer uses the knowledge gained to drive the expansion of the underlying host application. Business agility is being wired into the underlying platform by this approach.
• When the overall solution is sufficiently complete, it is passed to the system test team, who will test the Application at arm’s length (note that the decision models should have already been tested in the first phase for the 3C’s – completeness, consistency, correctness).
• When the Application passes its system testing, it is released to the Sponsor for UAT. The Sponsor should plan for an independent UAT with assistance from the Decision Designer as required.

It can be seen from the above that the Idiom approach is an iterative cycle of development and testing that focuses on the core IP first, and then builds out to include the supporting infrastructure.

As an aside, there was a great series of tweets yesterday that provide an analogy for the above. Firstly James Taylor re-quoted a source from Shell - 'Once you pour electronic concrete, it is hard to get out'.

To which Idiom replied:

Tweet 1 - Concrete builds a very stable house; and

Tweet 2 - Just don't cast your furniture in concrete too - decisioning is like furniture, U never know when the wife wants to move it!

In the above application, the Idiom Decision Models are furniture in the CA-Plex generated house.

So where are we up to?

Data Architecture

As noted last post, we first scoped the study area, and built a conceptual data model. This model has been expanded to form the basis of the Plex generated database. It also provided a conceptual framework to guide the development of the decisioning schemas being developed by the Decision Designer. So the Plex and Idiom components are building up independently from a common conceptual framework. In our analogy, the furniture is being built with an understanding of the rooms and overall plan of the house, but we are not yet mapping the furniture room by room.

Decision Models

Work has been done on the Contributions Model, Benefits Model, Unit Price Validation Model, and SFP Unit Pricing.

The Contributions Model implements a broad set of Australian legislative requirements. It is a complex model that was iteratively developed over 2-3 days by the Subject Matter Expert (SME) and Decision Designer who formed the decision modelling team. Testing has been done and the model is now ready for integration as a robust and complete implementation of this legislation.

The Benefits model was built from scratch for both Withdrawal and Death Lump Sum payments in one day. By following the systematic approach of deriving the schema inputs and outputs by first laying out the rules that need to be implemented, the team were able to build and unit test this decision model in 4 hours. In future there should be further additions to this decision model when other Benefit types are to be supported by the application, but these additions should be easy to add by copying the common pattern of decisioning that was implemented for the Death and Withdrawal benefit payments.

The first cut of the Unit Price Validation model was also built within a day, again by first white boarding the rules work-flow to get a candidate schema and then constructing the decision model. This decision model will expand as knowledge of the area builds up and is incorporated - a decision model is designed to grow and change!

The SFP Unit Pricing model was built to support Super Fund Unit Pricing. This decision model is 1 of 4 decision models that will need to be developed for Unit Pricing. The others being Unit Trust Fund pricing, Unit Trust Client pricing and Super Fund Client pricing. The Super Fund Unit Pricing model is currently being tested but is also likely to grow.

Points to note:

Idiom's agile approach to schema management allowed the team to make changes on the fly as they were writing the rules so at no point were they treading water waiting on other system components (like databases, screens, and interfaces).

Idiom's user interface and easy to teach concepts enabled a mutual knowledge transfer  between the SME and the Decision Designer, so much so that after 4 days the SME is now proficient in developing rules and making changes as testing
progresses. This has implications for training courses - maybe they should be dropped in favour of on the job training - far more productive.

Process Models

The XSOL Process models continue to be built out with the end Customer, capturing various requirements to be fed into the Plex development and reconciled with the Decision Models.

Plex Models

The Plex development has progressed apace in advance of the decision models by focusing on the standard components - the parts which are not business differentiators like security and menu systems, reference data tables and support systems, and client administration. These parts are being poured as 'electronic concrete', but with a model driven tool like Plex driving it, it is still very agile. By the 20th May, the sole Plex developer had developed the entire reference data and client subsystems, comprising 21 database tables and 61 application screens. These have been loaded up as an application and reviewed by the end customer - inside the last 2 week timebox.

Now the Plex development is moving into the area of back end support for the core funds management area. This will be reconciled with the evolving decision models in the next timebox, and adjustments made to the database and/or decision model schemas as required. An additional 14 tables have been defined to date.

37 days and all is well - see you in a couple of weeks. You can now read Part 3 here.

 

• Comments [0]