Application Portfolio Rationalization

1. OADP for IT OptimizationStage I: Portfolio Rationalization

2. IT OptimizationAn Applied OADP MethodologyIT Optimization is Oracles applied OADP methodology for aligning primarily theApplication and Technology layers with the Business Architecture3 Stages of IT Optimization 1. Portfolio Rationalization  Platform and Application Standardization 2. Data Center and Systems Optimization  Clustering  Virtualization  Consolidation  Security  Management Automation 3. Shared Services / Cloud Computing  IT as a ‘Business’ - ITaaB Business Copyright ©2009 Oracle Corporation. All rights reserved. 2

3. IT Optimization (ITO) Applying a standard process methodology ITO Stage I: Portfolio RationalizationArchitectureA hit t Vision Stage II: Data Center & System Optimization Strategic Business & ment ITO Alignm Stage III: Shared Services/ Cloud Computing Cl d C ti Copyright ©2009 Oracle Corporation. All rights reserved. 3

4. Common Drivers for IT Optimization > Discover Business Challenges gIT Optimization Area Issues and ChallengesPortfolio Rationalization Multiple applications providing the same functions Recent merger or acquisition Complex and inefficiencies associated with maintaining stove-piped systemsData Center dD t C t and Under tili d U d utilized servers and storage d tArchitecture Optimization HW refresh cycle or move to commodity HW platforms Management Automation g Data Center consolidation Security challenges due to complexityShared Services / Cloud Increasing transactions and data volumes g Financial Chargeback Just in time scalability y Copyright ©2009 Oracle Corporation. All rights reserved. 4

5. Stage I: Portfolio RationalizationPrerequisites and InputsPrerequisites • CxO Sponsorship for Larger Efforts, LOB sponsorship for smaller efforts. • Overall IT Optimization Architecture Vision Completed • Catalog of Business Capabilities, including (for each capability) • Value to the Business Strategy/Goals (Hi or Low) • QoS requirements (Availability and performance) Inputs • Scalability requirements (xx growth within yy years) • Matrix of Business Capabilities / Organizational units Copyright ©2009 Oracle Corporation. All rights reserved. 5

6. How do you Rationalize a Portfolio? Step 1 - Build inventory of existing applications / technology Inventory Step 2 - Map inventory to business / IT capabilities Map Step 3 – Analyze the portfolio against evaluation criteria (Portfolio Scoring) Analyze Step 4 – Propose the appropriate actions to transform the “Current State” into the Transform desired “Future State” Copyright ©2009 Oracle Corporation. All rights reserved.

7. Important Factors to Consider1. What are the driving factors for the Portfolio Rationalization process ? • Reduce Application Support Costs – Think about application consolidation • R d Reduce HW costs – Thi k about hardware consolidation when consolidating t Think b t h d lid ti h lid ti applications • Reduce Environmental Costs – Think about next generation hardware refresh to lower power consumption • Reduce IT Complexity (including ongoing support costs) – Reduce overall number of applications and integrations that are supported2. Is the Organization ready to move to a more centralized structure that may occur as a result of application consolidation ?3. Does the organization have the required PMO structure to support the rationalization efforts (there may be numerous overlapping projects proposed to effect the end state architecture) ?4. What is the organizations budget for the project (will affect roll out schedules and may necessitate cost saving quick hit projects over others to generate funds for the overall effort) ? Copyright ©2009 Oracle Corporation. All rights reserved. 7

9. Portfolio Rationalization Architecture Maturity IT as a Service • Standardize • Eliminate Redundancy y • Modernize Optimized IT Core • Migrate Integration Layer Service Group A Service Group B Service Group C Shared Services Application Grid Application Grid Application Grid / Data Grid Data Grid Data Grid Cloud Transitional Security Layer Computing Architecture Virtualized and Pt. to Pt. Integrations Consolidated SFAProduct SFA-Product product ERP SCM ERP- productMES- DB product Dev DB- Stage Inv LMS MGMT B2B B2B- Infrastructure IT Silos SFA Stage SFA- Test Product ERP- Prod Stage MES- MES- Stage Prod B2B- Stage Dev and Services SFAProduct product ERP SCM productMES- DB LMSInv DB- Product ERP- product Dev Stage MGMT 1 Client Stage FBT PAY G NTS Security Security Security Security TRDS Customs NTS A/c RRE IPS Penalty Refunds Data……. RBA Def Rationalized Integrate d A/C 1Excise Payments IT CCD Compliance Staff CR EC I ADD AW A ELS StaffBusiness Phone DDDR TASS PKI CDCC CWMS GC I Bus. Intel IVR WOC Ref aterial m Portfolio BOA Remote TAX Client BANK Staff Staff AG ENTS Call Centres B EPArchitectural Complexity Copyright ©2009 Oracle Corporation. All rights reserved.

