Build the ultimate enterprise data warehouse using SAP NetWeaver A look at JAD, RAD, XP, and SDLC methodologies

1. Build the ultimate enterprise data warehouse using SAP NetWeaver A look at JAD, RAD, XP, and SDLC methodologies Dr. Bjarne Berg Lenoir Rhyne College

2. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

3. Introductory Slide • Having the right approach to BW and NetWeaver will increase your project's success rate. • Most people use ASAP as their core NetWeaver methodology, but also leverage the best from other methods such as Joint Application Design (JAD), Rapid Application Development (RAD) and lately Extreme Programming (XP). • This session will teach you the core differences between these methodologies and also show you when and how to pick the right one for your project. • We will keep a fast pace and will not read any manuals (promise!!)

4. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

5. What user wanted How designer implemented it How customer described it How analyst specified it Business requirements One of the fists steps is to gather the right requirements. This is done in a variety of ways based on the methodology that the company employs. It is a complex process and involves a period: • Discovery and Education, • Formal communication, • Reviews • Final approvals. A NetWeaver implementation does not simply involve a series of black-and-white technical decisions; just because something is technically feasible does not mean it is wise or desirable from a business perspective.

6. What are the old methodologies based on? Most traditional methodologies are based on the System development Life Cycle (SDLC) approach. • Under this approach, the two key strategic tasks are to: • Completely define applications in the context of business requirements • Select technology based on compatibility and organizational know-how. Under the SDLC methodologies, defining an enterprise's requirements as completely as possible is extremely important, because even modest changes in the applications' functions is assumed to cause dramatically changes to the resulting tactical choices. For a SDLC methodology, the longer the project duration, the more important the methodology is to keep the project on-track.

7. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

8. A Brief Look at ASAP • ASAP for BW is based on many of the same ideas and approaches that are found in the ASAP methodology for R/3 • We will take a look at some core differences….

9. What is ASAP?

10. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

11. Joint Application Design - JAD In the late 1970s as a result of these complaints, the first versions of Joint Application Design (JAD) were developed by Tony Crawford and Chuck Morris at IBM. JAD was first limited to user requirements gathering and sometimes designs of the applications. The JAD workshop was an alternative to the structured interviews that the SDLC methodologies advocated. The guiding principles of a JAD sessions are: 1. Keep it very focused 2. Conducted in a dedicated environment 3. Quickly drive major requirements and interface "look & feel" Remember: "A user sign off is a powerless piece of paper" when matched against the fury of top management"...

12. Who Participates? - JAD 1. Facilitator – Facilitates discussions, enforces rules 2. End users – 3 to 5, attend all sessions 3. Developers – 2 or 3, question for clarity 4. Tie Breaker – Senior manager. Breaks end user ties, don’t attend 5. Observers – 2 or 3, do not speak 6. SMEs – A few subject matter experts (SME) for understanding business & technology Keep it very focused and explore the interfaces. How do the user want to see the screen layouts and functionality? A study of 60 development projects and found that without JAD, 35% of the functionality was missed (Source: Caper Jones)

13. JAD - Benefits JAD helps to merge business knowledge with information technology design, to provide useful interaction and thereby improve the quality of the systems being developed. JRP, or Joint Requirements Planning, is an approach to focus on the whole plan and execution of getting the “right” requirements. The JRP is often a supplement to the JAD sessions that is used for the specific program components and not a replacement for JAD. Initially JAD did not include the realization and the implementation phase. It was a set of workshops and not a comprehensive methodology.

14. JAD - Scalability The proponents of JAD claims that the advantages of JAD include a dramatic shortening of the time it takes to complete a project. It also improves the quality of the final product by focusing on the up-front portion of the development lifecycle, thus reducing the likelihood of errors that are expensive to correct later on. The argument was that the traditional methods have several built-in delay factors that get worse as more people become involved. As a result, the traditional methods were not scalable to larger information technology projects. JAD has increased scalability to large projects and can accommodate requirements gathering from high number of users

