How should EA be funded?

Alex Cullen of Forrester poses the question and provides the usual expert answer which can be paraphrased as "it depends".

The neat accounting view that there is an ongoing programme of delivery from which subventions can be drawn to pay for necessary evils of CIO, strategic planning in a manner similar to large plant replacement misses the point that you would not need active enterprise architecture people if everything was planned out.

Rather than comparing EA with IT management overheads like the CIO office, "research and development" within the wider enterprise may bear more fruit. In non-productive organisations like government agencies, policy development would be  equivalent to R&D. Then the thinking around EA funding would be closely aligned to the enterprise strategy rather than the current IT problem set. Of course, if you don't do R&D in some way then there is a pretty clear message that you are not interested in strategies so why do EA?

Practically though, if you believe that EA has a benefit for the organisation, you get the money from wherever is feeling the most pain from the lack of whatever EA will deliver.

Google apps are different if you speak American

In a departure from the data management good practice that I learned a while back, Google use the language setting for US English (rather than the proper one :) to determine how there apps work rather than simply the words , spelling, and punctuation used.
I discovered this as I set up a new apps account , accidentally left the default setting for language as US and discovered that I could use Google Voice to dial out to US and Canada for free from New Zealand. Not a big saving over Skype but a demonstration of how things are coming together in a common look and feel and set of services 'in the cloud'. Now your Google contact list is a one stop shop for outbound calling. Of course, there are ways of running a full Google Voice service outside the US but that requires a little more effort than putting up with a few odd spellings :)
The Google Apps dashboard also functions differently with US setting.

I am still a bit concerned that the gung-ho people from Google should misuse the language attribute rather than define a specific setting "Google-Voice-On". What next , identifying Europe by the use of the currency euro? Close enough?

Bob the hero?

Bob (Google Apps Script wizard) the hero?

Is Bob the hero of the company or has his boss and IT governance allowed him to become the biggest risk.
Google Apps scripts were showcased in a strong presentation at Google I/O 2010. In it, "Bob" was portrayed as a hero for great business performance improvement using spreadsheets and scripts. Although the scripting features presented form a sound toolkit for development around the Google Apps, I am concerned that they may simply replicate earlier problems in IT development.
I have reviewed government and commercial organisations and found much of their operations were centred on spreadsheets or MS Access databases and the like that had grown up from a long departed staffer's need to produce a one-off report for the manager. Auditability and indeed what a spreadsheet was intended to calculate had been lost in the mists of time. Do it yourself Business Process Automation as presented by the Google Apps team seems to offer the same opportunity for foul up but with the potential for more far reaching effects.
The example from Motorola in the second part of the presentation was impressive for its achievement of savings and business process improvement but rather had the hallmarks of an IT shop rather than a "Bob". Even with an IT project approach, there needs to be some consideration to the governance issues presented by such adhoc Business Process Automation. This concern was echoed in a question at the end of the video but not answered.
How do we avoid losing sight of key corporate information spread over contact lists, third party solutions and spreadsheets in the cloud?
Alternatively how do we empower the "Bobs" without hampering them with portfolio management, programme directors, project managers, advisory boards and other manifestation of "good" governance?

Should Government Mandate Backdoors f...

Despite the US being one bit of the world it seems to regard the Internet as its own rather than a global system of interconnected computer networks that use the standard Internet Protocol Suite to serve billions of users worldwide.
So now the FBI wants to snoop on any internet traffic it chooses.
What about the rest us whose traffic may accidentally pass through US controlled space? Do we, or our governments, get a say?
Apart from it being a bad idea technically to introduce backdoors because they offer a tempting target for the bad guys, misuse of the information gained by surveillance of the kind proposed is common. Governance of backdoor snooping is non-existent on the worldwide scale.

Government Enterprise Architecture - ...

Nick Malik identified some challenges in Federal Enterprise Architecture in a recent post. Which lead me to question how hard can it be to use Enterprise Architecture practices to support more effective government?

Considering the business of government rather than concentrating on the nuts and bolts of IT in the abstract, there are very few patterns of government business. Even those of us protected(?) by the 'Westminster System of Goverment' can eventually map out the nature of business.

