1. Mastering Unreasonable Deadlines with Oracle APEX at the German Telecom Shops Dietmar Aust / Opal Consulting 15.06.2008

2. Page 1 ODTUG Kaleidoscope 2008 Dietmar Aust Agenda  Introducing Opal Consulting  The customer  Project AbiT  The problem  Choosing APEX  The solution  Project ShopDB  Lessons learned

3. Page 2 ODTUG Kaleidoscope 2008 Dietmar Aust Introducing Opal Consulting  Dipl.-Inform. Dietmar Aust, Freelance Consultant  Master's Degree in Computer Science (MSCS)  1997-2000: Consultant at Oracle Deutschland GmbH / Düsseldorf  Focus areas: PL/SQL, Oracle Reports, Oracle Forms, Oracle Portal, PLSQL Web Toolkit (OWA)  Seit 09/2000: Freelance Consultant  Focus areas: Oracle Portal, Oracle Reports, Oracle Application Express, Oracle Express Edition  Activities  http://daust.blogspot.com/  http://forums.oracle.com/forums/forum.jspa?forumID=137 (APEX)  http://forums.oracle.com/forums/forum.jspa?forumID=251 (XE)

4. Page 3 ODTUG Kaleidoscope 2008 Dietmar Aust T-Punkt Vertriebsgesellschaft mbH

5. Page 4 ODTUG Kaleidoscope 2008 Dietmar Aust T-Punkt Vertriebsgesellschaft mbH  1986: The first shops are opened  May 2004 : Founded as a subsidiary of the Deutsche Telekom  The T-Punkt Vertriebsgesellschaft is the only stationary distribution channel for the Deutsche Telekom in Germany  Handling of 60 million private customers and over 2.5 million business customers  Around 800 shops servicing customers on over 90,000 qm sales area.  More than 6000 employees

6. Page 5 ODTUG Kaleidoscope 2008 Dietmar Aust Project AbiT The problem – Background information  The salaries of the employees have a fixed and a variable component, based on their sales success  Direct usage of the order management systems of the coroprate divisions (T-Com, T-Mobile)  The TPG gets compensated only for successful orders (credit rating, technical issues), but their employees not.  The gross sales revenue is relevant (agreement with labor union), but only the net revenue is transferred by the divisions  No realtime measuring of actual sales possible (no current figures for strategic decisions)  Workarounds  Usage of tally sheets  Usage of barcode scanners (40, 68, 90 scan codes) for counting the sales

7. Page 6 ODTUG Kaleidoscope 2008 Dietmar Aust Project AbiT The problem – Requirements  Management decision  Agreement with labor union  Time for design, implementation and pilot phase: 6 weeks!  Severe financial impact in case of failure (130% compensation for all employees)  Requirements  Build an order entry system for around 5.000 employees  Highly available (7 days per week, 07:00 – 22:00)  Simplify the process of counting the gross sales (variable compensation) −Audit proof  Enable real time monitoring of actual sales  Document discounted hardware sales (bundle security) −Compliance with state regulations  Four interfaces with existing systems (products, user accounts, shop information, actual sales)  Changing requirements until very late in the project

8. Page 7 ODTUG Kaleidoscope 2008 Dietmar Aust Project AbiT Choosing APEX  Why was APEX chosen?  They didn‘t know about APEX  J2EE was the preferred platform to implement web based solutions  The deadline was too tight, the usual contractors couldn‘t deliver in that timeframe  Opal Consulting was chosen based on a recommendation  Thus: no technology discussion, just „do it“

9. Page 8 ODTUG Kaleidoscope 2008 Dietmar Aust Project AbiT The solution – Technical architecture  Application Server (2):  Fujitsu Siemens RX 300 S2, 2 HT CPUs, 8GB RAM, Linux RH AS4  Oracle Internet Application Server 10.1.3  Database (2 node RAC):  Sun Fire V490 Server, 2 Dual Core CPUs, 8GB RAM, Solaris 10  Oracle 10.2, APEX 2.2.1 Mod_plsql AbiT - Platform Clients Hardware Load Balancer Application Server Oracle RAC 10.2 Mod_plsql Sql*net http

10. Page 9 ODTUG Kaleidoscope 2008 Dietmar Aust Project AbiT The solution - Performance and usage  Usage  3.500 users active per day  ~ 25.000 orders per day  400.000 hits per day  Utilization  Application Server: −>95% idle −#http Sessions: 30  Database Server −30% (70% with only one node running) −Sessions: 25-35 concurrent (per node) −Dedicated, no Shared Server (MTS)

11. Page 10 ODTUG Kaleidoscope 2008 Dietmar Aust Project AbiT The solution  Live demo

12. Page 11 ODTUG Kaleidoscope 2008 Dietmar Aust Project AbiT Next steps  It was planned as a temporary solution from the start  Now online since 10/2006  The application will replaced by other systems in several steps  Direct interfaces will be established to transfer the required information directly from the divisions  => the employees will have to enter the order only once