15. JAD - Today When JAD first was adapted as a methodology, a major benefit was proclaimed to be the unity of the team effort. However, as JAD gain adaptation in the 1990s many started to cut the cost of the sessions by reducing the travel expenses. The distribution of the team and the reduced interaction was for many the reason why JAD became less popular as a methodology in the late 1990s and is today rather uncommon as the sole development approach. You can use JAD for requirements gathering, but also need a more comprehensive development methodology. JAD laid the framework for other more radical approaches such as Rapid Application Development (RAD) and Extreme Programming (XP).

16. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

17. Rapid Application Development - A Short History An early critic of SDLC, Barry Boehm introduced the “Spiral Model” to reduce the risk of the projects through heavy prototyping. Each project was divided into critical parts and high risk areas was prototyped to drive the requirements and refine the deliverables with the users. In the late 1970s a method known as the Evolutionary Life Cycle (ELC) had been developed by Tom Gilb. Under this approach there were no formal phase of a project, but each parts of the project was developed with the users in sessions where prototypes were demonstrated and feedback was sought. In the 1980s Scott Shultz merged the Spiral Methodology and ELC and create Rapid Iterative Production Prototyping (RIPP) 1. RIPP = Spiral Model (SM), + Evolutionary Life Cycle (ELC) methodologies. 2. RAD = RIPP + SDLC methodologies.

18. What is RAD? In 1991, James Martin merged of best of RIPP and SDLC methods into a formal RAD methodology. What does RAD do? RAD compresses the phases of a SDLC and introduces an interactive approach for each of these phases. It also combines the design and construction stages into a single phase where the development process is interactive and not sequential. Each cycle of RAD is 1-21 days cycles and not phases

19. RAD as an Engine for NetWeaver Development The RAD core idea: Traditional methodologies are too slow and rigid to meet the business demands of today’s economy. Developers chosen for RAD teams should be multi-talented "renaissance" people who are analysts, designers and programmers all rolled into one Your RAD teams should consist of about 6 people, including both developers and full-time users of the system plus anyone else has a stake in the requirements (Walter Maner) Source: Dr T.H. Tse & Dr. Bjarne Berg Prototypes Small integrated teams - focus on small parts of the NetWeaver system (i.e. a set of infoCubes, web reports or functional area).

20. The First Session of RAD - How? Remember, RAD has an abbreviated blueprinting phase where meetings are executed in short succession to get the requirements. Most of the blueprinting and realization phase of the project are combined. The first meeting: a one or two days meeting with uninterrupted time Who: Power users, casual users, people who today interact with the current system and managers who have a stake in the outcome of the information system development. How many: A rapid pace is kept in these meetings and the number of attendees is kept at a manageable level, with typically no more than twenty people in attendance. Different Needs:The coordinators and business analysts will focus on shared information needs and conduct multiple sessions if needed. Why RAD?.. Increase involvement, less business disruption, less opinions, more consensus, information sharing and an education event.

21. RAD - The Instruments and Approach The RAD sessions can use a "information request form" to gather the relevant information about reports, processes and information availability being requested. It standardizes requirements and are consolidated, prioritized and used in follow-up discussions. Post such a form on the intranet and provide an easy way to communicate with the team. RAD is a spiral process that develops a set of prototypes Source: Dr T.H. Tse

