Deployment, Rollout & Maintenance (Inbetriebnahme, Rollout & Wartung) — Final Exam

Toolchain and development strategies

• A toolchain (configured to the requirements) supports development, operation and maintenance: SCM (Git, Mercurial, SVN), IDE (Eclipse, Visual Studio, XCode), CI software (Jenkins, Hudson), issue/project-management with dashboards (Jira, Redmine, GitLab), wiki software (Confluence), artifact repository (Nexus, Artifactory).
• Build to Change: develop software so it can be adapted quickly and easily to changed conditions.
• Release Management: the process of putting software into operation — planning and carrying out the release from the first idea to reaching the end user.
• Continuous Delivery: bring changes of all kinds to the end user as fast as possible, minimizing the risk of a change by automating as many steps as possible (build jobs) so changes reach the market faster.

User acceptance, training, and documentation

• User acceptance is decisive for a successful commissioning: involve users early; adapt training material/user documentation to their needs; run extensive training and a trial operation with feedback to remove fears (making mistakes, work taking longer) — fear of change otherwise causes resistance; show the new system's advantages; introduce the software gradually.
• Training: scope depends on the software's size and the user base; different user groups have different rights/functions and need different training concepts/material; explaining unneeded aspects hurts acceptance; make training interactive, keep groups small (≤10), ideally with a professional trainer.
• User documentation: target group is the end users; write target-group-oriented, organized by application modules/functions (not technical structure), understandable, with examples and sensible screenshots/videos; its two functions are introducing the feature scope and serving as a reference; technical (developer) documentation is normally not part of it.

Commissioning — planning and key questions

• Plan the steps before doing them (stakeholders must accept them); work iteratively (revising assumptions) within a predefined change process; account for iterations in scheduling and plan buffers — commissioning can bring big surprises (data centres still being built, visas denied, even war/sabotage).
• Central questions: where does the app run (own machine/cloud/with others)? own or shared DB? how are system boundaries defined? interfaces to other apps? foreign-language integration (training/docs)? integration of external systems/libraries?
• Plus: who is responsible for each step and for acceptance? how are integration tests done? who writes/provides documentation? who answers user questions? when does operation begin? a trial operation (Probebetrieb) eases familiarization, raises acceptance, and lets customer feedback flow into the product.

Formal acceptance (Abnahme) of software

Acceptance is the customer's formal taking-over of the work. The more complex the system, the more complex the acceptance — so multi-stage acceptance is needed, often by several stakeholders, and it must be traceable/auditable against a complete specification of all parts (simple systems need only a single acceptance).

• Questions to clarify: who accepts (admins, management), what is accepted, how exactly, with what (test-system spec), against what (target/should-spec), and when.
• Details/consequences: final checks; payment becomes due; warranty obligations and the limitation period for defect claims begin; the burden of proof for defects shifts to the customer; acceptance is formal on the basis of the specification and must be documented; what/when and required test cases should be predefined; several stakeholders should accept; budget time/cost for it.
• Steps: integration tests (functionality), installation and staff training, and an acceptance protocol (what was tested, how the system was integrated, further steps).
• Levels: technical basis (developer/function tests confirming runnability), content level (black-box and user-acceptance tests), and integration tests (interplay with other components — also important for updates). Test details are in Block 5 (QA).

Module/component integration and a good integration approach

• Integrating a module should need no knowledge of its internals: modularization splits software into modules with one task each, reusable and scalable, communicating via clearly defined interfaces; component integration starts from a clean architecture with clear interfaces and uses the Block-5 integration strategies (top-down, bottom-up, big-bang, vertical) and CI.
• Good approach: big-bang integration switches the way of working instantly with no familiarization phase → acceptance problems; instead run a trial operation during development with a representative user group giving feedback (changes within project scope), then after completion do extensive training, optionally parallel operation (costly, to avoid inconsistencies), iron out last issues — costly but safe, raising acceptance.

Enterprise integration — context

Enterprise integration connects several (large) IT systems; the goal is to integrate applications without having to adapt them, covering data, application and process integration, usually via middleware and adapters (compare SOA, the onion-shell model, microservices). The negative case is point-to-point integration where every app implements interfaces to every other — already 6 connections for 4 systems; Enterprise Integration Patterns are the better approach.

