May 7, 2015,11:00 AM EST

1. SOLVING THE REQUIREMENTS PROBLEM IN LEGACY MODERNIZATIONHow do we manage when the requirements are wrong or incomplete? May 7, 2015,11:00 AM EST

2. Don EstesPresidentDon Estes Consulting, Inc. donestes@donestes.comwww.donestes.com Hosted by: Jessica Dahbour ITMPI Jessica_Dahbour@compaid.com

3. About Presenter’s Firm Don Estes has been specializing in modernizing legacy applications since 1990, starting when “modernization” meant converting from assembler to COBOL, through 4GLs to object oriented and relational paradigms. He is now actively involved with applying semantic web technologies as the modernization paradigm of the future, using OWL/SWRL declarative modeling and RDF data access. A graduate of MIT and the University of Texas, Don is a member of the Cutter Consortium and a frequent contributor to various IT publications.

4. CAI Achieves IT Operational Excellence www.compaid.com

5. PDU Credits Available for this Webinar • The PMI has approved this webinar with PDUs • You will be eligible to receive 1.0 PDU credits • Your PDU email will be sent to you

6. Online Webinar RecordingsNOW AVAILABLE • Anytime Access • Hundreds of Topics Visit: www.ITMPI.org/library

7. Enjoy the benefits of ITMPI MembershipJOIN TODAY! • UNLIMITED Free Webinar Recordings • UNLIMITED Free PDU Credits • Hundreds of Topics Visit: www.ITMPI.org/subscribe

8. Agenda • Introduction • Definitions • Business Rule Invariance Across Modernization • Business Rule extraction • Summary

9. Introduction

10. Introduction “The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.” • Fred Brooks, author ofThe Mythical Man-Month,in a 1987 essay 10

11. Introduction • Symptom: fully tested systems show significant errors when placed into production • This was the genesis of the NY Fed project • Existing testing methodologies are fundamentally flawed when applied to application modernization • When you test against flawed requirements, you can pass the tests but still be wrong

12. Introduction • NY Fed project – 2.3 million lines of IMS COBOL rewritten into Java and Oracle • A pure technology refresh with “like for like” functionality • 4 sources of specifications: • Group of code readers updating the documentation • Business analysts • Automated business rule extraction from legacy source codes • Our team: “comparative testing”

13. Introduction • Our team’s goal was 100% testcoverage of the legacy code • In the process, correct errors and omissions in the specifications (“dynamic business rule extraction”) • Test cases would be created by the testing group using the same information used to rebuild the system • Result, they got it right about 50% of the time • Bottom line: even with the best analytical information, your specs will be wrong or incomplete by ~30-50%

14. Introduction • Mostly applies to large to verylarge scale projects (butsometimes with smaller too) • “Very large” defined as > 10,000,000 lines of COBOL (or 5,000,000 lines of Java) • “Large” defined as 1,000,000-10,000,000 lines of COBOL or equivalent • “Moderate” defined as 100,000-1,000,000 lines • “Small” defined as < 100,000 lines • Our webinar focuses on large to very large projects

15. Introduction • Solving the requirements problem involves some uncomfortable truths: • Technically “successful” projects can fail or overrun budgets due to insufficient or defective specifications • The users can review and sign off on the delivered system, but does it do what it was supposed to do? • By your tests? Yes • By the business? (They may not be able to tell) • Errors and omissions may not be recognized immediately but come to light over time • Not reasonable to expect the business to articulate all the complex criteria to thoroughly vet an application

16. Introduction • It’s not that we are building the new system incorrectly, we are building it and testing it against flawed plans. • This is the source of the functional errors and shortfalls in application modernization • And of the cost overruns and late deliveries • And of the occasional project failures

17. Introduction • This is the requirements problem in legacy modernization: • The requirements are incomplete and in some cases just plain wrong. • Today, we will present a practical solution to this problem.

