Trond Hjorteland

Information & Communications Technology

DDD SOA EDA Enterprise Architecture organisational design Organizational Change agile Sociotechnical Systems systems thinking

Oslo, Norway

Trond Hjorteland

Senior IT Consultant and sociotechnical facilitator.

Trond is an IT architect and sociotechnical facilitator from the consulting firm Scienta.no and has many years’ experience working with large, complex, and business critical systems, primarily as a developer and architect on middleware and backend applications. His main interests are service-orientation, domain-driven design, event driven architectures, and open sociotechnical systems, working in industries like telecom, media, TV, and public sector. His mantra: great products emerge from collaborative sense-making and design.

Trond tweets at @trondhjort and blogs at www.linkedin.com/today/author/trondhjort

Current sessions

Thriving in complexity

The world around us are getting ever increasingly hard to understand and predict in the way that we are used to. Simply taking a system apart and studying the elements and making useful models out of them seems to fail more often than not. Systems thinking is by many regarded as an essential tool for dealing with this kind of complexity, where unpredictability and ambiguity is the name of the game. The thing is that even though systems thinking is regarded as a new science, it is not an easy task to get a hang of. Not only is it mind-bending and frequently counter-intuitive, there are also numerous different schools of thought that frames things very differently and are useful for different things.

In this talk we will take a look at some of those schools of thought, with a specific focus on open systems as those are the kind of systems we frequently have to deal with in software development that is fundamentally a socio-technical enterprise. We will look into how important the environment is when dealing with such open systems and how we then collectively using participative democracy can deal with much of the complexity that the extended social field expose us to. We will see how we as a social system can become a learning organisation, which not only can adapt and be resilient, but even actively affect our futures. Not only will we cope better, we can actually thrive and build a better world for us all.

This a general intro to open systems theory and is based on a number of prototype talks held at different meetups and internal conferences. See https://www.linkedin.com/in/trondhjort/ for recordings.


Sociotechnical Systems Design for the “Digital Coal Mines”

70 years ago, a new approach and methodology called 'sociotechnical' was developed in the British coal mines and years of action research around the world followed to find ways to jointly optimize the technical and social aspects of the work system. This did not just make the organisations perform better, but also made it more adaptable, resilient, and improved the quality of work life for all involved.

The IT industry is struggling to find better ways of working with technology that progresses at an ever-increasing rate and where workers are demanding more participation in the design of both the products and the work itself. The publication of the agile manifesto is regarded as a pivotal moment and although the values and the principles described there seems to have a lot in common with the sociotechnical principles described 25 years earlier, it seems to lack the open systems theory thinking that was developed to manage in this turbulent environment.

In this talk we will take closer look at open sociotechnical systems thinking and compare it to agile, seeing where they overlap and diverge. Maybe methods and theoretical underpinnings developed in social sciences over the years are just what IT organisations need to cope and thrive in the increasingly complex and hazardous “digital coal mines."

Talk based on years of experience with agile way of work and a detailed study of the sociotechnical system design literature. Previous talks and blog post that touch on similar topics are available at https://www.linkedin.com/in/trondhjort .


Analysis is not enough

Most of us have been taught that analysis is the way to deal with complexity, breaking the problem up into small manageable parts and treat them in isolation. Systems thinking puts a different spin on this, showing that synthesis is equally important to fully understand a system, especially in order to get a grasp of the emergent behaviour that are not explainable based on the parts alone. In this talk we will take a look at these two paradigms and investigate how holism can provide important insights and knowledge to handle the complexity in domains where people are involved, be it user stories, microservices, and architecture. We will take a look at why reductionism is dominating in the natural sciences, while social sciences is mostly explained using holism and see what these professions can teach us about how to approach software as part of a sociotechnical system.

This is an introduction to systems thinking and its importance when dealing with complexity.


Good Fences Make Good Neighbours

Modularity is a key aspect of software and architectural design, setting explicit boundaries between different parts of the system. But we have been banging on about this since the 70s, and still we are creating big balls of mud -- now even the distributed kind. Either modularity as a concept is insufficient or maybe there are aspects here we seem to get wrong. We know that good fences make good neighbours, but only when the boundaries are placed correctly. How can we create robust and sustainable modular designs when identifying those boundaries are so challenging?

In this talk, we are going to take a closer look at why modularity is needed, what it actually can do for us, and how we can increase our chances of getting it right by taking a systems thinking approach. The claim made is that a holistic view of the problem space is critical; one that consider all its parts, including the business and all the people affected. Software development today is a inherently a sociotechnical endeavour and any modularisation effort, be it information hiding, SOA, microservices, DDD, Team Topologies and more, must take this into account in order to be able to create solutions that are sustainable and have the necessary conceptual integrity. Maybe this will guard you against the dreaded distributed big ball of mud, the killer of agility and productive collaboration.

