Michael
For more than four decades, I have worked with technical systems – not only with how they work, but why they work.
I am less interested in individual technologies than in the rules, dependencies, and feedback through which systems emerge, work together, and remain viable over many years.
One question has followed me through very different stages of my work:
What actually happens within a system – and does it match what we expect from it?
Understanding systems – piece by piece
Complex systems cannot be understood in their entirety.
Even a company with a few dozen or a hundred people consists of technical systems, workflows, informal knowledge, exceptions, and dependencies that no one can keep entirely in their head.
That is why I do not try to impose a finished model or a new architecture on a system as quickly as possible.
I define a relevant section, examine its processes, states, and known interfacesDefined boundary between systems or system components at which relevant properties, interactions, or relationships are specified
Auch bekannt als: System Interface, Technical Interface, and expand the picture as new dependencies become visible.
My own model of the system remains exactly that: a model. It can be incomplete – as long as it is known where knowledge is missing or assumptions have not yet been verified.
Control and deviation
A large part of my work has always involved comparing expected and actual states.
It began with analysis and controlling systems, continued through construction costing, enterprise software, and system migrations, and extended to platforms, production systems, and today’s AI-assisted workflows.
A deviation is initially just information.
It can be an error, a risk, a tolerable exception – or something interesting from which a better solution develops.
That is why I am interested in fault-tolerantAbility of a system to continue providing its required function despite certain faults
Auch bekannt als: Fault-Tolerant System, Error Handling and resilientAbility of a system to maintain, restore, or adaptively continue essential functions under disruptions and changes
Auch bekannt als: System Resilience, Resilient Systems systems: systems that make their state visible, can handle deviations, and still remain adaptable.
From mainframes to distributed platforms
My professional work began in the 1980s in electrical engineering, automation, and mainframe environments.
Since then, I have had the opportunity to encounter and help shape a wide variety of systems.
These included:
- analysis, controlling, and migration systems in field service
- enterprise software for construction companies
- accounting, costing, and business processes
- networked sites and Unix systems
- editorial, association, and intranet platforms
- logistics and brokerage platforms
- live streaming, billing, and payment systems
- internet-based machine control systems with feedback and usage-based billing
- international embedded and set-top box projects
- production and digitalization processes in mechanical engineering
- server, network, and system migrations
- publishing and publication systems
The technologies used changed constantly.
The fundamental questions surprisingly rarely did.
Architecture, integration, and operations
Software rarely exists in isolation.
I am particularly interested in the places where systems have to be connected: interfaces, data flows, migrations, old and new components, technical and operational processes.
Today, these include terms such as Systems AnalysisStructured examination of a system, its properties, and relationships as a basis for technical decisions
Auch bekannt als: System Analysis, Systems ArchitectureFundamental structure of a system with its elements, relationships, interfaces, and the principles according to which it is organized
Auch bekannt als: System Architecture, Solution ArchitectureArchitectural description of a concrete solution for a defined problem or set of requirements
Auch bekannt als: System Architecture, Systems IntegrationConnection of different components or systems into a cooperating overall system
Auch bekannt als: System Integration, Verification & ValidationEvaluation of whether a system meets specified requirements and is suitable for its intended use
Auch bekannt als: Verification & Validation, V&V, or Legacy ModernizationTargeted modification of existing systems and their environment without automatically equating modernization with complete replacement
Auch bekannt als: Legacy System Modernization, Application Modernization, Legacy Migration.
To me, they describe different aspects of the same work:
first understand what is actually there – and then decide what can reasonably be changed.
Programming has been part of my toolkit for decades. But it has rarely been an end in itself for me.
If a small program solves a problem, a small program gets written. If no new software is necessary, that is often the better solution.
AI as part of a system
Since 2025, I have been working more intensively with Large Language Models and AI-assisted workflows.
My initial approach was pragmatic: research, web development, programming, and writing could suddenly be done considerably faster.
But the limitations quickly became apparent as well.
Well-written results do not have to be correct. Detailed instructions do not automatically produce consistent results. More context helps only as long as the relevant context can still be processed. And a second AI can overlook the same plausible-sounding error as the first.
This raised new questions:
- How can the context relevant to a task be determined?
- How can rules outside a probabilisticProperty of a model or system in which probabilities are part of the calculation or description of possible outcomes
Auch bekannt als: Probabilistic System, Probability-Based System model remain verifiable? - How can results be independently cross-checked?
- Which statements can be verified against real systems?
- Where must a human retain responsibility?
- How do you build workflows that account for the limitations of AI instead of ignoring them?
Today, parts of this field are described by terms such as Context EngineeringSystematic design and provision of the context relevant to a specific AI task
Auch bekannt als: Context Management, AI EvaluationSystematic evaluation of the properties, results, and behavior of an AI system based on defined criteria
Auch bekannt als: AI Evaluation and Testing, LLM Evaluation, or AI AssuranceSystematic generation, evaluation, and communication of evidence to enable justified trust in relevant properties and the use of an AI system
Auch bekannt als: Artificial Intelligence Assurance.
At dragons@work, we are developing our own tools and rule sets for this purpose. Many of them are themselves still under development and are initially being tested in our own work.
Why Low-Tech?
Technologies come and go. Good models remain.
I like small, manageable systems.
The fewer unnecessary components a system contains, the easier it is to understand what happens within it, what effect a change has, and where an error or unexpected deviation occurs.
For me, Low-TechTechnical design approach that meets an actual need with a solution that is as appropriate, understandable, durable, and manageable as possible
Auch bekannt als: Low Tech, Low Technology, Low-Tech Approach, Simple Systems therefore does not mean using old technology for its own sake.
It means using only as much technology as a problem actually requires.
This connects with a second important topic in my work today: digital sovereigntyAbility to make autonomous decisions about digital systems, data, and dependencies and to remain capable of acting when conditions change
Auch bekannt als: Digital Independence, Technological Sovereignty.
Open formatsData format whose technical structure and meaning are sufficiently publicly documented so that independent implementations can create, read, and process data
Auch bekannt als: Open Format, free software, Self-HostingOperation of a digital service or system under one's own technical and organizational responsibility
Auch bekannt als: Self Hosting, Self-Hosted Operation, and traceable dependencies can help keep systems controllable and adaptable over the long term.
Technical toolkit
My daily work today includes the following areas:
- OpenBSD and Debian
- Lua, C, and shell
- server and network architectures
- self-hosting
- static websites and long-lived web infrastructures
- open data formats and federated systems
- technical documentation
- AI-assisted development and verification processes
Over the decades, numerous other operating systems, programming languages, databases, platforms, and tools have been added.
They are experience and a toolkit – not my job title.
Not only digital
Not all of the experiences of the past decades took place in front of a screen.
They include electrical engineering and installation work, trade and sales, business management, accounting, publishing, markets, and even building our own small wagon.
These experiences are not irrelevant to my technical work.
Technical systems are built and used by people and are almost always part of larger business or societal contexts.
What I work on today
At dragons@work, we are developing books, software, and open rule sets around technical systems and digital independence.
These include:
- technical books and documentation
- reference implementations
- open protocols and data formats
- tools for long-lived and traceable systems
- methods for verifying technical and AI-assisted work
- Biocodie as an attempt to look at rules, states, deviations, and development in technical systems differently
Many of these efforts intersect.
Books describe concepts, rule sets establish common foundations, and software serves to test ideas in practice and make them verifiable.
Technologies change. Good models remain.