18. Introduction • Agile & waterfall methodologies are based on • Deriving the requirements, • Then building the system, and • Testing the system against the requirements • There is a fundamental flaw in both methodologies • People can’t tell you what they don’t know • No one, including the original programmers, know everything in these old systems • Or in new systems either!

19. Can’t Allow This In Modernization Project

20. Introduction • Modernization is more difficult than greenfield development • Primum non nocere - “First do no harm” • The business is dependent on the current processing of business transactions • Especially true in highly regulated industries • We must have all the rules and have them accurately or the results of processing will be different

21. Introduction • So how do we manage when the requirements themselves are incomplete or wrong? • How do we cope when the SME’s cannot recognize a defect in all cases? • Detecting the defect is the essence of the solution • We break down the problem until it is manageable

22. Introduction • If a functional requirement is missing or in error, it will be immediately evident • This is, relatively speaking, straightforward. • When it breaks or found to be missing, we fix it. • If a business rule is missing or in error, the defect may not be evident • Detecting the error can be a significant problem • It doesn’t usually “break” – some aspect of the output will be wrong indicating a defect, but not obvious • Detecting the defect is the essence of the solution

23. Introduction • Solving the requirements problem means debugging the specification,per Fred Brooks • Debug the specification before we build the software rather than after we have built it • Debugging the specification will mean discovering the errors and omissions • In the functional requirements • In the business rules • Significantly cheaper, quicker and less risky

24. Introduction Or here? • ~200:1 Ratio – Defects fixed in production vs. requirements and design Do you want to find defects here? 24 24 Michael Lundblad and Moshe Cohen, Software Quality Optimization: Balancing Business Transformation And Risk, IBM, March 2009. 24 24

25. Definitions

26. Definitions • To solve the requirements problem, we must speak precisely • Specifications ≠ requirements ≠ business rules • Too often we speak as if terms were interchangeable • Definition: {Specifications} = {requirements} U {business rules}

27. Definitions • Recognize the differences between requirements and business rules • Requirements are what we need to do • Business rules are how we are supposed to do it • Manage the “what” differently from the “how” • Now, we are free to manage requirements one way and business rules another • Managing requirements will not change much from your current procedures • Managing business rules will change considerably

28. Definitions • Business rules must be proven correct by executionand proven to be completewith code coverage analysis • Definition: complete = all cases covered • Usually interpreted as all logical pathways covered • Tedious but doable within a reasonable budget • Costs more in beginning, saves more overall

29. Definitions: Non-functional Vs. Functional Requirements • Non-functional requirements have no relationship with business rules • Expressed as "system shall be<requirement>" • Technical characteristics: performance, high availability, auditability, backup, etc. • Technical standards: code quality, user interface, etc. • http://en.wikipedia.org/wiki/Non-functional_requirement

30. Definitions: Non-functional Vs. Functional Requirements • Functional requirements do relate to business rules • Expressed as "system shall do <requirement>" • Functions may be queries or updates to persistent data • The “what” also requires the “how”

31. Definitions: Conceptual Vs. Transactional Business Rules • Conceptual business rules define what is: • They define the semantics of the transactional business rules • Define semantics of elements: “account” entity, “primary” attribute of account, and “balance” attribute of account, signed numeric attribute of “balance”, etc. • Define relationship: “each primary account will contain a balance”, etc. • Transactional business rules control change: • “The balance in the primary account must never go below zero”

32. Definitions • Definition: conceptual business rule • Defines terms – business vocabulary or semantics, materialized in a data model • Defines facts – association among two or more terms • A derived fact is created by an inference or a mathematical calculation • aka “structural assertion” by Business Rules Group • Query functions  conceptual business rules • Static state – no data is changing with functional queries • Optimizing work process will frequently change the queries and when data updates are performed – but will not change the business rules controlling the updates! • {Conceptual business rules} = Ontology

