1 / 70

Approaches to Application Modernization

Don Denoncourt dondenoncourt@gmail.com. Approaches to Application Modernization. Outline. What is App Modernization and Why Bother? Modernizing Coders Code Moves to Data, Modernizing the Database Gradational versus Global Approach Fear Factor Grokking RPG

toya
Télécharger la présentation

Approaches to Application Modernization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Don Denoncourt dondenoncourt@gmail.com Approaches to Application Modernization

  2. Outline • What is App Modernization and Why Bother? • Modernizing Coders • Code Moves to Data, Modernizing the Database • Gradational versus Global Approach • Fear Factor • Grokking RPG • Save the Program, Save the Platform

  3. "Modernization is our jobs. It’s what IT does. We improve access to information for the businesses we work for." • Trevor Perry

  4. Traits of a Modern App • It has maintainable and testable code • It is modular and component-based • It provides a rich user interface • It uses the Model-View-Controller (MVC) design pattern • Separate presentation, flow control, and business logic • It is responsive to new business requirements

  5. Why Bother? • Modernizing applications is costly • Not modernizing is more costly • "60 to 80 percent of all software development is enhancements to or maintenance of existing projects." • Gartner Group report • Amounts to a 10% increase in legacy code per year

  6. Escalating Costs • Effort required to enhance and maintain legacy apps escalates with time • Fact: • Code is read far more often than it is written. • So: • "What sense does it make to bloat unreadable code at a rate of 10 percent per year?" • Reducing maintenance costs may be the biggest reason to modernize

  7. Modular Applications: • Allow you to quickly respond to business requirements • Improves interoperability: • Other applications • Languages • Technologies • Including SOA and REST

  8. Modernizing Coders

  9. Three Contexts of Modernization • User Interface • Code • Coders

  10. Modern UI • If you're not rewriting your entire app in a new language • Need to modularize RPG • before adding a Web front-end • What about… HATS and WebFacing? • WDHT is the Botox of UI modernization • Quick and easy • But behind that puffed-up face • There will always be the same old person

  11. Application Make-over • To make over a person (or an application)‏ • You need to start from the inside • That means • Attitude • Knowledge • Organization

  12. Attitude, Knowledge, and Organization • Attitude should come from personal fulfillment • But it can also be coerced from effective management • Knowledge is acquired from experience or education • Organization • micro-level • when restructuring a program • macro-level • when planning an attack for modernization.

  13. Training • Formal education • Most common strategy • But the best training is mentoring • Conferences and formal classes • are worthwhile • But mentoring virtually guarantees • New techniques can transform from knowledge to functioning business code

  14. Mentor • If you don’t have internal expertise • Get a consultant • one with mentoring skills • To substantially decrease costs: • Consider: • WebEx, GoToMeeting, and alternative web conferencing tools • Consultant may be off-site and part-time • Maximize your training budget's ROI • With 2 hours mentoring a day

  15. Master Programming Toolsets • Promote use of a modern development tools • WDSc/RDi • Eclipse, NetBeans, Visual Studio A good IDE provides tools that are necessary in the modernization process.

  16. Grokking the Code with WDSc

  17. Application Diagram

  18. Search and Replace

  19. Outline View

  20. Integrated Help

  21. Streamlined edit-compile-debug

  22. Code Moves to Data

  23. Modernize Your Database • 20-year-old RPG • Code manages what should be done with db • Table relationship management • Foreign key constraints. • Refactoring that code out • Reduces requirement for code

  24. Does your database really need modernization? • If your files are defined with DDS • If you are not using constraints and triggers • If you are planning to implement Business Intelligence • If you are planning to provide a web front-end to your data • If new developers need to look at code to understand your database • Then. Yes. You really need to modernize your database.

  25. Significant Performance Improvements • DDL-defined table page size much larger that DDS-defined files • DDL page size 64K • DDS page size 8-32K • Encoded Vector Indexes (EVI)‏ • SQL query engine (SQE) runs below the MI • Versus the Classic Query Engine (CQE) http://systeminetwork.com/article/performance-comparison-dds-defined-files-and-sql-defined-files

  26. New Column/Field Capabilities • BLOBs and CLOBs • Constraints • User-Defined Data types (UDT)‏ • Formula columns • Encryption and decryption • Complex view definitions (logical files)‏ • Expressions • Aggregation • Complex selection

  27. New Column/Field Capabilities • Long table and view names • 128 characters • Identity and RowId columns • Sequences • Auto-increment of keys • Column-level triggers • Column-level privileges (authorities)

  28. Object-relation Mapping Tools • Generators for ORM engines • Such as • Java Persistence API • Hibernate • OJB • Work best with a well-crafted database • And standard SQL DDL constructs

  29. Object Traversal • Enabled with 1 database operation via joins • Versus a read for each row/record • Java: • event.getVenue().getAddress().getStreet(); • Grails: • event.venue.addresss.street

  30. More reasons to modernize •  SQL is a widely used standard. • Openness • more and better options for third-party tools • Books and training readily available • Performance: • IBM is investing money on improving database access through SQL, not elsewhere. • Availability of skills • Easier find Java and SQL skills over RPG and DDS knowledge. • Functionality • Some new functions require SQL.

  31. “Code moves to data” • Business rules • As much as possible • belong in DDL • DDL-based Business Rules • Constraints • Primary and foreign keys • Column-level contraints • Triggers • Operations to perform on • Add, update, or delete operations.

  32. Benefits of DDL Business Rules • Removes duplicate code • Decreasing complexity • Improving maintainability • Self-describing • Enforces database integrity • Rules are always followed • Whether .Net, PHP, or Java web front-end applications • Or other RPG

  33. SQL's Data Definition Language (DDL)5-minute tour

  34. createtable item ( itemid varchar(10) notnull, productid varchar(10) notnull, listprice decimal(10,2) notnull, unitcost decimal(10,2) notnull, supplier intnotnull, status varchar(2) notnull, attr1 varchar(80) notnull, attr2 varchar(80) notnull, attr3 varchar(80) notnull, attr4 varchar(80) notnull, attr5 varchar(80) notnull, constraint pk_item primarykey (itemid), constraint fk_item_1 foreignkey (productid)‏ references product (productid), constraint fk_item_2 foreignkey (supplier)‏ references supplier (suppid)‏ ); createindex itemProd on item (productid); • PetStore DB • Used in the ubiquitous sample web application

  35. createtable product ( productid varchar(10) notnull, category varchar(10) notnull, name varchar(80) notnull, descn varchar(255) notnull, constraint pk_product primarykey (productid), constraint fk_product_1 foreignkey (category)‏ references category (catid)‏ ); createtable category ( catid varchar(10) notnull, name varchar(80) notnull, descn varchar(255) notnull, constraint pk_category primarykey (catid)‏ ); createtable supplier ( suppid intnotnull, name varchar(80) notnull, status varchar(2) notnull, addr1 varchar(80) notnull, addr2 varchar(80) notnull, city varchar(80) notnull, state varchar(80) notnull, zip varchar(5) notnull, phone varchar(80) notnull, constraint pk_supplier primarykey (suppid)‏ );

  36. PetStore on Squirrel SQL Client

  37. PetStore Database onWDSc's Data Perspective

  38. Field-level Constraints CREATETABLE orders ( CustNum CHAR(4), OrderNum CHAR(4), Quantity INTEGERCHECK (Quantity BETWEEN1AND50) );

  39. On Delete and On Update CREATETABLE CORPDATA.EMPLOYEE (EMPNO CHAR(6) NOTNULLPRIMARYKEY, FIRSTNME VARCHAR(12) NOTNULL, MIDINIT CHAR(1) NOTNULL, LASTNAME VARCHAR(15) NOTNULL, WORKDEPT CHAR(3) CONSTRAINT WORKDEPT_EXISTS REFERENCES CORPDATA.DEPARTMENT (DEPTNO)‏ ONDELETESETNULLONUPDATERESTRICT, PHONENO CHAR(4), HIREDATE DATE, JOB CHAR(8), EDLEVEL SMALLINTNOTNULL, SEX CHAR(1), BIRTHDATE DATE, SALARY DECIMAL(9,2), BONUS DECIMAL(9,2), COMM DECIMAL(9,2), CONSTRAINT UNIQUE_LNAME_IN_DEPT UNIQUE (WORKDEPT, LASTNAME)‏ );

  40. Database Reverse Engineering Tooling • Navigator • WDSc • System i System API • Third-party tools

  41. Navigator has a suite of SQL tools Note: IBM is phasing out database development with Navigator

  42. WDSc's Database Perspective

  43. Generate DDLon a PF called ALLTYPES

  44. System i API • Generate Data Definition Language (QSQGNDDL)‏ • Carsten Fleming wrote an iSeries command: GENSQLDDL DBOBJ(yourFile) + DBLIB(QSYS) + TYPE(*PF) + SRCFILE(QGPL/QDDLSRC) + MBR(yourFile) + MBROPT(*REPLACE)NAMING(*SQL) http://systeminetwork.com/article/apis-example-reverse-engineering-database-files-and-objects-sql-ddl-statements

  45. Gradational versus Global Approach

  46. Two Strategies: Globally or Gradually • Global modernization • Management backs the project with bucks • Bring in consultants • Purchase a modernization tool-set • such as Databorough’s X-Analysis. • Gradational modernization • Refactor code on an ongoing basis during normal business development

  47. Global Realities • Management often will not back such a concentrated effort • Even though, in the long run, • It is the most cost effective • There are two alternatives to this • Do nothing • And let your code swell beyond recognition • Improve code with the gradational approach.

  48. Gradational Philosophy "Regard every bug fix or enhancement as an opportunity to improve code."

  49. Gradational Realities • Consider a change request • Estimated as a 10- to 20-hour project • Quick-and-dirty status-quo • Opportunity to modernize • First time realities • Potentially take 80–140 hours • Time will appreciably decrease on each new request

  50. Gradational Benefits • Soon you will be more receptive change requests • Along with • Increased adaptability • Greater interoperability • Reduced code bloat

More Related