10. Portfolio Rationalization According to industry analysts such as Gartner, a focused applications rationalization effort will typically result in a 20% cost savings while improving support for the lines of business. Reduce Complexity and Cost • Fewer, more strategic vendors • Standardize processes • Eli i Eliminate i f information “ il ” i i “silos”, improve ddata quality & enable seamless sharing of information across the organization through integration • Support strategies; Global Single Instance, Shared Services • Eliminate redundant and niche applications • Reduce risk • M d i l Modernize legacy applications li ti • Simplify / standardize technology infrastructureShift IT spending from Infrastructure • Improve security and regulatory compliance to Strategic Investment • Delivery models; Buy vs Build ASP SaaS vs. Build, ASP, Copyright ©2009 Oracle Corporation. All rights reserved.

11. Architecture Vision Scope Considerations• Avoid “boil the ocean” approach. Attempt to define a scope that either 1. Reflects a “horizontal / vertical slice” of functionality, aligned with a business goal or objective. For example: – Rationalize all applications that support Financial Control & Reporting, with the goal of improving the quality and timeliness of information – Rationalize all applications that support Month End Close, with the goal of reducing Month End Close from xx days to x days – Rationalize all applications that support a Business Process in need of streamlining 2. Reflects a manageable set of layers of the enterprise technology capabilities, e.g. • Servers – consolidate or upgrade to reduce “sprawl” • Database – standardize/consolidate onto fewer instances • Integration middleware – standardize onto a single platform – leverage technologies like AIA to reduce integration complexity Copyright ©2009 Oracle Corporation. All rights reserved.

12. Architecture Vision Considerations• Confirm with Customer, their existing applications inventory will be mapped to Capabilities Model to identify redundancy/gaps• Common portfolio scoring criteria include strategic value, functional fit, conformance to IT standards, risk and TCO • For Application Portfolio Rationalization – Business Capabilities approach is commonly employed with customers who have low level of maturity in applications portfolio management and business process management – Oracle Business Capabilities Model enables teams to accomplish the first iteration of Application Portfolio Rationalization in less time, with fewer resources – The BCM can be used either in spreadsheet form or with a tool such as Primavera Prosight or Troux. – For Technology Capabilities Rationalization – Use the Oracle Technical Reference Model(TRM) to categorize Assets – The TRM can be used either in spreadsheet form or with a tool such as Primavera Prosight or Troux. Copyright ©2009 Oracle Corporation. All rights reserved.

13. Architecture Vision Considerations• Make it clear that Portfolio Rationalization may effect a loss in functionality in order to enable greater agility. • Apply the 80/20 rule to Application Functionality. If the target application supports 80% of the required functionality then the remaining 20% should not preclude its adoption as the standard. When implementing the remaining 20% make sure that they are done in such a way as not to impede upgrades to the application. • Composite applications can be set up to handle ‘missing’ functionality until such a time that the business processes change or the target application can support the given requirements. • It is better to use the extensibility features of applications rather than customizing the application itself. This will enable easier application upgrades and result far less complexity. Copyright ©2009 Oracle Corporation. All rights reserved.

14. Guiding Principles Sample Principles for Future State ArchitectureBusiness Architecture Simplified / Enable agility to Improve Operational standardized / deploy new Efficiency / Reduce managed business products & Costs processes capabilitiesApplication Architecture Maintain Shared Reduce / Acquire COTS Standardize products & Common Application Application customize only as Platform Footprint necessaryInformation Architecture Real-time Common Enterprise Out of the Box information updates Object Models analytics / schemas / monitoringTechnology Architecture 24x7 platform Open standards & Optimized , scalable, availability systems agile environment Copyright ©2009 Oracle Corporation. All rights reserved. 16