33. Definitions • Definition: transactional business rule • … a business rule expresses specific constraints on the creation, updating, and removal of persistent data in an information system. • aka “action assertion” by Business Rules Group • Statement that concerns some dynamic aspect of the business. It specifies constraints on the results that actions can produce. • Updates  conceptual & transactional rules • Updates still follow the same rules as the legacy system – unless the business rules are changing while modernizing • Updates are the greatest risk of damage from a defect – where changes are allowed and results persisted to disk • Instead of a single point defect, persisted incorrect results can cascade and trigger other defective results

34. Definitions: Example Requirements • Functional requirements: • I want to be able to reprint a mailing label for an account without updating the mailing date in the account. • I must request a mailing label from a workstation that has the ability to print it. • I cannot request a mailing label if the account is not in a state that allows a mailing label to be printed.

35. Definitions: Related Business Rules • Related transactional business rules: • Mailing labels can only be requested for accounts which exist, are active, have a status indicating that some processing has occurred against them, and do not have a status indicating that the currently due mailing has taken place. • The date, identity and location of the requester of a mailing label must be recorded. • The update of the account record and the information updated must be recorded. • Transactional rules use conceptual rules

36. Definitions - Summary

37. Business Rule Invariance Across Modernization

38. Business Rule Invariance • In physics we use an invariance principle to simplify complex problems • So, we can transform • Into • Makes life a lot easier!

39. Business Rule Invariance • The same principle applies to modernization • No change in business rules = simplification • This makes sense: if the business is not changing, business rules should not change • Conceptual business rules • Transactional business rules

40. Business Rule Invariance • Work flow, new queries, user interface, everything can change when modernizing • Queries (including reports and analytics) may change as much as desired • Except – the results of processing cannot change • Unchanged queries must return the same results • The same inputs to an update must produce the same results in the persistent data store

41. Business Rule Invariance • Requirements can change as desired • Business processes can be optimized to create value • Requirements can be informed by legacy artifacts, but are not ruled by legacy

42. Business Rule Invariance • We say that the business rules are invariant across a modernization • If business rules are changing, then you have a greenfieldproject to replace, not modernize, a legacy application • If requirements and business rules are being expanded • You have a hybrid modernization & greenfield project

43. Business Rule Invariance • Hybrid projects are a reality • Business rule changes may have been waiting for a long time (possibly years) to be implemented • New functionality and new business rules are also waiting (these can be accommodated) • Pressure to do it all at once can be overwhelming • Reality is that doing it all at once will take longer and cost more • Re-read The Mythical Man-Month

44. Business Rule Invariance • The invariance rule enables risk management • We can use the legacy system as the standard of truth • If invariance is violated, you have no standard of truth • Refer risk decisions to business • Modernization should be low risk • Hybrid and greenfield expose the business to greater risk, which require business decisions

45. Business Rule Invariance • Invariance allows a 100% complete and correct set of active business rules • All implemented functions will be correct • If you are missing a requirement, you may be missing a function, but what you have will be right

46. Business Rule Extraction Discovering Business Rules Without Errors Or Omissions

47. Business Rule Extraction • Business rules are the core of a modernization – get them right and everything else will fall into place • Get them wrong – and nothing will be dependable • Unfortunately, easier said than done Requirements User Interface Data Analytics Business Rules - Updates Queries Reports Work Flow

48. Business Rule Extraction • We assert that - • A 100% complete and correct set of the active business rules cannot be elicited via traditional business analysis or static business rule extraction tools, either alone or in combination. • Complexity and ambiguities will prevent reaching 100%

49. Business Rule Extraction • 3 stages to get 100% of the rules: • Stage 1: standard business analysis • Stage 2: static business rule analysis (analyzing inactive source code) • Stage 3: dynamic business rule analysis (object code is executing) • Think about that – • Stages 1 and 2 are limited by ambiguities • Stage 3 is based on executing code comparing new against old – no ambiguities!

50. Business Rule Extraction – Stage 1 • A classic diminishing returns curve • Nobody analyzes until they get to 100% • You are lucky to get 70% (and some of those wrong) % of active business rules extracted People give up somewhere around 50-70% to avoid analysis paralysis Effort