Vision

Tony Fish, in his book “Decision Making in Uncertain Times”, describes decisions as the result of balancing choices and judgements.  We reflect on our judgement of choice when we see the outcome of our choice.  Many times, in the world of business IT, the choice if frequently to follow the herd – after all, as the saying went[PW1] , “No one get fired for buying IBM”.  However, as Roger Martin points out in his book “A New Way to Think”, we often think that a poor result in business is because we have not tried hard enough, and so we double-down on the same types of decisions, following the same path, and grumble to ourselves when we get the same result.  Einstein was quick to point out that this is the route to madness. 

​

So, what is a manager to do?  This is exactly what this paper is about.  It presents a new paradigm in software design that separates out more clearly from the outset the business decision processes from the software coding.  It allows these business rules to be tested rigorously before they get anywhere near the code-writing process.  The approach, called ODASE[PW2] , allows the business to assemble a complete description and execution of the business requirements as a separate activity, before any software is written.  Programming is only required for the technical scaffolding necessary for a full working solution.

​

​

A new paradigm for software development

​​

The need for a new paradigm for software development is clear to those who have suffered from poor software design and implementation.  The postmasters in the UK who had to deal with the consequences of errors in the “Horizon” system[i] are at the extreme end of a spectrum of faults, but it is not outside of the experience of many people in Western Europe or North America to have the experience of a major system outage that was due to a failure in software [ii] [iii].  The detail of the software errors in these cases is long forgotten, whilst the social and reputational costs for those involved in writing and providing these software services is high.  It is not as though the trend is for a simplification of the software landscape.

 

The development of Retail 4.0 [iv] with “Omnichannel” sales and tight integration with modern logistics practices, or the complexities of “Quality by Design” as implemented in a Pharma 4.0 environment imply that the software development process is dependent on an extremely complex landscape of information and business rules.

​

Comprehensive gathering and modelling

​

This is the area that ODASE addresses. It provides a proven approach to gathering, modelling and then validating an assembly of business data and rules so that the software is built up around this valid information infrastructure rather than weaving it piecemeal into the software as the programming takes place.

​

The ODASE approach provides a clear separation of the business “What” from the software programming “How”.  The total set of business information and rules is specified and validated separately from the programming that delivers the mechanics of their manipulation. This specification of business information and business rules needs to be ‘declarative’, that it must only express business knowledge in a language that the business understands, avoiding any of the IT “how”. 

 

By focusing on the business information and business rules as a distinct entity the ODASE approach uses modelling techniques to check that all the information is present to provide the outcomes the business expects of its information, and that the business rules applied are complete, unambiguous, and logically valid. 

​

A complete specification of the business information and rules

​

The result of the ODASE approach at this stage is to provide a complete specification of the business information and rules that can be combined to build an “executable model” that behaves a little bit like a mathematical equation – if you give it inputs the model gives you outputs.  The executable business model is used against a broad set of competency questions to validate the completeness of the modelling process.  An executable business model developed using the ODASE approach can provide an explanation of how any result from the model was achieved.  This ensures that the set of business information and business rules is complete and fully understood. 

 

The corollary of this is that there should be zero defects coming from this executable business model.   This provides the programming side of the system development process to have significantly reduced concerns about data quality and completeness, allowing the IT team to focus on delivering a fully-working application that is suited to the enterprise’s IT infrastructure.

​

Built on the techniques for the Semantic Web

​

The ODASE approach is built on the techniques and supporting technical infrastructure for the “Semantic Web” – an idea that was there is Tim Berners-Lee’s initial drawings of the World Wide Web idea [v], that a web of information could be built up if we have a model that identifies the ‘things’ in our information and directional relationships which have their own meanings and relate one ‘thing’ or kind of ‘thing’ to another.  If these relationships are provided with a specific modelling vocabulary and other attributes, such as if the relationship is transitive or has a specific inverse relationship, then it becomes an approach that allows us to use formal logic, such as predicate logic, and we can do this with computer assistance.  No longer do we have to guess or infer what the type of data is in a spreadsheet cell, or what the relationship is between that cell and any other in that spreadsheet.  This web of data is a way for the meaning, the semantics of the relationship between information points to be specified unambiguously and for computers to be able to both query and reason over that data web.

​

This is the ‘special sauce’ of the ODASE method.  The modellers take what they learn from analysing the business information and speaking to people in the business and bring this information together into an ontology that models the types of information points and the kinds of relationships present in the business information, and this is then used to both develop a description of the business rules and to implement a web of data.  Taken together these are often termed a ‘knowledge graph’. As the modelling develops, the data structure is queried, rules are implemented, and the results returned are compared with expectations. 

​

Building the right model

 

The skill is in building the right model, capturing all the data types, and building an effective and concise knowledge graph and rule base. In the ODASE environment this is now an executable business information model, and it can be used directly by the programming team to deliver results to business applications.  This complete separation between business information modelling and developing software solutions using the validated executable model[MVB3]  is the key to dramatically shrinking the ‘bugginess’ of business software.  Each element can be tested independently, and this reduces the overall complexity of the software development process which is generally the root cause of software development failures such as described earlier.