15. Architecture VisionSample PrinciplesBusiness Architecture Principles• Cost Optimization – Low cost across the lifecycle of a product or service is a compelling value proposition for targeted customer segments.• Corporate Environment Responsibility – Going green is not only crucial from a social responsible and moral standpoint, it also has economic benefits. Eco-efficiency, eco- transparency and eco-innovation are critical for a greener future.• Enterprise Balance – This principle embodies “service above self” and decisions made from an enterprise wide perspective h t i id ti have greater l t long t term b benefit th t ti l d i i fit than tactical decisions made f d from a particular organizational perspective.Application Architecture Principles•CCommon U A li ti Use Applications – D li ti capability i expensive and proliferates conflicting Duplicative bilit is i d lif t fli ti data.• Technology Independence – Independence of applications from the underlying technology allows applications to be developed, upgraded, and operated in the most cost-effective and timely way.• Adherence to Open Standards - promote business / IT agility, reduce risk and achieve a lower agility overall TCO than proprietary applications.• Common Development Methodology and Tools - Standard development methodologies increase the likelihood of high quality results and promote reusable components.• Replace Obsolete Applications – Every application has a limited useful life span. Beyond this life span, the application becomes functionally deficient and costly to operate and maintain. p pp y y p Copyright ©2009 Oracle Corporation. All rights reserved. 17

16. Architecture VisionSample PrinciplesInformation Architecture Principles•Data Quality – Systems that consistently carry stale and incomplete data pose risk and inefficiency to the business and should be streamlined to only carry the information that it can realistically ensure quality for.•Master D t M M t Data Management - M lti l sources of data cause data quality/integrity i t Multiple fd t d t lit /i t it issues th t greatly i that tl increase system complexity and overall cost, while reducing agility.•Standard Data Exchange Format – Exchanging data in standardized representations lowers integration cost of supporting new and changing data model requirements.Technology Architecture Principles•Adherence to Open Standards - Standards compliance enhances flexibility.•Platform Standardization – simplifies maintenance and lowers support costs.•Availability - Loss of business service can be very costly and can often be underestimated.•Performance and Scalability - Responsive systems, with sufficient capacity, enable business success.•Service Level Objectives - If the Technology does not allow the business to meet its Quality of Service (QoS) objectives, then the business will suffer. bj ti th th b i ill ffGovernance Principles•Strategic Focus - Aligning the Enterprise Architecture with the business strategy increases the value of IT to the business.•Accountability - Accountability structures encourage compliance with the Enterprise Architecture.•Compliance to Enterprise Architecture - An effective Enterprise Architecture needs to be a guide for all IT projects•Wide Participation - Wide participation by stakeholders throughout the enterprise ensures that the Enterprise Architecture will meet the optimal requirements of the enterprise, not just a select group of LOB requirements.•Quantitative Decision Making - Utilizing quantitative processes and metrics provides a consistent and equitable means of evaluating decisions and i f l ti d i i d increases th effectiveness of E t the ff ti f Enterprise A hit t i Architecture GGovernance. Copyright ©2009 Oracle Corporation. All rights reserved. 18

17. Business Case Development Performed Architecture Vision Phase e o ed c tectu e s o ase Architecture Current Future Strategic EA Business Vision State State Roadmap Governance Case • Strategy Map • Understand the • Agree to • Business Value • Identify • Define Future - Customer existing Business Architecture alignment with State Costs/Risks • Identify Perspective Case culture Future State: existing auditing timelines and • Estimate EA - Financial - Quantifiable and other • Identify existing: milestones for Roadmap Perspective Measures financial - Goals / Drivers measurement Investments - Metrics for structures andBusiness Case • Business Model - Priorities calculation processes • Perform Development - Measures used - Value Proposition - Non-tangible or Cost/Benefit Activities - Metrics preferred - Cost Structure Soft criteria analysis and - Monetization Artifacts - Revenue Stream numbers • Build the actual Business Case • Business • Assess against document Capability Model benchmarks • Operating Model - Level of Business Process Integration and Standardization Work Effort Copyright ©2009 Oracle Corporation. All rights reserved.

19. Step 1 - InventoryInventory Current Portfolio• The process of rationalizing your portfolio begins with capturing an inventory of all applications and th underlying t h l ll li ti d the d l i technology platform, currently i use. l tf tl in• Capture information pertaining to an application’s underlying technology (e.g., hardware, operating system, database, etc.) as well. Standardization and lower TCO can be realized through migration of applications to run on a common technology platform.• Automated tools can quickly identify servers and software applications installed on your network, but there may be no substitute for human intervention when it comes t determining b i i f to d t i i basic information f application portfolio scoring such as ti for li ti tf li i h business capabilities mapping, strategic value, functional fit, conformance to IT standards, risk and TCO.• Completing such an inventory will usually reveal many overlapping and duplicate applications that are candidates for consolidation.• Spreadsheets or a tool like Treux can be used to capture the inventory list. Copyright ©2009 Oracle Corporation. All rights reserved.

