Designing Services, Messages & Business Rules for eBusiness Graham Witt

Topics  Some background Why this project was a bit different The techniques we used Managing change Lessons and benefits Further reading Slide 2© Graham Witt 2012

Some background The client:  NSW Land & Property Information their examples reproduced with thanks The overall requirement:  a set of services, to support supply of information by industry to government (B2G) by government to industry (G2B)  incoming information governed by numerous business rules Implications:  Business rules need to be: implemented in multiple platforms visible to multiple stakeholders (as far upstream as possible) Slide 3© Graham Witt 2012

Business rule visibility across the end-to-end process To avoid rework data compliance should be checked as early as possible Industry therefore needs access to Land Registry business rules © Mathew Cooper / Graham Witt 2012Slide 4 Client Subscriber Certifier Electronic Lodgement Network LR Land Registry Business Rule Book Industry case management systems Electronic lodgement & registration systems Common data standard Pre- lodgement acceptability checks Financial institution systems

The challenge To convert from  unstructured information with accompanying supporting evidence, to  structured data for automated compliance checking To convert from  manual compliance checking by expert examiners at the Land Registry, to  compliance checking by industry To automate manual compliance checking  in industry and the Land Registry Slide 5© Mathew Cooper / Graham Witt 2012

LR Information flow Paper conveyancing: “show me” Electronic conveyancing: “tell me” Slide 6 Lodgement Case ELNELN Client Identity Verification Client Authorisation Agreement Control of Right to Deal Registry Instrument Supporting Evidence Notice of Sale Lodgement Instruction ‘Paper curtain’ Land Registry Transaction Services Digital Signing Instrument Certification Registry Instrument Client Subscriber Certifier © Mathew Cooper / Graham Witt 2012 Subscriber System

Topics Some background  Why this project was a bit different The techniques we used Managing change Lessons and benefits Further reading Slide 7© Graham Witt 2012

A generic system © Graham Witt Slide 8

A typical system © Graham Witt Slide 9

This system © Graham Witt Slide 10

Topics Some background Why this project was a bit different  The techniques we used Managing change Lessons and benefits Further reading Slide 11© Graham Witt 2012

Techniques Standardised terminology (common agreed vocabulary) Business-friendly service definitions  Service Use Cases aka Message Use Cases  BPMN process models where service logic complex Business-friendly message descriptions  Business-friendly notations  Design component re-use Natural language business rule statements  Catalogued against data items © Graham Witt 2012Slide 12

Standardised terminology For all artefacts  Services  Message types  Data items  Data types  Processes Agreed Terms, compatible with current industry terminology, with:  agreed definitions (intensional)  synonyms (allowed and prohibited)  exclusions (“as distinct from”) Taxonomic relationships between Terms, e.g.,  Person is a category of Party Fact types, linking Terms using verb phrases, e.g.,  Document specifies Transacting Party © Graham Witt Slide 13

Service Use Cases – 1 Slide 14© Graham Witt 2012

Service Use Cases – 2 Slide 15© Graham Witt 2012

Service Use Cases – 3 etc. © Graham Witt 2012Slide 16

BPMN process models © Graham Witt Slide 17

Business-friendly message descriptions Describe content of message types in terms of  data items  relationships between them  cardinality and some content rules Various textual and diagrammatic representations tried  Entity-Relationship diagrams  XMLSpy diagrams  “Hand crafted” structure diagrams (in Visio) “High-level” block diagrams Hierarchic block diagrams with legal numbering Slide 18© Graham Witt 2012

“High-level” block diagram © Graham Witt Slide 19

Hierarchic block diagram with legal numbering © Graham Witt Slide 20

Data types – 1 Reusable data objects, i.e., that appear in multiple places in messages May be simple, e.g., May be complex, e.g. © Graham Witt Slide 21

Data types – 2 May be part of a taxonomy, e.g., © Graham Witt Slide 22

Message types Consist of data items that either:  have a data type, or  are composed of other data items © Graham Witt Slide 23

Natural language business rule statements – 1 Constrained natural language  Standardised terminology (terms and verb phrases)  Standardised syntax Allows for easier checking of duplicates, contradictions etc Can be understood by business stakeholders and information providers as well as developers Each catalogued against relevant data item © Graham Witt Slide 24

Natural language business rule statements – 2 Also full form of rule statement  Stand-alone (requires complete context)  Can be used as error message expressing desired condition © Graham Witt Slide 25

Topics Some background Why this project was a bit different The techniques we used  Managing change Lessons and benefits Further reading Slide 26© Graham Witt 2012

Managing change No repository dealing with all this and change Considered wiki approach: need relatively stable position for this to work Many reviewers  so needed accessible well-understood documentation and review platform MSWord allowed:  version deltas (revision marks)  reviewers’ proposed changes (revision marks)  reviewers’ comments (comments)  hyperlinks for navigation within and between documents PDF allowed:  publication of final versions Version number/folder discipline:  Published\...vn.00  WIP\...vn.mmaa (e.g., v2.01GW, v2.02PN) Slide 27© Graham Witt 2012

Topics Some background Why this project was a bit different The techniques we used Managing change  Lessons and benefits Further reading Slide 28© Graham Witt 2012

Lessons and benefits Lessons: the importance of agreeing, defining and using a common glossary the need for precision in language used the need to define concepts, messages (data), services/processes and business rules concurrently and iteratively, e.g.  errors in message design identified during rule writing Benefits: simplification of existing processes the business has been able to define, communicate, review and update its requirements Slide 29© Mathew Cooper / Graham Witt 2012

A measure of success NECDL, the national body tasked with implementing electronic conveyancing, needed:  a single common data standard  a set of message types incorporating the various state requirements That body:  determined the functional requirements for the national system  used the NSW message and document schemas as the basis for the common data standard  adopted the NSW documentation techniques  then incorporated each jurisdiction’s additional or different requirements  to produce a common data standard for the National Electronic Conveyancing System Slide 30© Graham Witt 2012

Topics Some background Why this project was a bit different The techniques we used Managing change A measure of success  Further reading Slide 31© Graham Witt 2012

Further reading – 2 Slide © Graham Witt 2012

Further reading Slide 33

Any questions? Slide 34 What?How?Who?When?Where?Why? © Graham Witt 2012