Real-Time Business Assurance Chung-Sheng Li DGM, Security, Privacy and eXtensible technologies IBM Research Division Research Division used to contribute to the Problem. We like to be part of the Solution in the future! November 8, 2006

Why Real-time Business Assurance? Real-time business assurance allows enterprises to comply with regulations and minimize risk Continuous Allows mistakes or fraud to be detected early, rather than long after the fact. Avoids restatement of results. Integrated Current solutions are fragmented. Fragmentation in solutions between partners and service providers (Ex.: IBM and Lenovo have different standards for revenue recognition) “Organizations that choose individual solutions for each regulatory challenge they face will spend 10 times more on compliance projects than those that leverage each implementation for multiple requirements (0.9 probability).” Gartner ITxpo, 2005 Complete Current auditing methods only verify integrity of a sample of transactions, and does not offer a complete view of the state of the enterprise. Can miss major accounting errors. Continuous auditing is gaining steam 81% of companies had or plan to have continuous auditing (PwC survey), e.g. Siemens, Cisco, FDIC. From 2005 to 2006, companies with continuous auditing jumps from 35% to 50% (PwC survey) Continuous information assurance (CIA) in a world with ever increasing and complex regulations on and among enterprises and service providers will drive productivity gains and transparency. New technologies in policy automation, information provenance and risk analytics will emerge to enable CIA Trends Compliance costs in enterprises increasing due to complex regulations and standards Increased regulation not restricted to financial or heavily regulated industries High cost due to non-compliance, fraud and improper risk management Fragmented GRC point solutions, including inter-enterprise fragmentation due to outsourcing and mashups Continuous compliance, auditing and monitoring gaining steam Implications Continuous compliance and monitoring of regulations, standards and policies will lead to productivity gains, transparency, better strategic planning and risk mitigation. GRC solutions will take into account the complex nature of regulations through policy automation GRC solutions will be integrated and interoperable, both across the enterprise and between the enterprise and solution providers A unified quantifiable risk framework will emerge facilitating risk management and mitigation across enterprises and service and solution providers Underlying all this will be information provenance which will emerge as an enterprise requirement utilizing provenance-aware middleware, applications, and storage Representational State Transfer (REST) SOAP was an acronym for "Simple Object Access Protocol". JSON (pronounced as IPA [dʒeɪsən], or like the English given name "Jason"), which stands for "JavaScript Object Notation", The Extensible Markup Language (XML) Synchronization: e.g., google maps and inventory system. From client to middleware-supported Policy-based dependency management. Automated fault-tolerance: required because of #apps, #dependencies, and lifecycle. The use of mashups w/ external Web services for increasingly vital enterprise applications will continue the disaggregation of IT Businesses will deal with information goods & services in the same management framework as they deal with physical goods & services Tools will shift focus to facilitate the management of external business services, not just machines and applications Thus allowing IT to manage the increasing cross-organizational dependencies in a scaleable & robust fashion New middleware and new infrastructure are needed to support: Rapid, lightweight development and deployment of Web services applications Increased automation and monitoring of SLAs, including “micro-SLAs” with existing suppliers Componentized middleware that delivers just the right function required for the application, and enables and enforces policies for the web services consumed by the application New legacy adaptors will have to be developed to mediate between legacy and Web 2.0 protocols Infrastructure that supports rapid deployment, rapid operational change, and rapid tear-down Radically simplified adaptive systems management in a dynamic unpredictable environment Representational State Transfer From Wikipedia, the free encyclopedia (Redirected from REST) Jump to: navigation, search "REST" redirects here; for other meanings of the word "rest", see rest. Representational State Transfer (REST) is a software architectural style for distributed hypermedia systems like the world wide web. The term originated in a 2000 doctoral dissertation about the web written by Roy Fielding, one of the principal authors of the HTTP protocol specification, and has quickly passed into widespread use in the networking community. While REST originally referred to a collection of architectural principles (described below), people now often use the term in a looser sense to describe any simple web-based interface that uses XML (or YAML, JSON, plain text) over HTTP without the extra abstractions of MEP-based approaches like the web services SOAP protocol. It is possible to design web service systems in accordance with Fielding's REST architectural style, and it is also possible to design simple XML+HTTP interfaces in accordance with the RPC style but without actually using SOAP. These two different uses of the term REST cause some confusion in technical discussions, even though RPC is not an example of REST. Systems that follow Fielding's REST principles are often referred to as RESTful; REST's most zealous advocates call themselves RESTafarians JSON JSON (pronounced as IPA [dʒeɪsən], or like the English given name "Jason"), which stands for "JavaScript Object Notation", is a lightweight computer data interchange format. JSON is a subset of the object literal notation of JavaScript but its use does not require JavaScript. The official MIME Media Type for JSON is application/json. JSON's simplicity has resulted in its widespread use, especially as an alternative to XML in Ajax. One of the advantages of JSON over XML as a data interchange format in this context is that it is much easier to write a JSON parser. In JavaScript, JSON can be parsed trivially using the eval() procedure. This was important for the acceptance of JSON within the Ajax programming community because of JavaScript's ubiquity among web browsers. In practice, arguments regarding ease of parser development or parser performance are rarely relevant due to security concerns regarding the use of eval() and the rise of built-in XML processing features in modern web browsers. For that reason JSON is typically used in environments where the size of the data stream between client and server is of paramount importance (hence its use by Google, Yahoo!, etc. which serve millions of users), where the source of the data can explicitly be trusted, and where the loss of fast access to client-side XSLT processing for data manipulation or UI generation is not a consideration. While JSON is often positioned "against" XML, it's not uncommon to see both JSON and XML used in the same application. For example, a client-side application which integrates Google Maps data with SOAP weather data requires support for both data formats. There is growing support for JSON through the use of lightweight third-party packages. The list of supported languages includes ActionScript, C, C#, ColdFusion, Common Lisp, E, Java, JavaScript, Lua, ML, Objective CAML, Perl, PHP, Python, Rebol, and Ruby. In December 2005, Yahoo! began supporting JSON as an option for some of its Web services SOAP This article is about the computer protocol. For the common cleaning mixture, see Soap. For other uses, see Soap (disambiguation). SOAP is a protocol for exchanging XML-based messages over a computer network, normally using HTTP. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework that more abstract layers can build on. There are several different types of messaging patterns in SOAP, but by far the most common is the Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another node (the server), and the server immediately sends a response message to the client. Indeed, SOAP is the successor of XML RPC. Extensible Markup Language (Redirected from XML) The Extensible Markup Language (XML) is a W3C-recommended general-purpose markup language for creating special-purpose markup languages, capable of describing many different kinds of data. In other words, XML is a way of describing data. An XML file can contain the data too, as in a database. It is a simplified subset of Standard Generalized Markup Language (SGML). Its primary purpose is to facilitate the sharing of data across different systems, particularly systems connected via the Internet. Languages based on XML (for example, Geography Markup Language (GML), RDF/XML, RSS, Atom, MathML, XHTML, SVG, Klip and MusicXML) are defined in a formal way, allowing programs to modify and validate documents in these languages without prior knowledge of their particular form Another big benefit are the easily composable and low-impedance Web services which turn applications into platforms.  This is the use of REST and XML/HTTP (