22. Step 2 - MAPMap Current Portfolio to business functions• Once you have captured the pieces of the portfolio, they must be mapped to the business f b i functions th t th support. ti that they t• The mapping does not necessarily need to be at a very granular level. Level 1 or 2 business process flows can be used for this effort. You could also use a simple matrix showing the applications and which business functions they support.• It is especially important to capture where a particular business process is duplicated. Through an iterative process, when new business processes are discovered relative to a given portion of the portfolio, the remainder of the portfolio should b analyzed ( t l tf li h ld be l d (at least at a summary l t t level) t d t l) to determine if th i those pieces are also supporting this process. Think in terms of a company that has more than 1 ERP system. While the multiple system may each support unique business processes, it it more likely that there is overlap among them.• Spreadsheets or a tool like Treux can be used to capture the inventory list to business process mapping. Copyright ©2009 Oracle Corporation. All rights reserved.

23. Current State Applications Matrix Current State Applications Layer Perspective Customer Internet Accounts Service & Billing Reimbursement Relations Mgt. Mgt Marketing Payable Repair AMIS Recipient QuickBooks MCC CREM BigTree MCC MCC AMER Web Store ACT CREM Navision ISCALA CREM EVA 3 EMEA Business MCC EBS Filemaker CREM APAC Works Pro SAP EBSAustralia Copyright ©2009 Oracle Corporation. All rights reserved.

24. Current State ArchitectureDeliverables• Applications Inventory • Owners • Business Users • Costs (* to be used in generating the business case) • Etc Etc…• High Level (Just Enough Just in Time) • Current Applications Architecture • Current Data Architecture • Current Technology Architecture • Current Integration Architecture• Current IT Organization Chart (* tto b used in establishing governance) be di t bli hi• Current PMO Structure (* to be used in establishing governance) Copyright ©2009 Oracle Corporation. All rights reserved. 26

25. Business Case Development Performed During Current State Architecture Phase e o ed u g Cu e t c tectu e ase Architecture Current Future Strategic EA Business Vision State State Roadmap Governance Case • Strategy Map • Understand the • Agree to • Business Value • Identify • Define Future - Customer existing Business Architecture alignment with State Costs/Risks • Identify Perspective Case culture Future State: existing auditing timelines and • Estimate EA - Financial - Quantifiable and other • Identify existing: milestones for Roadmap Perspective Measures financial - Goals / Drivers measurement Investments - Metrics for structures andBusiness Case • Business Model - Priorities calculation processes • Perform Development - Measures used - Value Proposition - Non-tangible or Cost/Benefit Activities - Metrics preferred - Cost Structure Soft criteria analysis and - Monetization Artifacts - Revenue Stream numbers • Build the actual Business Case • Business • Assess against document Capability Model benchmarks • Operating Model - Level of Business Process Integration and Standardization Work Effort Copyright ©2009 Oracle Corporation. All rights reserved.

26. Step 3 – AnalyzeAnalyze the Portfolio information gathered in Phases 1 and 2 applying objective criteria• The analysis should be done in the context of what the portfolio should look like in the future, not where is it now. ,• Portfolio evaluation can be simple or elaborate, depending on organizational maturity. For some organizations, just reviewing support for mission objectives and capturing an estimate of application costs will be a substantial accomplishment, accomplishment and is often enough to identify “low hanging fruit . low-hanging fruit”• When a recommendation for an application isn’t obvious, a more detailed analysis is required. While this could involve a wide array of criteria, some obvious considerations would include: strategic value, functional fit, conformance g to IT standards, risk and TCO.• Whatever level of analysis is applied, when the process is completed, you are able to recommend actions to take for each application including replacement, retirement, consolidation upgrade, modernize etc. retirement consolidation, upgrade modernize, etc• Make sure to take integration and information architecture changes into account when developing the future state architecture. Portfolio Rationalization almost always involves changes to interfaces ( y g (integrations) and the underlying data for g ) y g the applications. Copyright ©2009 Oracle Corporation. All rights reserved.

