Up next in 10
Socio-Technical Engineering and the Role of Roles in Software Projects
0 views
Aug 6, 2025
In software projects, individuals and technical artifacts mutually influence each other, forming complex socio-technical systems that necessitate a holistic approach. Despite their complexity, we can approach these systems similarly to how we approach technical systems: by eliciting requirements, designing, troubleshooting, and even testing them. The talk will demonstrate how these activities of systems engineering can be reinterpreted in the realm of socio-technical systems. Additionally, the talk will explore a new way of defining roles as bridges between social and technical elements in socio-technical systems. Roles can be likened to services. Just like with the socio-technical system itself, we can articulate requirements for roles, deploy them, and even execute test scenarios for validation. The talk will delve into the concept of 'Role as a Service' in detail. š Conference Website: https://softwarearchitecture.live šŗ CSharp TV - Dev Streaming Destination http://csharp.tv š C# Corner - Community of Software and Data Developers https://www.c-sharpcorner.com #CSharpTV #CSharpCorner #CSharp #SoftwareArchitectureConf
View Video Transcript
0:03
uh I as I said I live in bral you see it
0:06
uh I as I said I live in bral you see it
0:06
uh I as I said I live in bral you see it clearly it is the middle of the Europe
0:08
clearly it is the middle of the Europe
0:08
clearly it is the middle of the Europe I'm a systems architect my customers are
0:11
I'm a systems architect my customers are
0:11
I'm a systems architect my customers are usually from the transportation area
0:14
usually from the transportation area
0:14
usually from the transportation area from um Logistics or from medical
0:18
from um Logistics or from medical
0:18
from um Logistics or from medical devices and as you said I am an
0:20
devices and as you said I am an
0:20
devices and as you said I am an organizer of tebs in my home
0:23
organizer of tebs in my home
0:23
organizer of tebs in my home Village and working as software
0:26
Village and working as software
0:26
Village and working as software architect I did realized a couple of
0:28
architect I did realized a couple of
0:28
architect I did realized a couple of years ago that that software
0:31
years ago that that software
0:31
years ago that that software architecture is is being considered as a
0:33
architecture is is being considered as a
0:33
architecture is is being considered as a technical field
0:35
technical field
0:35
technical field but we operate in a more complex social
0:38
but we operate in a more complex social
0:38
but we operate in a more complex social technical environment where we have to
0:41
technical environment where we have to
0:41
technical environment where we have to deal with social and Technical aspects
0:44
deal with social and Technical aspects
0:44
deal with social and Technical aspects and that made me realize that uh we have
0:47
and that made me realize that uh we have
0:47
and that made me realize that uh we have to reink the role of software
0:49
to reink the role of software
0:49
to reink the role of software architecture at all and I started to
0:51
architecture at all and I started to
0:51
architecture at all and I started to think about the definition of what the
0:53
think about the definition of what the
0:53
think about the definition of what the software architecture or systems
0:55
software architecture or systems
0:55
software architecture or systems architecture could look like and to
0:58
architecture could look like and to
0:58
architecture could look like and to answer this this this growing complexity
1:01
answer this this this growing complexity
1:01
answer this this this growing complexity of social technical work of soci of
1:04
of social technical work of soci of
1:04
of social technical work of soci of systems Architects and after reading a
1:07
systems Architects and after reading a
1:07
systems Architects and after reading a lot of lot of definitions of system
1:09
lot of lot of definitions of system
1:09
lot of lot of definitions of system architecture I found out the one which
1:12
architecture I found out the one which
1:12
architecture I found out the one which was the more appealing to this reality
1:14
was the more appealing to this reality
1:14
was the more appealing to this reality which is systems architecture would be
1:16
which is systems architecture would be
1:16
which is systems architecture would be the navigation of complexity in projects
1:20
the navigation of complexity in projects
1:20
the navigation of complexity in projects and I would visualize the role of a
1:23
and I would visualize the role of a
1:23
and I would visualize the role of a systems architect as someone who writes
1:26
systems architect as someone who writes
1:26
systems architect as someone who writes the corve of the residual uncertainty
1:28
the corve of the residual uncertainty
1:28
the corve of the residual uncertainty because the the complex it comes from
1:30
because the the complex it comes from
1:30
because the the complex it comes from uncertainty and the role of a systems
1:32
uncertainty and the role of a systems
1:33
uncertainty and the role of a systems architect would be to to write this
1:34
architect would be to to write this
1:34
architect would be to to write this curve of residual uncertainty and to
1:37
curve of residual uncertainty and to
1:37
curve of residual uncertainty and to understand this the sources of the
1:39
understand this the sources of the
1:39
understand this the sources of the uncertainty and if an architect faces
1:42
uncertainty and if an architect faces
1:42
uncertainty and if an architect faces some discussions about some technical
1:44
some discussions about some technical
1:44
some discussions about some technical discussions for example about the
1:47
discussions for example about the
1:47
discussions for example about the database technology he or she would say
1:50
database technology he or she would say
1:50
database technology he or she would say okay guys this topic is very
1:52
okay guys this topic is very
1:52
okay guys this topic is very important but it is not on the curve of
1:55
important but it is not on the curve of
1:55
important but it is not on the curve of the residual uncertainty for now and the
1:58
the residual uncertainty for now and the
1:58
the residual uncertainty for now and the the goal or the mission of the architect
2:00
the goal or the mission of the architect
2:00
the goal or the mission of the architect would be to understand what are the
2:02
would be to understand what are the
2:02
would be to understand what are the current topics to be placed on this
2:05
current topics to be placed on this
2:05
current topics to be placed on this curve of
2:06
curve of
2:06
curve of uncertainty and while writing this curve
2:09
uncertainty and while writing this curve
2:09
uncertainty and while writing this curve of the residual uncertainty I was trying
2:12
of the residual uncertainty I was trying
2:12
of the residual uncertainty I was trying to understand what are the sources of of
2:16
to understand what are the sources of of
2:16
to understand what are the sources of of the uncertainty and and
2:18
the uncertainty and and
2:18
the uncertainty and and complexity and after after some thinking
2:21
complexity and after after some thinking
2:21
complexity and after after some thinking I've developed this this quadrant with
2:24
I've developed this this quadrant with
2:24
I've developed this this quadrant with four different sources first of all the
2:27
four different sources first of all the
2:27
four different sources first of all the technical uncertainty so this is a
2:29
technical uncertainty so this is a
2:29
technical uncertainty so this is a classical uncertainty that we as
2:31
classical uncertainty that we as
2:31
classical uncertainty that we as Architects are already familiar about
2:33
Architects are already familiar about
2:33
Architects are already familiar about where we have to to hedge technical
2:36
where we have to to hedge technical
2:36
where we have to to hedge technical options uh under the given risks but
2:39
options uh under the given risks but
2:39
options uh under the given risks but there are also different other sources
2:41
there are also different other sources
2:41
there are also different other sources of uncertainty for example the for
2:43
of uncertainty for example the for
2:43
of uncertainty for example the for example the domain uncertainty where we
2:45
example the domain uncertainty where we
2:45
example the domain uncertainty where we start to develop a project without fully
2:47
start to develop a project without fully
2:47
start to develop a project without fully understanding the domain or operational
2:49
understanding the domain or operational
2:49
understanding the domain or operational uncertainty where we have to plan
2:51
uncertainty where we have to plan
2:51
uncertainty where we have to plan something without knowing how much time
2:53
something without knowing how much time
2:53
something without knowing how much time or cost will it take or even the
2:56
or cost will it take or even the
2:56
or cost will it take or even the political uncertainty where in any
2:57
political uncertainty where in any
2:58
political uncertainty where in any organization political tension
3:00
organization political tension
3:00
organization political tension emerge from the interests conflicts of
3:03
emerge from the interests conflicts of
3:03
emerge from the interests conflicts of different
3:04
different
3:04
different agents and for sure there are already
3:07
agents and for sure there are already
3:07
agents and for sure there are already some some some
3:09
some some some
3:09
some some some proper established methods that try to
3:12
proper established methods that try to
3:12
proper established methods that try to to to bridge different sources of
3:15
to to bridge different sources of
3:15
to to bridge different sources of uncertainty for example domain driven
3:17
uncertainty for example domain driven
3:17
uncertainty for example domain driven design Brides Technical and domain
3:19
design Brides Technical and domain
3:19
design Brides Technical and domain uncertainty or team topologies or orc
3:22
uncertainty or team topologies or orc
3:22
uncertainty or team topologies or orc topologies or unfix try to bring Bridge
3:25
topologies or unfix try to bring Bridge
3:25
topologies or unfix try to bring Bridge technical uncertainty with operational
3:27
technical uncertainty with operational
3:27
technical uncertainty with operational uncertainty but as of today I I don't
3:30
uncertainty but as of today I I don't
3:30
uncertainty but as of today I I don't know any approach which addresses all
3:33
know any approach which addresses all
3:33
know any approach which addresses all these four sources of uncertainty that
3:35
these four sources of uncertainty that
3:35
these four sources of uncertainty that we face in
3:37
we face in
3:37
we face in reality and uh that that makes kind of
3:41
reality and uh that that makes kind of
3:41
reality and uh that that makes kind of the the discrepant between what the
3:44
the the discrepant between what the
3:44
the the discrepant between what the systems architecture can offer today and
3:47
systems architecture can offer today and
3:47
systems architecture can offer today and what is expected from it
3:49
what is expected from it
3:49
what is expected from it today um and based on this discrepant I
3:53
today um and based on this discrepant I
3:53
today um and based on this discrepant I was trying to uh figure out a new
3:56
was trying to uh figure out a new
3:56
was trying to uh figure out a new holistic approach that really addresses
3:58
holistic approach that really addresses
3:58
holistic approach that really addresses these four sources for dimensions of
4:01
these four sources for dimensions of
4:01
these four sources for dimensions of uncertainty to make the navigation of
4:04
uncertainty to make the navigation of
4:04
uncertainty to make the navigation of complexity in software projects um yeah
4:09
complexity in software projects um yeah
4:09
complexity in software projects um yeah easier and the idea that I want to share
4:12
easier and the idea that I want to share
4:12
easier and the idea that I want to share with you today is is very very simple
4:15
with you today is is very very simple
4:15
with you today is is very very simple basically social Technical Systems like
4:17
basically social Technical Systems like
4:17
basically social Technical Systems like software projects where we have social
4:19
software projects where we have social
4:20
software projects where we have social structures like people and teams and
4:22
structures like people and teams and
4:22
structures like people and teams and Technical structures like the software
4:24
Technical structures like the software
4:24
Technical structures like the software we produce they are very complex but at
4:28
we produce they are very complex but at
4:28
we produce they are very complex but at the end they are systems and we can
4:31
the end they are systems and we can
4:31
the end they are systems and we can approach them like any other systems for
4:34
approach them like any other systems for
4:34
approach them like any other systems for example like for any other systems we
4:37
example like for any other systems we
4:37
example like for any other systems we have different phases or different
4:39
have different phases or different
4:39
have different phases or different aspects of systems engineering we have
4:43
aspects of systems engineering we have
4:43
aspects of systems engineering we have requirements engineering you see this
4:46
requirements engineering you see this
4:46
requirements engineering you see this here on the left picture the biblical go
4:48
here on the left picture the biblical go
4:48
here on the left picture the biblical go given Moses the 10 test 10 Testaments
4:51
given Moses the 10 test 10 Testaments
4:51
given Moses the 10 test 10 Testaments Commandments as requirements
4:53
Commandments as requirements
4:53
Commandments as requirements documentation or
4:54
documentation or
4:54
documentation or specification after that we have design
4:56
specification after that we have design
4:56
specification after that we have design phase you here see here the biblical go
4:59
phase you here see here the biblical go
4:59
phase you here see here the biblical go design a human being or you see here on
5:02
design a human being or you see here on
5:02
design a human being or you see here on the right the troubleshooting which we
5:04
the right the troubleshooting which we
5:04
the right the troubleshooting which we do for the normal systems as well but we
5:06
do for the normal systems as well but we
5:06
do for the normal systems as well but we can do it El for so social Technical
5:08
can do it El for so social Technical
5:08
can do it El for so social Technical Systems you see here this great flood
5:12
Systems you see here this great flood
5:12
Systems you see here this great flood where a Biblical go have seen okay I've
5:14
where a Biblical go have seen okay I've
5:14
where a Biblical go have seen okay I've created the humanity but they didn't
5:16
created the humanity but they didn't
5:16
created the humanity but they didn't perform well I have to troubleshoot it
5:19
perform well I have to troubleshoot it
5:19
perform well I have to troubleshoot it so I will reset everything by by sing
5:21
so I will reset everything by by sing
5:21
so I will reset everything by by sing this great
5:23
this great
5:23
this great flood and by this by this um approach or
5:27
flood and by this by this um approach or
5:27
flood and by this by this um approach or this mindset uh would Define social
5:30
this mindset uh would Define social
5:30
this mindset uh would Define social technical engineering basically as
5:32
technical engineering basically as
5:32
technical engineering basically as classical systems engineering um Comm
5:36
classical systems engineering um Comm
5:36
classical systems engineering um Comm which is very common applied to social
5:38
which is very common applied to social
5:38
which is very common applied to social Technical Systems which are basically
5:41
Technical Systems which are basically
5:41
Technical Systems which are basically our software organizations software
5:43
our software organizations software
5:43
our software organizations software projects and so on and in today's to
5:45
projects and so on and in today's to
5:45
projects and so on and in today's to today's talk I will just guide you
5:47
today's talk I will just guide you
5:47
today's talk I will just guide you through these three aspects of systems
5:49
through these three aspects of systems
5:49
through these three aspects of systems engineering but applied to social
5:52
engineering but applied to social
5:52
engineering but applied to social Technical Systems but first of all small
5:56
Technical Systems but first of all small
5:56
Technical Systems but first of all small disclaimer I I don't see social
5:58
disclaimer I I don't see social
5:58
disclaimer I I don't see social technical engineering as a method it is
6:01
technical engineering as a method it is
6:01
technical engineering as a method it is rather an approach to think about social
6:03
rather an approach to think about social
6:03
rather an approach to think about social Technical Systems or mindset and within
6:06
Technical Systems or mindset and within
6:07
Technical Systems or mindset and within this mindset within this approach you
6:09
this mindset within this approach you
6:09
this mindset within this approach you can use multiple methods scrum safe um
6:12
can use multiple methods scrum safe um
6:12
can use multiple methods scrum safe um domain driven design team topologist so
6:14
domain driven design team topologist so
6:14
domain driven design team topologist so whatever you like social technical
6:16
whatever you like social technical
6:17
whatever you like social technical engineering is just a way of thinking of
6:20
engineering is just a way of thinking of
6:20
engineering is just a way of thinking of social Technical Systems as a classical
6:23
social Technical Systems as a classical
6:23
social Technical Systems as a classical systems so let's start with requirements
6:27
systems so let's start with requirements
6:27
systems so let's start with requirements as you know for Technical Systems we
6:28
as you know for Technical Systems we
6:28
as you know for Technical Systems we have functional functional requirements
6:31
have functional functional requirements
6:31
have functional functional requirements and we can also Define functional and
6:33
and we can also Define functional and
6:33
and we can also Define functional and nonfunctional requirements for social
6:36
nonfunctional requirements for social
6:36
nonfunctional requirements for social Technical Systems let's start with
6:38
Technical Systems let's start with
6:38
Technical Systems let's start with functional requirements they're quite
6:40
functional requirements they're quite
6:40
functional requirements they're quite obvious for example the Project X should
6:43
obvious for example the Project X should
6:43
obvious for example the Project X should develop the product y it sounds very
6:47
develop the product y it sounds very
6:47
develop the product y it sounds very straightforward but it also is loaded
6:49
straightforward but it also is loaded
6:49
straightforward but it also is loaded with a lot of information useful
6:51
with a lot of information useful
6:51
with a lot of information useful information for example it means that
6:53
information for example it means that
6:53
information for example it means that the project should just build the
6:55
the project should just build the
6:55
the project should just build the project product y but nothing else or it
6:59
project product y but nothing else or it
6:59
project product y but nothing else or it also means that the Project X have to
7:02
also means that the Project X have to
7:02
also means that the Project X have to build a lot of
7:03
build a lot of
7:03
build a lot of artifacts um with the product why it's
7:06
artifacts um with the product why it's
7:06
artifacts um with the product why it's not only the software it is also some
7:07
not only the software it is also some
7:07
not only the software it is also some requirement documentation it is a test
7:10
requirement documentation it is a test
7:10
requirement documentation it is a test plan it is maybe a project handbook and
7:12
plan it is maybe a project handbook and
7:12
plan it is maybe a project handbook and this list of technical artifacts will
7:14
this list of technical artifacts will
7:14
this list of technical artifacts will help to guide both Technical and
7:17
help to guide both Technical and
7:17
help to guide both Technical and organizational decisions because if we
7:19
organizational decisions because if we
7:19
organizational decisions because if we know the list of these artifacts we know
7:21
know the list of these artifacts we know
7:21
know the list of these artifacts we know which roles do we need and we know which
7:23
which roles do we need and we know which
7:23
which roles do we need and we know which peoples we have to F which people we
7:24
peoples we have to F which people we
7:24
peoples we have to F which people we have to hire to fulfill these roles to
7:27
have to hire to fulfill these roles to
7:27
have to hire to fulfill these roles to deliver these set of artifacts
7:30
deliver these set of artifacts
7:30
deliver these set of artifacts um this this requirement is very simple
7:32
um this this requirement is very simple
7:32
um this this requirement is very simple and obvious but it showcase the role of
7:35
and obvious but it showcase the role of
7:35
and obvious but it showcase the role of requirements because they can help
7:37
requirements because they can help
7:37
requirements because they can help navigating design
7:39
navigating design
7:39
navigating design decisions we have also other examples
7:41
decisions we have also other examples
7:41
decisions we have also other examples for examp like if you want to sync costs
7:45
for examp like if you want to sync costs
7:45
for examp like if you want to sync costs by 40% it is usually positioned as
7:48
by 40% it is usually positioned as
7:48
by 40% it is usually positioned as organizational requirement but it is
7:50
organizational requirement but it is
7:50
organizational requirement but it is actually social technical requirement
7:52
actually social technical requirement
7:52
actually social technical requirement because we have to make some changes in
7:54
because we have to make some changes in
7:54
because we have to make some changes in our social architecture of organization
7:56
our social architecture of organization
7:56
our social architecture of organization and both in technical organization of
7:58
and both in technical organization of
7:58
and both in technical organization of the systems and artifacts create another
8:00
the systems and artifacts create another
8:00
the systems and artifacts create another example we want to be build to build a
8:03
example we want to be build to build a
8:03
example we want to be build to build a platform for other products is also a
8:05
platform for other products is also a
8:05
platform for other products is also a social technical requirement because one
8:07
social technical requirement because one
8:07
social technical requirement because one thing is to build a technical product um
8:11
thing is to build a technical product um
8:11
thing is to build a technical product um the technical prodct platform but other
8:13
the technical prodct platform but other
8:13
the technical prodct platform but other thing is to make changes in the
8:15
thing is to make changes in the
8:15
thing is to make changes in the organization structure so that other
8:17
organization structure so that other
8:17
organization structure so that other teams and departments uh will use this
8:21
teams and departments uh will use this
8:21
teams and departments uh will use this platform so this will functional
8:24
platform so this will functional
8:24
platform so this will functional requirements and as with Technical
8:26
requirements and as with Technical
8:26
requirements and as with Technical Systems there are also nonfunctional one
8:29
Systems there are also nonfunctional one
8:29
Systems there are also nonfunctional one for like availability or development
8:32
for like availability or development
8:32
for like availability or development availability one can one can specify
8:35
availability one can one can specify
8:35
availability one can one can specify requirement like we want to be able to
8:37
requirement like we want to be able to
8:37
requirement like we want to be able to make any technical decision without
8:39
make any technical decision without
8:39
make any technical decision without relying on a single person for approval
8:42
relying on a single person for approval
8:42
relying on a single person for approval maybe you are familiar with a situation
8:43
maybe you are familiar with a situation
8:43
maybe you are familiar with a situation where someone says oh we can't make this
8:46
where someone says oh we can't make this
8:46
where someone says oh we can't make this decision because lead architect or the
8:48
decision because lead architect or the
8:48
decision because lead architect or the Project Lead is on vacation so this is
8:50
Project Lead is on vacation so this is
8:50
Project Lead is on vacation so this is was a case where the development was not
8:55
was a case where the development was not
8:55
was a case where the development was not available because of the vacation of the
8:57
available because of the vacation of the
8:57
available because of the vacation of the single worker that that that is able to
9:00
single worker that that that is able to
9:00
single worker that that that is able to make decisions and it is not bad or good
9:03
make decisions and it is not bad or good
9:03
make decisions and it is not bad or good and absolutely the question is what
9:05
and absolutely the question is what
9:05
and absolutely the question is what requirements you have so this
9:06
requirements you have so this
9:06
requirements you have so this requirement clearly conflicts with
9:08
requirement clearly conflicts with
9:08
requirement clearly conflicts with another requirement making a project for
9:11
another requirement making a project for
9:11
another requirement making a project for example efficient the question is not
9:13
example efficient the question is not
9:13
example efficient the question is not what is bad what is good but which
9:15
what is bad what is good but which
9:15
what is bad what is good but which requirements you have and making these
9:17
requirements you have and making these
9:17
requirements you have and making these requirements transparently we'll have to
9:20
requirements transparently we'll have to
9:20
requirements transparently we'll have to guide the technical and social decisions
9:23
guide the technical and social decisions
9:23
guide the technical and social decisions another example is development
9:25
another example is development
9:26
another example is development scalability where one might say okay we
9:29
scalability where one might say okay we
9:29
scalability where one might say okay we want our organization to be able to
9:31
want our organization to be able to
9:31
want our organization to be able to increase productivity by hiring more
9:33
increase productivity by hiring more
9:33
increase productivity by hiring more people but as the experience shows often
9:37
people but as the experience shows often
9:37
people but as the experience shows often what happens is that more people gets
9:40
what happens is that more people gets
9:40
what happens is that more people gets hired and the organizations become
9:42
hired and the organizations become
9:42
hired and the organizations become becomes even less performant because the
9:44
becomes even less performant because the
9:44
becomes even less performant because the technical architecture is not prepared
9:46
technical architecture is not prepared
9:46
technical architecture is not prepared for it and having requirements like this
9:49
for it and having requirements like this
9:49
for it and having requirements like this will help for sure social and Technical
9:51
will help for sure social and Technical
9:51
will help for sure social and Technical Architects anticipate those changes and
9:54
Architects anticipate those changes and
9:54
Architects anticipate those changes and prepare architecture both social and
9:55
prepare architecture both social and
9:55
prepare architecture both social and Technical one for requirements like this
9:59
Technical one for requirements like this
9:59
Technical one for requirements like this so this this was about requirements so
10:01
so this this was about requirements so
10:02
so this this was about requirements so basically requirements have to navigate
10:04
basically requirements have to navigate
10:04
basically requirements have to navigate both social and Technical decisions they
10:06
both social and Technical decisions they
10:06
both social and Technical decisions they also help to reduce complexity and
10:10
also help to reduce complexity and
10:10
also help to reduce complexity and navigate um social technical discussions
10:13
navigate um social technical discussions
10:14
navigate um social technical discussions they also help to uh verify the system
10:17
they also help to uh verify the system
10:17
they also help to uh verify the system design against the set of requirements
10:19
design against the set of requirements
10:19
design against the set of requirements because if we don't have requirements we
10:20
because if we don't have requirements we
10:21
because if we don't have requirements we don't know how to verify our social
10:22
don't know how to verify our social
10:22
don't know how to verify our social technical
10:23
technical
10:23
technical system now having requirements in place
10:26
system now having requirements in place
10:26
system now having requirements in place we can go to the next chapter which just
10:28
we can go to the next chapter which just
10:28
we can go to the next chapter which just design
10:30
design
10:30
design and the idea here is very simple
10:33
and the idea here is very simple
10:33
and the idea here is very simple basically design of any system is making
10:36
basically design of any system is making
10:36
basically design of any system is making Arrangement decisions about systems
10:38
Arrangement decisions about systems
10:38
Arrangement decisions about systems elements and if you understand what are
10:40
elements and if you understand what are
10:40
elements and if you understand what are the systems element system elements in
10:42
the systems element system elements in
10:42
the systems element system elements in Social Technical Systems and what are
10:45
Social Technical Systems and what are
10:45
Social Technical Systems and what are the arrangement decisions in Social
10:47
the arrangement decisions in Social
10:47
the arrangement decisions in Social Technical Systems then we get a language
10:49
Technical Systems then we get a language
10:49
Technical Systems then we get a language to describe our social technical design
10:52
to describe our social technical design
10:52
to describe our social technical design and with help of this language we can
10:54
and with help of this language we can
10:54
and with help of this language we can express our design we can communicate it
10:57
express our design we can communicate it
10:57
express our design we can communicate it and we we can discuss it and afterwards
11:00
and we we can discuss it and afterwards
11:00
and we we can discuss it and afterwards we can even use tactics and design
11:03
we can even use tactics and design
11:03
we can even use tactics and design patterns for solving structurally
11:05
patterns for solving structurally
11:05
patterns for solving structurally similar requirements in other systems to
11:08
similar requirements in other systems to
11:08
similar requirements in other systems to fulfill also our functional or
11:10
fulfill also our functional or
11:10
fulfill also our functional or nonfunctional requirements so let's go
11:13
nonfunctional requirements so let's go
11:13
nonfunctional requirements so let's go through these three aspects of of system
11:15
through these three aspects of of system
11:15
through these three aspects of of system design first of all system elements so
11:18
design first of all system elements so
11:18
design first of all system elements so what are the system elements in Social
11:20
what are the system elements in Social
11:20
what are the system elements in Social Technical Systems one can answer this
11:23
Technical Systems one can answer this
11:23
Technical Systems one can answer this question by looking on what happens in
11:25
question by looking on what happens in
11:25
question by looking on what happens in software projects in software projects
11:27
software projects in software projects
11:27
software projects in software projects people work on artifacts according to
11:30
people work on artifacts according to
11:30
people work on artifacts according to their roles basically we can visualize
11:33
their roles basically we can visualize
11:33
their roles basically we can visualize this on this uh entity relationships
11:35
this on this uh entity relationships
11:35
this on this uh entity relationships diagram we have persons people we have
11:39
diagram we have persons people we have
11:39
diagram we have persons people we have roles and we have artifacts the roles
11:41
roles and we have artifacts the roles
11:41
roles and we have artifacts the roles are allocated to people people work on
11:44
are allocated to people people work on
11:44
are allocated to people people work on artifacts and other roles could be
11:47
artifacts and other roles could be
11:47
artifacts and other roles could be stakeholders of artifacts for example
11:50
stakeholders of artifacts for example
11:50
stakeholders of artifacts for example Cassandra is a person and the role of
11:53
Cassandra is a person and the role of
11:53
Cassandra is a person and the role of lead architect is allocated to Cassandra
11:57
lead architect is allocated to Cassandra
11:57
lead architect is allocated to Cassandra so it's like allocating some service to
12:00
so it's like allocating some service to
12:00
so it's like allocating some service to a worker
12:02
a worker
12:02
a worker instance and we could define the role of
12:05
instance and we could define the role of
12:05
instance and we could define the role of Le architect as responsibility for
12:07
Le architect as responsibility for
12:07
Le architect as responsibility for software architecture documentation so
12:09
software architecture documentation so
12:09
software architecture documentation so basically in this notation the role is
12:11
basically in this notation the role is
12:11
basically in this notation the role is not defined by what the the person on
12:14
not defined by what the the person on
12:14
not defined by what the the person on who the role is located is expected to
12:17
who the role is located is expected to
12:18
who the role is located is expected to do the role is just defined as a
12:20
do the role is just defined as a
12:20
do the role is just defined as a responsibility for certain technical
12:22
responsibility for certain technical
12:22
responsibility for certain technical artifact and we could also say that
12:24
artifact and we could also say that
12:24
artifact and we could also say that software engineer the role of software
12:26
software engineer the role of software
12:26
software engineer the role of software engineer is a stakeholder of the
12:28
engineer is a stakeholder of the
12:28
engineer is a stakeholder of the artifact software architecture
12:30
artifact software architecture
12:30
artifact software architecture documentation and what one can do in
12:33
documentation and what one can do in
12:33
documentation and what one can do in software projects to to draw the social
12:35
software projects to to draw the social
12:35
software projects to to draw the social technical system design one can play
12:39
technical system design one can play
12:39
technical system design one can play this this role and artifacts
12:42
this this role and artifacts
12:42
this this role and artifacts mapping um by showcasing what artifacts
12:46
mapping um by showcasing what artifacts
12:46
mapping um by showcasing what artifacts does the system have for example in the
12:48
does the system have for example in the
12:48
does the system have for example in the middle you see here artifact software
12:50
middle you see here artifact software
12:50
middle you see here artifact software architecture documentation which role
12:52
architecture documentation which role
12:52
architecture documentation which role you have which role you have in the
12:54
you have which role you have in the
12:54
you have which role you have in the project for example here software
12:56
project for example here software
12:56
project for example here software architect somebody here product owner
12:58
architect somebody here product owner
12:58
architect somebody here product owner and so on and which person people you
13:02
and so on and which person people you
13:02
and so on and which person people you have in the project for example here Eva
13:03
have in the project for example here Eva
13:04
have in the project for example here Eva CH and Kate and then you can look uh
13:08
CH and Kate and then you can look uh
13:08
CH and Kate and then you can look uh whom we allocate the roles like here a
13:10
whom we allocate the roles like here a
13:10
whom we allocate the roles like here a product owner role is allocated to Kate
13:12
product owner role is allocated to Kate
13:12
product owner role is allocated to Kate or which roles are allocated as
13:15
or which roles are allocated as
13:15
or which roles are allocated as responsibilities for artifacts for
13:17
responsibilities for artifacts for
13:17
responsibilities for artifacts for example software architect is
13:19
example software architect is
13:19
example software architect is responsible for software architecture
13:22
responsible for software architecture
13:22
responsible for software architecture documentation and one can draw this uh
13:26
documentation and one can draw this uh
13:26
documentation and one can draw this uh infinitely big large diagrams to to to
13:30
infinitely big large diagrams to to to
13:30
infinitely big large diagrams to to to showcase the dependencies and
13:32
showcase the dependencies and
13:32
showcase the dependencies and relationships in the project in the
13:34
relationships in the project in the
13:34
relationships in the project in the project because following this diagram
13:36
project because following this diagram
13:36
project because following this diagram one can say Okay Kate is a product owner
13:40
one can say Okay Kate is a product owner
13:40
one can say Okay Kate is a product owner we know that product owner is a
13:42
we know that product owner is a
13:42
we know that product owner is a stakeholder of this
13:43
stakeholder of this
13:43
stakeholder of this artifact and this artifact is uh is um
13:48
artifact and this artifact is uh is um
13:48
artifact and this artifact is uh is um held responsible by the role software
13:50
held responsible by the role software
13:50
held responsible by the role software architect and the role is allocated to
13:52
architect and the role is allocated to
13:52
architect and the role is allocated to to Cassandra which basically means that
13:55
to Cassandra which basically means that
13:55
to Cassandra which basically means that Kate can go to Cassandra and express her
13:58
Kate can go to Cassandra and express her
13:58
Kate can go to Cassandra and express her information
13:59
information
13:59
information needs uh so that Cassandra knows what to
14:02
needs uh so that Cassandra knows what to
14:02
needs uh so that Cassandra knows what to put in the software architecture
14:04
put in the software architecture
14:04
put in the software architecture documentation so basically these
14:06
documentation so basically these
14:06
documentation so basically these diagrams can help people to get in touch
14:09
diagrams can help people to get in touch
14:09
diagrams can help people to get in touch and understand what are the information
14:11
and understand what are the information
14:11
and understand what are the information needs of each other so this were
14:14
needs of each other so this were
14:14
needs of each other so this were elements another part of this this
14:16
elements another part of this this
14:16
elements another part of this this design language would be uh design
14:19
design language would be uh design
14:19
design language would be uh design decisions Arrangement decisions so first
14:20
decisions Arrangement decisions so first
14:20
decisions Arrangement decisions so first of all we have the composition decisions
14:23
of all we have the composition decisions
14:23
of all we have the composition decisions for example you want to split U project
14:26
for example you want to split U project
14:26
for example you want to split U project organization into teams or you want to
14:28
organization into teams or you want to
14:28
organization into teams or you want to split the system into sub systems into
14:31
split the system into sub systems into
14:31
split the system into sub systems into sub components this is the first type of
14:34
sub components this is the first type of
14:34
sub components this is the first type of this first kind of arrangement decisions
14:37
this first kind of arrangement decisions
14:37
this first kind of arrangement decisions after you split it split it the question
14:39
after you split it split it the question
14:39
after you split it split it the question is how to integrate it for example how
14:41
is how to integrate it for example how
14:41
is how to integrate it for example how to integrate two teams should they have
14:43
to integrate two teams should they have
14:43
to integrate two teams should they have some scrum of scrums or some vly uh or
14:47
some scrum of scrums or some vly uh or
14:47
some scrum of scrums or some vly uh or just a select channel to integrate their
14:49
just a select channel to integrate their
14:49
just a select channel to integrate their work or should should two components be
14:52
work or should should two components be
14:52
work or should should two components be integrated by by middleware or database
14:55
integrated by by middleware or database
14:55
integrated by by middleware or database or synchronous communication and so on
14:58
or synchronous communication and so on
14:58
or synchronous communication and so on and the third type of Arrangement
14:59
and the third type of Arrangement
14:59
and the third type of Arrangement decisions is allocation as as we saw
15:02
decisions is allocation as as we saw
15:02
decisions is allocation as as we saw previously to whom we allocate the role
15:04
previously to whom we allocate the role
15:04
previously to whom we allocate the role of lead architect or uh where do we want
15:07
of lead architect or uh where do we want
15:07
of lead architect or uh where do we want to allocate the component X should it be
15:09
to allocate the component X should it be
15:09
to allocate the component X should it be allocated on a edge device like like
15:11
allocated on a edge device like like
15:11
allocated on a edge device like like smartphone or should it be allocated in
15:13
smartphone or should it be allocated in
15:13
smartphone or should it be allocated in the cloud so this are the example
15:16
the cloud so this are the example
15:16
the cloud so this are the example examples of allocation decisions and
15:18
examples of allocation decisions and
15:18
examples of allocation decisions and with the help of system elements and
15:22
with the help of system elements and
15:22
with the help of system elements and Arrangement decisions we can now Express
15:26
Arrangement decisions we can now Express
15:26
Arrangement decisions we can now Express the the social technical design of any
15:28
the the social technical design of any
15:28
the the social technical design of any social technical system we can verify it
15:31
social technical system we can verify it
15:31
social technical system we can verify it um comparing it to the set of
15:32
um comparing it to the set of
15:33
um comparing it to the set of requirements we can discuss it with
15:35
requirements we can discuss it with
15:35
requirements we can discuss it with other people we can communicate it and
15:36
other people we can communicate it and
15:36
other people we can communicate it and so on but what we also can do is to use
15:40
so on but what we also can do is to use
15:40
so on but what we also can do is to use patterns and tactics from other systems
15:45
patterns and tactics from other systems
15:45
patterns and tactics from other systems to fulfill similar requirements so it is
15:48
to fulfill similar requirements so it is
15:48
to fulfill similar requirements so it is a basically the classical biomimicry
15:50
a basically the classical biomimicry
15:50
a basically the classical biomimicry where we use in technical design the
15:52
where we use in technical design the
15:52
where we use in technical design the pattern Facey in the nature here's an
15:55
pattern Facey in the nature here's an
15:55
pattern Facey in the nature here's an example how it could work let's let's go
15:57
example how it could work let's let's go
15:57
example how it could work let's let's go back to our availability requirement if
16:00
back to our availability requirement if
16:00
back to our availability requirement if we want to make be able to make any
16:02
we want to make be able to make any
16:02
we want to make be able to make any technical decision without depending on
16:05
technical decision without depending on
16:05
technical decision without depending on anyone if this is our requirement what
16:07
anyone if this is our requirement what
16:07
anyone if this is our requirement what we can do is to look into the catalic of
16:12
we can do is to look into the catalic of
16:12
we can do is to look into the catalic of available patterns and tactics for
16:16
available patterns and tactics for
16:16
available patterns and tactics for availability for example in this book
16:17
availability for example in this book
16:17
availability for example in this book software architecture and practice you
16:19
software architecture and practice you
16:19
software architecture and practice you can find nearly sorted tactics to
16:22
can find nearly sorted tactics to
16:22
can find nearly sorted tactics to address availability requirements for
16:25
address availability requirements for
16:25
address availability requirements for sure not every one of not every tactic
16:28
sure not every one of not every tactic
16:28
sure not every one of not every tactic is applicable for for your use case but
16:30
is applicable for for your use case but
16:30
is applicable for for your use case but you can use these catalogs as checklists
16:32
you can use these catalogs as checklists
16:32
you can use these catalogs as checklists for inspiration I will just pick a
16:35
for inspiration I will just pick a
16:35
for inspiration I will just pick a couple of them to see how we can
16:37
couple of them to see how we can
16:37
couple of them to see how we can approach our availability requirement
16:39
approach our availability requirement
16:39
approach our availability requirement first of all is the redundance pair
16:42
first of all is the redundance pair
16:42
first of all is the redundance pair where we just say okay we have one role
16:44
where we just say okay we have one role
16:44
where we just say okay we have one role and we allocated to two persons which
16:46
and we allocated to two persons which
16:46
and we allocated to two persons which basically means that every one of these
16:49
basically means that every one of these
16:49
basically means that every one of these persons will be not so efficient as it
16:51
persons will be not so efficient as it
16:51
persons will be not so efficient as it would be if it would be their single
16:53
would be if it would be their single
16:53
would be if it would be their single worker instance because two persons have
16:55
worker instance because two persons have
16:56
worker instance because two persons have to Sy with each other um on The Daily
16:59
to Sy with each other um on The Daily
16:59
to Sy with each other um on The Daily architectural stuff but this red
17:02
architectural stuff but this red
17:02
architectural stuff but this red reduction in the performance will
17:04
reduction in the performance will
17:04
reduction in the performance will ultimately lead to the increase of the
17:07
ultimately lead to the increase of the
17:07
ultimately lead to the increase of the social technical availability of the
17:09
social technical availability of the
17:09
social technical availability of the role lead
17:10
role lead
17:10
role lead architect another idea would be to use a
17:13
architect another idea would be to use a
17:14
architect another idea would be to use a combination of two tactics self test and
17:16
combination of two tactics self test and
17:16
combination of two tactics self test and the removal from service where we just
17:18
the removal from service where we just
17:18
the removal from service where we just will REM remove one service component
17:21
will REM remove one service component
17:21
will REM remove one service component from the from service and see what
17:24
from the from service and see what
17:24
from the from service and see what happens what we can even do is to write
17:27
happens what we can even do is to write
17:27
happens what we can even do is to write uh bdd style tests for
17:29
uh bdd style tests for
17:29
uh bdd style tests for like given the located lead software
17:31
like given the located lead software
17:31
like given the located lead software architect is on vacation when an
17:33
architect is on vacation when an
17:33
architect is on vacation when an external software architecture audit for
17:34
external software architecture audit for
17:34
external software architecture audit for the project is requested the audit
17:36
the project is requested the audit
17:37
the project is requested the audit should not result in any major findings
17:39
should not result in any major findings
17:39
should not result in any major findings so what we can do we send Cassandra on
17:41
so what we can do we send Cassandra on
17:41
so what we can do we send Cassandra on vacation or just wait until she goes on
17:43
vacation or just wait until she goes on
17:43
vacation or just wait until she goes on vacation and then request the audit and
17:45
vacation and then request the audit and
17:45
vacation and then request the audit and see how the audit results uh and then we
17:48
see how the audit results uh and then we
17:48
see how the audit results uh and then we have either green or red test case and
17:51
have either green or red test case and
17:51
have either green or red test case and if it's red we can change the system
17:53
if it's red we can change the system
17:53
if it's red we can change the system design to address this
17:55
design to address this
17:55
design to address this issue so this was design basically like
17:59
issue so this was design basically like
17:59
issue so this was design basically like for Technical Systems if you have a
18:02
for Technical Systems if you have a
18:02
for Technical Systems if you have a language of elements and decisions we
18:05
language of elements and decisions we
18:05
language of elements and decisions we can express design we can verify it and
18:07
can express design we can verify it and
18:07
can express design we can verify it and we can reuse other patterns and tactics
18:10
we can reuse other patterns and tactics
18:10
we can reuse other patterns and tactics from other domains to fulfill our own um
18:14
from other domains to fulfill our own um
18:14
from other domains to fulfill our own um requirements and the last part of this
18:16
requirements and the last part of this
18:17
requirements and the last part of this talk is about troubleshooting because
18:19
talk is about troubleshooting because
18:19
talk is about troubleshooting because like any other system um social
18:22
like any other system um social
18:22
like any other system um social Technical Systems might have bugs and we
18:25
Technical Systems might have bugs and we
18:25
Technical Systems might have bugs and we have to fix them for sure there is no no
18:28
have to fix them for sure there is no no
18:28
have to fix them for sure there is no no ival solution to fix all bugs and all
18:30
ival solution to fix all bugs and all
18:31
ival solution to fix all bugs and all systems but what we can do is to follow
18:33
systems but what we can do is to follow
18:33
systems but what we can do is to follow generic principles of troubleshooting
18:35
generic principles of troubleshooting
18:35
generic principles of troubleshooting and the first is that the bugs are
18:37
and the first is that the bugs are
18:37
and the first is that the bugs are relative if we don't have requirements
18:39
relative if we don't have requirements
18:39
relative if we don't have requirements then there are no bugs for example if
18:41
then there are no bugs for example if
18:41
then there are no bugs for example if someone complains we have too many
18:42
someone complains we have too many
18:42
someone complains we have too many technical bugs and if there is no
18:44
technical bugs and if there is no
18:44
technical bugs and if there is no requirement on on quality of the
18:46
requirement on on quality of the
18:46
requirement on on quality of the software and it's work as design works
18:49
software and it's work as design works
18:49
software and it's work as design works as designed maybe the requirement was to
18:51
as designed maybe the requirement was to
18:51
as designed maybe the requirement was to F to deliver something very quickly it's
18:53
F to deliver something very quickly it's
18:53
F to deliver something very quickly it's no no no wonder there are so many bugs
18:57
no no no wonder there are so many bugs
18:57
no no no wonder there are so many bugs the same is if someone place that one
18:59
the same is if someone place that one
18:59
the same is if someone place that one has too many meetings maybe it's works
19:02
has too many meetings maybe it's works
19:02
has too many meetings maybe it's works as designed if there were no if there
19:04
as designed if there were no if there
19:04
as designed if there were no if there requirement to have distributed remote
19:06
requirement to have distributed remote
19:06
requirement to have distributed remote teams then it's clear that they would
19:08
teams then it's clear that they would
19:08
teams then it's clear that they would need to uh meet often and align on their
19:12
need to uh meet often and align on their
19:12
need to uh meet often and align on their work so it might work as designed and
19:16
work so it might work as designed and
19:16
work so it might work as designed and the conclusion here that there is
19:17
the conclusion here that there is
19:17
the conclusion here that there is difference between bugs which relate to
19:19
difference between bugs which relate to
19:19
difference between bugs which relate to requirements and perceived bugs which
19:21
requirements and perceived bugs which
19:21
requirements and perceived bugs which are just something not going as expected
19:24
are just something not going as expected
19:24
are just something not going as expected and in order to make perceived bugs to
19:26
and in order to make perceived bugs to
19:26
and in order to make perceived bugs to real bugs one has to change requirements
19:28
real bugs one has to change requirements
19:28
real bugs one has to change requirements and maybe change design anyway if you
19:31
and maybe change design anyway if you
19:31
and maybe change design anyway if you want to make this box as proper box uh
19:35
want to make this box as proper box uh
19:35
want to make this box as proper box uh we have to create new requirements to
19:37
we have to create new requirements to
19:37
we have to create new requirements to navigate the
19:38
navigate the
19:38
navigate the solution another idea would be that uh
19:42
solution another idea would be that uh
19:42
solution another idea would be that uh in complex systems uh it doesn't make
19:45
in complex systems uh it doesn't make
19:45
in complex systems uh it doesn't make sense to solve problems because as
19:47
sense to solve problems because as
19:47
sense to solve problems because as Russell akait was a complexity a
19:50
Russell akait was a complexity a
19:50
Russell akait was a complexity a scientist said that in complex systems
19:53
scientist said that in complex systems
19:53
scientist said that in complex systems you have masses as as systems of
19:56
you have masses as as systems of
19:56
you have masses as as systems of interconnected problems and this m they
19:59
interconnected problems and this m they
19:59
interconnected problems and this m they basically generate problems and instead
20:01
basically generate problems and instead
20:01
basically generate problems and instead of solving problems because problems are
20:03
of solving problems because problems are
20:03
of solving problems because problems are just symptoms one has to resolve messes
20:06
just symptoms one has to resolve messes
20:06
just symptoms one has to resolve messes that generates those problems and we can
20:10
that generates those problems and we can
20:10
that generates those problems and we can apply this this this mindset also for
20:12
apply this this this mindset also for
20:12
apply this this this mindset also for social Technical Systems for example
20:15
social Technical Systems for example
20:15
social Technical Systems for example let's take the meeting meetings problem
20:18
let's take the meeting meetings problem
20:18
let's take the meeting meetings problem if a project has too many meetings then
20:20
if a project has too many meetings then
20:20
if a project has too many meetings then it doesn't make any sense to make the
20:23
it doesn't make any sense to make the
20:23
it doesn't make any sense to make the meetings more efficient like there are
20:26
meetings more efficient like there are
20:26
meetings more efficient like there are common policies let's allow people
20:29
common policies let's allow people
20:29
common policies let's allow people decline meetings if they have nothing to
20:31
decline meetings if they have nothing to
20:31
decline meetings if they have nothing to contribute or one make one can make
20:34
contribute or one make one can make
20:35
contribute or one make one can make meetings more efficient by appointing a
20:37
meetings more efficient by appointing a
20:37
meetings more efficient by appointing a moderator or one can cluster all
20:40
moderator or one can cluster all
20:40
moderator or one can cluster all meetings in the first part of the day
20:42
meetings in the first part of the day
20:42
meetings in the first part of the day because it makes makes the meetings more
20:45
because it makes makes the meetings more
20:45
because it makes makes the meetings more efficient but it will not solve the mess
20:47
efficient but it will not solve the mess
20:47
efficient but it will not solve the mess which creates the meetings and if you
20:49
which creates the meetings and if you
20:50
which creates the meetings and if you want to understand what is the mess that
20:52
want to understand what is the mess that
20:52
want to understand what is the mess that creates so many meetings they have to
20:54
creates so many meetings they have to
20:54
creates so many meetings they have to look into the social technical
20:56
look into the social technical
20:56
look into the social technical architecture of the system social
20:58
architecture of the system social
20:58
architecture of the system social technical system which could be that
21:01
technical system which could be that
21:01
technical system which could be that there are two teams in the project one
21:03
there are two teams in the project one
21:03
there are two teams in the project one team is responsible for one component
21:05
team is responsible for one component
21:05
team is responsible for one component another one for another one these two
21:07
another one for another one these two
21:07
another one for another one these two components have fetch dependencies which
21:10
components have fetch dependencies which
21:10
components have fetch dependencies which results in in two teams having meetings
21:13
results in in two teams having meetings
21:13
results in in two teams having meetings over those because neither of the teams
21:16
over those because neither of the teams
21:16
over those because neither of the teams can make any decisions on their own and
21:19
can make any decisions on their own and
21:19
can make any decisions on their own and so this is basically the mess that
21:21
so this is basically the mess that
21:21
so this is basically the mess that generates so many meetings and one can
21:24
generates so many meetings and one can
21:24
generates so many meetings and one can solve this dissolve This Mess by
21:26
solve this dissolve This Mess by
21:26
solve this dissolve This Mess by bringing two technical components into
21:28
bringing two technical components into
21:28
bringing two technical components into one and making team a being responsible
21:30
one and making team a being responsible
21:30
one and making team a being responsible for this new big component and the team
21:33
for this new big component and the team
21:33
for this new big component and the team B is now free they can go and eat ice
21:37
B is now free they can go and eat ice
21:37
B is now free they can go and eat ice cream anyway the meetings problem will
21:40
cream anyway the meetings problem will
21:40
cream anyway the meetings problem will be
21:42
be
21:42
be dissolved so basically that's that's it
21:45
dissolved so basically that's that's it
21:45
dissolved so basically that's that's it um as I said the social technical
21:48
um as I said the social technical
21:48
um as I said the social technical engineering is nothing else but systems
21:51
engineering is nothing else but systems
21:51
engineering is nothing else but systems engineering for social Technical Systems
21:54
engineering for social Technical Systems
21:54
engineering for social Technical Systems and with this approach you can write
21:56
and with this approach you can write
21:56
and with this approach you can write requirements for social Technical
21:57
requirements for social Technical
21:57
requirements for social Technical Systems you can design them and you can
22:00
Systems you can design them and you can
22:00
Systems you can design them and you can troubleshoot them like any other systems
22:04
troubleshoot them like any other systems
22:04
troubleshoot them like any other systems you can also apply this approach in
22:07
you can also apply this approach in
22:07
you can also apply this approach in practice for example in your
22:08
practice for example in your
22:08
practice for example in your organization you can run social
22:10
organization you can run social
22:10
organization you can run social technical engineering Workshop where you
22:13
technical engineering Workshop where you
22:13
technical engineering Workshop where you will elaborate the understand the
22:15
will elaborate the understand the
22:15
will elaborate the understand the context of the social technical system
22:17
context of the social technical system
22:17
context of the social technical system so what is within system what is outside
22:19
so what is within system what is outside
22:20
so what is within system what is outside of it which people are inside which are
22:22
of it which people are inside which are
22:22
of it which people are inside which are outside which artifacts are inside which
22:24
outside which artifacts are inside which
22:24
outside which artifacts are inside which are outside then one can GA requirements
22:28
are outside then one can GA requirements
22:28
are outside then one can GA requirements as we've seen functional nonfunctional
22:30
as we've seen functional nonfunctional
22:30
as we've seen functional nonfunctional ones we one can document design social
22:34
ones we one can document design social
22:34
ones we one can document design social technical design by applying for example
22:36
technical design by applying for example
22:36
technical design by applying for example roles and artifacts mapping and if there
22:39
roles and artifacts mapping and if there
22:39
roles and artifacts mapping and if there are already some existing methes in
22:42
are already some existing methes in
22:42
are already some existing methes in Project one can dissolve them by
22:44
Project one can dissolve them by
22:44
Project one can dissolve them by following the the two generic ideas uh
22:48
following the the two generic ideas uh
22:48
following the the two generic ideas uh I've presented
22:49
I've presented
22:49
I've presented today so if you are interested in Social
22:53
today so if you are interested in Social
22:53
today so if you are interested in Social technical engineering I just started to
22:55
technical engineering I just started to
22:55
technical engineering I just started to write a book on it on linp it's um just
22:59
write a book on it on linp it's um just
22:59
write a book on it on linp it's um just the beginning but uh I will publish the
23:02
the beginning but uh I will publish the
23:02
the beginning but uh I will publish the progress on LinkedIn and my website
23:05
progress on LinkedIn and my website
23:05
progress on LinkedIn and my website complexity Navigator TRS if you're
23:08
complexity Navigator TRS if you're
23:08
complexity Navigator TRS if you're interested in the topic I would be very
23:10
interested in the topic I would be very
23:10
interested in the topic I would be very glad to stay in touch and exchange ideas
23:14
glad to stay in touch and exchange ideas
23:14
glad to stay in touch and exchange ideas with you thank you very much and
23:18
with you thank you very much and
23:18
with you thank you very much and [Music]