Scenario: Continuous Auditing for the Revenue Cycle Major Auditing Cycles Revenue/ Collection Cycle Acquisition/ Expenditure Cycle Production Cycle Payroll Cycle Finance and Investment Cycle Shipping system Billing Order entry Cash receipts Sales order Shipping notice Sales invoice Customers Inventory ↓ Cost of Goods Sold ↑ Accounts Receivable ↓ Cash ↑ Accounts Receivable ↑ Revenue ↑ Receive a request for goods or services Deliver the goods or services Request payment for the goods or services Receive cash in payment Payment Credit Granting Credit files, reports Customer payments (cash receipts) Customer order Purchase order, contracts

Continuous Assurance Architecture for Revenue Collection General Ledger (Journal) Supporting Documents for A/R Reserve, Discount, Returns and Allowance Policy Repository (e.g. Accounting Practices, Revenue Recognition guidelines) Ledger System Account Receivable (Master) Dashboard 2 Order System Credit Check (Master) Alert Pending Order (Master) Policy Engine Business Integration Server (e.g. WPS) Back Order (Master) Information Integration Server (e.g. WII) Compliance Report Billing System Streaming Control Identification & Audit Engine (based on quantifiable control risk) Sales Invoice (Master) Master Data Management (e.g. WPC, WCC) 3 Inventory Control System Transaction Provenance Store Control Provenance Store Audit Provenance Store Inventory (Master) 1 1 1 Cash Receipts System Cash Receipts (Master) Isolation and segregation Isolation and segregation Isolation and segregation