28. IT Portfolio Scorecard Prioritize Future State Capabilities (Specific Criteria)Likelihood of Success X- Y-Criteria Axis Weight Score Business Value Criteria Axis Weight ScoreOut of the Box X1: 15% Financial Return Y1: 30%FunctionalityNumber of Interfaces X2: 15% Risk Y2: 20%Development Effort X3: 20% New Business Benefits Y3: 15%Support X4: 10% Technology Efficiency Y4: 10%Business Critical X5: 25% Impacts Revenue Stream Y5: 15%FunctionalityStandards Based X6: 15% Implementation Time Y6: 10% X 100% Dimension Total Y 100% Source: Kraft Foods, 2002 Copyright ©2009 Oracle Corporation. All rights reserved. 31

29. Weighting Criteria Examples Hardware Characteristics• % utilization – currently at peak would suggest a need for upgrade upgrade.• Energy Efficiency – older machines will have higher power requirements, need more cooling and generally have a larger physical footprint in the datacenter• Scalability – can the machine be scaled internally (add processors or memory) or is it at full capacity? p y• Purpose – what applications are currently running on the particular machine and are they supporting business critical functionality?• Standards – it the machine in the currently recommended architectural standards?• S Support – h t how many people are th l there in the organization that can support the i th i ti th t t th hardware?• Lease Term – is the machine leased or owned, and is the lease term due to expire?• Manageability – is the machine easy to manage (does it have built in sensorssensors, can it to predictive self healing or it limited to failure notifications)?• Interfaces – does the machine support all the interfaces required for maximum availability and performance (does it support Infiniband, does it meet HA redundancy requirements)? y q ) Copyright ©2009 Oracle Corporation. All rights reserved. 32

30. Weighting Criteria ExamplesApplication Characteristics• Number of Customizations - will the customizations need to go into the target application – or will the business change to deal with less customizations?• Number of Interfaces - they will need to be re-written if the application is being removed• Number of Developers - how many are currently supporting an application that is being removed? They will need to be re-trained which will eat into short g y term cost savings.• Number of Support Personnel – the more that are re-purposed the lower the overall cost• Number of Versions Back - is it still supported by the manufacturer or will it needed t b upgraded? d d to be d d?• Adheres to Target Standards - helps achieve a simplified infrastructure – which will lower costs and improve agility in later stages of maturity• Has functionality to differentiate company in the marketplace – this would be a reason not choose a COTS application as a replacement• Number Users - how many people will need to be trained/re-trained on the target application? Copyright ©2009 Oracle Corporation. All rights reserved. 33

31. Weighting Criteria ExamplesBusiness Value• Eliminates HW/Support/Licensing – will reduce TCO• Reduces Risk – systems that are easy to implement have reduce risk and can generate faster ROI.• Lowers HVAC/Electric/support – more energy efficient systems are more efficient and will reduce costs• Directly Impacts Revenue Stream - talks to risk – back office rationalization may be lower risk than a CRM or Customer Facing system directly tied to revenue.• Provides needed functionality to g y grow the business - may rationalize an y application with an upgrade that the business currently needs• Enables quicker response to market factors – agility is a key differentiator for businesses. Those that can react quickly to market demands and opportunities will have a competitive edge.• Meets/Increases Compliance Requirements – as regulations increase, increase businesses need to ensure their stakeholders that they are compliant to maintain shareholder confidence. Copyright ©2009 Oracle Corporation. All rights reserved. 34

32. IT Portfolio Matrix > Prioritize Future State Capabilities 100 Difficult to execute but high value to the business Some low hanging fruitValu to the Business 50 ue Do not fund these projects Fund Selectively 0 0 50 100 Ability to Succeed Source: Kraft Foods, 2002 Copyright ©2009 Oracle Corporation. All rights reserved. 35

37. Future State ArchitectureArtifact Details – Applications Integration Diagram ICC EAI Architecture BUNZL THAI IDS E WMS PO ASN INTF361 INTF362 Nistevo Ni t INTF357 INTF360 Order INTF358 Transportation USSTCMN0 INTF359 INTF363 FTP Server RMF WBIC PO ASN Bill of Material INTF340 INTF361 INTF362 Invoice INTF338 COMCARE PO INTF306 Order INTF357 MAPICS PO INTF358 Invoice INTF307 ASN INTF359 Goods Order INTF112 Receipt INTF360 TRACKX PO INTF116 Order WMS Item Basic INTF104 Transportation Vendor INTF127 INTF363 Gen Inventory JD Movement INTF339 Edwards SAP Item Basic INTF334 SATTSTORE Goods Receipt INTF337 WMS ASN INTF332/335 Order PO INTF333 Order INTF 324/325/326 BPCS Customer INTF327 WCMt Dual Inventory INTF121/122 Price List INTF330 e Catalogue e Catalogue INTF3288 INTF331 Product Item Inventory Catalogue Item INTF329 Inventory Report INTF298/300 Report INTF299/301 OPTIVA Bill of Material INTF304 WERCS Product DB A2A B2B Copyright ©2009 Oracle Corporation. All rights reserved.