Operation, ITIL, and roles

• Operation is the life-cycle period during which a product is used and monitored for satisfactory performance; it is heavily formalized by process frameworks like ITIL (Information Technology Infrastructure Library — predefined processes, functions, roles and best practices, e.g. requiring prepared plans describing failure scenarios and solutions). Main tasks: monitoring and optimization.
• Roles (with different rights): Operators (ongoing monitoring, no infrastructure access — black box); Administrators (network admin = network infrastructure, technical admin = individual systems like app/DB/server, functional admin = apps via own UI, usually no underlying-infrastructure access); Support (contact for users, error reports come in here, with First/Second Level support).

Operation requirements and SLAs

• Requirements: high stability/fault tolerance (minimal downtime); data security (protection from unauthorized access/loss, emergency plans, backups); documentation for all relevant areas; recoverability (restart/recovery any time); easy analysability/adaptability/configurability; frugality (low CPU/memory use); independence (apps don't interfere); trained staff in place before commissioning.
• Service Level Agreements (SLAs): fix criteria for non-functional requirements, set by stakeholders before development and met during operation or penalties apply; define per the SMART principle — Specific, Measurable, Achievable, Reasonable, Time-bound. Examples: service availability, response time under load, time to answer a maintenance request.

Monitoring, optimization, and the operation checklist

• Monitoring: check reachability and task fulfilment, enable fast reaction to outages, serve as an internal quality benchmark (measure availability/response times, also for SLAs); the monitoring itself should be tested regularly; across all services; supported by tools like Nagios or Zabbix (Nagios: modules to monitor infrastructure across OSes, network services, a network analyzer for bandwidth bottlenecks, a log server for analysis/audits/threat detection; open source).
• Optimization: identify and use unused capacity (e.g. consolidating services onto one machine) for optimal infrastructure use — but balance hardware savings against less compute power and higher failure risk (one machine down = whole service down); keep in line with SLAs; always test optimizations first (does it deliver, what side effects, are SLAs kept), don't run them at peak times, optimize only where necessary and with measurable results.
• Operation checklist: are response times acceptable? sufficient availability? behaviour as expected? all SLAs met? backup/recovery strategies? redundancy/load balancing needed? enough staff? what if a machine fails? any single points of failure?

Robustness vs. performance and premature optimization

Operation often pits robustness against performance: defensive checks, validation and safe framework APIs cost speed, while raw speed can sacrifice safety. "Premature optimization is the root of all evil" — don't optimize before you have measured where the real bottleneck is; sensible optimization requires measurement ("you can't control what you can't measure"; "without data you are just another person with an opinion").

• Framework API vs clever faster workaround: a ~20% faster combination of calls 'not meant for it' risks breaking on framework updates, is harder to understand/maintain, and may have undocumented side effects — usually not worth it unless measurement proves the bottleneck matters; prefer the intended API.
• Measuring is hard in practice (e.g. concurrency, JIT warm-up, caching, GC pauses distort timings); the Block-5 link is to measure systematically (profiling, performance tests with latency/throughput metrics) rather than guess.

Semantic Versioning

Versioning communicates what an update contains and how risky it is; developers created rules (a versioning scheme) so version numbers carry meaning. The course references Semantic Versioning, a MAJOR.MINOR.PATCH scheme.

• MAJOR (X): incremented for incompatible API changes (breaking changes).
• MINOR (Y): incremented for new, backward-compatible functionality.
• PATCH (Z): incremented for backward-compatible bug fixes.
• Deprecation: before removing functionality (which would be a major change), mark it as deprecated in a release to signal it will be removed, giving users time to migrate — so removal does not come as a surprise.

Changelog

A new version should be accompanied by a changelog: it informs users and developers about what is new, what changed, and problems to expect on an update.

• Content/structure: group changes by type (Added, Changed, Removed, etc.); always give the date and version number (see Semantic Versioning); keep an Unreleased section and update it during development so nothing is missed.
• Example (Markdown): an [Unreleased] section, then e.g. ## [1.2.3] - 2001-02-03 with ### Added / ### Changed subsections listing the concrete changes.
• Automatic generation from commits (even with Conventional Commits) tends to be too detailed and needs much manual finalization/control.

Migration — motivation and types

IT development cycles are short, so software/hardware age fast and apps must be adapted to changed needs (legal or market-driven) to bring them to the state of the art (performance, throughput, flexibility). Migration requirements: no negative impact on running operation, and a well-ordered process.

• Software migration: switching from existing software to a new one (new DB/OS version, new ERP/CRM, Windows→Linux).
• Data migration: transferring data between systems (DB-vendor change, schema change, new ERP/CRM) — often using Extract-Transform-Load (ETL) tools.
• Hardware migration: changing the hardware (new machines, fibre vs copper).
• Application migration: replacing an application with a new one. Often a combination (software migration usually needs data migration too).

Maintenance foundations, terms, and artefacts

• Motivation: investment protection (software has strategic-economic value, keep its quality/functionality alive long, like renovating buildings) and cost minimization (not maintaining can cost more than maintaining).
• Maintenance = all software changes for fault correction, runtime-behaviour improvement, or adaptation to a changed environment (e.g. framework/library updates); triggers: found faults, runtime weaknesses, performance problems (more users), security holes, changed environment.
• Details: don't underestimate the effort (big OS/framework updates); relevant across the whole life cycle (ERP systems run 20+ years); maintenance cost often far exceeds initial development; happens alongside further development; preventive restructuring minimizes future effort; large maintenance should be its own project; record its scope in SLAs; specify maintenance artefacts (not just code — network, servers, frameworks, OS); plan maintenance already at initial analysis; high effort if maintainers ≠ developers (DevOps combines both); architecture-affecting maintenance is very costly; automation is often the only viable way.
• Software reengineering: re-developing a working component with the same functionality to improve quality (prepare for new functionality or migration); a higher abstraction level than refactoring (which can be a step of it). Refactoring: changing code without affecting functionality, to keep an app maintainable during maintenance (IDE-supported, e.g. splitting oversized methods).
• Reverse engineering: recovering code/models from artefacts like compiled binaries when old source is missing; includes re-documentation; aids understanding, usually a prep step before reengineering. Anti-patterns: common bad solutions, recognized early so improvement strategies can fix/avoid them.
• Artefacts: change requests (change wishes/fault reports — track controllably, transparently, via issue trackers, involve users); documentation of implemented changes/corrections (keep product docs consistent and traceable: who/what/why/how).
• Maintenance vs further development: maintenance does not change the functional state (only brings the technical realization up to date / further-develops existing functionality), whereas further development changes the functional state (add/remove functions); they can run in parallel, possibly by different teams.

Lehman and Belady's laws of software maintenance

Maintenance typically makes software larger and architecturally worse over time. Lehman and Belady (data collected 1976–1992) condensed this into six laws, holding especially for large, continuously used software:

Continuing change (software in use must continually adapt or becomes less useful); Increasing complexity (complexity grows unless work is done to reduce it); Self-regulation / fundamental law of program evolution (evolution is a self-regulating process); Conservation of organizational stability (invariance of work rate — the average effort/activity stays roughly constant over a release's life); Conservation of familiarity (invariance of release content — the incremental growth/change per release stays roughly constant); Continuing growth (the functional content must keep growing to keep users satisfied).

Framework lock-in and successor-system risk

Every library/framework you embed is another dependency you must update regularly, adapt to, and rarely control — a real challenge even for pros (GitHub needed 1.5+ years to move from Rails 3.2 to 5.2).

Brooks (analysing systems like OS/360) found that successor systems — the 2.0 built after the 1.0 release — carry an especially high risk of failing or being badly delayed (the "second-system effect").

A likely reason: emboldened by the first system's success and freed of its time pressure, developers over-engineer the successor — piling in all the features and refinements they had to leave out the first time — so it becomes bloated, over-ambitious and late. The remedy is disciplined scope control and incremental delivery.

• Lock-in: the more deeply you depend on a framework, the harder and costlier it is to update or switch away, because much of your code is tied to its conventions/APIs (compare consistent early abstraction from the framework).
• To minimize update pain: abstract from frameworks early, keep dependencies up to date in small steps (don't skip many versions), have good automated tests/regression to catch breakage, weigh the benefits (security, features, support) against the migration cost, and isolate third-party APIs behind your own interfaces.