Trond Hjorteland

Information & Communications Technology

DDD SOA EDA Enterprise Architecture

Oslo, Norway

Trond Hjorteland

Senior Consultant at Scienta.no, an aspiring sociotechnical systems designer.

Trond is an IT architect and aspiring sociotechnical systems designer from the consulting firm Scienta.no and has many years experience 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 sociotechnical systems, working in industries like telecom, media, TV, and public sector. Mantra: Great products emerge from collaborative sensemaking and design.

Current sessions

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."

New talk that is 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 and reductionism is the way to deal with complexity, breaking the problem up into small manageable parts and treat them in isolation. Systems thinking puts a totally different spin on this, claiming that instead holism and synthesis is needed 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 I will take a brief 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. 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 a short 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.

In summary, this talk will help you piece together all of the these good modularisation practices and understand the theory behind them, improving your holistic system design skills, and enabling you to create requisite coherence in your sociotechnical designs. Maybe this will guard you against the dreaded distributed big ball of mud, the killer of productive collaboration and business agility.

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,


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

NDC Oslo 2021

28 Nov - 2 Dec 2021
Oslo, Norway

Build Stuff 2021 Lithuania

16 Nov - 20 Nov 2021
Vilnius, Lithuania

Domain-Driven Design Europe 2021

3 Feb - 4 Feb 2021

NDC London 2021

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

Build Stuff 2020 Lithuania

10 Nov - 14 Nov 2020

Distributed Domain-Driven Design Day (DDDDD)

15 May 2020

Domain-Driven Design Europe 2020

2 Feb - 6 Feb 2020
Amsterdam, North Holland, Netherlands

KanDDDinsky

16 Oct - 17 Oct 2019
Berlin, Germany

NDC Oslo 2019

16 Jun - 20 Jun 2019
Oslo, Norway

KanDDDinsky

16 Oct - 18 Oct 2018
Berlin, Germany