38. Reference Models Architecture Component FrameworkCollectively, the Architecture Component Framework assets map onto theTechnology, Information and Application Architecture layers of an enterprisearchitecture framework.OFRA - The OFRA best practices framework maps directly onto the technologyarchitecture layer of an enterprise architecture framework. OFRA is based on anumber of architectural design perspectives that address specific architecturepatterns for designing solutions – SOA E2.0 and so on. E h perspective tt f d i i l ti SOA, E2 0 d Each tiembodies the sum knowledge and experience of Oracle, its partners andcustomers gained from implementing Oracle-based solutions. Each perspective isdefined to maximize the benefits of the Oracle technologies that are exploited inthe design.th d iORA – is a high level classification of software capabilities spanning technology,information and application architecture layers .Technology Capability Blueprint – an alternative viewpoint of the softwarecapabilities required to meet logical architectural requirements Copyright ©2009 Oracle Corporation. All rights reserved.

39. Reference Models Industry Reference / Solution DesignAn Industry Reference Architecture is an industry specific rendering ofORA. It maps against the technology, information and applicationarchitecture layers of an EA framework An IRA provides a definition of framework.Oracle’s technology stack and industry footprint capabilities that arerelevant for meeting the needs of a specific industry or industry domain.Solution Designs include industry solutions & technology patterns.Industry Solutions - Technology focused solution architectures defining highlevel functions and process flows, and with Oracle Technology and industryfootprint mappingTechnology Patterns - Technology focused solution architectures definingfunctions and process flows, and with Oracle Technology stack mappings Copyright ©2009 Oracle Corporation. All rights reserved.

40. Reference Architecture Taxonomy Design Oracle Enterprise Architecture OfferBest Practices Framework Architecture Framework Business Architecture Component ethodology Governan Framework Application Architecture Oracle Information Architecture Reference nce Architecture Me OFRA Technology Architecture Perspectives Technical SOA O ac e product app gs Oracle p oduct mappings Reference Reference Model Architecture (3rd party mappings) E2.0 Reference Architecture Solution Designs Security S it Reference Architecture Technology Industry Industry Patterns Solutions Reference Grid Architectures Reference Architecture BI/DW Reference Architecture Technology (Capability) Maximum Blueprint Availability Architecture Copyright ©2009 Oracle Corporation. All rights reserved.

41. Oracle Technology Reference Model June 2010 Development Middleware Security Management User Interaction Authentication Incident Content Mgmt BI Collaboration Mgmt g SOA & BPM AuthorizationProgramming Application Grid Service Level Languages Mgmt Directory Di t Database Info Mgmt Storage Grid Configuration IDE Analytics Auditing Mgmt Mgmt Mgmt Disaster Data Backup Embedded Recovery Replication In-Memory Encryption Security Recovery Performance S/W MgmtConfiguration Mgmt Provisioning Infrastructure I f t t Security OS VM Server Storage Network IRM Mgmt Copyright ©2009 Oracle Corporation. All rights reserved. 44