New talk that builds on the previous talk and blog post of mine, "Microservices Without DDD is Risky Business!", which are available at https://www.linkedin.com/in/trondhjort, extended with basic system thinking theory,


Modularity in open systems

Modularity is a common tool we use to deal with complexity, grouping things into neat boxes that let us focus on a small part of a larger system in isolation. We have probably done it this way for aeons. This changed with the introduction of a new way of looking at reality, a new framing frequently referred to as systems thinking. We learnt that any non-trivial system is defined by the interconnectedness of its parts and that the parts themselves are described by its role in the whole. It no longer made sense to view the parts as independent entities. Another realisation made was that some systems are closed and some are open to its environment, which change the playing field even more. Not only are parts dependant on the whole, the whole is also in a intimate relationship with its surroundings.This new framing opens up a new door to a whole new world, where unpredictability is abound and we no longer can safely use mechanistic tools like analysis and reductionism, expecting full determinism.

In this talk we will explore the impact this perspective has on us as developers of IT system, with our desire to create stable, predictable and robust solutions for the business and their users. How is that at all possible in the VUCA world of open systems where everything is connected to everything and where it all is in constant motion? Herding cats, anyone?

New talk done once as a short version for API Days 2021.


From Capabilities to Services: Modelling for business-IT alignment

Service-orientation is still a surprisingly hard and complicated endeavour after all these years and the risk of getting it wrong, potentially ending up with a distributed monolith with its tight coupling, fragility, and high cognitive load, is still very real to many. Our industry is fairly immature and moves so fast that internalising acquired knowledge seems difficult and we often go through cycles of re-discovery of findings made decades ago. Maybe some SOA practitioners from the previous attempts made some breakthroughs that we have missed as we now have another go with microservices? 

The concept of business capabilities from business architecture can be one approach to take a closer look at, with its holistic outside-in perspective of the company. The capability vantage point inherently abstracts away the 'what' a company does from the 'how' , describing the essence of what the business offers. In this talk we will take a closer look at what they are and what they can help us with, all the way from business strategies and analysis, via organisational design to data management and technical design. They may just be the tool we need to design services, micro or not, as parts in a business aligned sociotechnical system, where people, information, processes, and technology are jointly driving business outcomes.

Have done this talk a few times before, at KanDDDinsky 2018 in Berlin, muCon 2019 in London, and JavaZone 2019 in Oslo, where it has been well received and created interesting discussions. Business capabilities and their use in sociotechnical systems design seems to be new to most. Recordings of previous talks can be found on my LinkedIn page https://www.linkedin.com/in/trondhjort/.


Microservices Without DDD is Risky Business!

Just about everyone is doing microservices these days, at least that's what they're claiming. Microservices is the new black! But, how well are they really doing? When breaking things up there is a risk of ending up in the same rut as SOA did a decade ago, this time creating distributed monoliths. Is it at all possible to reach the promised land consisting of autonomous, cohesive, and loosely coupled services that can give your business the necessary agility in a competitive market?

Scientific research has shown that loosely coupled and well-encapsulated architectures is the most central factor in IT success, but it is critical that it is done the right way. Domain-driven design is often mentioned as an essential technique, especially modularising using bounded contexts that reflects the business domain. Combined with service-orientation this can lead to sustainable designs rooted in and governed by the business strategy. We will have a closer look at central aspects from both tool boxes, focusing on designing robust and autonomous modules that can be built and maintained independently by stable product teams. Since the business agility is constrained by the technical agility, these teams can now focus on building great products instead of fighting the architecture.

This is my oldest talk, actually first held in 2016. It has evolved a lot since then, with more data from the industry and personal experience. Have done it both online and live at conferences like NDC, Build Stuff, NDC. Recordings have gotten 7k+ views on YouTube, links can be found on my LinkedIn page https://www.linkedin.com/in/trondhjort/.


User Story Mapping for Domain Discovery

Are you in a company that is customer obsessed, striving to create solutions that focus on the user needs and desires? Maybe you even try to build those solutions together with the customer, involving them in the actual design by building incrementally using mock-ups, pilots, and MVPs? How can we build stable and sustainable IT solutions in such an highly agile environment?

In this workshop, we will take a close look at a technique that came out of the agile community; user story mapping. The original application was to get control of the product backlog, making it explicitly connected with the user interaction and help discovering delivery slices that are viable for the user. Its applicability can also be extended to include other phases of the product delivery, all the way from the initial ideas and inception, creating coherent customer journeys, to the continuous enrichment and maintenance of the product after the initial deliveries. Story mapping is not only a tool for product discovery, but also domain modelling and product delivery, being a tool to cross the chasm between business, UX, and IT.

