�ݺ�ߣshows by User: trondhr

�ݺ�ߣshows by User: trondhr / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: trondhr / Thu, 03 Nov 2022 17:47:53 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: trondhr Thriving in Complexity /slideshow/thriving-in-complexitypdf/253988698 thrivingincomplexity-221103174753-189da4eb
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.]]>
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.]]> Thu, 03 Nov 2022 17:47:53 GMT /slideshow/thriving-in-complexitypdf/253988698 trondhr@slideshare.net(trondhr) Thriving in Complexity trondhr 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. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/thrivingincomplexity-221103174753-189da4eb-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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.

Thriving in Complexity from Trond Hjorteland

]]> 24 0 https://cdn.slidesharecdn.com/ss_thumbnails/thrivingincomplexity-221103174753-189da4eb-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Sociotechnical Systems Design for the “Digital Coal Mines” /slideshow/sociotechnical-systems-design-for-the-digital-coal-minespdf/253988666 sociotechnicalsystemsdesignforthedigitalcoalmines-221103174548-b7cedc1e
0 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."]]>
0 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."]]> Thu, 03 Nov 2022 17:45:47 GMT /slideshow/sociotechnical-systems-design-for-the-digital-coal-minespdf/253988666 trondhr@slideshare.net(trondhr) Sociotechnical Systems Design for the “Digital Coal Mines” trondhr 0 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." <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/sociotechnicalsystemsdesignforthedigitalcoalmines-221103174548-b7cedc1e-thumbnail.jpg?width=120&height=120&fit=bounds" /> 0 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."

Sociotechnical Systems Design for the “Digital Coal Mines” from Trond Hjorteland

]]> 18 0 https://cdn.slidesharecdn.com/ss_thumbnails/sociotechnicalsystemsdesignforthedigitalcoalmines-221103174548-b7cedc1e-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 From Capabilities to Services: Modelling for Business-IT Alignment v.2 ext /slideshow/from-capabilities-to-services-modelling-for-businessit-alignment-v2-ext/170868062 fromcapabilitiestoservices-modellingforbusiness-italignmentv-190911130804
Service-orientation is still a surprisingly hard and complex endeavour, even after all these years. Our industry seems to go through cycles of re-discovery of knowledge with every new generation of developers, probably due to the exponential growth of new practitioners and the immaturity of this fairly young profession. The risk of doing service design wrong, potensially ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare, is still very real to many. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. The concept of business capabilities from enterprise architecture can be one approach to take a closer look at. It has proven to be very useful for a number of things, like business strategies, organisational structure, data management, and technical design. They can even help us identify subdomains, contexts, and those elusive (micro)services. Business capabilitiesare may just be the tool we need to design services in a business aligned sociotechnical system. This is the extended version.]]>
Service-orientation is still a surprisingly hard and complex endeavour, even after all these years. Our industry seems to go through cycles of re-discovery of knowledge with every new generation of developers, probably due to the exponential growth of new practitioners and the immaturity of this fairly young profession. The risk of doing service design wrong, potensially ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare, is still very real to many. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. The concept of business capabilities from enterprise architecture can be one approach to take a closer look at. It has proven to be very useful for a number of things, like business strategies, organisational structure, data management, and technical design. They can even help us identify subdomains, contexts, and those elusive (micro)services. Business capabilitiesare may just be the tool we need to design services in a business aligned sociotechnical system. This is the extended version.]]> Wed, 11 Sep 2019 13:08:04 GMT /slideshow/from-capabilities-to-services-modelling-for-businessit-alignment-v2-ext/170868062 trondhr@slideshare.net(trondhr) From Capabilities to Services: Modelling for Business-IT Alignment v.2 ext trondhr Service-orientation is still a surprisingly hard and complex endeavour, even after all these years. Our industry seems to go through cycles of re-discovery of knowledge with every new generation of developers, probably due to the exponential growth of new practitioners and the immaturity of this fairly young profession. The risk of doing service design wrong, potensially ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare, is still very real to many. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. The concept of business capabilities from enterprise architecture can be one approach to take a closer look at. It has proven to be very useful for a number of things, like business strategies, organisational structure, data management, and technical design. They can even help us identify subdomains, contexts, and those elusive (micro)services. Business capabilitiesare may just be the tool we need to design services in a business aligned sociotechnical system. This is the extended version. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/fromcapabilitiestoservices-modellingforbusiness-italignmentv-190911130804-thumbnail.jpg?width=120&height=120&fit=bounds" /> Service-orientation is still a surprisingly hard and complex endeavour, even after all these years. Our industry seems to go through cycles of re-discovery of knowledge with every new generation of developers, probably due to the exponential growth of new practitioners and the immaturity of this fairly young profession. The risk of doing service design wrong, potensially ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare, is still very real to many. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. The concept of business capabilities from enterprise architecture can be one approach to take a closer look at. It has proven to be very useful for a number of things, like business strategies, organisational structure, data management, and technical design. They can even help us identify subdomains, contexts, and those elusive (micro)services. Business capabilitiesare may just be the tool we need to design services in a business aligned sociotechnical system. This is the extended version.