43. Future State ArchitectureFuture State Applications Footprint Analytics OM, SCM, OM, SCM, OM, SCM, CRM Loyalty iStore Sales Field Service Field Service Field Service Financials Financials Financials iStore Marketing Order Mgmt Pricing CTO Business Operations Supply Chain Demand Order Procurement Services Planning Planning Management Demantra Configurator Replenishment ASCP Demantra PIM Forecasting Configurator Configurator Procurement Trade Management Procurement Point-of-Sale Service Contracts Service Contracts ASCP Optimization Forecasting lanning Store Inventory Mgmt Advance Scheduling Demantra Supplier Inventory Demantra Order Management InvoiceQuality Quality Match Planning Scheduling Supplier Advance Forecasting Advance Forecasting Order Management Item Planning g Returns Management Supply Network Collaborative Collaborative Warehouse Merchandise Planning Planning Category Mgmt Advanced Pricing Advanced Pricing Workforce Scheduling Optimization Management Management Price Optimization Learning Mgmt Value Chain Transportation Global Global Price Management Collaboration Management Order Promising Order Promising Promotion Planning & Optimization Store Helpdesk Value Chain Allocation Home Delivery Demand Forecasting “AS IS” Sales Audit Workforce Comms “TO BE” Corporate Administration EPM Financials Financials Human Resources Real Estate Financials Indirect Procurement Projects Compensation Helpdesk HR IT FIN Master Data Management Integration and CollaborationCustomer Customer Customer Online Customer Online TCA TCA Data Hub Data Hub Enterprise Infrastructure Apps you own Apps you own Proposed New Apps Proposed New Apps HCM Copyright ©2009 Oracle Corporation. All rights reserved.

47. Business Case Development Performed During Future State Architecture Phase e o ed u g utu e c tectu e ase Strategic EA Architect Current Future Business Roadma Governa ure State State Case p nce Vision • Strategy Map • Understand the • Agree to • Business Value • Identify • Define Future - Customer existing Business Architecture alignment with State Costs/Risks • Identify Perspective Case culture Future State: existing auditing timelines and • Estimate EA - Financial - Quantifiable and other • Identify existing: milestones for Roadmap Perspective Measures financial - Goals / Drivers measurement Investments - Metrics for structures andBusiness Case • Business Model - Priorities calculation processes • Perform Development - Measures used - Value Proposition - Non-tangible or Cost/Benefit Activities - Metrics preferred - Cost Structure Soft criteria analysis and - Monetization Artifacts - Revenue Stream numbers • Build the actual Business Case • Business • Assess against document Capability Model benchmarks • Operating Model - Level of Business Process Integration and Standardization Work Effort Copyright ©2009 Oracle Corporation. All rights reserved.

49. Step 4 - TransformPropose the appropriate actions to transform the “Current State” to the desired “Future State” using Transitional Architecture(s)• Once you have completed the Application Portfolio Analysis and developed a Future State Architecture, you are able to recommend actions to take for each application.• The recommended actions may include: – Replacing existing applications with Oracle Applications and retiring existing applications, resulting in Global Single Instance or Shared Services model – Upgrading existing Oracle applications – Modernizing legacy mainframe applications, leveraging Oracle SOA / AIA Foundation Pack – see Appendix or Modernization site – Migrating existing applications to run on a common platform (Oracle DB / RAC / Linux) – Enterprise SOA: Integrating existing applications leveraging Oracle SOA / AIA and optimizing Business Processes leveraging Oracle BPA Copyright ©2009 Oracle Corporation. All rights reserved.

50. Step 4 - Transform• The recommended actions may include (continued): – Introducing a single User Interface layer, leveraging Oracle WebCenter, across all applications to establish a common user e perience and ser experience collaborative work environment for End Users – Enterprise BI / DW / Reporting solution, leveraging Oracle Business Intelligence EE g – Enterprise Content Management solution, leveraging Oracle Universal Content Management – Enterprise Security solution, leveraging Oracle Identity Management p y , g g y g – OnDemand vs. OnPremise, Buy vs. Build, SaaS, etc…• A Single Global Instance of Oracle Applications may be the desired goal, goal however a “big bang” approach may not be practical An big bang practical. Implementation Roadmap reflecting a phased-rollout approach (employing one or more of the recommended actions on the previous slides) is a means of achieving a GSI incrementally, thus mitigating risk and i d impact of change on an organization. f h i i Copyright ©2009 Oracle Corporation. All rights reserved.

51. Strategic Roadmap Deliverable Details – Prioritized Candidate Projects Primary Targe ts Secondary Targets ntiating Build & Future State 1 Cu stomize a s Differen necessa ry to diffe rentia te usiness Value 4 Buy & Future State Medium 3 cu stomize a s 2 ne ce ssaryBu The Oracle Insight identified 5 major recommendation categories that were 7 A C D B evaluated for prioritization Tablestake E High 5 Buy be st Future State pra ctice A Core Applications 6 Unstructured Data B Management Impact Business Process C Optimization Marginal Stable Best Practice Advantage D Single, Common UI Current Operating Performance E Protected Enterprise Medium Low Medium High Effort Copyright ©2009 Oracle Corporation. All rights reserved.