22. RAD and Tools The key idea of RAD with NetWeaver is the creation quick reports/ queries that users are asked to jointly develop. In the beginning these are simply "mock-ups" with data that can be loaded from spreadsheet in a sandbox environment. As the sessions progresses, tools such as the SAP Query designer and the Web Application Designer is introduced and prototyping is done in each session with the users. Each RAD session is a working session, NOT a presentation session. Therefore, each session should therefore be at least 2-4 hours long (not at someone's cubicle). There should be at least 2-3 sessions each week to keep the work going forward…. Many critics of the SDLC methodologies have started to use Computer Aided Software engineering (CASE) and development tools such as the SAP query designer and the SAP web application designer to do interactive prototyping with the users.

23. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

24. System development lifecycle methodologies - SDLC This traditional methodologies from the 1970s, and still widely used today. In general, they are all based upon this structured step-by-step approach to developing systems. This rigid sequence of steps forces a user to “sign-off” after the completion of each specification before development can proceed. With such conventional methods, there is a long delay before the customer gets to see any results and the development process can take so long that the customer’s business could fundamentally change before the system is ready for use. This has been the area of highest contention among the critics of the SDLC methodologies. The SDLC methodologies structures the work into a project preparation, an analysis, a design, a development, a testing phase, and an implementation phase. However, SAP and each vendor refers to these phases by different names.

25. Source: Dr T.H. Tse The "Waterfall Methodologies"- SDLC The SDLC methodologies are known collectively as "waterfall methodologies". It gives a false sense of clear cut stages and does not address changes during development. It is hard to fix mistakes or missing functionality during integration test. What do you do when you find new critical requirements 2 weeks before go-live? The waterfall

26. Getting the NetWeaver requirements - SDLC Avoid creating a total inventory of all reports in the organization. The "top-5" (most used) sales, distribution, inventory etc. reports from each department will cover the vast majority of the reporting needs. Create structured interviews with individuals that have a stake in the outcome A single BW "report" may satisfy dozens of today's static reports. It is therefore impossible to map each individual legacy report to a single BW report. Avoid attempting to replicate each report based on what you might have in place today. Accept new ways of accessing data.

27. The SAP NetWeaver Workflow - SDLC / ASAP

28. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

29. Extreme Programming - XP XP started in the 1990s by programmers decided that the SDLC and JAD/RAD requirements gathering sessions took too much time and often just verified what they already knew. The argument for XP is that traditional methodologies were developed to build software for low levels of change and reasonably predictable outcomes. But, the business world is no longer very predictable, and software requirements change at extremely high rates. Development can be completed faster with collaborative efforts of teamed programmers. The phases still exists, but development is highly interactive and work done in the design phase is subject to change during the construction phase. The project is not following a “waterfall” methodology since phases are revisited until the final solution is done. The core premise of XP is that you can only pick 3 out of these 4 dimensions: cost, quality, scope, time.

30. XP and The Release Plan and Refactoring The best way to understand XP is to review its approach to work. The first piece of work is the planning. In this stage user stories are written from a user interaction standpoint. This is followed by determining the project development schedule which is a result of the software release plan. In XP, the release plan consist of many smaller go-lives. Also, the momentum of the project, known as the “project velocity” is measured and the project is divided into smaller iterations. People on the project may be reassigned to different work in the various iterations. Finally, from an execution standpoint, a stand-up meeting starts each day and re-planning occurs based on yesterday’s work progress .

31. XP and the Blueprinting The next phase is the blueprinting phase. The guiding principle of the blueprint is simplicity and meetings are held through short interactive design sessions. During the design work, stand-alone simple solutions are encouraged to reduce risk and no value added functionality is included during the blueprinting phase. This is done later, based on available time during the realization phase. The key to a successful design under XP is to refactor the work whenever and wherever possible. The trick is to keep on schedule and focus on what is really needed. The "nice-to-have" items are included in the realization phase if time allows.

32. XP - The Realization Phase During the realization phase, the customer has to be present. To assure quality, all BW extensions must adhere to previous agreed to standards and developers are responsible for unit testing all configuration. A unique feature of XP is that all configuration is done in pairs and only one pair of programmers can integrate their config into the production box at any given time. The system is collectively owned by the developers and final performance optimization is done after all the configuration is integrated. Whenever a bug is discovered, a test case is created (not before!) to verify the extent of the error and possible impact. The testing stage relies heavily on acceptance testing and multiple sessions are created for each iteration and for each software release. The XP results from the acceptance testing is scored and published to the team.

33. XP - The Critics Many critics have raised concerns with the XP approaches: 1. Reliance on verbal communication which may lead to “finger pointing” when things go wrong. 2. It is based on intuition-based decision making and a high degree of dependency on individual skills. 3. Insufficient planning and does not contain any sound approach to system verification and validation. Some claims that XP leads to rework as a norm, error prone systems and non-maintainable systems that finally leads to frustrated staff, and few heroes.

34. XP - Limitations XP does not work in “Dilbertesque” companies (companies with high degree of control for the sake of control). XP does not work easily in groups of more than about 20 programmers. It is hard to implement in environment where there is a high degree of commitment to existing data warehouses or reporting systems. XP is hard to implement in outsourced development environment when programmers are separated by space XP is extremely popular among web developers, DSS communities and among programmers. It is often used to retain and motivate the IT staff.

35. XP - How to make it Work First you need open, honest communication among programmers and between programmers and customers. Programmers must enjoy their jobs, and as motivators there are no project mangers, but rather project coaches (they may still be called “managers”). A major issue is that collaboration is really hard and normally not rewarded in business where winners are typically selected as individuals and not as teams. Despite these critics XP has a strong following in the programming community. While some see XP as a result of programmers rebelling against the structure enforced by companies, other sees this as a path back to “sanity” without artificial non-value-add paper work.

36. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

37. Framework for picking your "poison"

38. The Gray areas of Methodologies While presented as clearly delineated areas of selection, there are in fact several dimensions when multiple methodologies can be employed. I.e. when time to delivery is moderate, or when the impact of failure is moderate. The framework is intended to illustrate the differences among the appropriateness of each methodology. This decision is clearer in the extreme. However, in reality there may be “gray zones” where more than one answer may be correct.

39. What We’ll Cover … • Why have a Methodology at all? • The SAP ASAP Methodology and NetWeaver • Other Methodologies • Joint Application Design (JAD) • Rapid Application Development (RAD) • System Development Life Cycle Methodologies (SDLC) • Extreme Programming (XP) • A Framework for Selecting Your Methodology • Wrap up

40. 7 Key Points to Take Home SDLC is the appropriate technique when the impact of failure is high and the time to “get it right” is available. It is a rigid structure that follows clearly defined deliverables and formal checkpoints in form of “structured walkthroughs” of deliverables and a formal approval process. This is why these methodologies are favored method among mission critical application development. RAD is the preferred methodology if the time to delivery is compressed while the impact of failure remains high. Since RAD relies heavily on prototyping, the application is developed faster and the end outcome is better known earlier in the process. Extreme programming (XP) is a highly preferred method when developing web pages and stand-alone applications. This is due to the rapid development cycle and the fact that most web and stand-alone applications can rapidly be rewritten with minimal disruption to the organization (the impact of failure is typically low). Your need more than one tool in your shed !!

41. 7 Key Points to Take Home JAD is the appropriate technique when the delivery time is relatively high as compared with XP and RAD. At the same time the impact of failure is low and group consensus can be achieved since more time is available relatively to RAD and XP. Limitations of JAD: Since the requirements are gathered by group sessions, it is unlikely that JAD will lead to the optimal requirements for applications, but rather the consensus of the community. When the impact of failure is high, a better approach might be to prototype or to have structured interviews as proposed by the RAD and SDLC methodologies. ASAP is a great start for complex large projects where impact of failure is high. Consider more than one approach if time to delivery is constrained or your analytical application is not operational needed (business can work for a few days without it). If your organization is to thrive, software development must mature to a level, where there are many tools available to the managers, and to a level where the “hammer” does not continuously argue that it is better than the “saw”…

42. Your Turn! Questions? How to contact me: Dr. Bjarne Berg bergb@lrc.edu

43. Resources Five Core Metrics: The Intelligence Behind Successful Software Management – by Lawrence H. Putnam & Ware Myers Enterprise Architecture Planning : Developing a Blueprint for Data, Applications, and Technology; by Steven H. Spewak ISBN: 0471599859 Publisher: Wiley Rapid Development by Steve McConnell Paperback: 680 pages ; Publisher: Microsoft Press; ISBN: 1556159005 Start to Finish Guide to IT Project Management by Jeremy Kadlec, Digital: 109 pages. Publisher: NetImpress; ISBN: B0000W86H2

44. More Resources Beck, Kent (1997) “Chrysler Comprehensive Compensation with XP”., published Feb. 2001: The Agile Software Development Alliance Beck, Kent (2000)., Extreme Programming Explained: embrace change., Addison Wesley Longman, Inc., 2000 Berg, Bjarne (1997) “Introduction to Data Warehousing”., module 2., pp.88-107. New York., NY., Price Waterhouse LLP. October 1997. Berg, Bjarne (2004) “Managing BW projects – part-2”., SAP project management conference, Las Vegas, NV, WIS publishing, November. Boehm, Barry (1986) "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software Engineering Notes, August. Boehm, Barry (1988) "A Spiral Model of Software Development and Enhancement" IEEE Computer, vol.21, #5, May, pp 61-72.

45. More Resources Botkin, John (1998)., "Customer Involved Participation as Part of the Application Development Process." University of Maine. Caristi, James (2002) “Extreme Programming: Theory & Practices”., Valparaiso University., SIGSEE 2002 conference tutorial. Damian, Adrian., Hong Danfeng., Li, Holly., Pan, Dong (1999) "Joint Application Development and Participatory Design". University of Calgary, Dept. of Computer Science. Dennis, Alan R., Hayes, Glenda S., Daniels, Robert M. Jr. (1990) "Business process modeling with group support systems". Journal of Management Information Systems. 115-142. Spring. Gilb, Tom (1989)., “Principles of Software Engineering Management”., Addison-Wesley Longman. Jennerich, Bill (1990)., "Joint Application Design -- Business Requirements Analysis for Successful Re- Engineering." UniSphere Ltd., November. Journal of Systems Management (1995)., "JAD basics"., Sept./Oct. ed. Keefer, Gerold (2003)., “Extreme Programming Considered Harmful for Reliable Software Development”., AVOCA GmbH., September ed.

46. More Resources Kettemborough, Clifford (1999)., “The Prototyping Methodology“., Whitehead College, University of Redlands Larman , CraigVictor R. Basili (2003)., Iterative and Incremental Development: A Brief History”., IEEE Computer, pp. 47-56 Martin, James (1990)., “Information Engineering Planning & Analysis, Book II”., Prentice-Hall, Inc. Nobuhiro, Kataoka., Hisao, Koizumi., Kinya, Takasaki., & Norio Shiratori (1998). "Remote Joint Application Design Process Using Package Software". 13th International Conference on Information Networking (ICOIN '98)., January., pp. 0495 Soltys, Roman., Crawford, Anthony (1998) "JAD for business plans and designs"., The Process Improvement Institute., October 1998. Univerity of California (1996) ., “Application Development Methodology”., UCD., on-line at http://sysdev.ucdavis.edu/WEBADM/document/toc.html

47. More Resources The University of Texas at Austin (2004) "Joint Application Development (JAD) What do you really want?" http://www.utexas.edu/admin/ohr/is/pubs/jad.html. Accessed on October 24. Yatco, Mei (1999) “Joint Application Design/Development”., School of Business, University of Missouri-St. Louis. Wood, J. and D. Silver (1995),. “ Joint Application Development”., 2nd ed., New York : Wiley. Wetherbe, James C. (1991)., "Executive Information Requirements: Getting It Right", MIS Quarterly, March., p. 51.