Welcome to the IDIOM Software Blog.

Decision Designer - is this a career move?

Mark Norton  2 June 2010 09:13:41 AM
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 WIES 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.