Day 1

Mer information kommer

”I mitt yrke som It-Arkitekt så har jag jobbat med många olika ramverk och metoder och har hittar många guldkorn. Men i den nya världen där förändring är mycket AI driven och har mer av en mystisk black box är det svårare att hitta något som fungerar. Det som finns idag bygger på att man kan utvärdera och agera på nya behov och förutsättningar. Så jag har tagit tag i problemet och utvecklat ett eget ramverk som kan hantera osäkerheten som finns idag med AI. Jag delar gärna med mig av hur jag har lyckats hantera utmaningarna och vilka erfarenheter man kan ta med sig hem till sin egen organisation och implementera”

Mathias har en gedigen och mångsidig bakgrund inom IT med erfarenhet från både privata och offentliga verksamheter. Han har verkat i roller som projektledare, lösnings- och IT-arkitekt, samt teknisk specialist, där han särskilt utmärkt sig med djup kompetens inom molnlösningar och licenshantering.

Genom åren har Mathias lett såväl stora och komplexa projekt som förstudier, utredningar och förändringsinitiativ med tydligt fokus på verksamhetsnytta. Han är resultatorienterad, självgående och engagerad, vilket ofta lyfts fram av kunder som uppskattar hans förmåga att både driva arbetet framåt och skapa förtroende i organisationen.

Mathias är särskilt skicklig på att kommunicera ett tydligt ”varför” i förändringsarbete – han strävar alltid efter att få med sig både teamet och intressenter på resan mot gemensamma mål. Hans styrka ligger i att kunna växla mellan strategiskt helhetsperspektiv och operativ detaljnivå, vilket gör honom till en uppskattad länk mellan verksamhet och teknik.

AI makes it easier than ever to produce code, models and solution proposals. That does not make architecture less important. It makes it more demanding.
The problem is that different parts of the organisation do different jobs. Some parts need repeatability. Others need coordination under uncertainty. Others require fast action under time pressure. In the same way, different processes try to secure different things: an actual outcome, consistent and legitimate handling, or stable automation. The same architecture logic can therefore not work everywhere.
In this session, Henrik Ekstam shows why we need to distinguish more clearly between planned architecture and emerging architecture. Planned architecture works when the answer is largely known and the change can be realised step by step. Emerging architecture is needed when the problem is not yet fully defined and value must be discovered in reality, together with others.
AI strengthens both needs. To use AI well, we need more structure underneath: data, semantics, governance and operating model. But the easier it becomes to generate answers, the more important it also becomes to understand which logic should dominate in a given situation, and which people need to be involved to create a relevant answer.

After the session, participants will be able to:
Distinguish between when architecture should standardise and when it should enable exploration
Identify which logic a process or problem requires
Understand why AI increases the need for both structure and human interpretation
Use architecture to create clarity in decisions, not only documentation
The core thesis of the session is simple: the role of architecture is not primarily to give answers. It is to create enough clarity for the right answer to emerge in the right context.

AI gör det enklare än någonsin att producera kod, API:er och till och med arkitekturbeslut. Men när systemen växer uppstår en klassisk fråga i ny tappning:
Vet vi hur våra tjänster faktiskt samverkar – och är arkitekturen fortfarande ändamålsenlig?

I denna session presenterar vi ett angreppssätt för kontinuerligt uppdaterad dokumentation av samverkande tjänster, där AI används som stöd – men där människan förblir central.

Utifrån ett konkret initiativ visar vi hur man kan:
• Skapa sekvensdiagram (Mermaid) direkt från kod i valda repositories
• Bygga och underhålla en kanonisk informationsmodell med “human-in-the-loop”
• Automatiskt identifiera förändringar i API:er, meddelanden och databasstrukturer
• Generera och uppdatera tjänstekartor och dataflödesdiagram
• Dokumentera verksamhetsregler kontinuerligt – inte bara vid projektstart

Vi diskuterar särskilt:
• Hur AI kan användas för att extrahera arkitektur ur kod utan att skapa falsk trygghet
• Varför informationsarkitekter måste vara aktivt involverade i modelleringen
• Hur man designar ett arbetssätt som kombinerar automation och mänsklig involvering
• Hur arkitektur kan bli levande, kontextuell och förklaringsbar