Continuous Assurance Architecture for Revenue Collection General Ledger (Journal) Supporting Documents for A/R Reserve, Discount, Returns and Allowance Real time identification of “controls”: based on quantifiable risk framework for assessing the inherent risk, audit risk, control risk, and detection risk Policy Repository (e.g. Accounting Practices, Revenue Recognition guidelines) Ledger System Account Receivable (Master) Dashboard Policy for revenue recognition: e.g. IBM recognizes revenue at shipping, Lenovo recognizes revenue at delivery; gross vs. net, multi-element arrangement, etc. Policy for identification of “Controls”: e.g. any entity that has a sale price higher that $1M, or delivery latency higher than 7 days, or involving returned goods, or involving discount higher than 5%, or sales commission higher than 3%. 2 Order System Credit Check (Master) Alert Pending Order (Master) Policy Engine Business Integration Server (e.g. WPS) Back Order (Master) Information Integration Server (e.g. WII) Compliance Report Billing System Streaming Control Identification & Audit Engine (based on quantifiable control risk) Sales Invoice (Master) Master Data Management (e.g. WPC, WCC) 3 Inventory Control System Transaction Provenance Store Control Provenance Store Audit Provenance Store Inventory (Master) 1 1 1 Cash Receipts System Constructing the “entity” centric provenance: need to collect information on the entirely history of who has done what at when on the “entity” from order placement, credit check, order fulfillment, inventory verification, shipping verification (from carrier), invoicing, payment collection, account receivable, and general ledger. Potentially needing to extract provenance from supporting documents related to A/R reserve, discount, returns, and allowance. Cash Receipts (Master) Isolation and segregation Isolation and segregation Isolation and segregation

Discovery and/or Capture End-to-End Provenance General Ledger (Journal) Supporting Documents for A/R Reserve, Discount, Returns and Allowance Inference/discovery end-to-end provenance from business context and information warehouses Policy Engine Ledger System Account Receivable (Master) Policy Repository Order System Credit Check (Master) Pending Order (Master) Master Data Management (e.g. WPC, WCC) Provenance Discovery & Management (e.g. WII) Business Integration Server (e.g. WPS) Back Order (Master) Billing System Sales Invoice (Master) Inventory Control System Automatically capture provenance from execution of business processes Inventory (Master) End-to-End Provenance Store Customer, Product, and Price data Cash Receipts System Cash Receipts (Master)

Compliance Oriented Architecture Using Provenance Store Asynchronous vs. Streaming Assurance Assurance/ compliance is performed synchronously as applications record provenance into provenance store Assurance/compliance is performed asynchronously as applications record provenance into provenance store Enterprise Application Enterprise Application … Enterprise Application Enterprise Application … Information Warehouse Information Warehouse Information Warehouse Information Warehouse Record Documentation of Execution Record Documentation of Execution Streaming Assurance Engine Streaming Query of Provenance Data End-to-end Provenance Store Assurance Engine End-to-end Provenance Store Query Provenance Data

Thank You csli@us.ibm.com Chung-Sheng Li DGM, Security, Privacy and eXtensible Technologies IBM Research Division