1. 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

2. 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 (

3. 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

4. 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

5. 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

6. 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)

7. 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

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