a = REATECHNOLOGY REA (Resources, Events, Agents) Pavel Hruby Presentation at Vienna University of Technology November 3, 2008 This presentation is about the REA (resources, events, agents) model, which is going to revolutionize the way the software business applications are developed. We'll compare two solutions of the same problem: 1. A business process in a successful state-of-the-art business software application (Microsoft Dynamics NAV) 2. The same process in an REA application, We will sketch other advantages of the REA model in the area of interoperability and e-commerce. Note: lower the screen resolution to 1024x768, because otherwise the demonstrations would be difficult to see.Fundamental Principle of susiness = REATECHNOLOGY The economic activities of an entity are a sequence of exchanges of resources Ra the pracess of giving up some resources to obtain others. Therefore, we have to not only keep track of increases and decreases in the resources that are under the control of the entity but also identify and record which resources were exchanged for which others,” Yuji tir Yuji ii : The Foundations of Accounting Measurement, Prentice-Hall 1967. 10The REA (Resources, Events, Agents) model fo with Commitments and Contracts = REATECHNOLOGY ‘Contact Lo = co on ween William McCarthy Soo eene sen || io Tea = aaa — pera “Accounting Systems in a Shared Data Environment. The Accounting Review (Gaty 1882 pp 5078 Guido Geerts ‘Enterprise Information Systems, 1208, Bill McCarthy made a data model based on ljir’s ideas. Bill McCarthy with Guido Geerts later extended the model with the concepts of Commitment and Contract, and several other concepts such as Group, Type and Policy. REA specifies the rules that every real business system conforms to, such as: -every economic event has a provider and a recipient agent; -every economic event is related to a resource, -every economic event is related to another economic event explaining what the agent receives in return. -every commitment is fulfilled by an economic event. "Axioms of the REA Ontology | for exchange processes, independent view S LS REATECHNOLOGY [Eehcsretic et tbe tatty action rtatonstipeo enacty ne Each economic event must be related to exactly one provider and one recipient [ sence agen. Each economic event must eventually be related by duality relationship to another ‘economic event, in which the provider agent receives an economic resource which has more value to this agent in its pursuit ofits entrepreneurial goals. | Each economic resource must be related by stockflow relationship to at least one ‘economic event where an agent is a recipient, and to at least one other economic ‘event where the same agent is a provider. Each commitment must be eventually related by fulfillment relationship to at least one economic event. [ ESRSottnt is be eated by reservation elation to racy one Each commitment must be related to exactly one indented provider and one lnmtended recipient economic agent. — page 12 Similar axioms exist for conversion processes, where the rules regarding the number of agents in each process is different.g Partners of susan’s Gallery zE REATECHNOLOGY i Acquistion co si: GE). 2 ey We Susan's Gatery Variations: rayment by cash / credit card ment beforehand / afterwards the Sate/Purchase page 13 yment on account, by subscription, in installments We'll create an REA model for Susan’s gallery.The Sales Process .. S REATECHNOLOGY _{(conange proms» Artwerk npr cash economic agente carom agents ‘aller, *Suatomer Treo ae dre sexnarges [economic overt» Sale of Artwork does not need to occur at the same time as Cash Receipt. The time order of the events emerges at runtime. Cash receipt can occur after or before the Sale of Artwork, can occur in installments, or some Cash can be received as a prepayment beforehand and the rest after the Sale. This flexibility is very useful when designing software applications that has to deal with unexpected user requirements. 14The Acquisition Process = [<== NSN REATECHNOLOGY >, cam sf ee” }—= am seomomi gente tery Tame | secages [ERRRSee equation eth lass ie page 15 The acquisition process follows the same pattern.The Rental Process = —— REATECINOLOGY (coaangepumas” so. ecnge gone Petion = 2g seoonome gente seconome spent ‘alieny Property Owner a one | Renal = cash -—_ “Soa eahibtion ea page 16 The rental process follows the same pattern.Business Processes of susan’s Gallery —— REATECHNOLOGY Susan cate (=) page i7 This is an REA version of Porter's value chain. REA gives a precise definition of the term “business process”. A business process is a set of economic events related by duality relationship. 17Process of Gallery Services = REATECHNOLOGY _ soln ols Ze SS ae a T-shirt with Miami Beach Topics J siao9 lf 7 Relax in this high quality (Hanes-Beef y- T) white T-shirt with Miami Beach Topics silk-screened on the front. The “ back is plain. page 28 Should also suggestions how to relax be part of the REA ontology? 28Conflict ze Ontologies are designed to be general I the same categories for all systems in the domain E-commerce applications are all different I They must meet specific user requirements page 23 | would prefer to keep the REA ontology small and focused. The but a software applications, as well as e-commerce standards need placeholders to accommodate variability. 29Susan Works Here = REATECHNOLOGY Susan is a manager of an ART GALLERY. Susan buys and sells fine art, and design furniture.Two Parts of an Application .. EEN REATECHNOLOGY 1. REA is the stable core | REA describes principles that mever change, and | apply to all e-commerce anc procuction planning ‘Stable Core(REA) applications Specific |” \ 2. Reusable components that Requirements |~ | Software | ‘Glagnoater’ |» (Application, | are designed to Change often crane 1 are industry and application Specific ‘extend the REA model in a consistent manner can be implemented, for example, as SOA services: page 30 “Never change’ is a strong statement, and, of course, also the basic laws of physics change once in every couple of hundred years. But for the purposes of creating a particle accelerator it is safe to assume that \c? is not going to change. Likewise, it is safe to assume that the basic laws of ‘ess, defined by the REA ontology are stable, for the purposes of designing e-commerce applications. 30Model-Driven Design of Business Applications .. REATECHNOLOGY ous Dama ity Cow) CE ee == ane ee gcormogres [Sonera nates 7 ane oe ee The REA ontology can be extended by other ontologies covering the specific requirements. Software applications can be developed by “weaving” other ontologies into the REA ontology. This is especially useful in model-driven design. The “weaving” is, sometimes referred to as “model merge”. 31as = REATECHNOLOGY | =» |__ salesforce.com E-Commerce and Interoperal Microsoft Dynamics = [=p ——~ Peoplesoft Pe resource row TE Pert (ents aw ad no epee in UNL 2.0) page 32 Interoperability can be based on shared business semantics defined by the REA ontology. This will assure a conceptually consistent model, where also some requirements, unknown to committees developing the e-commerce standards, will be fulfilled. 32Electronic Document Standards a (non-REA standards) ———— ay REATECHNOLOGY Examples I Universal Business Language (UBL), developed by OASIS. [O10XML (offentlig Information Online) in e-Government in Denmark I Cross-Industry Invoice, developed by UN/CEFACT I XBRL GL (eXtensible Business Reporting Language, Global Ledger) They are driven by requirement of compatibility with all of the data and document formats that exist in the world, instead of being driven by domain semantics and conceptual integrity, UBL and UN/CEFACT are two leading standards developed independently on each other. OIOXML — *Offentlig Information Online XML" (‘Public Information Online” in Danish) is based on UBL. 33Example: a Cross Industry Invoice - UN/CEFACT = I REATECHNOLOGY ‘Anon-REA approach (adapted from UN/CEFACT) [ tnvoiee is = message elalming payment for goods or services supplied under consitions aoreed between the suppher and ti customer Definition 1] invoice Heacer Invoice fw baler: [-echarnaverdon:ating [> tnvoice Line 1 xs0 covers MOST COMMON, but not all, scenarios. I Allows interoperability by using brutal force (.e. legislation) atic tha a wm ueceorlefct casera! ance CCLBER. se UN/CEFACT - United Nations Centre for Trade Facilitation and Electronic Business. UNECE - United Nations Economic Commission for Europe. page 34 34Cross Industry Invoice - a Better Model = ENN REATECHNOLOGY Apossible solution epistemologically adequate to REA [| lnvoice isa message elalming goods or services, for goods or services supplied under ‘conditions agreed between the supplier and the customer. Materatzed Claim |_Tateiaized 1+ sDateOrissve setlement__1.+| Eeanomlc Event *SeraiNumber Terms 1 Covers ALL scenarios. [Allows interoperability at semantic level - economic semantic ofthe document can be Interpreted by a software application. page 35 Details about REA claims are here: -Geerts G., McCarthy W.: Augmented Intensional Reasoning in Knowledge- Based Accounting Systems. Journal of Information Systems, Volume 14, No. 2, 2000, pp. 127-150. International standard ISO/IEC FDIS —15944-4 Information technology — Business Operational View — Part 4: Business transaction scenarios — Accounting and economic ontology 35NY Why is REA Better tnan your oinerreveite ontciogy? | REATECHNOLOGY “Ontology is a study of the categories of things that exist or may exist in some domain...” I Sowa, J .: Knowledge Representation: Logical, Philosophical, and Computational Foundations, Course Technology, 1999, “based on some fundamental idea beyond the things immediately present.” [inspired by George Polya: How to Solve it, Princeton University Press, 1982. ‘The REA ontology is based on the fundamental idea of modeling business as exchanges of economic resources between business partners. page 36 36The REA Model is Also Good For . I REATECHNOLOGY Domain-specific language for modeling business systems | REA-based 0st for modeling business systems Feally WarKS. Providing complete past, present and future information about an enterprise [Avaliable on demand and understandable to non-accountants Electronic business |The REA model enables Interoperability sed on understanding o: fundamental principles of business domain, rather than on political consensus. Design method for tongiving applications [| The REA model enables to separate the stable ¢ore and ‘the Changeable part of the =)s=m ; page 37 37REA as a Design Method = ™ REATECHNOLOGY Other modeling WHAT - the economic resource approaches WHEN - the economic event underemphasize or completely omit WHO _ - the economic agents "ha Why: HOW — - services (extending REA) WHERE - the address service WHY —- the duality and fulfillment ‘An example of an REA-based design method is UMM, the 2003 version: un/cEFACT Modeling Methodology User Guide, 2003, document CEFACT/TMG/NOS3 /cefact/umm/UMM userguide 220606, The REA model is the only known business modeling method that can provide the answers to why business processes occur, why an enterprise performs its business processes, and why a specific modeling element is part of the model. ‘An example is: “Why do customers need to pay this shop?” The answer, which an REA-based model can provide, is: “Because they received the goods.” This answer cannot be given by any alternative business modeling method, because the business interpretation of the modeling elements, and business validation of the model, are not available to a tool and are left solely to the modeler. 38My Favorite Books on susiness patterns = REATECHNOLOGY Agursis ParrERNs: Ennaras ma Ds Eze Here are examples of excellent books containing a lot of domain knowledge. But they describe the domain knowledge as independent pieces of information, with no relationships between each other, without a common backbone. 39Susan Uses a State-of-the-Art Business Software to Keep Track of her Business a S REATECHNOLOGY (we use Microsoft Dynamics NAV as an example) page 4Business Patterns with the REA Backbone = NN REATECHNOLOGY Pavel Hruby, Jesper Kiehn, Christian Vibe Scheller: Model-Driven Design Using Business Patterns I Springer, 2006 (Endish edition) | Nikkei BP, 2007 ( apanese edition) ccs ceed “The best book on REA so far” Dave Feinstein at http://amazon.com DRANG ese leet Selected chapters are in: Capitalism in UML: Designing Service-Oriented Applications that Understand your Business ‘http://www om/papers Our book describes business patterns with the REA backbone. Dave Feinstein wrote at amazon.com: “I came across Fowler's book and | think it was great and | liked it so much, especially modeling the account and the related entries. But that was about it as far as the simplicity goes. It started to get a bit more complex as I started to get more patterns. | started to do some more searches till | got to the REA, Resources- Events- Agents and that was it. Iwas blown away. The model is so simple but powerful in capturing the most fundamental concepts in the accounting and business domain. So | think, REA model will change the business information modeling arena in the same way object oriented programming changed the programming world, and like design patterns impacted the design world. lalso predict that this book will be for the business application architecture community as the GoF book to the software designers community at large. * 40_ Other REA Books tor students of Accounting = LLL REATECHNOLOGY = & nang et al, 2007 shows how easy is to develop REA ations using Microsoft Access [Dunn et al. 2004 is targeted to students of accounting, I Hollander et al. 1999 describes the REAL made! (Resources, Events, Agents and Locations Page aREA Community .. REATECHNOLOGY REA Bootcamps (SMAP - Semantic Modeling of Accounting Phenomena) for teachers in accounting information systems, held every J anuary in the USA, International workshops | 2008, 8-9 February, in Stockholm, Sweden 1 2008, June, in Montpellier, France 1 2006, June, on Santorini, Greece 1 2004, Ap International conference REA-25, Newark, Delaware, USA, 2007 in Copenhagen, Denmark REA Software REA Technology offers probably the most pure and complete REA application ‘so far, which is also model-driven, and with clear separation of the REA part and the designed-for-change part. Workday’s goal is to offer an alternative to ERP. The REA model is one of many of their differentiators to traditional ERP systems Group Accounting offers an REA solution for cooperatives — groups of independent individuals working together. This is very hard in traditional accounting solutions, which only work from the viewpoint of a proprietor. REA supports the “independent view” out of the box, allowing, for example, modeling the supply chain. 42Summary Features of REA Business Solutions LE REATECHNOLOGY independent view (a trading-partner-independent model) ao [REA spptcations provide supply-chain management and scounting | Trectionel applica ons are limited to the viewpoint of « proprietor. 2.Both monetary and non-monetary elements of transactions {REA applicstions seertesy integrate production and finances. Traditional accountings limited to financial transactions, and pommonetary tananctons are confusingly represented ih Fnmncial iit of measure (og as dlr value). [roses acc retary sg recone Kita telants tiaet erie Expected vamann(eo: plans, budgets) [pee iann< manera a Agreed vmacine (e.g. orders, contracts) | scton, epstion nd praiction of he cea crpieatons HTraditional solutions Transferred vnmsine(transactions made) | | Confusing maces of the past event) Realized rmnason (0.9. claims, invoices) oman Teieenatvn "nave page ad 43s Contact LS REATECHNNOLOGY Pavel Hruby http://reatec! (com Sarena page 44a = REATECHNOLOGY Let’s take a Closer look (demo) | will show you that some tasks are very easy, but some are not. In fact, every software like this has some very serious problems, and | will show you just a little example. Itis interesting that everyone with basic knowledge of REA can very quickly discover from a particular application's data model, which common business scenarios will be supported and which will not be.Why . REATECHNOLOGY It is Very easy to create a sales order. Why is it so difficult to find out whether an order has been paid? Using a State-Of-The-Art Business Application? Itis so difficult because Microsoft Dynamics NAV is a software for ACCOUNTANTS. For accountants, the process ends when an invoice is issued (at that time the revenue is recognized and tax is calculated). Accountants even call the transaction at that point "REALIZED”. However, for Susan (an owner of the gallery) is very important to know whether invoices have been paid. You might know that companies sometimes receive a fraudulent letter, stating that a company forgot to pay a small amount, such as 30 or 50 USD, several years ago. Accountants sometimes pay that — because it is very difficult to verify this information in the current accounting software applications.That’s You = REATECHNOLOGY a Business Analyst and Software pesigner page? Accountants did not tell you about how important is to register a payment and link the payment to other transactions, such as to the sales order. But you would like to make a software application that satisfies Susan's - the gallery manager's requirements, not only the accountant's requirementsHow do You Identify user Requirements that Have not Been communicated to You? as REATECHNOLOGY By page 8 User requirements are certainly an important input to software design, but we also know that they are always incomplete. But how could we possibly know something we do not know about?How do You Identify user Requirements that » . Have not Been communicated to You? — REATECHNOLOGY You could consider the REA model, (Resources, Events, Agents). The general principle that applies to all business systems. REA is for business systems what Einstein’s @=MC? is for physics. You can use REA to determine the unknown pieces of the software design, similarly as you use the laws of physics to determine the unknown pieces of a technical construction.