Much of the business of ministries, departments of state, and even minor agencies is not peculiar to their title or function. Formulating policy; measuring impact of policy; funding; communicating with citizens are a major part of every arm of government and there is value in having a common set of 'all of government' functions, activities, business rules etc. At the very least, it would reduce the number of reinventions of the wheel taking place in the areas of process improvement and consequential ICT solutions.

The remainder of the departmental business can be further divided. Sectors of government are often handled by a number of separate agencies (Education, Transport, Justice for example spawn agencies dedicated to special functions,like standards in education). There are however common objects, and objectives across the sectors (eg students; roads; people). This leaves a small amount of the business of a single government department that is peculiar to that small enterprise. 

There is, of course, a reasonable amount of Enterprise (IT) Architecture going on a whole of government basis driven by cost pressure but the scope for improving the whole operation of government is vast. Despite the advantage that government, as an enterprise, has over commercial enterprises, I do not see much evidence of the full scope of Enterprise Architecture in government. The size of the architecture problem would be considerably smaller and more likely to be delivered upon if the common elements were dealt top-down ...
 One view of the all-of-government; one view for each sector of government for the bits that remain; and then one view for each organisation for the bits that are truly the unique interest of that department.

Dynamic BPM Success Story

Sandy Kemsley brought us some good news here with

• a government department going from legislation to operation system in 12 months;
• agile methods in a government program of work;
• (dynamic) BPM underlying case management

What a pity the growth 'industry' is the UK's Insolvency Service.

Intercepts for Facebook etc?

Computerworld seems to have woken up to this issue which has been around the privacy community for sometime.

The Obama Administration is reportedly considering a statute that would make it easier for federal authorities to intercept communications over services such as Facebook, Skype and BlackBerry -- an idea that's stoking anxiety within the privacy community.

The debate includes worthy noises about the need to eavesdrop on terrorists but does not address the trust that gets placed in the government agency.

For those of us outside the US whose communications are incidentally caught up in US service providers like Google, or Skype there are another set of considerations.

• Does every tin-pot government agency in the world get its own feed from the communications honeypot?
• Are we going towards a 2-level communications regime (inside and outside US regulation)?
  

• While end-end encryption inherent in RIM's BlackBerry defeats the eavesdropper, it is easily identifable that encryption is taking place and could lead to the assumption that the parties involved are 'evil' rather than simply private.

Those interested in privacy rights would do well to advocate end-end encryption of every communication to make wholesale eavesdropping ineffective until encryption scheme breaking moves forward a few more generations.

UPDATE: An expert view here from Bruce Schneier.

Security Barriers are not Enough

Lauren Weinstein commented reasonably on the Alleged Snooping at Teens' Data by Google Engineer . Yet again we are shown that technology is no match for the evilly disposed or simply stupid. You do not have to be a conspiracy theorist to understand that there is a lot of sensitive information flying around the internet or that by collating seemingly harmless data, sensitive information can be reconstructed. Points of concentration in the network (your ISP, Google, Bing and the like) increase the threat simply through the quantity of data available for analysis. Network security, database security and the strangely titled "Site Reliability Engineer" have fairly free range to see controlled information in order to do their job but are they to be trusted? and who watches the watchers?

The trusted person does not have to be in the shadows. There are plenty of jobs where an authorised person could misuse authority. Law enforcement immediately springs to mind. Generally we trust those people in law enforcement, they are checked, double checked and swear allegiance. But what do we do when people in these positions abuse the trust. In New Zealand, they get promoted!

A senior policeman caught accessing the police computer to pass on information to a private investigator working for convicted pack rapist Brad Shipton has been promoted to head the Police College's investigation and intelligence school. In 2005, then Senior Sergeant Dave Archibald was reprimanded for accessing the computer system known as National Intelligence Application during the trial of former police officers Shipton, Bob Schollum and two Mt Maunganui residents. from Dominion Post 25/08/2010

Remember that it is the information that has to be controlled and protected, and that its presence in a computer network is not the whole of its life. On the systems side we need to ensure that:

• information is appropriately classified
• if the information needs to be restricted to authorised parties, there are systems
  

• to ensure that the information access is appropriately controlled
• to track the handling of that information so that misuse is detected
  

and, out in the real world, we need to behave as though privacy and personal security matter.

Signalling in BPMN

At the risk of raising the ire of those that want to avoid precise meaning in their process flow diagrams, I recommend a study of Anatoly Belychook's handy primer on the use of the signal event.