​

Bug-free

​

Having the clear modelling of the information this way continues to deliver business benefit beyond significantly improving the chances of bug-free software.  It also makes it easier to spot where, for example, personally identifiable information (PII) or other specified information types are being used across the business, and this leads to a reduction in the burden of legislative compliance e.g. General Data Protection Regulations (GDPR) or Sarbanes-Oxley (SOx).  Software reliability, the deep understanding of how information is used, and the ability to explain all decisions made over a set of business information using specific business rules are all at the heart of ethical software. 

 

Reliable and ethical software

​

With ODASE this is ‘built-in’ rather than ‘bolt-on’.  Steve Jobs described the importance of focusing on values [vi], and companies building software to deliver information-rich products and services will want to be sure that these are built in ways that reflect and implement their values.  The ODASE approach provides a solid approach to building reliable, ethical software. Being ‘reliable’ and ‘ethical’ in this case means that the software assembled around the ODASE executable business model will return explainable results that use the appropriate business information in ways that follow the business rules and the appropriate consequential inferences of both the modelled data and these rules.  Both enterprises and their clients will find that they can trust the data.

​

Concrete examples

​

ODASE executable business models are at the heart of software systems in several business types. 

Examples of these include:

​

• A season ticket flexible product and pricing solution for the Belgian Railways [vii] that provides the agility, adaptability and cost-effectiveness desired by the business, and at the same time meshes well with the cloud-based API accessibility and high performance that the corporate software development style required.
   

• A pricing and scoring application for a large insurance company’s [PW4] car insurance products that efficiently generates quotes, calculates the pricing of contracts and determines the applicability of a product based on an acceptance policy [viii].  The application serves about 30,000 requests per day. Changes to insurance products are made by changing the ontology and rules which, after testing, are used directly by the production application. This separation of business information modelling activities from software programming that is key to the ODASE approach results in the time-to-market following changes in the business information or business rules being dramatically reduced. In addition, the resulting application has been noticeably free of bugs.
   

In addition to the comprehensive systems mentioned above, the ODASE approach has been used in development or experimental stages in the following business domains:
 

• Defence (Command and Control message translation or BML, Battle Management Systems)

• Human Resources

• Life Science (Configure/Price/Quote for bespoke proteomics and genomics).

• Consolidating financial data for dashboards

• Transport (alarm correlation)

• Telecommunications (Configure/Price/Quote)

• IT (IT4IT, i.e. Configuration Management)

• Banking (an experimental Semantic Bank)

• Complex regulations (FATCA, US Foreign Account Tax Compliance Act)

 

Paraphrasing Fred Brooks’ observations from almost 40 years ago [PW5] , [ix]  the greatest challenge in building software is getting the information model correct.  This still true today, but the ODASE approach is an elegant method to help enterprises succeed quickly in this challenge.[PW6] 

​

​

​

​

​

​​

Sources:

 

[i] “Post Office Horizon scandal explained: Everything you need to know” - https://www.computerweekly.com/feature/Post-Office-Horizon-scandal-explained-everything-you-need-to-know

 

[ii] “Global transport systems struck by IT failure. Airline check-in, train tickets and payments onboard ferries are among the services disrupted.” - https://www.airport-technology.com/news/global-transport-systems-struck-by-it-failure

 

[iii] “Screwed Drivers Open ATMs to Attack” - https://eclypsium.com/research/screwed-drivers-open-atms-to-attack/

 

[iv] “Retail 4.0: The Future of Retail Grocery in a Digital World” - https://www.mckinsey.com/~/media/mckinsey/dotcom/client_service/retail/articles/the_future_of_retail_grocery_in_digital_world%20(3).pdf

 

[v] “Information Management: A Proposal” - https://www.w3.org/History/1989/proposal.html

 

[vi] “Steve Jobs - Apple Core value” - https://www.youtube.com/watch?v=JayWnYq9zks

 

[vii] “Ontologies and Semantic Rules in Real Life.  A Mission-Critical Product and Pricing Solution for the Belgian Railways” - https://ceur-ws.org/Vol-3816/paper32.pdf

 

[viii] “The Logic of Insurance: an Ontology-Centric Pricing Application” - https://www.ceur-ws.org/Vol-1383/paper2.pdf

 

[ix] Brooks, F.: No Silver Bullet: Essence and Accidents of Software Engineering. In Computer, Vol 20, No 4 (April 1987) pp 10-19.

 [PW1]Changed following discussion

 [PW2]Might review

 [MVB3]Remember my remark: separation between business and IT

 [PW4]Can we mention Aviva?  Is this still in operation?

 [PW5]I am wondering if this quote, whilst true, needs some explanation, and so it might not be appropriate here – in a paper of this type.

 [PW6]I think that the quote #10 (Sterling & Shapiro) is just a little too ‘academic’ and perhaps we should leave that one out.