From Capabilities to Services: Modelling for Business-IT Alignment v.2 ext from Trond Hjorteland

]]> 403 0 https://cdn.slidesharecdn.com/ss_thumbnails/fromcapabilitiestoservices-modellingforbusiness-italignmentv-190911130804-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Microservices without DDD is risky business! REDUX /trondhr/microservices-without-ddd-is-risky-business-v2 microserviceswithoutdddisriskybusinessv-190620220431
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, in effect creating distributed monoliths. So, is it at all possible for anyone to reach the promised land consisting of autonomous, cohesive, and loosely coupled services? My claim is that it is doable, but not without some up-front modelling under the guidance of Domain-driven Design concepts like "bounded context", "core domain", "ubiquitous language" and “aggregates”. Distilling the domain, drilling deep into the core business concepts, and breaking it up into isolated and protected contexts will take you a long way. Add some business capability modelling and service-orientation into the mix, and you are halfway there. Use it as a map to guide you on the journey towards an orderly and robust distributed system, built by adding one MVP at the time in a low-risk agile manner. This is a redux of the 2016 talk with the same title.]]>
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, in effect creating distributed monoliths. So, is it at all possible for anyone to reach the promised land consisting of autonomous, cohesive, and loosely coupled services? My claim is that it is doable, but not without some up-front modelling under the guidance of Domain-driven Design concepts like "bounded context", "core domain", "ubiquitous language" and “aggregates”. Distilling the domain, drilling deep into the core business concepts, and breaking it up into isolated and protected contexts will take you a long way. Add some business capability modelling and service-orientation into the mix, and you are halfway there. Use it as a map to guide you on the journey towards an orderly and robust distributed system, built by adding one MVP at the time in a low-risk agile manner. This is a redux of the 2016 talk with the same title.]]> Thu, 20 Jun 2019 22:04:31 GMT /trondhr/microservices-without-ddd-is-risky-business-v2 trondhr@slideshare.net(trondhr) Microservices without DDD is risky business! REDUX trondhr 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, in effect creating distributed monoliths. So, is it at all possible for anyone to reach the promised land consisting of autonomous, cohesive, and loosely coupled services? My claim is that it is doable, but not without some up-front modelling under the guidance of Domain-driven Design concepts like "bounded context", "core domain", "ubiquitous language" and “aggregates”. Distilling the domain, drilling deep into the core business concepts, and breaking it up into isolated and protected contexts will take you a long way. Add some business capability modelling and service-orientation into the mix, and you are halfway there. Use it as a map to guide you on the journey towards an orderly and robust distributed system, built by adding one MVP at the time in a low-risk agile manner. This is a redux of the 2016 talk with the same title. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/microserviceswithoutdddisriskybusinessv-190620220431-thumbnail.jpg?width=120&height=120&fit=bounds" /> 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, in effect creating distributed monoliths. So, is it at all possible for anyone to reach the promised land consisting of autonomous, cohesive, and loosely coupled services? My claim is that it is doable, but not without some up-front modelling under the guidance of Domain-driven Design concepts like "bounded context", "core domain", "ubiquitous language" and “aggregates”. Distilling the domain, drilling deep into the core business concepts, and breaking it up into isolated and protected contexts will take you a long way. Add some business capability modelling and service-orientation into the mix, and you are halfway there. Use it as a map to guide you on the journey towards an orderly and robust distributed system, built by adding one MVP at the time in a low-risk agile manner. This is a redux of the 2016 talk with the same title.