I would emphasise that the signal event allows the ultimate "late binding". You do not have to design the world process ... only the bit you are in control of at the moment. When you come to an event that you know will be useful to another bit of the enterprise ... Signal ... then when a use is found in another bit of process design you do not have to redo the process design work again. Of course, you will need a way to hunt down these useful signals and some standardisation of how they will look in your enterprise.

For those of us that look forward to the executable process, Signals also provide a simple communication method between parallel flows within the same pool and avoid the process designer having to think too much about implementation level stuff like writing data to a store somewhere.

see also

BPMN only part of the solution

Scott Francis takes up the pen in the the ongoing and tedious debate about BPMN ( enough, too much, too hard, too rigid, too imprecise ....) and makes the excellent point that "too many people think that BPM starts and stops with BPMN!".

With a very small set of symbols, BPMN allows a range of expression of process definition from a whiteboard-quality overview to the precision of a computer algorithm for calculating Pi. Even with a palette of 1007667 English words, it is very difficult to get the necessary precision for specifying a business process. Working on the basis of the average reader using only a small subset of those possible words (about 2000) it is clear that we need something more formal than text to get to commitment on what a process is or should be.

It would be really scary if those responsible for the operation of multimillion dollar enterprises can't take on the meaning of a set of symbols that can be put on a small wallchart.

The sad thing is that there is not a similar set of symbols that could be used to encapsulate other aspects of the business canvas so that discussions on whiteboards, or around coffee-bar napkins could be more enduring and useful communication of requirements.

Online privacy, Tracking, and IE8’s InPrivate Filtering

A bit of puffery here for IE8's InPrivate containing a lot of good pointers for the paranoid and those mere mortals who don't like the idea of vast collections of electronic fingerprints being collected by law-enforcement and other sinister bodies. The concern raised by the Panopticlick study does not appear to be addressed though. Taking the good point that "it is how the web works", a cloaking mechanism that, makes you look as though you are using the most common browser out-of-the-box without all those helpful pieces of information that together make you unique, might be useful. After all how many sites need to know that I have Macromedia Flash:Version 10 (version 10.1 r53)

Cellos for sale!

On a completely different tack , I am fundraising for a new cello! An excellent Almy full-size cello and a high quality 3/4 ce3llo are for sale and described here

BPMN 2.0 Best Practice

The LinkedIn Group for BPMN has a discussion on the need for a best practice for BPMN 2.0.
People come at BPMN from a wide spectrum of use from initial discussion of a business process to the IT developer perspective and a matching wide variety of views of best practice will evolve.
BPMN supports a design to execution path.
Tom DeBevois makes a similar point ...

“Certainly, BPMN enables a powerful requirements gathering tool and it can be a part of the over-the-wall requirement. Still, the central focus of BPMN is to support an agile executing environment and promote visible active, responsive change.”

This focus in the notation is in my view highly desirable. A side benefit at BPMN 2.0 has been the tightening up of syntax and meaning. This should help in the process development by making it relatively easy to critique specifications, as Tom was able to do ...

“For instance, consider the car sales process example (Figure 5-5 in the Method and Style Book). At one point in the process, sales enters an order from the factory and a message is shown from the subprocess to the Factory process. This seems correct; however, when I review an actual BPMN process diagram, it suggests to me that the definition of the process might be insufficient. In reality, what happens in most corporations is a salesman takes the paper order form and punches in the car order into another system.”

This is not a defect in the example, or in the style of BPMN 2.0. It merely represents the stage reached in the process design (it is to be hoped, before critical review).
BPMN does not in itself do the design. Transforming thoughts and words into the formality of BPMN 2.0 reduces the ambiguity of common spoken language. Coming from the technical disciplines of IT , I am attracted by the concept of an execution specification of the process that relates directly to an expression of the apparent problem being addressed. I anticipate a few round trips between business process specification and execution design. That is, it is still best for there to be an ongoing conversation between the person originating the problem and the provider of the solution rather than throwing arbitrary specifications over a wall.
Jakob Freund provided a clear example of the happy path through the design process in BPMS. I particularly liked the transition between viewing the process as flowing between departments of an organisation (level 1) to those departments carrying out independent and complex activities communicating through messages (level 2).


This is an example of what could be described as a “best practice” as ..

