At ThoughtWorks Quarterly Review, Amir Uttman and Derek Longmuir discuss strategies for effectively managing legacy systems.
Legacy system have the following characteristics: Expensive to maintain, unchangeable, old-fashioned, unreliable, complicated, old, COBOL, mainframe, single point of failure, untested, undocumented, obsolete (no vendor support). However, legacy systems work, are business critical, are the system of record, and are familiar to the employees. Most importantly, legacy systems currently provide business value.
Next Amit and Derek define a legacy system as a system in which the quality has degraded to such an extent that it needs to be replaced. A legacy platform is a software or hardware system that is no longer supported. Thus, with time, the risk of using a legacy system gradually increases.
Amit and Derek then cover some options for replacing legacy systems. These include the build vs. buy option, the hiding the complexity option (usually does not work – nice front with spaghetti code behind), or the big bang replacement option(usually fail due to trying to create a prefect replacement). They give real word examples like Hershey’s ERP system, FBI Virtual Case Files, and Windows Vista.
It is important to remember that the real cost of systems is 10% to build and 90% for maintenance.
Amit and Derek next discuss effective legacy system replacement strategies and techniques:
1. Technology asset portfolio: Figure out where you are right now, what is the current state of the technology system(platform and software), what skills you have to maintain that system (operational, technical, and business skills). Based on that, you can figure out what kind of risks you face. How long is the system going to be around? How old is it? Who are the vendors that can support it?
2. Governance: Continually review your assets
3. Systems Health Check: Use several tools to visualize code complexity and ensure you have the basics of Source Control Management and Automation.
Some problems of migrating legacy systems:
1. Tendency exists to take existing logic and recode it as is on the new platform. No thought is put into new features. Sometimes, same bugs are ported over.
2. Code that no one knows what it does.
3. No benefit in investment until way later in the project.
Showing posts with label Thoughtworks Quarterly. Show all posts
Showing posts with label Thoughtworks Quarterly. Show all posts
Monday, February 15, 2010
Saturday, October 10, 2009
Turning on a Sixpence – No Excuses: Concept To Cash Every Week
At ThoughtWorks conference, Kris Lander and Gus Power gave a talk about their agile process and practices. They share with us their experience and stress that they are not telling us how to do things but just showing us how they do things. Below is a list of their practices:
1. Sustainable throughput – follow the money and ship every iteration to production. Show financials outside bullpen. Profit vs. return, cost per unit vs. units delivered, capacity cost vs. velocity, rework completed vs. rework queues, flow. Minimize work in process, Avoid inventory, Keep it visible with $ value.
2. 1 week iteration – focus relentlessly on delivering profitable features every week: Surfaces waste, flushes out breaks in value stream, start thinking about done straight away, regulates pressure over longer periods, start on Wednesdays.
3. Automated deployment – maintain a 1-click deploy that requires no manual intervention: Automated deployment to all sites (Test, demo, CI, prod), Robust and repeatable, A/B legs; no down time, used Hudson and Gant, Used separate queue, Automated schema/data migration, Checked deployed version.
4. Iterate to get something out there – enrich the functional depth of features iteratively: Business learns what it needs, cheapest solution first.
5. Dealing with bugs – fix bugs as soon as they are discovered: No bug backlog and no tracking tool, onsite customers says what’s really a bug, within slice, interrupt pair and fix in story, outside story, write pink card with visible priority at top of board.
6. Managing technical debt – don’t get into debt. If you do, repay some of it every iteration: Team decision, confront value fetishists, blue card always visible with $ value.
7. TDD – working from outside in, drive with tests to keep code habitable, testable and maneuverable: Low cost of change, maintain options with succession, do the valuable refactoring, acceptance criteria create common language, executable acceptance tests. Use jsunit, junit, selenium, integration, load. Use different groovy testing patterns.
8. Continuous feedback – Develop stories in vertical slices to create opportunities for feedback: tester does exploratory testing, onsite customer steers feature evolution, interaction designer sees feature evolve, follow the dots to done.
1. Sustainable throughput – follow the money and ship every iteration to production. Show financials outside bullpen. Profit vs. return, cost per unit vs. units delivered, capacity cost vs. velocity, rework completed vs. rework queues, flow. Minimize work in process, Avoid inventory, Keep it visible with $ value.
2. 1 week iteration – focus relentlessly on delivering profitable features every week: Surfaces waste, flushes out breaks in value stream, start thinking about done straight away, regulates pressure over longer periods, start on Wednesdays.
3. Automated deployment – maintain a 1-click deploy that requires no manual intervention: Automated deployment to all sites (Test, demo, CI, prod), Robust and repeatable, A/B legs; no down time, used Hudson and Gant, Used separate queue, Automated schema/data migration, Checked deployed version.
4. Iterate to get something out there – enrich the functional depth of features iteratively: Business learns what it needs, cheapest solution first.
5. Dealing with bugs – fix bugs as soon as they are discovered: No bug backlog and no tracking tool, onsite customers says what’s really a bug, within slice, interrupt pair and fix in story, outside story, write pink card with visible priority at top of board.
6. Managing technical debt – don’t get into debt. If you do, repay some of it every iteration: Team decision, confront value fetishists, blue card always visible with $ value.
7. TDD – working from outside in, drive with tests to keep code habitable, testable and maneuverable: Low cost of change, maintain options with succession, do the valuable refactoring, acceptance criteria create common language, executable acceptance tests. Use jsunit, junit, selenium, integration, load. Use different groovy testing patterns.
8. Continuous feedback – Develop stories in vertical slices to create opportunities for feedback: tester does exploratory testing, onsite customer steers feature evolution, interaction designer sees feature evolve, follow the dots to done.
The Agile PMO: Real Time Governance
At ThoughtWorks technology briefings, Ross Petit and Jane Robarts gave a talk on governance. They start out by mentioning that governance appears to be there to prevent bad more than for actually doing good. It’s to make sure we don’t fail to meet expectations. Today projects have multiple vendors, stack, and stakeholders. Every project has an element of system integration. There is a lot of discovery and hundreds of decisions being taken. We need to make sure all these decisions are taken in a consistent manner and aligned with our goal. A study shows that well governed organizations outperformed poorly governed ones by 8.5 % annually. They face the same king of market and competitor risks as everybody else but the chance of an implosion by ineffective management is way less.
Next they describe IT governance and how it is usually put in terms of technology, assets, budgets, or planning. But it really comes down to behavior. IT is a people business, so governance should be about how people go about executing. We should answer 2 questions. Are we getting value for money and are we getting things in accordance with expectation (regulatory compliance, business control, security, performance, functionality, etc)
They then describe the dual role of the PMO. To delivery teams, the PMO represents the buyers and the funders. They are the buyer’s agent of an IT asset. To a buyer, the PMO represents delivery. They are underwriting the risk that the asset will be developed and complete. Most PMOs focus on one role, but not both.
Next they describe how businesses and IT are not known for good governance. Some examples in business are the A380, mortgage failures, and madoff ponzi scheme. IT examples include projects that are on time and on budget but do not meet client requirements, or there is a hidden system integration project inside an overall delivery project. To be better at governance, we need to be activist investors and not passive. We need to be aware that effort is not result, and the best time to scrutinize is before the wheels fall of. We need the right information and we need it in the right context. There is an asset context and people context. Then we create a lot of transparency and we can work on problems relentlessly.
They describe a continuous governance cycle of IT projects to answer the 2 governance questions: Are we getting value for our money and are we getting things according to expectation. 1st we get the information that we need, and then we can feed a continuous cycle of challenging what it is that we are doing and what it is that we are getting.
Next they describe IT governance and how it is usually put in terms of technology, assets, budgets, or planning. But it really comes down to behavior. IT is a people business, so governance should be about how people go about executing. We should answer 2 questions. Are we getting value for money and are we getting things in accordance with expectation (regulatory compliance, business control, security, performance, functionality, etc)
They then describe the dual role of the PMO. To delivery teams, the PMO represents the buyers and the funders. They are the buyer’s agent of an IT asset. To a buyer, the PMO represents delivery. They are underwriting the risk that the asset will be developed and complete. Most PMOs focus on one role, but not both.
Next they describe how businesses and IT are not known for good governance. Some examples in business are the A380, mortgage failures, and madoff ponzi scheme. IT examples include projects that are on time and on budget but do not meet client requirements, or there is a hidden system integration project inside an overall delivery project. To be better at governance, we need to be activist investors and not passive. We need to be aware that effort is not result, and the best time to scrutinize is before the wheels fall of. We need the right information and we need it in the right context. There is an asset context and people context. Then we create a lot of transparency and we can work on problems relentlessly.
They describe a continuous governance cycle of IT projects to answer the 2 governance questions: Are we getting value for our money and are we getting things according to expectation. 1st we get the information that we need, and then we can feed a continuous cycle of challenging what it is that we are doing and what it is that we are getting.
Friday, June 19, 2009
Lean Concepts for IT Professionals
At ThoughtWorks conference, Richard Durnall and Kraig Parkinson gave a talk about Lean Software development. They start out by giving a brief history on Lean and how it led to the Toyota Production System (TPS). They then describe Lean in detail and cover the 4 levels of concern as
1. Philosophy - long term thinking or challenge. How are we going to accomplish these goals given the constraints: Long term vision(looking at 5, 10, 20 years), adaptive planning as we learn more and are faced with new challenges, process based company with human focus.
2. Process - steps to take to get there: Pull systems (wait for order before starting), eliminate waste, value streams, Jidoka automation (providing humans with tools to support what they do), Heijunka (even out the work to make a balanced system), visual controls (see where the work is), stop the line (at Toyota the line stops about 27,000 times a day), build in quality.
Eliminate waste (overproduction, waiting, unnecessary transportation, over processing, excess inventory, unnecessary movement of our people, defects, unused employee creativity)
3. People and partners - Respect and work together towards the ultimate goal. Supplier and partner relations (share resources to make suppliers and partners better since they share the same ecosystem), encourage the right behaviors (point everyone in the same org in the same direction), training and personal growth.
4. Problem solving - in depth look at the real issues. Genchi Genbusu (go, see and do for yourself, get involved), 5 why’s (root cause analysis tool – ask why 5 times and at the 5th time you know the root cause), 5s (stabilize and standardize what we do as a platform for continuous improvements going forward), ishikawa (fishbone diagram for root cause analysis tool), A3 reports (get all information you can on one side of A3 paper – annual financial statement – intent that less is more), PDCA (plan, do check, act cycle).
Wrapping all this together is a sense of continuous improvement (Kaizen).
Next, they look at Lean in IT:
1. IT has a problem - mediocrity: over budget, over schedule, not delivering useful features, projects failing.
2. IT is a business process and we can use Lean techniques to improve them like value stream map to measure cycle time efficiency. The process involves walking through the process and tracking 3 metrics: value added time (amount of time to do something of value that the customer will appreciate), elapsed time (from start to finish including waiting time), and cumulative elapsed time (over all time from request until delivery). This shows IT waste like extra features, waiting, unnecessary transportation, gold plating, partially completed work, unnecessary movement, defects, and unused employee creativity. One can apply Lean practices like pull practice, eliminate waste, and adaptive planning to improve the cycle. We do not need to fix everything. We need to work on our immediate constraint and once that is fixed we can move on to the next one.
3. Further engage business and deliver better results: IT works across business units and can see the process from end to end. Focus on customer. Realign key management metrics to be more of a throughput focused vs. status focused - what is the profitability, how smooth is the process.
4. Look at other lean organizations and learn from them. Start with the customer, focus on quality not cost (and cost will drop as quality improves), find the change agents and empower them, don’t get trapped in the tool age (concentrate on philosophy, beliefs and values), and remember that anyone can introduce change.
This presentation is available on InfoQ at http://www.infoq.com/presentations/durnall-parkinson-thoughtworks-lean-it
1. Philosophy - long term thinking or challenge. How are we going to accomplish these goals given the constraints: Long term vision(looking at 5, 10, 20 years), adaptive planning as we learn more and are faced with new challenges, process based company with human focus.
2. Process - steps to take to get there: Pull systems (wait for order before starting), eliminate waste, value streams, Jidoka automation (providing humans with tools to support what they do), Heijunka (even out the work to make a balanced system), visual controls (see where the work is), stop the line (at Toyota the line stops about 27,000 times a day), build in quality.
Eliminate waste (overproduction, waiting, unnecessary transportation, over processing, excess inventory, unnecessary movement of our people, defects, unused employee creativity)
3. People and partners - Respect and work together towards the ultimate goal. Supplier and partner relations (share resources to make suppliers and partners better since they share the same ecosystem), encourage the right behaviors (point everyone in the same org in the same direction), training and personal growth.
4. Problem solving - in depth look at the real issues. Genchi Genbusu (go, see and do for yourself, get involved), 5 why’s (root cause analysis tool – ask why 5 times and at the 5th time you know the root cause), 5s (stabilize and standardize what we do as a platform for continuous improvements going forward), ishikawa (fishbone diagram for root cause analysis tool), A3 reports (get all information you can on one side of A3 paper – annual financial statement – intent that less is more), PDCA (plan, do check, act cycle).
Wrapping all this together is a sense of continuous improvement (Kaizen).
Next, they look at Lean in IT:
1. IT has a problem - mediocrity: over budget, over schedule, not delivering useful features, projects failing.
2. IT is a business process and we can use Lean techniques to improve them like value stream map to measure cycle time efficiency. The process involves walking through the process and tracking 3 metrics: value added time (amount of time to do something of value that the customer will appreciate), elapsed time (from start to finish including waiting time), and cumulative elapsed time (over all time from request until delivery). This shows IT waste like extra features, waiting, unnecessary transportation, gold plating, partially completed work, unnecessary movement, defects, and unused employee creativity. One can apply Lean practices like pull practice, eliminate waste, and adaptive planning to improve the cycle. We do not need to fix everything. We need to work on our immediate constraint and once that is fixed we can move on to the next one.
3. Further engage business and deliver better results: IT works across business units and can see the process from end to end. Focus on customer. Realign key management metrics to be more of a throughput focused vs. status focused - what is the profitability, how smooth is the process.
4. Look at other lean organizations and learn from them. Start with the customer, focus on quality not cost (and cost will drop as quality improves), find the change agents and empower them, don’t get trapped in the tool age (concentrate on philosophy, beliefs and values), and remember that anyone can introduce change.
This presentation is available on InfoQ at http://www.infoq.com/presentations/durnall-parkinson-thoughtworks-lean-it
Thursday, October 9, 2008
Forging a New Alliance
At ThoughtWorks quarterly conference, Scott Shaw and Martin Fowler discussed the communication gap that exists between IT and the business side. Originally, IT department was created to centralize desktop administration and to gather MIS data. IT managed billing systems, accounting system or data processing on a centralized computer system. Things changed with the introduction of the PC. A broader range of business functionality came under IT functionality. Martin predicts that custom application provision will see IT department effectively disappear. Commodity standard stuff will move to the cloud and get hosted in a data center while custom software will move closer to the business side and the way to thrive in the IT world is to move closer to the business people.
Next they discuss some disturbing trends in IT that result in this communication divide between business and IT.
1. Slow to market: They note statistics that show about 34% of IT projects are successful. Here success is defined as on time and on budget. Martin notes that success should really be measured as providing value. They also show an input value stream that shows a typical example in which out of 90 days, 18 days are spent adding value and 70 days are spent in waste (waiting for handoffs). To have a successful rapid feedback loop, you need to have minimal latency.
2. Bloatware: This investment in large software platform that is intended to make it more responsive to the business. They give examples showing the same platforms growing to 200x their original size over the past 15 years, yet they mostly still provide the same business value.
3. War for talent: People fleeing the industry. The job is really boring. We took thinking and the design part away from people writing the code. There is no sense of ownership or context around what they are doing.
Next they cover some encouraging trends:
Collaborative team: Face to face communication, joint ownership of outcome, multi skilled people where developers can code and learn business domain (Make jog more interesting because of variety of task), and continuous improvements (plan, do, check). This results in better responsiveness, richer communication, higher quality, and improved staff retention.
Rise of craftsmanship: Master apprentice relationship. Attention to tools and quality and simplicity. Polyglot programmers. Software is all about design. Design is important because of its role in the long term of things. We should not see software as a cycle of building something and then it is delivered and we do not see it again. There should not be a disconnect between building and supporting something. Looking at long term brings out importance of design. It is important to have a code base that can absorb changes and gives the right degree of long term horizon to think of investments.
Perpetual beta: get software out there for people to try, fund things incrementally. Get away from project mentality and move towards product support mentality.
User experience design: 65% of features are rarely or never used Standish group. Bring user experience design into the iterative cycle of user needs analysis, collaborative design with users, design refinements, and test with users.
Domain Driven Design: enhance communication of internals of software. Use same language between business people and developers.
Domain Specific languages: makes the code readable to the business side making it easier for them to understand the code and improves communication.
They also gave several examples of case studies where these trends have helped out. They conclude that today business and IT are separate. In 2020 business and IT will come much closer to together. How are we going to survive the post IT world? What techniques and approaches are we going to use?
This presentation is available on InfoQ at http://www.infoq.com/presentations/New-Alliance-Shaw-Fowler
Next they discuss some disturbing trends in IT that result in this communication divide between business and IT.
1. Slow to market: They note statistics that show about 34% of IT projects are successful. Here success is defined as on time and on budget. Martin notes that success should really be measured as providing value. They also show an input value stream that shows a typical example in which out of 90 days, 18 days are spent adding value and 70 days are spent in waste (waiting for handoffs). To have a successful rapid feedback loop, you need to have minimal latency.
2. Bloatware: This investment in large software platform that is intended to make it more responsive to the business. They give examples showing the same platforms growing to 200x their original size over the past 15 years, yet they mostly still provide the same business value.
3. War for talent: People fleeing the industry. The job is really boring. We took thinking and the design part away from people writing the code. There is no sense of ownership or context around what they are doing.
Next they cover some encouraging trends:
Collaborative team: Face to face communication, joint ownership of outcome, multi skilled people where developers can code and learn business domain (Make jog more interesting because of variety of task), and continuous improvements (plan, do, check). This results in better responsiveness, richer communication, higher quality, and improved staff retention.
Rise of craftsmanship: Master apprentice relationship. Attention to tools and quality and simplicity. Polyglot programmers. Software is all about design. Design is important because of its role in the long term of things. We should not see software as a cycle of building something and then it is delivered and we do not see it again. There should not be a disconnect between building and supporting something. Looking at long term brings out importance of design. It is important to have a code base that can absorb changes and gives the right degree of long term horizon to think of investments.
Perpetual beta: get software out there for people to try, fund things incrementally. Get away from project mentality and move towards product support mentality.
User experience design: 65% of features are rarely or never used Standish group. Bring user experience design into the iterative cycle of user needs analysis, collaborative design with users, design refinements, and test with users.
Domain Driven Design: enhance communication of internals of software. Use same language between business people and developers.
Domain Specific languages: makes the code readable to the business side making it easier for them to understand the code and improves communication.
They also gave several examples of case studies where these trends have helped out. They conclude that today business and IT are separate. In 2020 business and IT will come much closer to together. How are we going to survive the post IT world? What techniques and approaches are we going to use?
This presentation is available on InfoQ at http://www.infoq.com/presentations/New-Alliance-Shaw-Fowler
Subscribe to:
Posts (Atom)