Microservices without DDD is risky business! REDUX from Trond Hjorteland

]]> 421 2 https://cdn.slidesharecdn.com/ss_thumbnails/microserviceswithoutdddisriskybusinessv-190620220431-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 From capabilities to services modelling for business-it alignment v.2 /slideshow/from-capabilities-to-services-modelling-for-businessit-alignment-v2/119980994 fromcapabilitiestoservices-modellingforbusiness-italignmentv-181019071641
Our industry seems to go through cycles of re-discovery of lost knowledge with every new generation of developers, which probably is not so odd considering the exponential growth of practitioners. Allegedly half of the programmers today are juniors, which means many of them have yet to encounter the challenges faced decades ago. For example, many run the risk of falling into the trap of modelling services around domain entities, risking ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare. Lucky for us, we have shoulders to stand on to get us out of the quagmire, or even better, prevent us from getting on that slippery slope in the first place. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. There are many great techniques to consider, like context mapping, user story mapping, event storming, and value chain analysis, but in this talk I will focus on the lost art of business capability modelling. My thesis is that a technique that was relevant in the pre-computing era might be just as useful and relevant when we split our monoliths into a mesh of autonomous (micro)services. Maybe they even could help us identify subdomains, contexts, and organisational structure; in effect the construction of sociotechnical systems?]]>
Our industry seems to go through cycles of re-discovery of lost knowledge with every new generation of developers, which probably is not so odd considering the exponential growth of practitioners. Allegedly half of the programmers today are juniors, which means many of them have yet to encounter the challenges faced decades ago. For example, many run the risk of falling into the trap of modelling services around domain entities, risking ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare. Lucky for us, we have shoulders to stand on to get us out of the quagmire, or even better, prevent us from getting on that slippery slope in the first place. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. There are many great techniques to consider, like context mapping, user story mapping, event storming, and value chain analysis, but in this talk I will focus on the lost art of business capability modelling. My thesis is that a technique that was relevant in the pre-computing era might be just as useful and relevant when we split our monoliths into a mesh of autonomous (micro)services. Maybe they even could help us identify subdomains, contexts, and organisational structure; in effect the construction of sociotechnical systems?]]> Fri, 19 Oct 2018 07:16:41 GMT /slideshow/from-capabilities-to-services-modelling-for-businessit-alignment-v2/119980994 trondhr@slideshare.net(trondhr) From capabilities to services modelling for business-it alignment v.2 trondhr Our industry seems to go through cycles of re-discovery of lost knowledge with every new generation of developers, which probably is not so odd considering the exponential growth of practitioners. Allegedly half of the programmers today are juniors, which means many of them have yet to encounter the challenges faced decades ago. For example, many run the risk of falling into the trap of modelling services around domain entities, risking ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare. Lucky for us, we have shoulders to stand on to get us out of the quagmire, or even better, prevent us from getting on that slippery slope in the first place. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. There are many great techniques to consider, like context mapping, user story mapping, event storming, and value chain analysis, but in this talk I will focus on the lost art of business capability modelling. My thesis is that a technique that was relevant in the pre-computing era might be just as useful and relevant when we split our monoliths into a mesh of autonomous (micro)services. Maybe they even could help us identify subdomains, contexts, and organisational structure; in effect the construction of sociotechnical systems? <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/fromcapabilitiestoservices-modellingforbusiness-italignmentv-181019071641-thumbnail.jpg?width=120&height=120&fit=bounds" /> Our industry seems to go through cycles of re-discovery of lost knowledge with every new generation of developers, which probably is not so odd considering the exponential growth of practitioners. Allegedly half of the programmers today are juniors, which means many of them have yet to encounter the challenges faced decades ago. For example, many run the risk of falling into the trap of modelling services around domain entities, risking ending up with a distributed monolith with its devastating coupling, fragility, and cognitive nightmare. Lucky for us, we have shoulders to stand on to get us out of the quagmire, or even better, prevent us from getting on that slippery slope in the first place. Being conscious of fallacies like those of distributed computing and anti-patterns like functional decomposition and entity services are all well and good, and necessary heuristics to good service design, but we often crave more concrete guidance. There are many great techniques to consider, like context mapping, user story mapping, event storming, and value chain analysis, but in this talk I will focus on the lost art of business capability modelling. My thesis is that a technique that was relevant in the pre-computing era might be just as useful and relevant when we split our monoliths into a mesh of autonomous (micro)services. Maybe they even could help us identify subdomains, contexts, and organisational structure; in effect the construction of sociotechnical systems?

