A business approach to Oracle E-Business Suite response time, E-to-E and SLAs

1. A business approach toOracle E-Business Suiteresponse time, E-to-E and SLAs Gary Piper Oracle Irish User Group Dublin 24 February 2005

2. Agenda… • What is End-to-End? • Differentiate between a technical and business transactions • What is response time? • What is, and what’s in an SLA • Simple SLA measurements • Identifying the cause and effect of a performance issue

3. “End to End” a misunderstood concept… • Means different things to different people and roles • The real issue is defining a transaction • Vendors will sell an “End to End” solution based on their chosen interpretation of a “transaction” • Vendors often conveniently define what “End to End” means based on their ability to provide a technical solution • Most solutions are technology based • All claim to be non intrusive • Appliance Vs Sniffer technology • Head and tail markers • Agents

4. What is “End to End”?… • Every one has a strong opinion  • There are two fundamental questions • What does “End to End” mean? • What is a transaction? • The meaning of “End to End” is dependent on both role and skills bias • Technical (i.e. DBA) • Business User (i.e. Application user) • Business management (i.e. GM and above) • One size does not fit all • It’s all about what is collected, measured and reported on • Reaching an agreement with the business is paramount

5. End to End monitoring… • Generally based on collecting varying degrees of information using various methods, storing it and reporting on it • One product tracks and stores every user transaction • Imagine the size of the repository • Maintaining the repository • Often confused with diagnosing performance issues • Collect what is relevant and reportable • Collect and maintain what is historically usable • Value of historical information - 1 day, month, year

6. What is a transaction?... • Unbelievable Statement: • “IT should define what a transaction is as the business has no idea” • Translation: • We have a tool that can collect SQL code • As with “End to End”, the definition of a transaction is both skill and bias based • Technical (i.e. DBA) • Business User (i.e. Application user) • Business management (i.e. GM and above)

7. Transactions… • In order to understand transactions you must first understand how the application is accessed • Full Service • Self service • Concurrent Requests • 3rd party accesses ( Developer, SQL*PLUS, ADI etc…) • No single measure adequately covers all access types • Full service has variable port numbers and the information path changes once a full service session is established • Self service activity is a stateless activity with shared resources

8. Transactions… • Transaction types • Concurrent Requests – Database and server activity • Full Service – Internal user response time • Self Service - Internal and Customer response • Other – ( SQL*Plus, Toad, ADI, Discover….) • All transaction methods are required for the full story • For Full and Self service activity help the business define a consistent and measurable transaction • You can then refer to “the transaction” and every one knows what you mean

9. Technical Vs Business Transaction… • Transactions can be divided into three categories • Technical • Synthetic • Business • The problem with most transactions is that they are variable • In all cases CONSISTENCY is the key • Was that a 1 or 1,000 line PO? • Did the user submit an unbounded report?

10. Mx User Technical Reporting - Know your audience… User Speak IT Speak Interest in IT Milliseconds Chart of Accounts Hygiene factor Latency Vendor Address Month End Interface Table Part of my job Purchase Order Router Cheque Run Career Focus IP Address Recurring Journal Mid Tier Posting Buffer Gets Bill of Materials AP / AR

11. Transaction types… • A set of transactions consists of all of the following types • One Second - Technical • One Minute - Synthetic • One Week – Business • Detailed collections should be turned on as required for • Performance issue resolution • Performance tuning – Code • Adhoc reporting

12. Transaction – Technical… Time Line 1 Second 1 Minute 1 Week “Transaction” is taking longer than 3 seconds SELECT id_flex_code, id_flex_num, application_column_name, segment_name, segment_num, decode(application_column_index_flag, 'Y', 'Indexed', 'N', 'No Index', application_column_index_flag) FROM fnd_id_flex_segments WHERE application_id = :B1 and id_flex_num = :B2 and enabled_flag = :B3 ORDER by id_flex_num, segment_num; • With the exception of Discoverer, ADI, etc: • E-Business Suite is a packaged application • Low % performance issues associated with Code • Code tuning usually fixes symptom not cause • Often User behavior – Unbounded reports

13. Transaction – Synthetic… Time Line 1 Second 1 Minute 1 Week Synthetic transactions

14. Approval B E 7 days Transaction – Business… Time Line 1 Second 1 Minute 1 Week Business Activity: User “A” approves all orders over €X and all expense claims over €X (approval bottleneck) - Notification response delays Deferred Processes: Items “B” & “E” are deferred based on a “guessed” resource usage where as its actual usage is very small

15. “End to End” perspective… 1 Week Business Process 1 Minute 1 Second SELECT id_flex_code, id_flex_num, application_column_name, segment_name, segment_num, decode(application_column_index_flag, 'Y', 'Indexed', 'N', 'No Index', application_column_index_flag) FROM fnd_id_flex_segments WHERE application_id = :B1 and id_flex_num = :B2 and enabled_flag = :B3 ORDER by id_flex_num, segment_num; End User – SLA / Diagnostic Technical - Resolution

16. Simple Transactions… • CONSISTENCY • FNDOAMCOL – OAM is good for something • User Access • Full Service (Synthetic transaction) • Self Service (Synthetic transaction) • Workflow • Business process • Time from PO receipt to dispatch • The benefits are in the collection of known and targeted information

17. Response time… • Response time now becomes a simple measure • The time it takes for the defined “transactions” to run • When we mention the “the transaction” is slow, we all know what “the transaction” is

18. What is in an SLA… • Often SLAs are confused with performance objectives • Definition of a priority 1, 2 and 3 issue • Issue resolution procedure • Who will be notified and how • Who will respond and in what time • Contingency plans and timings • Business support structure and procedures • 10% associated with application performance • “the transactions” SLAs are about managing expectations

19. SLA response times… • Don’t pick SLA values because they sounds palatable, you will spend all your time explaining why the value was missed • SLA response times values based on Standard deviation ranges • 95% Below X seconds, 99% below X seconds • Easy to obtain • Be realistic you should only have to negotiate this value once • Synthetic transactions do not include think time etc.. so make this clear when documenting your SLA value • Define a base line: • Number of requests per day • Number of users • Self Service page requests

20. Internal External Hardware Database “SLA” “Usage” Span of control… So your transactions and SLA are in place…

21. Cause and effect… • Don’t get blamed for something you cannot control • Measuring Self Service response from multiple locations • If one site is slow may be a network segment or localised web server • If all are slow most likely database or central network*

22. Diagnose – Technical vs Business… Not all problems are caused by technical issues Performance Issue Identified Business Activity Technical Issue Code

23. Diagnose – Technical vs Business…

24. Inappropriate User Behavior…

25. Point in time… • Allows you to see the user activity that was occurring at the time of the issue • Know who to blame  • Show the affect of their actions • Know which self service customers may have been affected and call them (customer service) • Requests • Full Service • Self Service End time Start time Point in Time

26. Questions… Questions or Visit us at the Quest stand Disclaimer: All material contained in this document is provided by the author "as is" and any express or implied warranties, including, but not limited to, any implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the author be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of any content or information, even if advised of the possibility of such damage. It is always recommended that you seek independent, professional advice before implementing any ideas or changes to ensure that they are appropriate

27. A Business Approach toOracle E-Business SuiteResponse Time, E-to-E and SLA’s Gary Piper Irish UKOUG 2005 Dublin 24 February 2005