13. Page 12 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The problem  Deutsche Telekom long term goals  Expansion strategy of new shops crucial  Missing the expansion target in 2006  Number of newly opened shops too low  Analysis showed major deficits  No clear definition of tasks and responsibilites  Lack of transparency, current state of processes  Lack of communication, some tasks performed in parallel by different teams  Time to open a shop too long  No central information system, wrong addresses  New rollout process was designed by external consultants

14. Page 13 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB Requirements  Implement a central shop database as a single „source of truth“  Consolidation and unification of different datasources  Data consistency  Implement the new rollout process, based on a workflow engine  Clear responsibilites, deadlines per task  Read- / write access to be controlled via user roles  Automatic validation (geocoding) of each address to eliminate typos  Visualization of maps (shops and market information)  Purchasing power, age distribution, competition  Process monitoring and historicization of modified data

15. Page 14 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB Challenges  The project plan was extremely ambitious  Project kick off in April 2007 (customer analyzes requirements)  First involvement in the middle of April  First prototype in May  Going live on 13.06.2007 (Version 0.6)  Going live on 10.08.2007 (Version 1.0)  Existing MS Access applications  Couldn‘t migrate everything in one step => stepwise migration  The application was changed until late in the project (new columns/data)  Minimize downtime of the MS Access application  The data model had to be redesigned  Many details of the requirements were unclear  => extremely iterative approach with weekly prototypes  Show stuff early  Get them involved

16. Page 15 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB Choosing APEX  APEX was already established through the AbiT project  Short development cycles  Performant application platform  No additional complex setup needed, just install another application on the same infrastructure  Project team  Two developers  One project manager

17. Page 16 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – technical infrastructure Mod_plsql AbiT - Plattform Clients Hardware Load Balancer Application Server Oracle RAC 10.2 Mod_plsql Sql*net http Geo-Komponenten Geo / Application Server Map visualization Geocoding http MS Access Clients ODBC / Sql*net

18. Page 17 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – MS Access migration  Problems:  Who builds these applications? −MS Access power users, no true developers  Column names >30 chars and special characters used  Direct migration of the data model not sensible  Changing the data and data model until very late in the project  Short downtime  => Solution:  Normalizing the table and column names with a VBA script  Database link from Oracle to MS Access (any ODBC data source)  ETL process to migration the data from MS Access to Oracle  Layer of views in Oracle  Linking the views via ODBC and creating views in MS Access

19. Page 18 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – Workflow

20. Page 19 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – Workflow  Open Source pl/sql Workflow Engine  http://plflow.sourceforge.net/ http://plflow.sourceforge.net/  XPDL 1.0 compliant, no import/export of processes  Creation of processes via table inserts  No UI, just backend framework  Easy to integrate and stable  Process visualization possible using Graphviz

21. Page 20 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – Workflow  Role based tasklist  Email notifications  New tasks  Overdue tasks  Embedded links to the task / shop

22. Page 21 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – Workflow  Status information

23. Page 22 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – Geocoding of addresses  Goals  Unambiguous spelling of addresses −No more typos!  Usage of coordinates −Make sure a certain distance between shops  Software  JCoder Business (infas Geodaten)

24. Page 23 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution – Workflow  Visualization  Addresses / shops  Layers of information  Software  MapSuite (infoware)  Market data (infas Geodaten)

25. Page 24 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB The solution  Live demo

26. Page 25 ODTUG Kaleidoscope 2008 Dietmar Aust Project ShopDB Next steps  Implement more processes to support the full lifecylcle of a shop  More processes after the decision to open the shop  Implement remaining functionality of the MS Access application  Establish the ShopDB as the leading system for all shop relevant information in the TPG  Tenacy agreements  Monitoring the costs  Cutting down costs  Reclaim accounting differences from the service provider  Current release went production on 12.06.2008

27. Page 26 ODTUG Kaleidoscope 2008 Dietmar Aust Lessons learned Major benefits of APEX  Leverage existing Oracle skills !!!  Developers can become productive very fast  No steep learning curve  Good separation from business logic and the UI (themes and templates)  Rapidly incorporate design changes, very flexible  Changed requirements until late in the project  Excellent tool for RAD or agile development  Strongly iterative approach (weekly prototyping) delivers very high customer satisfaction  Get them involved!  Oracle heterogenous services are cool!

28. Page 27 ODTUG Kaleidoscope 2008 Dietmar Aust  Contact:  Opal-Consulting Dietmar Aust  Web: http://www.opal-consulting.dehttp://www.opal-consulting.de  Blog: http://daust.blogspot.com/http://daust.blogspot.com/  E-Mail: dietmar.aust@opal-consulting.dedietmar.aust@opal-consulting.de Q & A