Modernization Projects - They Don't Have to Suck
•Download as PPTX, PDF•
0 likes•90 views
Modernization of legacy systems is often a variation of lipstick on a pig. But if you ask the right questions you find opportunities for incorporating valuable, engaging work that makes you the hero. Learn how to spot these opportunities and demonstrate how it’s a win for everyone involved.
Recommended
Recommended
More Related Content
Similar to Modernization Projects - They Don't Have to Suck
Similar to Modernization Projects - They Don't Have to Suck (20)
Recently uploaded
Recently uploaded (20)
Modernization Projects - They Don't Have to Suck
- 1. Modernization Projects They Don’t Have to Drag Suck
- 3. WORKING-STORAGE SECTION. 01 AutoTable. 02 TableValues. 03 FILLER PIC X(18) VALUE ”Tesla Porsche". 03 FILLER PIC X(18) VALUE ”AMC Chevrolet". 03 FILLER PIC X(18) VALUE ”Nissan Jeep". 03 FILLER PIC X(18) VALUE “Honda Toyota". 03 FILLER PIC X(18) VALUE ”Mercedes GMC". 02 FILLERh REDEFINES TableValues. 03 Auto OCCURS 12 TIMES PIC X(9). 01 AutoCount OCCURS 12 TIMES PIC 999 VALUE ZEROS. • Back end engineer looking to get together with front end coder to watch Netflix and chill 01 AutoIdx PIC 999. 01 HeadingLine PIC X(19) VALUE " Auto DriverCount". 01 DisplayLine. 02 PrnAuto PIC X(9). 02 FILLER PIC X(4) VALUE SPACES. 02 PrnDriverCount PIC ZZ9.
- 10. ?
- 11. Let’s Break This Down
- 14. 1. Understand what result you’re trying to derive 2. Efficiently gather information from several sources 3. Take into account constraints for accessing that information 4. Make an assessment of that information 1. Does it meet my criteria? Is A > B? 2. Is it relevant? Is A > B when C > D? 5. Calculate something 6. Write a message to Kafka to have the result written to your data store. 7. Test that your solution efficiently solved that problem and moved the application forward. 1. Understand what functionality or behavior you’re trying to elicit 2. Efficiently gather information from several users 3. Take into account barriers for getting the right information 4. Make an assessment of that information 1. Did the user enter the right info? 2. Is it relevant? Did the user enter the right information at the right step in the process? 5. Make a decision about that information 6. Save it for use later in the process 7. Check that the solution helps the business do what it needs to do. Coding Business Process
- 17. How Do You Get That Insight?
- 18. Step 1 Learn about your client’s goals and the mission of their organization
- 21. Step 2 Find out what business problems the application itself solves
- 23. Step 3 Learn how it’s really going for the end user (This is key!)
- 26. Step 4 Put it all together
- 28. Be The Hero
- 29. “If only I had some faster horses…”
Editor's Notes
- Washington DC has a lot of software engineering work We may not be in SF or NY
- (Washington DC has a lot of software engineering work) But there’s plenty of work updating commodity systems, especially legacy applications It isn’t all sexy But that doesn’t mean our work has to suck How many of you work on legacy projects? How many LOVE it? Let’s see what we can do about that
- “Modernizing” is a shiny word for updating a legacy system It means taking a system that’s been around for many years and bringing it up to current standards It’s rare for us to see “green field” projects, particularly with large enterprises Initially, it sounds like we could build something new and cool But often, it just means we are rebuilding the same functionality on a new platform
- Updating legacy applications can be problematic Legacy applications have usually been patched over the years so it’s likely that the code is fragmented and functionality has been bolted on. Also, software development best practices have evolved over time However the application was coded, the process for doing so has probably been surpassed
- Furthermore, a legacy app is likely part of a larger suite of apps that the organization uses that have been jammed together There’s a good chance that it hasn’t seen a lot of love in a long time
- Who loves rework? Who is dying to copy and paste someone else’s logic? Who wants to unravel someone else’s spaghetti code of old and new functionality? Who relishes the expectation to lift ‘n’ shift? Who’s excited by a project that has little impact and doesn’t really improve upon anything? Hmmm, this isn’t sounding too promising
- BUT What if there was a compelling reason to really dig into the project? What if you found an opportunity to improve the application? What if you knew something your client didn’t that would make the project way more innovative. AND interesting to work on? What if you were actually making users happy? What if people were thanking you for doing what you do? The real question is: What if you were truly adding value to the project? You have a unique vantage point You know what technology can do – the people at the top do not Plus, you are rubbing elbows with business analysts, UXers, and Product Owners And, you may have been asked to pull metrics from the legacy system… We’re going to take advantage of all of this
- You have a perfect storm of access to these resources What if you could use these resources to discover opportunities for pulling the application into 2018 – or at least 2017?
- You’d be a hero! But how?
- Legacy applications are based on business processes that solve problems They may be convoluted, but there is an underlying process that the application is addressing Understanding the underlying business process and how it fits into the organization is the key to making you a hero You may not have thought of a legacy project in these terms but hear me out You have the capacity for this, trust me…
- As an engineer you are typically asked to code to requirements or to PBIs (user stories) That’s because you have a rational brain You understand dependencies and logical sequences and conclusions The business process of a legacy application is similar There are the goals There are specific conditions There are influencing factors and constraints There is ultimately a logical solution
- Coding and Business Processes follow logical sequences
- All this to say, if you understand the basic business process behind the legacy application, then you have all the insight you need to make it better. Really better. You know what to look for You know where improvements will really make a difference You know when you should recommend new ways of streamlining the process or adding new functionality that ultimately benefits the organization.
- This is NOT solution-ing Everyone’s got bright ideas What matters is that you recognize opportunities for solving business problems that use technology that you understand (and no one else does) This is recognizing true value and having the means to deliver it
- Learn about your client’s goals and the mission of their organization Find out what business problems the application itself solves Learn how it’s really going for the end user Put it all together
- Your clients didn’t just decide to modernize the old application because it’s running on COBOL. There’s a solid business reason for them to bite this bullet so find out what that reason is The question you want to ask is: How does this application fit into the larger mission of the organization? How does this modernization fit into the grand scheme of things? Performance: If it’s payroll, maybe the organization is buying other company and they have to accommodate a steady stream of incoming employees Cost to maintain: Maybe they need to sunset the old infrastructure and move the application to the cloud Interfacing: Maybe they need to break up the old data base so they can open access to the information through microservices Foundation: Are they preparing for new functionality? Understanding this helps you understand what the real priorities are for the client. If your Product Owner regularly engages with your team, you should be able to learn from him/her how the application fits into the larger picture.
- (If your Product Owner regularly engages with your team, you should be able to learn from him/her how the application fits into the larger picture) If your team is working on metrics to help measure how the application is meeting the organization’s goals, pay close attention to these These clue you in to exactly what improvements will make a difference If you don’t have access to the Product or Business Owner, then ask your business analysts what mission, goals, and metrics the client cares about. They are going to rely on you to make sure the solution is technically feasible They should be able to give you the insight into the business you need
- Clunky or not, the legacy application was built to solve problems Hopefully you have a sense of what the overall process is, but you also should understand what the underlying business problems are What does the application enable users to do? What drove the organization to pour thousands upon thousands of dollars into this application only to spend thousands more to modernize it? What does the client get out of this thing? How does solving these problems tie back to the organization’s new mission and goals? The client may say “bigger, faster” You might say “underground train” Your Product Owner and business analysts can give you insight directly into this as well
- It’s easy enough to hear the client’s side of things, but what about the people who have to use the application day to day? What are their pain points? What are their work-arounds? How is the application killing them? Take part in UX exercises Learn first hand about the experience of using the application Recognize where users are getting tripped up on that dashboard Imagine solutions that not only meet the business process need but also help the user If you see UX issues (and the technical solution for solving them) that can be tied back to the client’s goals? Then you’ve just uncovered a potential beeline to bringing real value to the client After all, as a savvy engineer, you are up to date on many of the advanced solutions for user interaction
- (As a savvy engineer, you are up to date on many of the advanced solutions for user interaction) Should it really take six clicks for the user to get a list of options and make a choice? Does the user have to be inundated with questions or can the application progressively reveal options? Do fonts have to be so tiny because “there is only one way” to cram all this info onto the screen? You know technical solutions (animations, progressive display) that help the UX team solve problems for the user Often client sees one way for solving the business problem – the same way the legacy application has been doing it for years They don’t necessarily know how the user would like to perform the process or do the task Your insight into this (along with your technical know-how) can open up new opportunities for improving the application while building something innovative and valuable Isn’t that MUCH MORE INTERESTING?
- Get tight with your PO, your BAs, and your UXers You provide them with great code You validate the feasibility of the solution they’ve designed As such, they should provide you with broader insight into the project The organization The client The users Use what you’ve learned about the project along with your technical know-how to look for better ways to modernize the application Organizational Goals: If you understand the ultimate goals the client is trying to achieve You’ll be at the front line for knowing if the modernized version is going to achieve those goals You’ll be first to smartly suggest alternative solutions that truly bring value to the organization Business Problem: If you understand the problem that the application helps the user solve You’ll recognize if the legacy application took an outdated approach to addressing the problem You can question the constraints that the legacy application was originally built under You’ll spot opportunities for using new technology to streamline the process NOT – HOW DO I IMPROVE THIS FUNCTION – HOW DO I IMPROVE THIS PROCESS Users Needs: If you understand what users are trying to do and what trips them up You’ll know if the new technical approach you want to take will help them
- Ideas are a dime a dozen No flaming logos Henry Ford understood the big picture It’s ideas that make a real difference that matter If you keep an eye on the big picture, then you’ll know when to make those killer recommendations and when you should just keep your ideas to yourself
- If you can align an idea and potential solution with the mission, process, and UX, then the client is more apt to take on the innovative work even if it’s a little out of scope Then it’s no longer lift ‘n’ shift It’s innovation with a purpose It’s building something valuable for everyone involved It’s being excited to drive to work in the morning