Trond Hjorteland

Information & Communications Technology

DDD SOA EDA Enterprise Architecture

Oslo, Norway

Trond Hjorteland

Senior Consultant at Scienta, aspiring 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 design.

Current sessions

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 balls of mud and now even distributed big balls of mud. 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, you are going to see the best bits of modularity from SOA, microservices, DDD, Team Topologies, and more. You will see how microservices improved physical modularity compared to SOA, but lost the connection to business capabilities and the related team structure by its focus on size. And you will see how DDD's bounded contexts can help us retain the benefits of microservices while reintroducing the connection to the business that SOA once had.

Modularity in architecture is sociotechnical - the shape of the software and the shape of the organisation are highly interdependent and coevolving. So we will also see how Team Topologies provides a blueprint for aligning teams and architecture using patterns for identifying teams, shaping their interactions, and minimising cognitive load.

In summary, this talk will help you piece together all of these good practices and understand the theory behind them, improving your holistic system design skills and enabling you to create conceptual integrity in your designs. Maybe this will guard you against the dreaded distributed big ball of mud.

This is a new talk, but will in essence be a amalgamation of my two talks on DDD and business capabilities for anyone doing microservices.


From Capabilities to Services: Modelling for business-IT alignment

Service-orientation is still a surprisingly hard and complex endeavour after all these years and the risk of getting it wrong, potentially ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare, 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, holistically in a business aligned sociotechnical system, where people, information, processes, and technology defined by the business capability they supports.

Have done this talk before, at muCon London, KanDDDinsky Berlin, and JavaZone Oslo. For links, see my LinkedIn profile https://www.linkedin.com/in/trondhjort. The talk is partly an experience report and theoretical foundation. It can be adjusted to different lengths, but is currently at about 60 min.


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.

I have done this talk before, at JavaZone in Oslo, but then in Norwegian. The attendance was good and it has gotten quite a few views on Vimeo ((https://vimeo.com/181948156) .


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

Distributed Domain-Driven Design Day (DDDDD)

15 May 2020

Domain-Driven Design Europe 2020

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

KanDDDinsky

16 Oct 2019 - 17 Oct 2019
Berlin, Germany

NDC Oslo 2019

16 Jun 2019 - 20 Jun 2019
Oslo, Norway

KanDDDinsky

16 Oct 2018 - 18 Oct 2018
Berlin, Germany