52. Strategic Roadmap Functionality Driven Transitional Architecture Current State (CS) Establish Common Migrate to Common Single Payroll Application Payroll Application Application • MA& Growth resulted • Define Standards for common • Establish common business • Execute common business in 4 payroll systems p y y p y payroll application. pp p processes for p y payroll data p processes for Payroll yBusiness • Set up PeopleSoft rules to capture and processing support entire employee population • Multiple payroll • Set up PeopleSoft instance • Consolidate Payroll apps • All new employees set up in applications – 1 • Build migrations from existing • Train payroll users on new PeopleSoft Payroll. PeopleSoft Payroll payroll applications into application • Retire obsolete payrollApps instance PeopleSoft • Execute Migration plans to applications. • Establish interfaces to Payroll move employee data into new Data (i.e. budgeting apps) instance • Payroll data stored in • Establish single view of the • Formalize data governance • Data Governance Processes in multiple applications employee for Payroll data procedures. Place • Establish Data Governance • Validate migrated employee • Product metrics for businessinfo Processes data. process • Establish metrics for business processes • No standard • Set up infrastructure to support • Run instance on new platform. • Tune application as required to hardware or software Enterprise PeopleSoft Instance support Payroll functions for payrollTech applications Copyright ©2009 Oracle Corporation. All rights reserved.

53. Strategic Roadmap Business Process Driven Transitional Architecture Current State Rationalize Sales Rationalize Financial Rationalize HCM Ready for (CS) Process Processes Applications Optimization • Define Current • Establish common • Establish common • Establish common • Common use businessBusiness State Here business processes for business processes for business processes for processes can be sales Finance people related functions optimized on a new infrastructure platform for grown • Define Current • Consolidate disparate • Consolidate Financial • Consolidate ERP • Consolidate Applications State Here sales applications onto a applications onto a applications onto a single can be optimized on a common platform common platform platform shared platformApps • Standardized Application • Standardized Application • Standardized Application Interfaces in Place Interfaces in Place Interfaces in Place • D fi C Define Current t • Si l view of sales d t Single i f l data • Si l view of fi Single i f financial i l • Si l view of Single i f • C Common/Shared d t i /Sh d data is State Here for the organization data for the organization employee/partner/etc… ready to be consolidated • Data Governance • Data Governance data for the organization into a single databaseinfo Processes in Place Processes in Place • Data Governance instance or common Processes in Place database platform • Define Current • Apps and process • Apps and process • Apps and process • Standard Infrastructure State Here standardized on standardized on standardized on platform optimized for HATech architecture standards architecture standards architecture standards and scalability – enabling growth Copyright ©2009 Oracle Corporation. All rights reserved.

54. Oracle@Oracle Architecture Roadmap Current S C State: <Transitional Future SState: Business Silos States> Operational Excellence (1998) (2003)Business • 40 Data Centers • Multiple Transition • Centralize and Globalize IT PhasesArchitecture • 2300+ S ff Staff • C Centralize IT GGovernance • 1998 65 ERP inst. • Gain IT efficiencies via IT standardization • 2001 20 ERP inst. & optimization • 2002 10 ERP inst. • Reduce Data Centers (2)/Staff (1600) • Save on expenses ( p ($1B/year) y ) • 2003 1 ERP inst inst.Application • Few standard business • Standardize core business processes and • For BPs, started withArchitecture processes rationalize apps RevRec/Financials • 40 Education registration • Education Sys Rationalization (1) systems • Phase I Capabilities • IT Support Rationalization (1) • 27 IT Support apps • Acct • E-Bus SSuite S / Std/Rationalization • >1000 applications Reconciliation (< 100 applications) • CorporateInformation • 63 Financial databases • Financial Data Rationalization SubmissionsArchitecture • 60 IT Support databases (1 single global instance) • Process • IT Support Data Rationalization pp Efficiency (1 single global instance) • 97 Email servers on 120 • Phase II Capabilities • Email ConsolidationTechnologyArchitecture databases • Full Balance (2 server cluster/4 DBs) • 501 Education servers Sheet & P&L • Education Server Consolidation (296) • 600 t t servers test • E Exceptions ti • T t Server Consolidation (30) Test S C lid ti • Analysis/Review … Copyright ©2009 Oracle Corporation. All rights reserved. 57

Application Portfolio Rationalization

Bob Rhubart

Application Portfolio Rationalization