Sessionen kopplar direkt till temat ” Hållbarhet utöver klimat och utsläpp” genom att visa hur vi kan:
• Göra system mer begripliga
• Stärka dialogen mellan utvecklare, arkitekter och verksamhet där människan behåller sin roll och agens
• Säkerställa att AI förstärker – inte försvagar – arkitekturens kvalitet

Alla system har en arkitektur. Frågan är om den är synlig, förståelig – och uppdaterad.

Mer information kommer inom kort

Traditionellt UX-arbete bygger på överlämningar. Resultatet: långa feedback-loopar, tappad kontext och friktion mellan design, utveckling och verksamhet. Med AI förändras förutsättningarna i grunden — UX kan arbeta direkt i kodbasen, inte som en vision i dokument utan som något körbart, testbart och itererbart i realtid.

Feedback-loopar som tog veckor tar nu timmar. Designers, utvecklare och kunder möts kring samma artefakt. Överlämningar ersätts av kontinuerligt samarbete. Lars Olof Berg delar konkreta byggstenar och lärdomar från ett skarpt projekt — och vad som krävs för att ta steget från individuella AI-trick till ett fungerande arbetssätt i skala.

In large-scale agile development, many important problems are not technical in themselves, yet they have major technical consequences. Unclear roles, weak coordination, poor communication, and inherited ways of working can create non-technical debt: hidden human and organizational conditions that slow teams down, complicate decisions, and undermine system development over time.
 
This presentation shows why non-technical debt matters for IT architects and other practitioners working with socio-technical systems. Based on empirical studies of large-scale agile development, it introduces process, social, and people debt as practical concepts for understanding how human context affects architecture and delivery. The session will highlight how to identify these issues, why they matter even more in an AI-supported development environment, and what practitioners can do to improve collaboration, decision-making, and system design.

My father was operations manager at a gold mine in the inland of northern Sweden. During a visit to the mine, he didn’t just explain the process—he paused at something that stuck with me: it takes as little as 3 grams of gold per 1 ton of rock for mining to be worthwhile. Three grams. Out of a million grams of grey stone. That ratio has stayed with me ever since.

In the AI era, it feels more relevant than ever. We are drowning in data, models, prompts, agents, and possibilities—but real value is still extremely concentrated. What if just 3 KB of insight in 1 TB of data is enough to make data mining worthwhile? Or 0.25 seconds in a 24-hour day for a reflection to be worth writing down? Even when the work feels grey, repetitive, and seemingly uninteresting, there is gold beneath the surface. The question is whether we have the right tools, the right pickaxe—the right framework, process, and architecture—to distinguish the gold.

This talk takes its starting point in Pickaxe Principles – Thriving in the AI Gold Rush, but goes beyond the book by, among other things, using the journey of writing, launching, and scaling the book as a concrete case. The audience will follow how AI, workflows, agents, and automation are used in practice to move from experiments to coherent systems—with the goal of creating 2×, and in some areas 10×, real impact.

The focus is not on individual tools or models, but on the architecture that enables consistent value creation over time. We explore why many AI initiatives get stuck in short-term productivity, while few succeed in building systems where small insights accumulate, are refined, and grow in value. Often, it’s not the technology that fails, but the context: accountability, incentives, human judgment, and discipline in everyday work.

Using the gold rush metaphor as a framework—prospecting, mining, refining, and value creation—we discuss how architects can design socio-technical systems where people, AI, and organizations collaborate in a sustainable way.

After the talk, participants will leave not only with inspiration, but with concrete and directly applicable tools for how they can:

identify the “3 grams of gold” that create real value in their data, systems, and AI initiatives
discover and unlock potential in themselves and in people around them
design architecture, ways of working, and incentives that ensure small insights are actually captured, refined, and reused
build structures where consistency compounds—so that value grows over time, even when everyday work feels grey

The goal is for participants to return to their organizations with a shared language, a clear framework, and a practical starting point for gathering gold—in themselves, in others, and in the systems they are responsible for.

The focus of this talk will be to explore how, as organizations continue to automate and modernize, the risk of designing systems that outperform or constrain human capacity grows. In complex socio-technical environments, performance of an organization behaves less like a machine you can optimize part-by-part and more like a quantum system: outcomes emerge from interdependence, context and observation. The authors of this talk proposal that sustainable organizations arise not from maximizing technology alone, but from cultivating a culture and practice of kinship between humans, their processes and their technological systems. That organizations need to focus on optimization that is not additive, but relational – changing one element of an organization changes the whole, and what we choose to measure and automate shapes what is possible.