From capabilities to services modelling for business-it alignment v.2 from Trond Hjorteland

]]> 3309 1 https://cdn.slidesharecdn.com/ss_thumbnails/fromcapabilitiestoservices-modellingforbusiness-italignmentv-181019071641-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Microservices without DDD is risky business! /slideshow/microservices-without-ddd-is-risky-business/92789912 microserviceswithoutdddisriskybusiness-180403162147
How relevant is domain-driven design (DDD) 13 years after Eric Evans' well-known blue book? The book and the community it grew out of was to a large extent defined by how large enterprises built their IT systems at the start of this century, dominated by the two large and all-encompassing platforms J2EE and .NET, often constructed in a very planned and controlled way. How on earth could this then be relevant in a world dominated by agility, microservices, and a plethora of technologies and platforms? Actually, central DDD concepts like bounded context, core domain, ubiquitous language, distillation, and aggregates fits even better in such a dynamic world than the large monoliths we struggled with back then. This rich toolbox contains techniques that helps us getting more intimate with the business, better understanding their visions and needs; principles helping us designing better and more sustainable solutions that are closely linked with the domain; and pattens for constructing autonomous components in an agile fashion. Fits like a glove! Presentation held at JavaZone 2016.]]>
How relevant is domain-driven design (DDD) 13 years after Eric Evans' well-known blue book? The book and the community it grew out of was to a large extent defined by how large enterprises built their IT systems at the start of this century, dominated by the two large and all-encompassing platforms J2EE and .NET, often constructed in a very planned and controlled way. How on earth could this then be relevant in a world dominated by agility, microservices, and a plethora of technologies and platforms? Actually, central DDD concepts like bounded context, core domain, ubiquitous language, distillation, and aggregates fits even better in such a dynamic world than the large monoliths we struggled with back then. This rich toolbox contains techniques that helps us getting more intimate with the business, better understanding their visions and needs; principles helping us designing better and more sustainable solutions that are closely linked with the domain; and pattens for constructing autonomous components in an agile fashion. Fits like a glove! Presentation held at JavaZone 2016.]]> Tue, 03 Apr 2018 16:21:47 GMT /slideshow/microservices-without-ddd-is-risky-business/92789912 trondhr@slideshare.net(trondhr) Microservices without DDD is risky business! trondhr How relevant is domain-driven design (DDD) 13 years after Eric Evans' well-known blue book? The book and the community it grew out of was to a large extent defined by how large enterprises built their IT systems at the start of this century, dominated by the two large and all-encompassing platforms J2EE and .NET, often constructed in a very planned and controlled way. How on earth could this then be relevant in a world dominated by agility, microservices, and a plethora of technologies and platforms? Actually, central DDD concepts like bounded context, core domain, ubiquitous language, distillation, and aggregates fits even better in such a dynamic world than the large monoliths we struggled with back then. This rich toolbox contains techniques that helps us getting more intimate with the business, better understanding their visions and needs; principles helping us designing better and more sustainable solutions that are closely linked with the domain; and pattens for constructing autonomous components in an agile fashion. Fits like a glove! Presentation held at JavaZone 2016. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/microserviceswithoutdddisriskybusiness-180403162147-thumbnail.jpg?width=120&height=120&fit=bounds" /> How relevant is domain-driven design (DDD) 13 years after Eric Evans' well-known blue book? The book and the community it grew out of was to a large extent defined by how large enterprises built their IT systems at the start of this century, dominated by the two large and all-encompassing platforms J2EE and .NET, often constructed in a very planned and controlled way. How on earth could this then be relevant in a world dominated by agility, microservices, and a plethora of technologies and platforms? Actually, central DDD concepts like bounded context, core domain, ubiquitous language, distillation, and aggregates fits even better in such a dynamic world than the large monoliths we struggled with back then. This rich toolbox contains techniques that helps us getting more intimate with the business, better understanding their visions and needs; principles helping us designing better and more sustainable solutions that are closely linked with the domain; and pattens for constructing autonomous components in an agile fashion. Fits like a glove! Presentation held at JavaZone 2016.

Microservices without DDD is risky business! from Trond Hjorteland

]]> 279 1 https://cdn.slidesharecdn.com/ss_thumbnails/microserviceswithoutdddisriskybusiness-180403162147-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-trondhr-48x48.jpg?cb=1684732873 My current focus and main interest are IT/enterprise architecture, especially large distributed systems consisting of loosely coupled autonomous components, each being the technical authority for a specific business capability and single source of truth. In short, TLA galore with service-orientation (SOA), events (EDA) and domain-driven design (DDD) joined together as event-driven SOA. trond.hjorteland.com https://cdn.slidesharecdn.com/ss_thumbnails/thrivingincomplexity-221103174753-189da4eb-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/thriving-in-complexitypdf/253988698 Thriving in Complexity https://cdn.slidesharecdn.com/ss_thumbnails/sociotechnicalsystemsdesignforthedigitalcoalmines-221103174548-b7cedc1e-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/sociotechnical-systems-design-for-the-digital-coal-minespdf/253988666 Sociotechnical Systems... https://cdn.slidesharecdn.com/ss_thumbnails/fromcapabilitiestoservices-modellingforbusiness-italignmentv-190911130804-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/from-capabilities-to-services-modelling-for-businessit-alignment-v2-ext/170868062 From Capabilities to S...