Legacy Software
What are Legacy Software problems?
Problem: no one understands business requirements anymore
cumbersome to get exact details of a system
Increase in computer performance was long enough to compensate growth
however: single-core increases very very slowly
Example: Banking
50+ years ago: Teller with Machine
30+ years ago: Stock Exchange with Paper & PC
~1980:
.png)
- changes to the system without fully understanding it
- often through time-pressure
- system growth
- architectural tweaks
- staff leaves
⇒ System Complexity grows
Challenges
Software Design: right abstraction difficult to find for explanation to people
Project Management: coordinating evolution of huge systems hard
Change of Change: drivers of change evolved from new products to new regulations
How widespread is Legacy Software?
Occurrences
Enterprise Software Packages (80’-00’)
- industry solutions
- monolithic design around DB
- weak scalability
Microsoft Office
- Office Package
- over 30 million LoC in 2006
- inconsistent functionality between apps
Fat Client Applications (90’)
- user-driven developments on PC
- inconsistent design
- high degree of duplication
- many dependencies
- weakly understood
Leading Internet Companies
- maintain and enhance old systems
- large investments to manage code base
Mainframe Evolution
Outlook and Solutions
- documentation is important
- description of key concepts from the project
- software becomes legacy quicker than before
Ingredients for future business platforms
- scalable, distributed & secure transaction processing platform
- novel methods to specify, analyze, implement & test large amounts of business functionality
Accelerate Development
- Technical Migration migrate existing business app gradually to new infrastructure
- Analysis & Reengineering typically external & offshore teams involved
- Migration to Software Packages replace legacy app by industry-standard SW-package
- Industry-Specific Framework more rapid if functionality comes from framework
- Domain-Specific Languages more rapid if functionality comes from language
- Artificial Intelligence assist replacing code
Abstraction Building Software
IBM Throw-In:
- replacement projects are often more complex than previous implementation
- companies do not go into the details of the company and make it more “general”
- technology and business-functionality should both be considered
Models of Building Software
Waterfall-Model
How it Works
working from top to bottom
.png)
- Top Management: Software for ….
- Business Analyst: Products, Processes, Functionalities, …
- Requirement Engineers: Workflows, Interfaces, Rules, Formulas, …
- Software Architects: Components, Modules, Base Tech, …
- Software Engineers: Data Structures, Algorithms, …
Problems
- Top Management: < 1 page
- Business Analyst: 100+ pages
- Requirement Engineers: 1.000+ pages
- Software Architects: 100+ pages
- Software Engineers: 100.000+ LoC
- many hand-over points
- every group assumes preceding work is complete, accurate & consistent
- only feedback loop is at the end
Agile Models
working all levels and growing outwards
<1 page from top management
business owner provides incomplete list of features
- frequently interact with dev & provide feedback
- dev team rapidly builds feedback & gets feedback
Problems
- involved people need broader understanding to make decisions on multiple levels
- decisions are taken without clear understanding of whole view
- impossible / difficult to understand why decision were taken
- models do not scale well to large apps
- models require proximity of involved people to keep communication
- can become patchwork (if no cleanup in use)
- difficult to make accurate business case
Micro-Service
Advantage
- scalability
- flexibility
- resilience
- easy maintenance
- decentralization
Disadvantage
- complexity
- latency
- data management
- distributed sys concern (network failure, …)
- testing overhead
Increase Efficiency of Software Building
little config. package
- low-effort
- changes to processes
- integration challenging
- user-driven add-ons
highly config. package
- BA & RE still needed
- highly-specific skills
- integration challenging
industry-specific framework
.png)
- similar to package
- provides more flexibility
- own extensions
Domain-Specific-Language
- similar to IS-framework
- provides more flexibility
- creating features
Generic library / framework
- increase productivity
- for developers
Dev. automation tools
.png)
- simplify communication
- req. management
- project tracking
- reduce manual activities
- DevOps (auto testing)