We will create a map for a concrete product taken from the pay TV domain, trying to follow all the phases of the product discovery and learn the intricacies of the domain along the way. The user need is the main driver here, but will also be constrained by company strategies, IT legacy, organisational structure, and many other factors. We will also see how the map can be used to handle changes in requirements as well as explore how one can incrementally construct the product to shorten the essential feedback-loop.

This is a 2 hour session, focusing on the story mapping technique.


Get a holistic view of your company with business capabilities

Did you know that there are large corporates out there with hundreds of customised versions of the same ERP system built by different teams serving the same purpose? Or, have you observed shadow IT, where business departments take matters into their own hands when not getting attention in the IT department?

Complex legacy architecture all too often reduce the competitive edge and business agility in large organisations, as well as becoming both more costly to maintain and expand upon. Resolving service problems takes a long time and new initiatives to fix and improve takes too long to realise, if at all.

Value stream mapping and business process diagrams may provide some insight, but they will not necessarily give you the proper context as duplications and bias in your ecosystem often is well hidden. You lack the necessary situational awareness.

When walking out of this workshop you will have the tools needed to gain a holistic view of your company, including the ability to map out IT's current situation and how to get you to where you want to be. All based on the company's business strategy, as the IT strategy is nothing more than a way to secure your company's sustainability and success.


User Story Mapping for Domain Modelling

Are you in a company that is customer obsessed, striving to create solutions that focus on the user needs and desires? Maybe you even try to build those solutions together with the customer, involving them in the actual design by building incrementally using mock-ups, pilots, and MVPs? Or, maybe you are not there yet, but want to be? Anyhow, you have probably then wondered how on earth you can design and build a viable systems portfolio in such a setting, avoiding the risk of stringing together unfinished components with duct tape, strings and paper clips, or creating overly complex solutions to cater for any future need. There is a lot of talk about evolutionary architecture, but how can we tie that in with the customer needs? In order to build sustainable systems we need to know where the early prototypes are taking us; we need to be able to see further ahead. In short, what can help us do domain modelling in this highly agile world?

In this workshop, we will take a close look at a technique that came out of the agile community; user story mapping. The original application was to get control of the product backlog, making it explicitly connected with the user interaction and help discovering delivery slices that are viable for the user. Its applicability can also be extended to include other phases of the product delivery, all the way from the initial ideas and inception, creating coherent customer journeys, to the continuous enrichment and maintenance of the product after the initial deliveries. Story mapping is not only a tool for product discovery, but also domain modelling and product delivery, being a tool to cross the chasm between business and IT, i.e. the problem and solution domain.

We will create a map for a concrete product taken from the pay TV domain, trying to follow all the phases of the product discovery and learn the intricacies of the domain along the way. The user need is the main driver here, but will also be constrained by company strategies, IT legacy, organisational structure, and many other factors. We will then try to create a domain model that not only cater for the initial needs, but also what the map is telling us about the future. The goal is the balancing act of supporting the initial version well, not creating an overly-complex model that caters too much for possible future need, but still being adaptive enough to absorb changes that we see coming.

This is a 3 hour session where we will explore both story mapping and domain modelling.


Past and future events

KanDDDinsky 2022

31 Oct 2022 - 2 Nov 2022
Berlin, Germany

Domain-Driven Design Europe 2022

20 Jun 2022 - 24 Jun 2022
Amsterdam, North Holland, Netherlands

NDC Oslo 2021

29 Nov 2021 - 3 Dec 2021
Oslo, Norway

Build Stuff 2021 Lithuania

17 Nov 2021 - 21 Nov 2021
Vilnius, Lithuania

Domain-Driven Design Europe 2021

4 Feb 2021 - 5 Feb 2021

NDC London 2021

25 Jan 2021 - 29 Jan 2021
London, England, United Kingdom

Build Stuff 2020 Lithuania

11 Nov 2020 - 15 Nov 2020

Distributed Domain-Driven Design Day (DDDDD)

15 May 2020

Domain-Driven Design Europe 2020

3 Feb 2020 - 7 Feb 2020
Amsterdam, North Holland, Netherlands

KanDDDinsky

17 Oct 2019 - 18 Oct 2019
Berlin, Germany

NDC Oslo 2019

17 Jun 2019 - 21 Jun 2019
Oslo, Norway

KanDDDinsky

17 Oct 2018 - 19 Oct 2018
Berlin, Germany