• the process is decomposed by responsibility
• information required by the various responsibilities is clarified (it is the message content)
• organisational change (eg outsource development) does not necessarily force process change

It would be useful for organisations adopting BPMN to be able to point to practice notes. Those “best practices” must be appropriate to the organisation and to the task in hand.
I suggest that a reasonable approach at this stage in the life of BPMN the best approach is to take one or more of the publications like Bruce Silver’s and go through it crossing out and highlighting depending whether you feel the ‘rule’ is appropriate. This then becomes the initial quality manual for BPMN.

I do feel that any BPMN symbols used in the early stages should be used correctly.
Things important to the expression of the business requirement should be included (however complicated the diagramatic representation) but avoid the temptation to express unnecessary “how to” in the model. I do not feel that the symbol palette for level 1 or 2 of BPMN 2.0 should be a constraint on the modeller. It is more appropriate as a compliance statement for tool providers.

BPM not appropriate here?

Keith Swenson used the example of a major amalgamation to indicate an area where BPM would not be applied in his post Where did I put that major airline merger process definition?
Of course that may be true in that particular case, but it is poor argument for decision-making about how you are to manage a process, or processes in general.
I accept that there are things you just do (let's have lunch today...) and that some things come about despite having no obvious plan or process (UK government, eventually) but dispute the premise that BPM should not be playing a part.
One problem with BPM, is the assumption that the process cannot be changed in flight. It seems entirely reasonable that

1. a process instance should be followed ;
   
2. have a “I’m sorry, Dave. I’m afraid I can’t do that.” moment;
   
3. and be changed at that point.
   

Visualising the state in a BPMN diagram allows a view of what has been followed up to a state and what is expected to follow. The executable BPMN engines of today will struggle with a change to in-flight process instances but there is still plenty of development mileage to run there.

Incidentally, scheduling lunch or any other meeting often does need to follow a process while personal assistants juggle diaries. An advantage of formalising those processes is that all the players understand what is going on and play their part in a choreographed fashion. There are a number of function-specific tools that hide the complexity of process involved in some common activities but that does not mean the disciplines of BPM should be ignored.

Another way to fail at customer relations

It was a windy day in Wellington (120kph forecast) today but Pacific(Virgin) Blue where confidently predicting the early arrival of DJ56 on their animated web page. Just like being in the pilot's seat!
Drive confidently to the airport  and find that DJ56 has been diverted to Auckland and will make another attempt to get to Wellington some time later in the day. Return home.
Wondering when I should return to airport to pick up returning son, I head back to Pacific Blue's site that had impressed me earlier to learn that the 'system' thinks that DJ56 has landed in Wellington on time at 3:15 with a picture of the track to prove it.




This revealed that the system does not report where the plane is, but where it should be . This  is not much use to anyone.
So I had to resort to the dreaded customer assistance phone service. I had to wait over 9 minutes to get a real person, but I had no better plans. What really annoyed me was the music on hold being interrupted every 30 seconds to tell me that I should avoid waiting by going on to the (discredited) website. Eventually, a real person was able to tell me that the plane was due to land in Wellington at 3:05 (the local time was then 4:18). I suppose the call centre was using even more out of date information a few time zones away. I updated the call centre with the news that the plane had been diverted , and was, after another delay, advised that that was correct but they had no further information! Not even when it was due in Auckland.

Keep the coding out of BPM!

Phil Ayres writes on experiences in the refreshingly un-politically-correct world of Mexico City. I particularly liked the learning point:

if you can avoid coding (and in my opinion HTML, Javascript and all that proprietary script inside a BPM tool is code) do so. Code makes BPM solutions brittle, and hard for business users to update in the future.

The developers of BPM solutions have done a good job of providing process design tools and execution engines around the process flow. Unfortunately, the likes of Intalio, clutter their core idea with attempts at being a total application development system and fail. Even HelloWorld examples get cluttered with XPATH, SQL, XFORMS and Javascript.
BPM solutions seem to have been accidentally painted as an alternative to disciplined development and lessons painfully learned in IT-shops are having to be relearned.

It would be nice to see BPM solutions architected with clear separation between presentation, data-handling, business decisions, rules and process flow logic. Coding is required somewhere along the way but we should all understand where and who is responsible for it.

Business Rules Concepts

Business Rules Concepts by Ronald G. Ross (Third Edition)

This is a handy introduction to business rules where it really matters, in the business side of the enterprise.
I read this from two perspectives - as an old-stager in the IT domain and viewing it as a text to recommend from enterprise architect to business decision-makers.

The first pass left me spluttering "well how would this work in practice" at a number of stages. On the second read I was nodding in agreement throughout at the exposition of why expressing Business Rules formally, is a good thing.

What I would like to see is a companion volume "Business Rules Practice Manual" but as Ron Ross says this is probably best provided by some hands-on consultancy.

I did feel that the concept of separation between Business Rules and Business Process could have been pursued more. Certainly you need to avoid coding your business rules within the business process as you would wish to keep them out of the mainline IF-THEN coding of CODOL, JAVA or whatever but some hints about how to integrate the use of BR with BPM would have been useful.

I was glad to see the re-introduction of Decision Tables, familiar from my youth in COBOL and PL/1 programming. However, the examples of decision tables miss explanation of both the basic principles and reasoning. My use of these, from software development, is a bit dated but wikipedia provides a clearer grounding with this example:

A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. The following is a balanced decision table.

Printer troubleshooter

		Rules
Conditions	Printer does not print	Y	Y	Y	Y	N	N	N	N
	A red light is flashing	Y	Y	N	N	Y	Y	N	N
	Printer is unrecognised	Y	N	Y	N	Y	N	Y	N
Actions	Check the power cable			X
	Check the printer-computer cable	X		X
	Ensure printer software is installed	X		X		X		X
	Check/replace ink	X	X			X	X
	Check for paper jam		X		X

With a business rules focus you may object to the expression 'Action' . Replacing 'Action' with 'Assertion' probably meets the intent within Business Rules.
The example on page 111 is particularly difficult to understand.
The use of N-values conditions makes it difficult to rationalise the large number of rules that you get when using many conditions independently to determine what to do. I would replace the N-values with a set of binary values Customer IS 'Silver' etc.
Introducing the 'ELSE' rule feature of classic decision tables at this stage might avoid frightening people with the thought that they are going to have to explicitly deal each of the 192 rules. Yes, 'ELSE' does sound a bit like programming so how about 'Otherwise' or 'Default'

One further niggle - the Table 12.2 is missing in the copy I received -even in the digital age human error can still get you! Ron kindly provided a pdf of this.

That said, if you want to explore the sound basis for Business Rules in your enterprise, start with this entry point.

Beyond the Enterprise

In public sector organisations, I still see architecture efforts being focussed inwards on making the IT shop more effective rather than outwards to serving the public service goals. While reducing costs is laudable, looking at the broader picture in the government/public sector may reap more benefits through common design and implementation. Some obvious examples spring to mind:

• Shared data-centres and infrastructure - the physical components of "IT"
  
• Shared software stack - a managed selection of components on which particular applications can be built
• Shared business services - eg HR, communications, 

These ideas seem attractive but getting sufficient momentum to make effective enterprises at lower cost has been hard. How can we do better?

• 'Benevolent' dictatorship
• Build it, and they will come
• Present idea and everyone will see it your way

"Yeah right" but there is an alternative that could be born from the efforts of enterprise architecture professionals to architect the enterprise. If, as the Enterprise Architect, you start from the Business Operating Model of your enterprise, there is a fairly obvious set of divisions that can be made:

• Things that are common to any organisation (accounting, hr, property management ...)
  
• Things that are done because the enterprise is part of central government or simply in the public sector. (Budget cycles, freedom of information, working with elected bodies ...)
• Things that are peculiar to the sector of government the enterprise is working in (education , health, transport ...). All governments seem to sprout specialist agencies in addition to the main portfolio departments/ministries.
• Things that service the relationship of government to sector. For example a common health record is a service across public, private medical services and the individual clients of those services.
• Things that are special to the enterprise - (delivering welfare payments, certifying standards met...)

Part of any strategic review by Enterprise architects in the public sector should be to separate the business goals/functions/processes into the broad categories above. Original thoughts and planning can be reserved for the last class. Items falling into the other sort bins are candidates for shared or common services.

Common to any organisation	Rationalise to standards of business practice Work with "all of government" enterprise architects for strategic direction and implementation roadmap for common solution from readily available components.
Common within government organisations	Work with "all of government" enterprise architects for strategic direction and implementation roadmap.
Sector of government	Work with "sector government" enterprise architects for strategic direction and implementation roadmap.
Sector business services	Note there is not a  common 'head' organisation here. A sector is more of a federation of providers and consumers of services. Ring fence these services for formal definition. Establish lead provider for these within sector.
Special to this enterprise	Internally-focussed business process improvement. Look for business functions that can be generalised (generic application processing rather than application for dog licence)

That is just looking at the business operations ... technology follows! In all cases when considering the technology components, solution architects should be directed towards common services and common behaviours. This is important even for business functions and processes that may be regarded as one-off.

Right answer in selecting a BPMS - three BPMS???

Janelle Hill, Gartner Research VP,  was quoted by Mike Gammage in The BPMS Finds Its Home

'The right answer in selecting a BPMS is often three BPMSs, based on the particular projects' needs.'  

An immediate reaction to this is "what twaddle, doing the same thing 3 ways ..." but this may just be a characteristic of our time.

A need for end to end process definitions  was established (and it would be nice for them to be easily transformed into execution). IT solution vendors are just catching up by delivering products or relabelling earlier ideas as BPMS.

Governance practices over introduction of new technology are heavily weighted to buy rather than build, for very good reasons. Unfortunately, the Business Process and its management is only a component of the solution to any practical business problem.

Pure-play BPMS vendors emerged providing an attractive solution to the technical need for a means of execution of business process specifications but a very sketchy idea of how solutions could be delivered. Grafting on Business Rules Engines, rudimentary web user interfaces and database may make the product look attractive to a small development shop but tends not to tick the boxes for a project focussed on getting the business working quickly. A reasonable judgment call would be to accept the need for standard expressions of business process (BPMN, etc) and simply require the bought solutions to be compliant. This may result in multiple products but at least the short-term needs are being met.

If the BPMS bit of the technology portfolio looks to be an area where rationalisation to a single implementation is a priority, we actually need to be able to design to use BPMS as a component of the total solution and not expect the BPMS component or vendor to be the driver for every solution. As Mike Gammage says,

Out in the real world, business processes are only partly automated, and they need to be made visible and managed and improved end-to-end.  If BPM is seen as being focused on just one part of the CIO's portfolio of automation capabilities, then we've surely lost the plot.

So in our Enterprise Architecture efforts we need the business to be formalised in Business Rules, Business Process, and Decisions as well as having technology pieces that map to these formal constructs of the Business Operating Model.

Do Rules need a Rules Engine?

Do Business Rules need a Rules Engine?

Architectures tend to spring from technical IT types stacking a set of facilities that they have or can buy into a neat PowerPoint picture and centre on the solution execution rather than the long path of getting there. Hence, when Business Rules is thought about, a box is placed centrally labelled Business Rules Engine. A couple of bullet points in the presentation to senior management cover the concept that a clear statement of facts and rules by the business will be transforms magically and with little effort into operating code in the IT domain.
There can be little argument against stating the requirements in a provably consistent form that can readily change with  business change is a good thing.
Mark Myers provides an insight this month. With an example of an organisation that did its rules definition so well that a rules execution engine did not add value.

 As part of our SOA architecture we had specified a rule engine.  We had a vision of "rules as service" and using the rule engine would be the core component.  The job of the rule engine, in part, was to help meet the business goal of "agile rule management."  Our thought at the time was that this kind of interface would aid in rule change and rule management.  As it turned out, the business involvement in maintaining a business-side repository provided a much better interface in managing rules.  The amount of meta-data needed to accompany each rule could not even begin to be captured in the interface offered by the rule engine.  During this process the business became very interested in and knowledgeable about their business and just wanted the rules (logic) implemented.  They didn't want to be involved in the gritty implementation details and really didn't care how the logic was ultimately implemented.

 Mark Myers, "Something Happened on the Way to the Forum:  Did We Really Need a Rules Engine?" Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL:  http://www.BRCommunity.com/a2010/b526.html 

So no, you do not need a 'rules engine' bought in to execute rules. If you have a comprehensive development shop working in the SOA style then the implementation of an additional engine in the mix is probably not an effective use of budget.
However, if you are less blessed or want to downsize those pesky developers then there are rules engines out there. BUT the most important thing is to capture the rules, facts, nouns and verbs in a manageable form within the business.