ArchitectureConference - Short25min
Designing Systems That Can Be Changed Safely
This talk examines how to design software architectures that enable safe, reversible change. It highlights real-world patterns and pitfalls for evolving long-lived systems, focusing on reducing risk, increasing observability, and avoiding brittle flexibility or overengineering. Attendees learn principles for managing change under real constraints beyond tests and CI/CD.
talk.summaryAiDisclaimer
Tevfik EkiciThermo Fisher Scientific
talkDetail.whenAndWhere
Friday, June 19, 12:50-13:15
Room 1
talks.roomOccupancytalks.noOccupancyInfo
Change is inevitable in software, but most systems are not designed to absorb it safely. New requirements, new teams, and new constraints are often introduced into architectures that become increasingly brittle over time.
This talk explores what it really means to design systems that can be changed safely. Going beyond tests and CI/CD, we’ll focus on architectural decisions that reduce blast radius, make behavior observable, and keep change reversible. We’ll examine why “flexibility” often becomes a liability, how black-box dependencies undermine safe evolution, and why overengineering in the name of future-proofing frequently backfires.
Drawing from real-world experience with long-lived, mission-critical systems, the session highlights practical patterns and anti-patterns for evolving software under real constraints such as validation, organizational pressure, and team change. The focus is on principles that hold up over time, not specific tools or frameworks.
Key takeaways include:
– What “safe change” means in practice
– How to limit risk and failure impact
– How to avoid irreversible architectural decisions
This talk explores what it really means to design systems that can be changed safely. Going beyond tests and CI/CD, we’ll focus on architectural decisions that reduce blast radius, make behavior observable, and keep change reversible. We’ll examine why “flexibility” often becomes a liability, how black-box dependencies undermine safe evolution, and why overengineering in the name of future-proofing frequently backfires.
Drawing from real-world experience with long-lived, mission-critical systems, the session highlights practical patterns and anti-patterns for evolving software under real constraints such as validation, organizational pressure, and team change. The focus is on principles that hold up over time, not specific tools or frameworks.
Key takeaways include:
– What “safe change” means in practice
– How to limit risk and failure impact
– How to avoid irreversible architectural decisions
Tevfik Ekici
Tevfik is a Principal Software Systems Developer and Software Architect at Thermo Fisher Scientific with 15+ years of experience building and modernizing large-scale enterprise systems. He specializes in transforming legacy, high-risk platforms into scalable, multi-technology ecosystems that teams can actually sustain.
He leads the modernization of mission-critical systems, reducing operational risk and long-term cost while improving delivery stability. His work sits at the intersection of architecture, hands-on development, AI, and automation — but his real impact is on how teams, processes, and technology evolve together.
Tevfik is passionate about sharing real-world lessons from systems that survived years in production — and from those that didn’t.
He leads the modernization of mission-critical systems, reducing operational risk and long-term cost while improving delivery stability. His work sits at the intersection of architecture, hands-on development, AI, and automation — but his real impact is on how teams, processes, and technology evolve together.
Tevfik is passionate about sharing real-world lessons from systems that survived years in production — and from those that didn’t.