Folge 12: Gespräch mit Rob England (The IT skeptic)

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Rob England ist als IT Skeptic weltweit bekannt und beschäftigt sich seit Jahren mit ITSM, Agile und DevOps. Wir sprechen über das schlimmste, was der IT passieren konnte: Projekt Management.

In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ sprechen die Gastgeber Alex Lichtenberger und Dirk Söllner mit Rob England, auch bekannt als der IT-Skeptiker, über die Probleme traditionellen Projektmanagements in der IT und die Vorteile des Übergangs zu DevOps und agilen Methoden. England argumentiert, dass traditionelles Projektmanagement oft ineffizient und ungeeignet für die IT ist, da es die Komplexität und Veränderlichkeit von Softwareentwicklungsprojekten nicht berücksichtigt. Er diskutiert, wie DevOps und Agile eine bessere Anpassungsfähigkeit, stärkere Teamdynamiken und kontinuierliche Verbesserung ermöglichen, und betont die Notwendigkeit einer kulturellen Veränderung in Unternehmen, um diese neuen Arbeitsweisen zu unterstützen.

Inhalt

  • Einführung und Vorstellung von Rob England
  • Kritik am traditionellen Projektmanagement in IT-Projekten
  • Vorteile von DevOps und agilen Methoden gegenüber traditionellem Projektmanagement
  • Diskussion über Dysfunktionen im Projektmanagement und ihre Auswirkungen auf IT-Teams
  • Die Rolle von Automatisierung und kontinuierlicher Verbesserung in DevOps
  • Notwendigkeit einer kulturellen Veränderung für erfolgreiche DevOps-Transformation
  • Betrachtung von DevOps als globale Bewegung und ihre unterschiedliche Anwendung weltweit
  • Abschlussdiskussion und Schlussfolgerungen zu DevOps und Projektmanagement

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich begrüße die Zuhörer und Zuhörerinnen auch im Namen von Alex Lichtenberger.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern,
damit unsere Hörer und Hörerinnen inhaltlich, persönlich durchblicken und die Unternehmen erfolgreicher machen können.
Hallo und willkommen zu dem Podcast DevOps – auf die Ohren und ins Hirn.
Das heißt, DevOps durch die Ohren in den Gehirn zu bringen.
Mein Name ist Alex Lichtenberger und zusammen mit Dirk Söllner runne ich diesen Podcast.
Wie Sie hören können, ist das jetzt unser erster Podcast in Englisch.
Der Grund dafür ist, dass wir heute einen besonderen Gast haben, Rob England, auch bekannt als IT-Skeptiker.
Hallo Rob.
Hallo, freut mich, auf der Bühne zu sein.
Ja, danke.
Danke, dass Sie mitgekommen sind.
Es ist nicht nur speziell, dass es in Englisch ist, aber Rob ist auch auf der anderen Seite des Globes, also jetzt aus der europäischen Perspektive, in Neuseeland.
Das bedeutet also auch, dass die Zeit, die wir in dieser Session rekordieren, um 10 Uhr in der Nacht in Deutschland oder in der Schweiz ist.
Und Ihr Zeitpunkt ist jetzt 8 Uhr in Neuseeland.
8 Uhr, ja.
Unglaublich.
8 Uhr morgen, also ich kann Ihnen sagen, dass die Wetter morgen sehr schön ist.
Gut, ja.
Ich hoffe, dass es uns gelingt.
Also, wie es jetzt in Englisch ist, und ich denke, wir werden auch einige neue Redner haben, also ist es auch wert, kurz zu erklären, worum dieser Podcast geht.
Also unser Ziel ist es, interessante Interviews und Experten-Zweige über DevOps zu machen.
Und auch, weil es ein Podcast ist, also glaube ich, dass es auch sehr interessant ist, für Menschen, die eigentlich das Medium eines Podcasts lieben, also sei es im Zug, Bus, Auto oder auf der Fliege.
Heute geht es um das Thema Projektmanagement, das ist das schlimmste, was sich bei IT jemals passiert.
Eine sehr interessante These, denke ich.
Und bevor wir eigentlich in das Projektmanagement hineingehen.
Ein Thema und ein Thema von DevOps.
Vielleicht, Rob, können Sie sich kurz darüber vorstellen, was Sie als Person und was Sie professionell machen.
Ja, Rob.
Okay, also ich habe in Wellington, New Zealand, seit zwölf Jahren konsultiert.
Vor dem, als ich als Pre-Sales-Mann in Vendorland gearbeitet habe, habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Und, äh, also habe ich mich für Lösungen konzentriert.
Ich komme aus einem ITIL und Service-Management und operatio-Besitz-Besitz-Beifragung, obwohl,
wenn Sie, Entschuldigung, wenn Sie sich tief hinschauen, dann war ich früher ein Code-Developer.
Und, äh, in diesem Zeitpunkt habe ich über Service-Management und Regulierung und Strategie
gewechselt.
Und ich habe ebenfalls einen kleinen Blog eingebaut, den ich 12 Jahre zuvor hatte, als das
eine novelte Sache war.
Und es hat ein bisschen eine Nachfolge auf dem ganzen Weltraum gegeben, was Spaß war.
Und es hat ein bisschen eine Nachfolge auf dem ganzen Weltraum gemacht.
me into a bunch of people so that along the road of agile and then later devops the blog was um
taking a very skeptical view of these things and throwing a lot of rocks and some of the leading
thinkers in the devops space worked on me over a period of years and slowly broke down all my
objections and turned me into a bit of a fanboy a bit of an evangelist for devops so
i’ve been trying to talk to people in wellington about devops for quite a long time and in recent
years it has exploded and now i work a hundred percent in devops consulting it’s all i do
and i work now with my partner in life and work dr cherry vu and we call ourselves teal unicorn
which is a a a bit of a trendy
brand but we we like uh riding on the wave of of fed energy so teal unicorn uh actually quite
proud of that one i think it’s quite a good brand for a consulting organization and so that’s what
we do we consult here in wellington we design and build games we deliver games such as the phoenix
project game from gaming works we go to conferences we speak we spoke at the devops enterprise summit
and um just immerse in all things devops it’s wonderful hello rob so thanks and it’s nice to
have you here in our podcast so like we do to all our guests um what would you say how would you
define devops so devops is whatever you say it is man you know it has no formal definition so it’s
wonderful that you asked that question of everybody and uh
i take the big picture definition so you know some people would say it’s somebody in a server
room automating a linux server and some people would say it’s continuous integration and
continuous delivery and continuous testing and the flow from development to deployment
and particularly the automation of that but i take the even bigger view of the alms
service and the sharing and applying those principles to all the value streams in it
not just the require to deploy value stream but anywhere where we can move to new ways of working
which is my preferred phrase for describing it so for someone like me the term devops is actually
more baggage than help these days because it’s very technical and it focuses on dev and ops
and it doesn’t really embrace all the principles of new ways of working which have emerged in this
space yes okay so um like you like alex and like me we all came from it service management so what
do you think what uh what’s the correlation between id service management and devops several decades
ago
but um
uh i think that that itsm is just part of the thinking and um
you know i’m a big fan of gene kim’s approach to that itsm is an integral part of all of this but
itsm needs to move its thinking forward just like every other aspect of it needs to so
that whole crossover and impact on itsm is a particular area of interest and study for me and
that’s what we presented on last week it’s uh we went kind of tribal for a while and the
agile slash devops community in the itsm community kind of got it opposite ends of the paddock and
threw stones at each other and it hasn’t necessarily been a constructive relationship but
um you know we’re seeing lately i think around the world that the two groups are now really
starting to think together and get together and cross over ideas and
devops and agile are bringing bringing new thinking into idle um hence idle practitioner
or as i prefer to call it idol 3.5 and um and hence the work on idol 4 and hence
verism as a framework and hence um uh finally some influence from thinkers like richard cook and
sydney decker and some of the new ways of thinking about error
and resilience and and particularly thinking around complex systems so all these ideas
are spilling into the itsm space at last and uh so i think that’s the relationship is that
we there has been a tribalism but we’re coming together and we should i’ve always advocated that
we just need to bring itsm along on the journey yeah yeah let’s hope i mean that uh future
versions of uh itel and also verizon
will will bring in these ideas and coming back to your definition also of devops uh i actually
as dirk said we ask that question every interview guest and each time it’s a little bit different but
from my point of view i liked uh that you’re actually holistic well holistic whatever but
holistic view so uh looking at the different aspects uh which are needed and especially the
the people aspect so um
as the people aspect um
so now you know sorry in fact now i’m trying to expand
to train myself to say new ways of working and managing
big because one of the strongly emergent themes in recent years has been that for
an organization to change the leaders need to change right and so all the talk around
servant leadership and transformational leader and and realizing that often agile and devops when we say solutions but we’re definitely trying to sell it into the community as well trying to create solutions in terms ofWhat should weglif if there’s a right path how to give to this learning path etc
and transformational leader and and realizing that often
agile and devops
fail, because the management
think it’s something you do
to fix their people, and that they don’t
need to change the way they manage it all.
We really need to break
that. Yeah, which
nicely brings us to the
actual topic. So you
talked about management,
so also
now talking about managing
projects,
and one of your,
I mean, the reason how
we got to that topic is
also, I mean, some of our
listeners maybe know
the blogs of Rob England,
always with very interesting
titles.
I personally like also the one
that was titled, like,
How DevOps Messes With Your Head.
But recently you wrote a couple of
blogs, like,
I have to look that up, but it was
like
10 Agile
Principles That Screw Up
Conventional Project Management,
or the latest
one was the Oxymoron of Agile
Project Management,
or an older one, Project Management
was the worst thing that
ever happened to IT.
So I think they all go into the same
direction. So Rob, maybe you can
just as an intro, you can also
shortly explain. So we did now for
decades, projects,
so now
you say that’s the worst thing ever happened to
IT. Can you please explain?
So
the way I
see it, somewhere back
in the 80s and 90s
as
the cost of IT escalated
in lots of organizations, generally
for very good reasons, because IT was becoming
more and more mission critical and more and more complex
and so the costs were rising.
And organizations
governed IT like a black art.
They really didn’t understand how it works
in the same way that they understand how
finance works or
people management works. So
it was just a black art. They didn’t
understand it. So they went, oh my god, we need
to get some control over this.
Let’s black box it. Let’s
define the inputs and measure
the outputs. And so let’s put
a project and program management framework
over it so that we can see that we’re
getting what we thought we were getting with our money.
And IT
being typical IT,
took an
intensive engineering approach
to project management and adopted
civil
engineering style project management.
And imposed
these strict
waterfall constructs
on us. And
as a result
applied a paradigm
that is completely inappropriate
in a software world.
And the reason I say
it’s inappropriate is
because of our understanding now.
So at the time, you know,
we didn’t know everything that we know now.
But we understand now that
what we build are not simple systems, they’re
complex systems, that
you can define a bridge down to the
last rivet and
girder and then
build the bridge
because it’s near to a
simple system. Whereas
a software system
is nothing of the sort. It’s a complex system.
Which means that we have
no idea when we start the journey
what it is we’re actually going to build.
And yet
project management perpetuates this myth
of
define once, execute perfectly.
Design what you’re going to do
and then do it.
And have
defined inputs and expected
outputs.
Great. So let’s go a little bit more into detail.
And just a few days ago
I read your blog article
about dysfunctions of
project management. And I think it’s
a good point to use it
for a podcast to talk about
some of your mentioned
points over there. So
what do you think, how much
responsibility is within
DevOps?
Yes, I put those 20 dysfunctions
out yesterday and it seems to have stirred up
a bit of a hornet’s nest. So I’ll be looking forward
to putting this podcast link out as a response
to some of that.
There’s some really major
dysfunctions that project
management thinking drives in IT.
I’m a people person
so I’m with you.
Anything that affects people is,
one of my primary concerns.
And so, you know,
the basic model for project management
is we bring the
team to the work.
So we define a piece of work
and then we draw together people to create a team
to execute that piece of work.
And then when the work is completed, we disband the team.
Which is,
flies in the face of everything
we know about human behavior.
That any team has to go through
the old forming, storming, norming,
performing cycle. They need to
take time to coalesce as a group.
And they’re only just getting into the
performance. Once you get into the performing phase,
you can then start optimizing how you work.
So they get into a performing
phase and they start optimizing
how they work. And the next thing you know, the project’s
over and the team’s disbanded.
And they all sent off in different directions.
So it’s a highly
dysfunctional way of managing
people.
Whereas, you know,
product management thinking is that you have
a standing product team.
That is as stable for as long as possible.
And has the time to get into a performing
and then continuously optimizing mode.
And instead of bringing the team to the work,
we bring the work to the team.
Yeah.
Yeah, I fully agree.
And there are like now two aspects you looked at.
One is the problem with the phased approach.
And
I’m also, I’m most of the time working as an agile coach.
And I agree that, you know, in the beginning, if you don’t
know exactly what the requirements are, there’s a complex system.
You have to make the experience first.
And anyway, the team is in a storming phase that you cannot be
sure what your performance is.
So you rather go an agile approach.
And the other thing is also what I really like and what I see
as well is so less now talking about projects, what’s more about
products and what, what I would be interested because how do you see
with you saying, okay, that’s actually the traditional or waterfall project
management doesn’t make sense anymore, but don’t we still have situations
in IT where, where it still would make sense.
So where we, where we actually, when we know where we exactly want to go
and requirements are clear from the beginning, so isn’t it rather
like, let’s say a typical consultant answer, like it depends.
So which approach we choose, you know what I mean?
I, I, I don’t, I don’t feel that way.
I know a lot of people do, um, for two reasons.
One is I challenge the assertion that we know our requirements
in any software situation.
Um, so we are always building a complex system.
If nothing else, every system we build has people in it.
And as soon as you have people in a system, it’s by
definition complex, people are never simple linear and predictable.
So, um, and all our systems have people in them.
We have to stop pretending that we build things that have no people in them.
So, so I challenged the assertion that wherever in a situation where we’re
about to build a simple linear system and, and, and we have a clear understanding
of the requirements for that simple linear system, I just don’t
think we’re in that situation.
So I think that’s one challenge to it.
And then the other challenge is the whole bimodal thing, you know,
even if, even if there was a situation where project management
was a usable approach, um, I see no reason why we should have two
ways of working in an organization.
It’s equally amenable to doing it in an agile way.
So, you know, let, let’s adopt a single way of working for the organization
that works in all situations instead of adopting a new way of working for
the situations where the old way of working doesn’t work and then still
dust off the old way of working and drag it out occasionally when it does fit.
Mm-hmm then as a, as a, as a consequence, this would mean that, uh, so
you, you say bimodal is not really an option.
So what, what would be the consequence for the, for the companies that
there is only one model of working?
The consequence of only one model.
Uh, so to, to flip that, I think, you know, the consequences of bimodal are
toxic mm-hmm and, and it’s,
it’s possibly the worst idea that Gartner have ever had, but there’s a lot
of comp, but there’s a lot of competition for that title from Gartner.
It’s, it’s, I mean, I, I, I also play a little bit the devil’s advocate.
So, and Gartner by was also, they were the ones who came up with, with
the successor of the bimodal, which was the, uh, uh, paste layered
application, uh, or what, how was it called?
You’re right.
Multi, multi-speed IT, isn’t it?
Mm-hmm yeah.
And, and, um.
And I’m an advocate of multi-speed IT mm-hmm only in the sense that whatever
one way of working we come up with, it needs to embrace multiple cadences.
So, you know, the pace layering model and the application of multiple cadences,
I’m fine, I’m down with, but that we can still do all of those different
cadences with the same way of working is the point mm-hmm and, and, you know,
Gartner have softened their bimodal stance a bit by talking about convergence as
well, but, you know,
a, but I think we, we, we should aspire to converge as fast as possible because as long
as you maintain bimodalism, whether it’s product versus project or digital versus industrial,
you know, agile versus waterfall, uh, you, you’re immediately introducing tribalism
into the organization.
You’re immediately driving the idea that we have two teams, we’ve got the cool new funky
kids and we’ve got the boring old farts.
And, and.
Yeah.
und du fährst sofort eine große Schleimhaut in die Mitte deiner Organisation.
Es ist ein wirklich, wirklich toxischer Weg, um zu arbeiten.
Welche Organisation möchtest du gehören?
Also wenn du die Leute fragst, wollen natürlich die Leute Teil der coolen Leute sein.
Also ja, wir fahren auch enttrennte Positionen, sodass andere Leute sagen,
hell nein, ich bin, du weißt, das ist nur verrücktes Cowboy-Stuff.
Ich bleibe hier in der sensiblen, solid,
prüfen Welt von, weißt du, du fährst enttrennte Positionen beide Wege, tatsächlich.
Also ein guter Punkt.
Schau einfach von Neuseeland nach Europa, in die USA und überall in der Welt.
Was denkst du, sind DevOps überall in der Welt gleich?
Wie Idle sollte gleich sein oder Scrum sollte gleich sein,
weil da sind einige Frameworks geschrieben worden.
Also was denkst du, sind DevOps überall in der Welt gleich?
Ich denke,
Well, actually, DevOps is all over the world different.
So that’s a good answer.
So one of the things we need to learn is,
and this comes back to the whole product versus project thing.
We don’t know where it ends.
Anytime we do any work in the real world,
I think outside of really strictly defined technological spaces,
because technology can be really tightly locked down to be near a simple system.
But any other area of the world,
which is why Agile thinking is exploding out into business now.
We don’t know where it ends.
So whether it’s a project or whether it’s introducing DevOps ways of working
or introducing Agile, or any change at all to build something or change the way we work.
We don’t know where it ends.
So that means that DevOps looks different in every single organization around the world.
The only thing that’s common is the fact that DevOps is different, but every single organization around the world.
The only thing that’s common is the fact that DevOps is different in every single organization around the world.
is the principles they applied in order
to move forward on their journey.
But the result of applying
those principles to a complex system is
random. It’ll be different in every single
instance. So you can start
seeing patterns across large amounts of
data to see common patterns that
emerge from organizations
that take these approaches.
But there’s certainly no one pattern that
emerges and there’s no one answer.
Every organization’s
DevOps journey or any journey
is unique.
This is also what, from my
point of view, makes it
very interesting.
Maybe we can also ask the question
a little bit differently.
I think you would agree that
DevOps is also very much
a movement. So as you said
also in the beginning, there is no formal definition.
So it’s a movement. I think
you travel a lot in conferences
and speak. So how do
you see, so which regions
also in the world, so where is
DevOps very much pushed
or influenced? Do you see some
patterns here?
I’m not sure
I have a sufficiently global
view to answer that well.
You’ve got London,
isn’t it?
Yeah, so there’s passionate support
coming in the UK and
Europe and
of course there’s an epicenter
of energy in the US.
In New Zealand, well certainly
Wellington seems to be rocking
even by a global standard.
People are always surprised.
My clients include the New Zealand’s
largest government department
and New Zealand’s tax
collector.
And all the major banks are on
this. The National Airline is on this.
The telcos are on this.
So all the big core
horses in New Zealand are
either way advanced
or at least have one
blue glittery leg on the horse.
They’re all
very
they’re all starting the journey
or well down the journey.
And so
one of the banks has completely
transformed itself. One of the government departments
has completely changed the way it deploys software.
So certainly it’s hot here.
But I don’t
have a good picture around the rest of the world.
I think that’s an interesting question. I’m always
fascinated by China.
So here you have
what is now one of the largest
economies on earth.
And it’s almost completely
opaque to us. We have very little
visibility for what’s actually going on
in China in terms of ways of working.
So I know
some people
go and do training and have exchanges
and work with universities in China
and have a small visibility of this.
And there’s some academic
exchange. But every time I try and
research, I find it
really quite opaque.
And I think that’s a really interesting question
because
you know,
China is on the cusp in the next
couple of years of being one of the
five most powerful
countries on earth.
And
will eventually, of course, be the most powerful
country on earth. And yet we have
very little idea what’s going on there.
Yeah, great.
So have a look on your 20
point list regarding point number
nine. I think it’s a great point.
That leads to the point
do we have product teams
or do we have projects? And I think
it’s a good point
over there. So what’s
the experience with automation
within projects? I would
say so within
a project you are not
forced to
automate the things. And within
product teams who build
it and who run it, they are forced and they
are pushed to automate their
work. Absolutely.
So what happens
is that
my rule of thumb is it costs about
three times as much to automate a test
as it does to execute
that test manually.
So if
you’re a project manager, you’ve got the option
of either doing all the testing
once manually at the end
or investing in
automation and doing it many times throughout
the project. And for
many old school project
managers who don’t get what this is all
about, they go, you can’t be serious. Why
would I triple my testing costs?
So
they have
and in terms of automating
continuous delivery and any
other areas, they’re only going to do it once.
They’re going to build the thing,
they’re going to deploy it, they’re all going to run away.
So, you know, why
would they be interested in automating deployment?
They’re never going to have to do it again.
Yeah.
So all the incentives
are wrong for project managers
and for people on projects. They’re paid,
they’re incented, they’re measured on
how
they’re going to do it.
So, you know, I think that’s a good point.
Quickly and
accurately, they deploy once.
And maybe
one interesting point
would also be so
now, let’s say having also some
insight
and seeing all the problems
with the traditional
phased project management
and the wish
of the companies
also change towards
DevOps, standing teams, doing
agile, you build it, you own
it.
But now, let’s talk about
transformation. So people
which were used
to work
20 or 30 years
the traditional mode and now
you want to move
and you want, I understand that you work
as a consultant, you support
companies in that transformation.
And I think it’s also a
mindset change. So do you have some
tips for us? How can
we, from your experience,
what are the changes?
What are the challenges
and to actually that people
change towards the new way of
working?
Many, many, many
thoughts on this. But
some of the core ones are
I’m highly amused when I see
organizations that announce that they’re
going to move towards agile ways of
working and they’re going to do that in a
big bang project because
apparently they missed
the agile class, you know. So we
have to move towards
new ways of working in an agile way, which means
we should iterate, increment,
experiment, explore, find
our way. Because again, we don’t
know how it lands. And
I get some really interesting
conversations with traditional
organizational change management people
who want to know what the target operating
model is. And
I say, well, I have no idea. And
anybody who tells you
they know what your operating model is going to look like
in two years time, you should show them the door
because they have no idea either. Can I
ask a question between you? So I’m
hearing now that actually also the transformation
itself, you can do it in an agile way,
right? Absolutely.
It’s essential to
move forward
incrementally and experimentally
to find out what works at your organization
right now at this
point in time. And
so another language that I use is
talking about navigational
stars as aspirations
that we sail towards.
In the northern hemisphere, you
talk about the pole star or the north star.
Well, that doesn’t
work, of course, down
here in New Zealand. So I
talk about Matariki, which is a
Maori name for the
Pleiades constellation,
the Subaru constellation,
which is a constellation they navigated
with, which is highly
significant to them. But I use
that language of a navigational star
that
the navigational star is
that we do everything in product teams
and we don’t
have any
project organizational constructs
and da, da, da, da, da.
But that’s a star that we’re sailing towards.
It’s not something we’re going to just
leap to overnight. It’s
the direction we should be going in.
Yeah, consent.
So let’s switch to another point.
I like to talk about the
word or the phrase
bimodal IT.
The IT with two speeds.
Or different speeds. What do you think
about that in the context of
DevOps? I think again,
many, many thoughts, but one of the core ones
again is that we must
create white space.
So
around any attempts to
work in new ways. So even though
I’m really down on the
idea of bimodal,
ironically
bimodal is essential
as a temporary thing
while you’re experimenting
with new ways of working.
In order to experiment with a new way of working
you have to give it
isolation, white space.
You need to decouple it from the rest of your system
so that it can move in new ways.
Otherwise it’ll still be locked into the old
system.
It’s a common joke amongst consultants.
You probably see the same thing yourself
over and over again. You go into organizations
and they say, oh we tried
agile and it doesn’t work.
And the moment you
probe that, you discover that they told a team
to be agile, but left them locked into the rest
of the machine. So it was impossible for them to be agile.
And the other interesting
thing I noticed was
self-fulfilling prophecy.
So if people say,
if they are really skeptical
or no-no’s
and say, oh this will not work,
then it actually will not work.
So coming back to that
I understand, so yeah
it’s the key to success.
It’s a journey to experiments
step by step
and maybe Biomodel is the first step
to actually the next step.
But how do you deal with
because each organization
has such kind of people
so the really no-no’s
or
in a negative sense.
So I think
of this in terms of the normal distribution.
And
there are those early adopters
and pioneers at the other end of the normal
distribution who are on board straight away.
So I like to say
work with the people who want to be changed.
If people are resistant
then I used to bang away
but my strategy now is if people are resistant
I just go find and I go somewhere else.
So find
the people who want to be changed, work with the people
who have the vision, who are the early adopters
are the pioneers
and create some proof points.
Because as soon as you do something
within the organization or very close
to the organization that works
then you start moving down that balcony
you start moving into the early majority
the people who just need to see it.
And as soon as they see it they go
oh it does work and they start getting on board.
And then as soon as the early majority starts
coming on board then the late majority goes
oh look everybody is going over there
and they come along as well.
And the naysayers end up
standing on their own wondering where everybody went.
That sounds pretty
impressive also.
What if people just change by themselves
or they want it by themselves.
Your say actually creates
some early successes
and if people see that
they want to move to that as well.
So another analogy
we’ve used is that
I just kind of run around an organization
with a blowtorch trying to set the grass alight
and
every now and then
we hit somewhere that is nice and dry
and eager to hear new ideas
and a fire takes off.
Other places nothing happens.
Well okay, fine. Just move on.
Concentrate on the areas where you are getting
a reception and get something going.
Get those proof points and then
later on you do have to
start addressing the areas of resistance
but if you’re already getting momentum
and if you’ve already got data and evidence
and proof points from within the organization
then you start going up the pole
to management going look do you want this or don’t you.
We need to work together to address
these other areas.
Yeah true.
Sounds really really good.
Now we’re talking about
I think half an hour about
your blog article
that sounds like a manifesto
against project management
and regarding the
DevOps philosophy.
So I think we should
minimize
projects and should build up
product teams.
The teams who deliver,
who build it, who run it.
What do you think about that?
I think we’re all familiar with the momentum
of projects that
I was just talking to
someone the other day about this
in the context of a very large project
where if you’re within
or even if you’re outside the organization
as a consultant, if there’s a whole lot
of money being sunk on a big project
then if somebody says
if somebody is a naysayer, if they say
oh look this isn’t going to work because
you’re just seen as
somebody who is trying to create a
self-fulfilling prophecy. You’re seen as somebody
who’s not on board, who’s actually working
counter to this important project.
And so you get the whole emperor’s
new clothes thing where everybody’s just
all smiling and nodding and saying how
fantastic this project is because nobody
wants to be seen to be the one
who’s
not supportive.
And so projects
just get this horrendous momentum
of their own.
There’s the sunk cost fallacy.
There’s the way they’re divorced from
customers so often
so the customers don’t even realize how off the
rails it’s going. All these things
are many different
causes but the pattern is that
projects get a life of their own.
I heard a wonderful story recently
about a project that had been
not killed off but just shut down
sort of put on ice and
then the organization discovered months later
that they were still paying a whole bunch of
vendors and consultants in the context of that
project and so while they thought it was
on hold they’d actually burnt the rest of the budget
for the project.
Which I thought was fun.
So, no, exactly.
And whereas the whole
premise of Agile is that you’re constantly
re-evaluating your assumptions, you’re
constantly re-evaluating whether or not you should
even do this thing and one of the
four options every time you evaluate
an iteration is to completely
abandon the
it’s continue,
deploy,
pivot or abandon, right?
Yeah, so now
honestly, because looking
now at Agile, because Agile
Manifesto, it’s 2001
and also I think
Scrum or other frameworks
are even older. If I
talk to developers they also say
yeah, we do that
actually since
a while already. So why is
it that now talking about
horses, why it took so
long until
they start
adopting, so not
only Agile but now also including
operations, so DevOps?
Well, actually
I don’t think it took very long. I think it only
took a decade or two. Okay.
Depends
on what you define longer.
Yeah, yeah.
You know, if we look at the rates of
how fast society can
change and how fast
whole industries can change,
then, you know, a
decade is not a long time.
And even though
technology is changing at a blinding
pace, it drives this fallacy in
thinking that individual
humans and teams and
organizations and industries and
societies can change at
the same pace. And they can’t. Humans change
at a remarkably
slow pace. I make the joke that we
have to wait for some people to die to see
change. Looking
at the watch, right?
Yeah, no, it’s
for me it was
very interesting, but I have no questions.
No more questions so far.
Thanks,
Alex, for that hint.
We should go to
come to an end for this podcast.
So thank you, Rob.
Thank you, IT Skeptic, for
having you here in our podcast.
Really the first one
in English. I hope it’s not
going to be the last one. And I
think thank you for your remarkable
ideas. Thank you for your
blog posting and all the things
you mentioned to
help us to build a better
IT, to make IT faster
and reliable, more reliable.
So thank you to have you here.
Oh, thank you. It’s been fun.
I’m happy to have been part of it.
Thank you for the opportunity. Yeah, thanks
also from my side. It was really a pleasure talking
to you.
Thank you.

Folge 11: Adaption des Spotify Modells bei Objectivity

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Diese Folge berichtet über die Erfahrungen bei der Adaption des Spotify Modells beim englisch-polnischen Softwareunternehmen Objectivity. In dieser Folge von „DevOps – auf die Ohren und ins Hirn“ sprechen Alex Lichtenberger und Dirk Söllner mit Thomas Lechmann von Objectivity über die Adaptation des Spotify-Modells in ihrem Unternehmen. Thomas beschreibt die Herausforderungen und Erfolge dieser Transformation, einschließlich der Reorganisation in Squads, Tribes, Chapters und Gilden. Er betont, wie das Modell Autonomie, Vertrauen und einen Fokus auf persönliche Verantwortung fördert, und diskutiert die Balance zwischen Autonomie und Standardisierung sowie die Bedeutung kontinuierlicher Anpassung und Verbesserung im Rahmen des Modells.

Inhalt

  • Vorstellung von Thomas Lechmann und Objectivity
  • Einführung des Spotify-Modells bei Objectivity
  • Herausforderungen bei der Implementierung des Modells
  • Struktur von Squads, Tribes, Chapters und Gilden
  • Balance zwischen Autonomie und Verantwortlichkeit
  • Entwicklung von Best Practices und deren Anwendung
  • Anpassung und Skalierung des Spotify-Modells
  • Zukunftspläne und kontinuierliche Verbesserung bei Objectivity

Shownotes

Objectivity Unternehmenswebseite: Objectivity

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich begrüße die Zuhörer und Zuhörerinnen auch im Namen von Alex Lichtenberger.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern,
damit unsere Hörer und Hörerinnen inhaltlich, persönlich durchblicken und ihr Unternehmen erfolgreicher machen können.
Willkommen auch von meiner Seite. Mein Name ist Alex Lichtenberger und ich möchte ganz herzlich,
begrüssen heute den Thomas Lechmann von Objectivity.
Das Thema heute ist die Adaption des Spotify-Modells bei Objectivity.
Spotify, das ist ja zurzeit in aller Munde.
Viele Firmen lassen sich durch dieses Organisationsmodell inspirieren und auch Objectivity.
So da denke ich, haben wir heute ganz spannend zu erfahren, wie das bei Objectivity umgesetzt wurde.
Ja, Thomas, dann würde ich sagen, stell dich doch mal ganz kurz vor.
Also kannst du dich auch gerne länger vorstellen und sicherlich ist es auch interessant, von der Firma Objectivity etwas zu hören.
Wir werden es gleich an deiner deutschen Sprache merken.
Du sprichst deutsch, aber du bist kein Deutscher.
Also insofern bin ich gespannt, was du auch über Objectivity zu erzählen hast.
Ja, ich habe schon ein paar Wörter vorbereitet.
Also ich kann lesen.
Aber werde ich etwas.
Was dazu auch sagen, wenn ich es so machen kann.
Also ich heiße Thomas und ich arbeite für Objectivity seit fünf Jahren.
Also es ist mein sechstes Jahr jetzt und ich begann als PMO, so Project Management Office, wo ich habe Project Manager geholfen, das Projekt zu verwalten.
Und weil ich sammelte die nächsten Erfahrungen in Objectivity oder bei Objectivity.
Habe ich entscheidet, dass ich etwas anderes machen wollte und das eigentlich war möglich und ich habe meine Rolle verändern.
Ich ging in die Richtung der Service Management und eigentlich arbeite ich immer noch daran, also bei Service Management und was ich mag am meisten in meiner Arbeit ist die
Unberechenbarkeit.
Und was ich meine, ist, dass eigentlich jeder Tag.
Ist ein großes oder kleines, aber stets und immer Fragezeichen.
Man weiß nicht, was passieren wird.
Und das ist die Sache, die ich am meisten mag an meiner Arbeit.
Objectivity, also Firma Objectivity, die Firma wurde in 1991 in Coventry, das ist Großbritannien, gegründet.
Und seit.
Falls.
27 Jahren unterstützen wir unsere Kunden mit Softwareentwicklung, Support und Software Integration und Project Management nach circa 16, 16 Jahren, also in 2007 Firma hat entscheidet, das Entwicklungszentrum in Breslau gegründet.
Und wo heutzutage der Großteil unserer Mitarbeiter.
Arbeitet ich auch von Zeit zu Zeit gehe ich zu oder nach Großbritannien oder zu nach der Kunde für die, die ich arbeite und speziell in den letzten fünf Jahren hat sich die Firma enorm weiterentwickelt und vergrößert und das hat viele Veränderungen mitgebracht.
Und wir haben in den letzten vier Jahren, vier oder fünf Jahren die Mitarbeiter hier vierfach und jetzt haben wir circa eigentlich über 650 Mitarbeiter und wenn ich startete in 2012, dann wäre ich 140 oder 135.
Also jetzt haben wir viel mehr Leute.
Bei Objektivität.
Das klingt ja schon mal spannend, also Wandel ist die einzige Konstante, bevor wir ins Thema Spotify bei Objektivität gehen, die Frage, die wir allen unseren Gästen stellen, auch dir, Thomas, was, was verstehst du unter DevOps, bitte?
Also, wenn ich an die Antwort gedacht habe, habe ich mich entscheiden, um etwas.
Eigentlich ein paar, ein paar Satzen zu stellen und für mich als meiner Praxis jeder Tag.
DevOps ist am meisten die Fähigkeit, je nach Bedarf unterschiedlich und unterschiedliche Ressourcen einzusetzen.
Also alles hängt von den Umständen und Bedürfnissen ab und das Bedürfnis des Kunden wird vollständig bestimmt und immer.
Und für mich.
Der Schlüssel ist, die Anforderungen gut zu verstehen.
Das ist der Schlüssel, die mein, die die wichtigste und das erwartete Ergebnis zu liefern, also liefern, Ergebnis, das ist die wichtigste, wie ich ja, wie ich gesagt habe, also das ist, was ich verstehe unter DevOps.
Okay.
Jetzt hast du ja eben gesagt, dass ihr bei euch.
Ähm, entschieden habt, auch Dinge zu verändern, ähm, dass ihr auch gewachsen seid in, in Breslau und der Titel ist ja Adaption des Mod, äh, Spotify Modells bei Objectivity, also insofern dann mal die Frage, ähm, warum habt ihr euch denn entschieden, etwas zu verändern, also was waren die Treiber bei euch, ähm, etwas zu verändern?
Also zuerst, was ich, äh, über das, über das Spotify Modell sagen kann, ist, dass das Modell ist skalierbar.
Und wir wollten etwas ändern, weil so große Veränderung, so große, äh, Erwachsung, äh, äh, wir brauchen oder wir brauchten etwas Besonderes, äh, und etwas Neues für uns.
Und das Spotify Modell ist, äh, popular in der Welt eigentlich und, äh, es klappt für beide kleine und, äh, also, äh, große Kunden.
Ähm, und für, für die wir arbeiten und das Spotify Modell auch ermöglicht den horizontalen Austausch von Wissen und Menschen, äh, und das ist, was ich benutze, was wir benutzen, jeder Tag eigentlich.
Und in Spotify, äh, in meiner Meinung das Grundproblem oder die Grundsache ist die Autonomie eines Teams.
Und das ist, was ich sehe in meiner, in meiner Arbeit.
Also wir haben Teamen, die für die verschiedene Kunde arbeiten und die Teamen sind sehr autonomisch und die, äh, eigentlich entscheiden, was zu machen und wenn zu machen, um das, äh, um das, äh, Produkt für eine Kunde zu liefern.
Und, äh, die Kultur auch ist bekannt für ein hohes Maß und an, äh, Ermächtigung und Vertrauen.
Das ist auch wichtig, Vertrauen und ein Fokus auf Persönlichkeit.
Und, äh, ist für ihren Sieg für Zweck bekannt.
Also die Teams, die wir haben, sind voll befugt, befugt, äh, und ihre Mission zu erfüllen und die, äh, Freiheit auch, auch zu haben, äh, unbehängig zu handeln.
Und, äh, was ich meine, ist das das Beste und auch die, äh, schwierigste an der Arbeit für, äh.
Oder wenn wir arbeiten mit Spotify Modell, ist die Autonomie, also etwas, was ich, äh, gesagt, was ich schon gesagt habe, also Teamen, äh, die, die entscheiden, was zu machen und wenn zu machen.
Und es ist auch wichtig, äh, Spotifys Modell, äh, ist nicht, äh, in einer Organisation zu kopieren, also etwas, was wir schon gesagt haben, sondern die entsprechenden, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh, äh.
Anpassung in, äh, Betracht zu ziehen, also vielleicht nicht Spotify bei Objectivity, aber das Modell, also am besten aus Spotify Modell für Objectivity, äh, und das Modell, äh, führt auch, äh, eine Aufleitung in Gruppen ein, äh, abhängig von den Kompetenzen oder der gemeinsamen Arbeit für ein Ziel oder und einen Kunden.
Ja, jetzt bist du ja schon ein bisschen in die Details eingegangen, ähm, wann habt ihr denn begonnen, euch an diesem Spotify Modell auszurichten, denn, ähm, mich würde nochmal ein bisschen interessieren, warum ihr euch verändern musstet, also, äh, sind euch Kunden abgesprungen, waren Kunden unzufrieden, äh, oder habt ihr euer Wachstum nicht mit dem, mit den alten, ähm, Abläufen, mit den alten, ähm, ähm, ja, mit der alten, mit der alten Aufbauorganisation hinbekommen, also warum musstet ihr euch verändern?
Weil das Modell, die wir, äh, früher haben, war nicht, äh, gut, äh, also die, eine Minute, also die Leute, die hier arbeiten, die hatten, äh, eigene Gewohnheiten und weil, äh, wir haben sich entwickelt und vergrößert als Firma, die waren nie, äh,
nie mehr, ähm, aktuell, vielleicht kann ich so sagen, aktuell, also wir, wir haben entscheidet, dass wir etwas anderes, äh, äh, versuchen müssen.
War das dann auch ein Effekt, du hast ganz zu Anfang erwähnt, war ein starkes Wachstum und das ja klassische, oder wenn man ja noch ganz klein ist als Firma, kann auch sehr gut zusammenarbeiten, man kann gemeinsam als, als Team auf den Kunden fokussiert und war es dann, dass ihr auch aufgrund,
äh, des Wachstums dann vielleicht eine gewisse, äh, Siloisierung stattgefunden hat und das, so wie auch jetzt, äh, Dirk gesagt hat, dass da ein bisschen der Kunde aus den Augen gegangen ist, äh, kann man, kann man das so beschreiben?
Und noch besser zu verstehen wirklich die Treiber, äh, das, das Warum, warum musstet ihr was ändern, äh?
Also das, das war, das war auch etwas, äh, was, äh, kommt Interessantes von, mit, mit, mit, äh, Spotify Modell.
Also, äh, was du gesagt hast, also Treiben, Gilden, Squads, äh, das ist, das ist alles, was macht, äh, ein Team und dann das, äh, auch, äh, macht das Team zu, äh, autonomisch zu sein eigentlich.
Okay, okay, gut. Gut, also da, äh, was mir da sehr gut gefällt, du hast das, äh, erwähnt auch, äh, ihr habt, äh, viele Firmen, die sehen, es gibt ja diese berühmten,
äh, Spotify Videos auf YouTube, äh, die heissen, äh, Spotify Engineering Culture und dann kopieren die Firmen das einfach eins zu eins, aber das habt ihr ja nicht gemacht, ihr habt das, äh, adaptiert auf eure Bedürfnisse, auch habe ich verstanden, aus dem Bedürfnis zu, äh, skalieren, oder, dass ihr ein bisschen Manko achtet, wenn das traditionelle, agile Modell, das ihr auf das Team auskriegt, aber was ist, wenn man das, äh, man muss ja auch zwischen Teams abstimmen und dann, du hast erwähnt danach,
äh, auch, äh, die Begriffe Squads und Tribe, glaube ich auch, das ist ja auch etwas, das so ein bisschen von Spotify kommt, was, was habt ihr da genau gemacht, wie habt ihr euch da organisiert oder euch inspirieren lassen von Spotify?
Ja, also Spotify gibt dir ein Framework und das ist, was ich, was wir benutzen haben und wir haben das mit den besten Software-Praktiken kombiniert und, äh, Treiben und Gildien,
äh,
das haben wir auch, äh, gebracht und Squads, also, äh, Treiben, die, die, die, die wir, äh, haben und das, das, das sind die größten Teams auf, äh, Leuten, die verschiedene Kompetitionen haben und dann arbeiten, also, das ist ein großer Team, das, das, das arbeitet für ein, für eine Kunde, das ist, was wir Tribe nennen und dann haben wir auch, äh, Gildien, Gildien, die sind die, äh, Teams, die, äh,
wo Leute mit, äh, selben Kompetitionen sind und dann Squad, das ist eigentlich ein Team, äh, mit verschiedenen Leuten, die, äh, die liefert für einen Kunden, das kannst du, das, das können wir so nennen.
Ja, fangen wir vielleicht dort, oder, weil der Squad, auch wenn man sich das Video anschaut, der Squad ist eigentlich so die, die Grundeinheit, eben das selbstorganisierte Team, you build it, you own it, wie, wie habt ihr da, was ist bei euch?
squad wo hängt ihr das auf was ist die verantwortung wie sind die zusammengesetzt
also was gott macht macht ist die
eigentlich denn den service oder das produkt würde ich jetzt bei der service und produkt
weil wir auch support team haben und das in support kaufst du auch squad haben und dann
squad kein kann ein produkt machen oder auch ein service das ist was das ist wie ich es bei
objektivität aussieht als ihr damals begonnen habt mit spotify also mit dem modell das für
euch zu adaptieren wie viele mitarbeiter warte den zu den damen damaligen zeit es war in 2000
und
14 also es war ca 200 ok 2014 mit 200 mitarbeiter wenn ich das jetzt mal
ich muss ein von antworten ja thomas du hast es gesagt jeden tag neue überraschungen und das
war eben kunden anruft das heißt wir fangen mal wieder an den kunden in den mittelpunkt
zu stellen und müssen und podcast aufnahme dann da fortsetzen wo wir eben aufgehört hatten meine
frage war zu und mitarbeiter habt ihr zu der zeit damals gehabt als euch entschieden habt
für spotify für die adaption des modells habt ihr das ganze dann quasi in einem
großen rundum schlag eingeführt oder oder adaptiert oder habt ihr einzelne teams nach
und nach aufgebaut also wir haben das mit einem big bang gemacht es waren es war ein riesiges
risiko aber stets so haben wir das so haben wir entscheiden und so haben wir das gemacht und es
es war eigentlich gut und von meiner meinung es war auch in sehr interessant in das teil
zu nehmen und das war in 2014 wenn wir das modell adaptieren starten
das insofern spannend auch dass ihr könnt euch vielleicht noch erinnern werden der letzte podcast
war damit martin thalmann von swiss kommt die haben auch sich am spotify modell angelehnt die
haben die ersten evolution
bei euch habe ich verstanden so big bang am schluss muss es natürlich auch passend für
euch hat das offensichtlich so gepasst was waren dann also dann also big bang habt ihr
wirklich im neuen setup wohl gesagt okay das sind die produkte services sind die teams die
squats sie dahinter seht ihr habt die schon die chapters et cetera habt ihr das alles zum
vornherein
das dauert das dauert eigentlich ein paar wochen monaten und man kann man kann man weiß dass die
einführung einer so großen veränderung weil das war eine große veränderung steht vor einem
widerstand aber wie ich gesagt habe das war ein big ein großer challenge aber es war
auch sehr interessant und ich glaube dass wir dass wir das gut gemacht haben und es weil was steht
dafür ist dass immer mehr und mehr leute nach objektivität kommen und auch bei kunden ok also
kunden und mitarbeiter auch oder ja genau
also mitarbeiter das dass ich was was ich leute gesagt habe und kunden auch ja okay aber das ist
glaube ich für mich also wenn ich in den schulungen bin immer auch ein argument den den teilnehmern
klarzumachen es geht nicht nur darum die kunden zufrieden zu stellen mit einer neuen organisation
mit einer neuen art zu arbeiten sondern auch die attraktivität als arbeitgeber zu heben an der
stelle und sofern finde ich es gut wenn ihr da auch die praktischen ergebnisse damit habt also
wirklich wenn ihr sagen könnt für
wir sind als arbeitgeber attraktiver geworden weil wir anders arbeiten als vielleicht vor weiß ich nicht
zehn oder 15 jahren der fall war du hast gesagt ist auch eine große herausforderung ist eine große
veränderung was war denn so aus deiner sicht im rückblick was man die größten hemmnisse also wo
kamen die größten widerstände und wie seid ihr damit umgegangen also von meiner perspektive und
wie ich es
wie ich es
wie ich es
sehe und wo sich also die die größte war also ich habe ein beispiel eigentlich also jetzt arbeiten
wir in tribes und und chapters und das war hier nicht bevor und das war eine größe veränderung
auch und die was fast was der schlüssel hier ist ist dass die die mitarbeiter und die leute dass das
dass wir objektiv arbeiten die werden hier von drei master oder chapter leaders unter unterstützt
und für mich ist es eigentlich sehr interessant weil ich kann weil wenn ich wenn ich wenn ich
brauche ein kompetition die ich nicht habe oder ich brauche jemand das hat das das hat etwas
eigentlich ist etwas neues dann kann ich versuchen mit der gilt oder mit mit anderen treiben zu
solche kompetenzen zu suchen und dann bin ich jemanden gefunden hat dann kann ich versuchen
diese kompetenzen zu versuchen bei bei oder für die kunde die ich arbeite für und als ich
verstehe weil die frage von von dirk war ebenso herausforderungen challenge aber ich verstehe
auch dass eigentlich die ganze organisation war dem ganzen sehr positiv eingestellt ist
es richtig dass damals sagt ja machen wir wir wollen die veränderung richtig von meiner also
ja ich glaube dass das wichtig ist dass ich das ist meine meinung was mich da noch interessieren
würde wird das ja erwähnt da gab es neue rollen die ihre eingeführt hat so squat stripe tief und
ich hatte auch letzten die erfahrung das was im workshop in der abteilung das war mit dem
management haben wir auch solche strukturen definiert neue rollen agile coach und plötzlich
so was passiert jetzt eigentlich mit uns braucht es uns überhaupt noch also das vielleicht auch
weil ihr hattet ja früher auch gab es vielleicht die klassischen chefs was ist damit den passiert
kam da nicht auch widerstand oder habe die das als chance gesehen die sind aber stets mit stets
mit uns aber die rollen nehmen sich anders jetzt ja und die die klassische struktur ist nie hier
es gibt ein struktur weil es wurde nicht klappen ohne ein struktur also es gibt leaders die
mitarbeiter unterstützen man nennt die nicht chefs vielleicht ja aber die sind stets mit uns
und und jeden tag die also es gibt wieder welche die die die mitarbeiter unterstützen und damit
sie ihren tag das beste aus ihren fähigkeiten rausholen sorry dass ich zwischenfrage sind
das weil die leute jetzt bezug zum spotify ist das sind dass die chapters dann chapter
leads oder chapter leads oder guild masters auch weil in in chapter oder in guilds haben
sie haben wir eigentlich leuten die dieselbe kompetition haben also
es ist chapter leaders oder guild masters das ist die rolle für die leute die weit so das spotify
modell nicht so können wir haben die eine grundidee senkt dies quatsch es sind nicht autonome teams
die verantwortliche produkte übernehmen damit in jedem team haben ein ähnlicher rollen habe
jetzt zum beispiel produkt auch
Und ja, die Idee ist ja dann vom Spotify-Modell, okay, jetzt machen wir halt, nehmen wir alle Produkt-Owner zusammen, die können dann gemeinsam ihre Kompetenz weiterentwickeln.
Und das ist dann der Chapter. Und wenn es mehr informal ist, ist es dann die Gilde.
Die Gilde, die haben typischerweise dann so informelle Mailing-Listen an Conferences etc.
Habt ihr das auch so umgesetzt oder wie habt ihr euch das umgesetzt?
Sehr ähnlich eigentlich. Also wir haben auch verschiedene Rollen, die in einem Squad sind.
Wir haben Developers, wir haben Testers, wir haben Business-Analysts, wir haben Scrum-Masters auch.
Und die sind alle verschiedene Rollen, die in einem Squad sind.
Und dann hast du die, oder eigentlich haben wir ein Team, das sich verschiedene Leute vorstellt.
Und dann…
Die alle haben seine Gilden oder seine Chapters, wo sie verschiedene Kompetenzen verwählen, ich meine, Exchange.
Also die können mit den Leuten, die dieselbe Kompetenz haben, in Kontakt gehen.
Ja, das ist ja ganz, ganz wichtig, dass man trotz der Autonomie…
Ja, das ist ja ganz, ganz wichtig, dass man trotz der Autonomie in den Teams den Austausch fördert, sei es informell, sei es auch, wenn auch vielleicht gemeinsam, ja, sagen wir, Dinge beschlossen werden müssen, die dann für alle zugehörigen Squads dann auch gelten.
Ja.
Wir hatten ja beim letzten Mal, Alex hat es schon angesprochen, den Martin Thalmann, und da war auch ein wichtiger Punkt für die Swisscom, wie sie ihr Alignment hinbekommen haben.
Und das ist ja manchmal auch ein Problem, wenn man zu sehr…
Wenn man zu sehr in Richtung Autonomie geht, dass so ein gewisses Alignment fehlt, das heißt die Ausrichtung auf das Unternehmen und so weiter.
Also wie schafft ihr das, dass ihr trotz Autonomie auch schon mit zentralen Vorgaben arbeitet, dass die Teams trotzdem, ich sag mal, ein Alignment hinbekommen?
Ja, also es ist nicht einfach eigentlich, den Spagat zu finden zwischen der Autonomie und der Verantwortlichkeit.
Also wir geben so viel Macht und Verantwortung wie möglich zu unseren Menschen, unseren Mitarbeitern, aber es ist doch auch wichtig, die Verantwortung, wie ich gesagt habe, nicht zu vergessen.
Also du hast etwas zu machen, du hast Tasks und du musst wissen, dass du die…
Liefern musst.
Also es gibt Termine, also es ist Autonomie, aber es gibt auch Termine und die Verantwortlichkeit.
Und das ist hier die Rolle der Gildie, Best Practices zu entwickeln und auch diese Best Practices zu zeigen.
Also wenn jemand Neues ist oder wenn jemand Fragen hat oder wenn jemand Probleme hat, dann…
Kannst du oder können wir mit der Gildie in Kontakt zu gehen und dann die Best Practices zu erwarten.
Und die Gildie hilft in solchen, mit solchen Problemen.
Also der Squad kann quasi dann…
Da gab es ja nochmal ein Telefon, aber ich denke, jetzt können wir weitermachen.
Ich möchte noch kurz nachdenken.
Nachhacken, weil wir haben jetzt darüber gesprochen, so Alignment versus Autonomie.
Und wenn man das Spotify anschaut, wie das Handhaben, die haben dann schon eine sehr, ich würde sagen, nicht einseitige, aber sehr, sehr spezielle Ansicht.
Zum Beispiel, wenn es um Standardisierung geht, sagen sie, es dürfen keine Standards vorgegeben werden, sondern das ist in der Autonomie des Teams.
Und dann ist so der Path of Least Resistance, sagen sie.
Ja, quasi das.
Das, was sich dann durchsetzt, also wenn ein zum Beispiel Tool sehr erfolgreich ist im Team, die anderen Teams sehen das, dann adaptieren das automatisch und das wird dann wie ein de facto Standard.
Also wie geht ihr mit dem um, wenn es jetzt um das Thema Standardisierung Tools, aber auch Prozesse geht?
Habt ihr da auch so diesen Weg eingeschlagen oder wie macht ihr das?
Auf einer Seite muss man sagen, dass die, dass die Standards und Prozesse hier sein müssen.
Weil ich bin der Meinung, dass ohne Prozesse und ohne Standarde kann man eigentlich nichts erreichen oder ist es wirklich schwer.
Und an der anderen Seite haben sie oder haben wir Teams, die Autonomie haben.
Also wie kann man diesen Teams Standards geben?
Dann haben sie doch keine Autonomie, kann man sagen.
Aber die, die, die, die, die größte, die größte Challenge oder die größte.
Schwierigkeit ist die, ist die, den goldenen Mittel zu finden.
Also von meiner Meinung, die Autonomie muss sein, aber es müssen doch auch Sondern Standarde oder Prozesse sein, weil oder die oder oder oder diese Prozesse.
So, da hatten wir schon wieder mal den Kunden am Rohr, am Telefon.
Insofern die nächste Frage schließt sich da vielleicht gerade an.
Thomas, du hast vorhin gesagt, ihr habt euch für Spotify entschieden für das Modell, weil es sich sehr schön skalieren lässt.
Wenn ich mir jetzt vergleichbare Unternehmen von der Größe angucke, so 600 bis 650 Entwickler, hast du ja gesagt, seid ihr.
Da sind häufig Unternehmen dabei, die mit Skalierungs Frameworks arbeiten, Save oder was es da alles noch so gibt.
Meine Frage wäre also, skaliert ihr quasi mit diesen vielen Entwicklern wirklich nur aus Spotify heraus oder nutzt ihr noch andere?
Methoden, andere Frameworks, um so viele Personen wirklich unter einen Hut zu bekommen?
Also wir haben das Spotify Modell adaptiert für uns, aber das bedeutet nicht, dass wir, dass wir vielleicht begrenzt ist.
Das ist nicht das beste Wort, aber das ist, was das ist, was ich meine.
Also wenn wir entscheiden, dass das Modell ändern muss, dann werden wir das noch einmal adaptieren.
Oder wenn wir entscheiden, dass.
Wir etwas Neues, anderes und besser für uns sehen, dann vielleicht können wir auch etwas anderes zu adaptieren, entscheiden zu adaptieren.
Also von meiner Perspektive, von meiner Meinung, es.
Es funktioniert gut, aber was die Zukunft bringt, dann wissen wir jetzt nicht.
Dann werden wir sehen und wir sind.
Flexi, also wenn wir etwas ändern muss, dann werden wir das ändern.
Das, das klingt doch sehr vernünftig, würde ich sagen.
Wenn ich, wenn ich jetzt zurückblicke, wir haben ja am Anfang ein bisschen über die Treiber gesprochen.
Oder warum wolltet ihr eine Veränderung?
Und, und dann habt ihr gesehen, ja, Spotify, das bietet eigentlich eine gute, gute Inspiration.
Und die habt es nicht einfach kopiert.
ihr habt für euch adaptiert ihr habt ihr nach wie du jetzt gesagt der vernünftige ansatz ja
halt regelmäßig schauen passt das noch wenn nicht müssen wir anpassen wir haben noch ein
bisschen darüber gesprochen er hat diese konstrukte wie squat und frei wir hat das
adaptiert ihr habt dann chapter und gilden strukturen drüber gelegt und es funktioniert
grundsätzlich gut meine frage wäre so und ich denke das wird vermutlich jetzt ein bisschen
kürzer podcast ja ausblick was wie geht es dann so so weiter und ein bisschen hast du die frage
auch schon beantwortet also für mich das ist etwas das ich schon erfahren hat also in die
vergangenheit habe ich eine
andere rolle als jetzt also für die zukunft die ausblick für mich das bedeutet dass die
leute die bei objectivity arbeiten die können entscheiden ob sie ob sie etwas anderes machen
wollen oder ob sie für die für die für dieselben kunden arbeiten wollen für mich das ist die
möglichkeit um etwas zu ändern wenn man solche brauche hat
also es für mich das bedeutet dass wenn du etwas ändern wolltest dann kannst du das bei
objectivity machen du musst nicht eine andere firma zu suchen weil objectivity so flexi ist
und es gibt ein chance etwas zu ändern wenn du willst also für die zukunft wir haben das modell
jetzt spotify modell und für mich es funktioniert gut und ich hatte eine option etwas zu ändern wenn
ich wenn ich wollte das machen und das ist für mich das ist der grund das ist der schlüssel dass
wenn man sich entscheidet dass er oder sie etwas machen wollte dann kannst du das entscheiden kannst
du das machen
gut ja ich glaube dann sind wir am ende dieses podcast ich bin gespannt wie der nachher wenn
wir das zusammengeschnitten haben klingt das war sicherlich mal ein sehr interessanter podcast von
der aufnahme her und ich hoffe dass war da auch für die zuhörer genug an informationen
rübergebracht haben also ich sage an dieser stelle mal auf wiederhören und vielen dank thomas dass
du für uns hier ja als als redner zur verfügung gestellt
gestanden hast als gesprächspartner von mir auf wiedersehen
ja sehr gerne euch beide zu zu sprechen danke auch von meiner seite

Folge 10: Digitale Transformation bei der SwissCom

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge des Podcasts „DevOps – auf die Ohren und ins Hirn“ diskutieren die Gastgeber Alex Lichtenberger und Dierk Söllner mit Martin Thalmann, dem Leiter DevOps bei der Swisscom, über die umfassende DevOps-Transformation im Unternehmen. Thalmann gibt Einblicke in die anfänglichen Herausforderungen, die Implementierung agiler Praktiken, die Reorganisation nach dem Spotify-Modell und den Übergang zu einem agilen Mindset im gesamten Unternehmen. Er betont die Bedeutung von Agilität, Stabilität und kontinuierlicher Verbesserung, während er auf die Notwendigkeit hinweist, sowohl technologische als auch kulturelle Veränderungen anzugehen, um eine erfolgreiche Transformation zu gewährleisten.

Inhalt

  • Einleitung und Vorstellung von Martin Thalmann
  • DevOps-Transformation bei der Swisscom: Hintergründe und Ziele
  • Agile Praktiken und die Implementierung im Unternehmen
  • Herausforderungen während der DevOps-Transformation
  • Implementierung des Spotify-Modells in der Organisationsstruktur
  • Wichtigkeit von Stabilität und Qualität in agilen Teams
  • Beziehungen zwischen Entwicklungs- und Betriebsteams („You build it, you run it“)
  • Personal- und kulturelle Veränderungen innerhalb der Swisscom
  • Zukunftsperspektiven und nächste Schritte in der DevOps-Transformation

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zu einer neuen Folge des Podcasts DevOps – auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich begrüße die Zuhörer und Zuhörerinnen auch im Namen von Alex Lichtenberger.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern, damit unsere Hörer und Hörerinnen inhaltlich, persönlich durchblicken und ihr Unternehmen erfolgreicher machen können.
Gut, herzlich willkommen auch von meiner Seite.
Mein Name ist Alex Lichtenberger.
Und ich möchte ganz herzlich begrüssen Martin Thalmann, heute ein ganz spezieller Gast, auch mit einem sehr spannenden Thema.
Martin Thalmann, Leiter DevOps bei der Swisscom und auch Initiator oder Mitinitiator der DevOps Days in der Schweiz und des DevOps Meetups in Zürich.
Also willkommen Martin.
Besten Dank.
Ja, und ich würde sagen, bevor wir da jetzt ins Thema reingehen.
Also Thema DevOps Transformation bei der Swisscom.
Möchtest du dich kurz vorstellen, so als Person, aber vielleicht auch kurz die Swisscom.
Ich denke, die Schweizer Gäste, die kennen ja, kennen alle eigentlich die Swisscom als Telco-Anbieter, aber die Swisscom ist ja noch mehr.
Vielleicht kannst du ja kurz da vorstellen.
Bitte Martin.
Also mein Name ist Martin Thalmann.
Ich arbeite jetzt seit mehr als drei Jahren bei der Swisscom.
An der DevOps Transformation kann das in verschiedenen Rollen, darf ich das begleiten und mitgestalten.
Im Moment ist meine Rolle, dass ich als Product Owner für ein Team arbeite, von dem wir agiles Coaching und Trainings für die ganze Organisation zur Verfügung stellen.
Vom Hintergrund her habe ich eigentlich einen Entwickler-Background, habe also selbst mal programmiert und dann viele Jahre als Projektmanager gearbeitet.
Sowohl im Entwicklungsteil als auch im Betriebsteil.
Also ich denke, ich kenne von dieser Seite her sowohl das klassische Umfeld, den Betrieb, die Entwicklung, konnte ich schon sehr viel Erfahrung sammeln in dem Bereich.
Und im Moment arbeite ich bei der Swisscom.
Die Swisscom ist das führende Telekommunikationsunternehmen und eines der führenden IT-Unternehmen in der Schweiz.
Und was wir machen ist, wir bieten Privatkunden Breitbanddienste an.
Im Digital-TV, Mobilfunk und umfassende Services.
Und im B2B-Segment umfasst das Angebot Netz-, Cloud- und ICT-Dienstleistungen.
Gut, herzlichen Dank Martin.
Dann stellen wir jedem Gast immer die Frage, was verstehst du unter DevOps?
In dem Sinne auch an dich die Frage Martin, was verstehst du unter DevOps?
Kann man das überhaupt definieren?
Und wie?
Ja, das ist eine gute Frage.
Also wenn man es in einem Satz definieren soll, dann würde ich auch sagen,
DevOps ist eigentlich Agilität konsequent zu Ende gedacht.
Und wenn ich etwas mehr Zeit für die Antwort mir nehmen darf,
dann würde ich wahrscheinlich auf die Bezeichnung von John Willis zurückgreifen,
der ja diesen CALMS-Begriff definiert hat.
Wo er sagt, DevOps, da geht es um Culture, es geht um Automation, Lean, Measurement und Sharing.
Und ich habe das Gefühl, das trifft es eigentlich sehr gut,
weil es ist bedeutend mehr als nur eine Technologie,
aber genau gehört auch die Technologie mit dazu.
Also es ist eine ziemlich umfassende Sache,
damit man es schafft, Wert schneller zum Kunden zu bringen.
Ja Martin, vielen Dank.
Das ist ja schon mal interessant.
Interessante Definition, eine interessante Beschreibung.
Mit dem John Willis finde ich auch eine gute Idee.
Ich glaube, das kann man auch immer wieder anbringen.
Und da kann man sehr viel auch in der Erklärung, was ist DevOps,
kann man sehr viel reinpacken an der Stelle.
Jetzt hast du von der Swisscom gesprochen und von Transformation.
Transformation heißt ja auch immer Organisationsveränderung.
Warum habt ihr das denn gemacht?
Also was waren so die Treiber für euch dabei?
Ja, sagen Sie, es gibt.
Es gibt zwei Haupttreiber, die ich identifizieren kann.
Auf der einen Seite sind es klar die Anforderungen vom Markt.
Ich denke gerade die Telekommunikationsbranche ist eine Branche,
die in einem extrem schnellen Wandel ist.
Und vor allem wird auch die Konkurrenz immer globaler.
Also ich denke, die Swisscom sieht die Konkurrenz nicht nur
in den anderen Telekom-Anbietern im Schweizer Markt,
sondern es sind vor allem dann halt auch die globalen,
die mit Diensten wie Netflix, mit WhatsApp, mit Skype
eigentlich unser Kerngeschäft auch anbieten, angreifen.
Und damit wir da wettbewerbsfähig bleiben,
da klappt es eigentlich mit der bestehenden und mit der herkömmlichen Art,
wie wir Projekte machen, geht es eigentlich nicht mehr.
Und das ist wieder der zweite Grund.
Also wir haben, bevor wir Richtung DevOps umgeschwenkt sind,
haben wir auch mit der Klassik,
mit der klassischen Wasserfall-Projektabwicklung Projekte durchgeführt.
Und mit dieser klassischen Abwicklung hatten wir auch die klassischen Probleme.
Das heisst, wir hatten sehr, sehr lange Projektlaufzeiten.
Wir haben Fehler immer erst ganz am Schluss im End-to-End-Test gefunden.
Und das Verrückte ist ja, dass dort die Fehler am teuersten sind.
Also wir haben die meisten Fehler dort gefunden,
wo sie am meisten Kosten verursachen.
Es gab dann häufig die Situation,
dass der Kunde nicht ganz zufrieden war mit dem, was er erhalten hat,
also was von der Software geliefert wurde.
Und wir konnten auch schlichtweg schlecht auf Änderungen reagieren innerhalb des Projektes.
Und das waren eigentlich so die zwei Hauptgründe,
weshalb wir gesehen haben, auf die klassische Art,
da können wir nicht mehr weiter erfolgreich am Markt agieren.
Ja, also ich finde das sehr nachvollziehbar.
Und es ist ja auch wichtig, sich über das Warum im Klaren zu sein.
Man macht ja nicht DevOps wegen DevOps.
Und da gibt es auch einen Grund.
Und bei euch ganz klar auch eine Business-Motivation.
Das eine habe ich herausgehört, so Innovationsfähigkeit,
aber dann auch klar so Dinge wie Time-to-Market.
Und das führt uns eigentlich so zur nächsten Frage,
jetzt vor diesem Hintergrund.
Wie seid ihr dann das angegangen?
Weil ihr seid, ich glaube, auch schon da einige Zeit unterwegs.
Was war so der erste Schritt?
Den ihr dann oder die ersten Schritte, die ihr unternommen habt?
Ja, vielleicht muss man noch vorausschicken,
dass bevor wir überhaupt angefangen haben,
das wirklich als Programm oder als Initiative aufzuziehen,
wir haben ja nicht bei Null begonnen,
sondern wir hatten da bereits verschiedene Teams in der Organisation,
die in einem sehr, sehr lokalen Fokus auch schon mit Scrum oder mit Kanban experimentiert hatten.
Also es ist ja nicht eine,
es ist nicht eine komplett neue Erfindung,
sondern es basiert auf diesen bestehenden agilen Prinzipien.
Die gab es schon, darauf haben wir aufgebaut.
Und wir haben dann im 2014,
haben wir damit wirklich gestartet,
uns mit dem Thema DevOps auseinanderzusetzen.
Und dann haben wir gesagt, okay, das klingt spannend,
das klingt nach einem sehr vielversprechenden Ansatz
und haben dann mit verschiedenen Pilot-Teams,
haben wir versucht, erste Erfahrungen zu sammeln.
Also wir haben quer durch die Organisation
etwa sechs oder sieben Teams gesucht und identifiziert
und haben gesagt, okay, mit denen starten wir mal,
mit denen versuchen wir mal,
diese ersten Prinzipien von DevOps anzuwenden
und zu schauen, was geschieht.
Und das war super spannend.
Und ich würde sagen, von den sieben versuchten Piloten
waren sechs innerhalb von sehr kurzer Zeit erfolgreich,
richtig.
Und wir haben einen positiven Effekt nachweisen konnten,
auch wenn wir so die ganz klassischen Dinge
wie ein Continuous Delivery dort noch nicht eingebaut haben,
sondern vielleicht zuerst nur mal an der Zusammenarbeit gearbeitet haben.
Okay.
Na gut, da kann man ja noch mal ein bisschen drauf eingehen.
Du hast ja erzählt, dass ihr schon ein paar Teams hattet,
dass ihr schon die ersten Erfahrungen auch gesammelt hattet.
Und habt ihr dann irgendein DevOps-Modell genommen?
Also irgendwo out of the box irgendetwas gefunden?
Oder wie seid ihr dann quasi gestartet, um zu entscheiden
oder um zu sagen, jetzt machen wir,
versuchen wir auch nach DevOps-Prinzipien vorzugehen?
Ja, zu der Zeit, zu dem Zeitpunkt,
also es war ja doch schon einige Zeit her,
da gab es eigentlich noch relativ wenig Referenzmaterial.
Ja.
Also das Phoenix-Projekt, das Buch war draussen,
das haben wir natürlich alle gelesen
und uns gut mit der Person auch identifiziert.
Aber so, was DevOps ist,
das so ganz, ganz klar war es zu dem Zeitpunkt noch nicht.
Wir haben dann eigentlich parallel zu diesen Pilot-Teams,
haben wir dann gesehen, dass das funktioniert,
haben das dann auch mit mehr und mehr Teams gestartet.
Also wir haben einen ganzen Teil der Entwicklungsabteilung,
haben wir,
nach diesen Prinzipien aufgesetzt.
Und je mehr Gewicht, dass das bekommen haben,
dann ist so etwas Spannendes geschehen,
dass nämlich auf einmal alle Leute gesagt haben,
ja, wir sind auch agil.
Und die haben dann statt Projekt-Meetings,
haben sie Stand-Ups gemacht
und statt Wasserfallphasen waren das Sprints.
Und wenn man ein bisschen genauer draufgeschaut hat,
hat man dann aber gemerkt, ja, Moment mal,
das ist nicht agil,
sondern da ist einfach ein agiles Label draufgeklebt worden.
Und das war so der Moment,
wo wir gesagt haben, jetzt müssen wir eine für die Swisscom
gültige Definition von DevOps müssen wir finden.
Und was wir gemacht haben,
wir haben uns zu diesem Zeitpunkt,
haben wir uns dann an das Referenzmodell von IBM angelehnt,
haben das angeschaut.
Und die setzen so auf sechs verschiedene Capabilities,
die nötig sind.
Das ist Continuous Integration,
Continuous Testing,
Continuous Release und Deployment,
das Continuous Monitoring,
Continuous Customer Feedback und Optimization
und das Continuous Business Planning.
Und an diesem Modell hat uns eigentlich sehr gut gefallen,
dass es sehr ein umfassendes Modell ist.
Also, sagen wir mal, dass es halt all die verschiedenen Disziplinen,
auch die betrieblichen Disziplinen gut abdeckt,
dass es das Business involviert.
Und es ist nicht nur eine rein technische,
wir machen jetzt eine
Continuous Delivery Pipeline Geschichte war.
Und dieses Referenzmodell hat uns dann auch geholfen,
um gemeinsam uns daran auszurichten und zu sagen,
okay, das ist unser Verständnis.
In die Richtung wollen wir eigentlich gehen.
Ja, du entspannst, Martin.
Also ich höre heraus,
ihr habt ja schon früher,
ihr habt Erfahrung gemacht mit agilen Teams.
Ihr habt auch in der Initial
dann ein paar Piloten daraus gelernt,
euch an die agilen Prinzipien orientieren.
Und dann das Ganze, sagen wir,
bereichert dann auch mit diesem IBM-Kompetenzmodell
wie Continuous Delivery etc.
Und dann aus dem raus eigentlich wie gewachsen.
Und ich habe auch,
ich denke, da hat ja dann auch das,
so wenn man das Team als Basis nimmt,
das selbstorganisierte Team,
das sich dann end-to-end schlussendlich Verantwortung übernimmt.
Ihr habt euch ja dann, glaube ich,
auch stark am Spotify-Modell orientiert.
Ist das richtig?
Das ist richtig.
Wir haben dann gesagt,
wir wollen nach diesen agilen Prinzipien arbeiten
und haben dann überlegt,
und wie können wir das jetzt am besten
auch in der Organisation abbilden?
Und dort waren wir der Überzeugung,
oder sind wir immer noch der Überzeugung,
dass eine klassische Hierarchie sich nicht so gut
mit diesen agilen Ansätzen verträgt.
Und deshalb haben wir gesagt,
wir möchten dort wirklich einen Schritt weitergehen.
Wir möchten das auch in der Aufbauorganisation abbilden
und haben uns für diese Aufbauorganisation,
haben wir uns dann für das Spotify-Modell entschieden.
Das heisst eigentlich,
das agile Team,
das besteht bei uns zwischen sechs und vielleicht neun
hundert Prozent assignten Personen,
die fix in einem Team und genau einem Team arbeiten.
Und dieses Team zusammen, das, das,
das ist eine Squad dann.
Und mehrere Squads,
die thematisch am gleichen Thema arbeiten,
die bilden zusammen eine Tribe.
Und auf Stufe Tribe gibt es einen Tribe-Chief.
Und was von der Seite her noch ganz spannend ist,
ist, dass wir gesagt haben,
im SAP oder in der eigentlichen Hierarchie
rapportieren alle Leute an den Tribe-Chief.
Und das führt dazu,
dass der Tribe-Chief eine Führungsspanne
von 50 bis 125 Personen hat.
Und bei einer solchen Führungsspanne
ist es natürlich klar,
dass dieser klassische Führungsstil
mit regelmässigen Meetings mit den Mitarbeitenden
und Performancegesprächen und dergleichen,
das geht einfach gar nicht mehr,
weil man gar nicht mehr die Kapazität dazu hat.
Und deshalb hat uns eigentlich dieses Modell
auch dazu geholfen,
die Selbstorganisation zu fördern.
Weil wir sagen,
was immer das Team selber organisiert,
was man organisieren kann,
soll das Team auch selber organisieren.
Und nur ganz wenige Punkte,
wo es zum Beispiel auch gesetzliche Anforderungen gibt,
die werden nach wie vor von einem Tribe-Chief
oder von einem Agile-Coach,
der auch auf dieser Stufe agiert,
quasi übernommen.
Und um da einfach noch ein Gefühl zu bekommen,
von was für einem Mengengerüst sprechen wir da?
Also wie viele Squads oder wie viele Leute
sind da zurzeit in so Squads?
In so Squad-Konstrukten unterwegs?
Ja, das hat auch,
das ist auch gewachsen über die Zeit.
Also begonnen haben wir mit vielleicht etwa
100 bis 200 Leuten,
wo wir das so aufgesetzt haben.
Und über die Zeit haben wir das
mehr und mehr ausgeweitet.
Und diesen April,
also jetzt auf den 1. April,
haben wir entschieden,
dass wir die ganze Dev-Organisation,
also die ganze Entwicklung
und das ganze Application-Operation
haben wir jetzt auf diesen Namenssatz umgestellt.
Und das sind rund 1000 Personen,
die davon betroffen sind,
von dieser organisatorischen Veränderung.
Ich glaube, was da aber auch wichtig ist,
ist zu sagen, das ist die reine Aufbauorganisation.
Das ist eigentlich ein rein hierarchisches Konstrukt,
wenn man es so will.
Was ja, wenn wir aber von Agilität sprechen,
und dort ist ja dann auch die Frage,
wie kann man ein einzelnes agiles Team skalieren,
aber eine ganze Unternehmung.
Und für diese Skalierung
richten wir uns dann am Safe-Modell aus.
Und wenn man Safe anschaut,
dann hat ja Safe die Überzeugung,
dass wir immer uns an einem Value-Stream ausrichten sollen.
Also was erzeugt am Schluss Wert für den Kunden?
Und dieser Value-Stream ist aber Organisation,
oder eben dieses Silo übergreifend.
Also es ist dann nicht nur die Entwicklung,
die davon betroffen ist,
sondern es sind auch die Business-Units davon betroffen.
Und das sind auch die reine Infrastruktur,
die davon betroffen sind.
Und das gibt dann eigentlich mehr die Ablauforganisation,
die eigentlich viel stärker und wichtiger ist,
als die eigentliche Aufbauorganisation.
Ja, und so auch die,
am Schluss geht es ja um die Zusammenarbeit.
Genau.
Entlang des Value-Streams hat er dann am Schluss,
mit dem er den Wert dem Kunden liefert dann.
Genau, genau so.
Ja Martin, das klingt ja ganz interessant.
Ich wollte nochmal einhaken nach dem Thema,
oder bei dem Thema Agile Coach und Tribe Lead.
Wenn ich das richtig verstanden habe,
ist der Tribe Lead oder der Tribe Chief
wirklich mit einer enormen Verantwortung ausgestattet.
Hohe Führungsspanne, hohe Verantwortung.
Der Agile Coach ist ihm im Prinzip gleichgestellt.
Also hat er eine gleiche Verantwortung,
hat er ein gleiches Ansehen bei euch?
Ja genau, das ist genau so, wie du es sagst.
Wir haben den Tribe Chief,
der eigentlich mehr für die inhaltliche Verantwortung
der Tribe ist.
Der schaut, dass alles gut funktioniert,
dass der Fluss da ist,
dass sie die Software liefern,
schaut vielleicht auch für,
dass die Betriebstickets gelöst werden und so weiter.
Also er hat einen sehr starken inhaltlichen Fokus.
Und dann haben wir gesagt,
wenn man eine Agilitätsreise angeht
oder eine DevOps-Transformation angeht,
so eine Transformation braucht Zeit
und da braucht es auch Unterstützung dazu,
dass man das vorwärts bringen kann.
Und das ist dann die Rolle des Agile Coaches.
Wir haben uns sehr bewusst dafür entschieden,
dass der Tribe Chief und der Agile Coach
auf Augenhöhe zusammen das machen.
Das heisst, der Agile Coach ist für die Transformation
der ganzen Tribe zuständig
und bildet zusammen mit dem Tribe Chief ein Führungsduo.
Und die sind auch hierarchisch so,
ist das abgebildet,
weil beide rapportieren an den gleichen Vorgesetzten.
Also es ist wirklich ein Führungsduo auf Augenhöhe.
Und das heisst auch eben so,
die klassischen Management-Rollen,
die es dann immer weniger braucht,
und dafür dann die neuen Rollen,
Agile Coach, Tribe Chief.
Wenn ich mir das jetzt so klassisch vorstelle,
das hat ja sicher auch bedeutet,
dass es dann weniger,
also vor allem Mittelmanagement gebraucht hat.
Was waren da so die Herausforderungen?
Oder stimmt da meine Annahme,
die ich geäussert habe?
Ja, die Annahme ist absolut richtig.
Also diese agile Transformation
hat insbesondere auf das Mittelmanagement,
hatte das eine grosse Auswirkung.
Vor der Transformation hatten wir ungefähr 10%,
ich sage das mal in Anführungszeichen,
Management overhead.
Das heisst, von diesen 1000 Leuten,
die in dem Bereich arbeiten,
hatten wir 100 Leute,
die in irgendeiner Führungstätigkeit unterwegs waren.
Und das Ziel der Transformation war auch,
dass wir gesagt haben,
das reduzieren wir auf 5%.
Das heisst, jede zweite klassische Führungsrolle,
die wir bisher hatten,
die gibt es heute nicht mehr.
Das heisst, und wir haben uns bewusst dagegen entschieden,
dass wir gesagt haben,
wir machen so ein 1 zu 1 Mapping,
dass wir gesagt haben,
ein Team Leader wird nachher,
ich sage mal Scrum Master oder so,
sondern wir haben gesagt,
okay, wir setzen das neue Setup auf
und schauen dann,
dass wir die richtigen Leute dafür finden.
Und da gab es natürlich auch viele Leute,
die sich dann umorientieren mussten
oder ich sage im Sinne von,
dass sie jetzt eine komplett andere Aufgabe wahrnehmen.
Sei es als Agile Coach,
sei es als Tribe Chief
oder vielleicht auch eine viel technischere Rolle
wieder als DevOps-Ingenieur
oder als Scrum Master oder Product Owner.
Ja, also die einzige Konstante ist die Veränderung.
Und das ist halt für,
das Individuum oder man kann das als Chance anschauen
oder einige sehen das vielleicht dann als Gefahr.
Und ja.
Genau.
Also das ist so.
Und ich glaube,
das haben wir auch gesehen,
für die einen ist das eine extrem spannende Reise
und für die anderen war es wahrscheinlich nicht nur angenehm.
Das ist definitiv so.
Habt ihr noch ein paar andere Herausforderungen meistern müssen?
Also du hast vorhin davon gesprochen,
klassische Projekte, klassische Probleme.
Jetzt ist ja im agilen Umfeld auch nicht alles toll.
Also welche Probleme siehst du denn für euch,
für dich aus eurer Erfahrung aus den agilen Vorgehensweisen?
Also ich würde sagen,
das Schöne an dieser Vorgehensweise ist ja,
dass man eigentlich permanent wieder drauf schaut
und ein Learn und Adapt macht.
Und so sind wir auch in der Transformation vorgegangen.
Also wir haben viele Dinge,
haben wir einfach mal ausprobiert in einem kleinen Team,
haben geschaut, ob es funktioniert
und wenn es nicht funktioniert hat,
haben wir es angepasst.
Und so haben wir zum Beispiel auch dann irgendwann gesehen,
also die Frage ist ja immer,
wenn man autonome Teams hat.
Autonome Teams sind gut
und die sind auch extrem wichtig,
aber es geht nicht nur mit der Autonomie,
sondern es kommt,
irgendwann kommt dann die Frage auch nach dem Alignment auf.
Und das haben wir so ein bisschen gelernt.
Zuerst waren wir wahrscheinlich zu fest nur auf Autonomie
und haben dann gesagt,
okay, jetzt müssen wir etwas Alignment reinbringen
und haben dann Save als dieses Konstrukt mit reingebracht.
Und so denke ich schon,
das ist das Schöne,
dass man eigentlich permanent wieder sieht,
was hat funktioniert,
was müssen wir anpassen
und dass man dann diese Dinge auch anpassen kann.
Wenn ich jetzt die jetzige Situation anschaue,
dann sind wahrscheinlich
die grössten Herausforderungen,
sind so die Themen,
dass man,
diese Veränderung braucht Zeit.
Man hat so ein bisschen die Tendenz,
nach einer gewissen Zeit wieder in alte Muster zurückzufallen
und da braucht es sehr viel Ausdauer
und eine konstante und gleichbleibende Kommunikation
und eben auch Coaches,
die einen da unterstützen,
dass man in die Richtung geht.
Aber auch das Thema mit
dem Involvement von den Business-Abteilungen,
sind so,
da kommen ganz viele Themen hoch.
Wie stellen wir sicher,
dass Business sich auch auf diese Arbeitsweise anpassen kann
oder davon profitieren kann?
Das geht dann hin bis zu Shop-Mitarbeitenden
oder Leuten,
die im Call-Center arbeiten,
die davon betroffen sind,
wenn wir auf einmal,
zweimal pro Monat neue Releases
in die Produktion bringen,
statt wie bis anhin
nur dreimal im Jahr.
Also die Herausforderung gibt es immer,
aber was mir gefällt,
die Idee vom agilen Team,
dazu gehört dann auch Learn and Adapt,
das heisst dann eben auch
aus diesen Herausforderungen
denen begegnen
und dann daraus lernen.
Und dann, was ich herausgehört habe,
was ich spannend finde,
eben dann agil wirklich im doppelten Sinn,
also einerseits schon das agile Team,
aber die Transformation selber,
wie sie gesteuert wird danach
auf eine agile Art und Weise.
Das finde ich ganz, ganz wichtig,
weil gerade weil es ja eine Kulturänderung ist,
da ist der Vorbildcharakter immens wichtig.
Und wenn man jetzt eine agile Transformation
als ein klassisches Projekt aufsetzt,
dann bin ich der Überzeugung,
dass das nicht funktionieren kann,
sondern diese agilen Prinzipien,
die müssen auch in die Transformation mit einfließen.
Ja, in dem Kontext würde mich,
und ich denke auch die Zuhörer,
noch die Frage interessieren,
auch zur bimodalen IT, oder?
Weil es ist ja,
ich denke jede Enterprise IT
oder jede Firma macht jetzt Erfahrung mit,
oder hat schon seit längerer Zeit Erfahrung
mit agilen Teams,
vielleicht sogar Richtung DevOps,
aber viele machen ja dann den bimodalen Ansatz
und sagen ja,
in gewissen Bereichen,
da macht Agile Sinn,
vor allem dort,
wo halt viel Veränderungsdruck, Risiken
und da gibt es auch einen Bereich,
der wird einfach klassisch weitergefahren.
Wie steht da die Swisscom dazu?
Wir haben den Weg auch gemacht
und ich würde mal sagen im 2016
oder Mitte 2016 haben wir auch gesagt,
wir wollen den Weg gehen,
wir wollen Richtung bimodale IT gehen
und zu dem Zeitpunkt,
hatten wir noch den Eindruck,
dass wir mit dem agilen Teil relativ klein beginnen
und das über die Zeit aber immer stärker wächst
und am Schluss vielleicht so eine 70-30 Verteilung von Agile
und zu den Systems of Record sind.
In der Zwischenzeit sind wir aber der Überzeugung,
dass die bimodale IT eigentlich keinen Sinn macht,
wir diese Trennung zwischen Focus on Stability
und Focus on Agility,
der macht für uns eigentlich nicht so viel Sinn,
weil auch agile Systeme müssen stabil sein,
die müssen robust sein,
die müssen 100% Qualität liefern
und auf der anderen Seite
gibt es immer weniger Systeme,
wo man sagen kann,
die sind jetzt einfach da
und da muss man nichts mehr machen
und wir haben auch ein bisschen gemerkt,
dass es eine Zweiklassengesellschaft gibt
und dass es auch für die Kultur gar nicht gut ist,
dass man dann so sagt,
ja, ich bin im neuen und im agilen Teil
und alle anderen sind auf dem Abstellgleis
und diese Notation,
die haben wir irgendwie nicht rausgebracht
und deshalb haben wir auch gesagt,
nein, es gibt eigentlich nur einen Weg
und das ist der Weg der Agilität.
Wasser auf meine Mühlen,
ich bin ja auch ein Gegner sozusagen von bimodaler IT,
also insofern freut es mich,
dass ihr eure Erfahrungen auch gemacht habt
und nachdem ihr die Erfahrungen gemacht habt,
zu der Entscheidung gekommen seid,
zu der Einschätzung gekommen seid,
bimodaler IT macht keinen Sinn,
wenn man es wirklich richtig macht
und was ich auch interessant finde,
ist die Aussage,
dass natürlich auch agile Teams
auch Stabilität liefern müssen
und das auch können,
also das ist jetzt ja nichts Besonderes,
zumindestens aus meiner Sicht,
wenn ich agil entwickle und Betrieb mit dazu nehme,
also DevOps,
dass ich dann eben auch wirklich
schnell liefern kann,
schnelle Zyklen habe
und trotzdem Stabilität,
ich sage mal, ins Team natürlich reinbringen
und auch in die Applikation,
die ich bereitstelle, den Service.
Absolut, absolut, ja genau
und da hilft ja auch die ganze Automation,
also wenn ich die Tests automatisiert habe,
wenn ich die Deployments automatisiert habe,
wir haben es auch so aufgesetzt,
dass wir immer die Teams,
wir glauben dort an den Satz,
you build it, you run it,
also das heisst,
bei uns ist das Entwicklungsteam
immer auch für den Betrieb
ihrer Applikationen verantwortlich
und mit dieser Aufteilung
braucht man keinen Handover in dem Betrieb mehr
und mit dieser Aufteilung bedeutet das aber auch,
wenn ich etwas falsch
oder wenn ich einen Fehler in der Entwicklung mache,
dann sehe ich direkt die Auswirkungen im Betrieb
und kann daraus lernen
und kann es dann das nächste Mal wieder besser machen.
Ja, ich meine, es ist ja auch ein bisschen,
also einfache Psychologie,
oder wenn ich natürlich jetzt,
wenn ich, klar, ich kann agil arbeiten,
ich bin im Dev-Team,
aber wenn ich sage,
ja gut, betreiben muss es ja dann ein anderer
und das ist mir ja egal,
wenn es dann nicht so stabil ist,
aber wenn man,
wie du sagst,
you build it, you run it,
dass man dann wirklich als Team Verantwortung übernimmt,
dann überlegt man sich eben zweimal,
ob das, was man baut,
das auch bezüglich Stabilität
und man übernimmt dann wirklich die End-to-End-Verantwortung.
Das, ja.
Da geschehen dann auch ganz spannende Sachen,
wo man, wenn man die Teams dann,
oder als wir die Teams neu aufgebaut haben
und die Leute zusammengesetzt haben,
wo zum Teil Leute aus dem Betrieb
eigentlich vorher gar nicht mit den Leuten
aus der Entwicklung gesprochen haben
und wenn die dann zusammen angeschaut haben,
wie die die Deployments machen,
dann sehr schnell Optimierungspotenzial aufgekommen ist,
dass man gesagt hat,
hey, das kann ich doch schon im Code einbauen,
dann musst du es nicht mehr manuell machen,
dass man so eigentlich noch schon
durch das gemeinsame Verständnis
zu besseren Lösungen gekommen ist.
Ja.
Und hat da dann auch so ein T- oder P-Shaping,
hat das auch stark,
dass dann plötzlich Leute,
die sagen wir aus dem klassischen,
früher einfach nur klassische Betriebsaufgaben,
wie du sagst,
die haben fast selten mit wirklich Entwicklung gesprochen,
dass sie dann sich Richtung Entwicklung bewegt haben,
plötzlich solche Tase und umgekehrt auch Entwickler,
die dann zum Beispiel innerhalb des Sprints
dann gewisse Aufgaben übernommen,
die sonst der Betrieb gemacht hätte?
Das ist ganz klar das Ziel,
dass wir das erreichen müssen.
Genau in die Richtung möchten wir gehen.
Was man aber auch sagen muss ist,
das ist etwas, das wieder Zeit braucht.
Es ist einfach, die Teams zusammenzulegen.
Es ist einfach zu sagen, wir wollen das.
Wir machen zum Beispiel in der Rolle,
machen wir keine Unterscheidung mehr
zwischen Entwickler und Betrieb.
Wir sagen, beide sind DevOps-Ingenieurs.
Da gibt es keine Unterscheidung in der Rolle.
Aber was man schon merkt,
das kann man schnell machen.
Die Rollen anpassen geht einfach,
die Teams zusammenstellen,
das geht auch einfach.
Aber wirklich der Skills-Aufbau,
das ist etwas, das sehr viel Zeit braucht.
Und das versuchen wir dann auch zu unterstützen,
zum Beispiel durch so Communitys,
durch so Community of Practice,
wo wir die Leute zusammenbringen,
wo wir Ausbildungsinitiativen machen,
damit man über die Zeit
so einen T- oder P-Shape aufbauen kann.
Aber das geht nicht von heute auf morgen.
Das ist wirklich ein Invest.
Also Community of Practice,
wir haben jetzt viel über die Swisscom gesprochen.
Über Community of Practice sagen wir intern,
dann auch Skills weiterzuentwickeln.
Aber es ist ja auch,
DevOps ist ja auch stark eine Community,
die DevOps Days oder auch DevOps Meetups,
wo dann der Austausch
firmenübergreifend stattfindet.
Wie haben wir auch in der Einleitung gesagt,
du hast die DevOps Days Schweiz initiiert,
mitinitiiert.
Was war da der Grund auch dafür
oder auch die Motivation jetzt aus Swisscom Sicht?
Der Punkt ist,
eigentlich haben wir zuerst rein intern angefangen.
Wir haben gesagt,
wenn wir diese autonomen Teams haben
und denen auch die Freiheit geben wollen,
die Dinge so zu tun,
wie sie es tun wollen,
dann möchten wir trotzdem,
dass sie voneinander lernen.
Und deshalb haben wir gesagt,
okay, lass uns möglichst
ein niederschwelliges Angebot aufbauen,
wo wir den Leuten mehr oder weniger
nur eine Plattform geben,
sich gegenseitig auszutauschen.
Und das Resultat war wirklich beeindruckend.
Es hat so viel gute Kommunikation
und gegenseitige Befruchtung auch stattgefunden,
dass wir gesagt haben,
eigentlich ist es schade,
wenn wir das nur innerhalb von der Swisscom machen,
weil wir sind extrem überzeugt,
dass wenn wir das auch mit anderen Leuten
aus der Industrie teilen,
dass wir gegenseitig voneinander lernen können.
Und das war dann eigentlich die Motivation,
weshalb wir erst ein Meetup aufgebaut haben
mit Leuten, wo wir Kontakt dazu hatten,
auch von anderen Firmen.
Und aus diesem Meetup,
das hatte einen sehr starken Zulauf,
waren auch immer sehr, sehr spannende Begegnungen,
die wir dort haben.
Und dann haben wir gesagt,
okay, das müssen wir jetzt einfach weiterziehen
und haben letztes Jahr zum ersten Mal
die DevOps Days organisiert.
Und dieses Jahr, am 2. und 3. Mai,
finden sie zum zweiten Mal statt.
Und eigentlich genau um diesen Geist,
dieses gemeinsame Teilen und Voneinanderlernen,
um das zu fördern.
Ich war da letztes Jahr auch dabei.
Ich kann das sehr empfehlen.
Also ich werde auch dieses Jahr
wieder an die DevOps Days gehen.
Das ist schlussendlich auch ein super Austausch,
um gegenseitig zu lernen, voneinander.
Was auch noch,
was vielleicht die Zuhörerinnen und Zuhörer
interessieren würde,
so wiederum,
um auf die Swisscom zu schwenken.
Wir haben darüber gesprochen,
eben das Warum, die Motivation,
dann wie habt ihr gestartet,
den Ansatz, den ihr gewählt habt.
Wir haben gelernt,
das ist eigentlich eine Reise,
die nie aufhört.
Was sind so,
wenn man jetzt über die Zukunft spricht,
was sind jetzt so die nächsten Dinge,
die ihr im Rahmen der DevOps Transformation
angehen wollt?
Ja, das Thema,
es gibt eigentlich wie so drei Hauptthemen,
die wir angehen im Moment.
Das eine ist,
und das ist extrem schön,
hat mich sehr gefreut,
dass Agilität jetzt wirklich
bis in die Konzernleitung gekommen ist
und die Konzernleitung sich auch
ganz klar dazu committed hat,
gesagt hat,
wir wollen das auf die ganze Firma ausrollen.
Und das ist extrem spannend.
Es gibt natürlich auch wieder
ein paar spannende Herausforderungen,
also wie,
dass wir das Ganze angehen können.
Und dann ist ein Thema,
das Ganze,
die Thematik mit der Portfolio,
Steuerung,
also die ganze Finanzierung
war bisher sehr stark im Projektfokus.
Also wir haben eigentlich Projekte finanziert.
Und wenn man das agile Gedankengut weiterdenkt,
dann sollte man ja eher hingehen
und sagen,
wir finanzieren stehende Teams
oder ich sage mal Portfolio-Epics,
die aus solches dann finanziert werden.
Und das hat dann natürlich
auf diesen ganzen Portfolio-
und Finanzierungsaspekt,
das ist eine grosse Auswirkung.
Das ist so der zweite Teil,
wo wir dran sind.
Und der dritte Teil,
dort geht es dann sehr stark um
die ganzen Personalprozesse,
um HR-Themen,
wo man so mit den klassischen Ansätzen,
die stehen auch im Konflikt
mit dem agilen Gedankengut.
Also es geht um das Thema Anstellung
von neuen Mitarbeitenden.
Es geht um das Thema Beurteilung,
aber auch Entwicklung und Entlöhnung.
Und da möchten wir die Prozesse
unter die Lupe nehmen,
möchten schauen,
wie wir stärker das agile Gedankengut
auch in die Prozesse reinbringen.
Ja, sehr gut.
Ich habe nochmal einen anderen Punkt
und das ist das Thema Mindset, Kulturwandel.
Ich stelle bei vielen meiner Kunden fest,
dass das zumindest aus meiner Sicht
oftmals auch eine Art Generationenfrage ist.
Also ältere Mitarbeiter oder Mitarbeiterinnen
gehen mit dem Thema anders um als Jüngere.
Ich bin mir am überlegen,
ob ich dem zustimmen kann oder nicht.
Ich glaube, ich würde es nicht so pauschal sagen.
Ich habe vieles erlebt.
Ich habe schon ältere Mitarbeiterinnen
und Mitarbeiter erlebt,
die mit Freude und als Vorbild
eigentlich den agilen Weg gegangen sind.
Und ich habe das andere aber auch schon erlebt,
dass wir bei jüngeren Mitarbeitern
sehr grosse Schwierigkeiten haben.
Vielleicht ist es in der Tendenz
ein bisschen so, wie du es sagst, Dirk.
Aber ganz generell würde ich das nicht unterstützen.
Ich glaube, es kommt viel stärker
auf die Haltung des Menschen an
und auch auf die Neugierde und Bereitschaft,
etwas Neues anzugehen.
Und weniger zu sagen,
und wenigerhaft zu sagen.
Okay, ja.
Ich polarisiere manchmal etwas,
um so ein paar Aussagen rauszuhören.
Und insofern kann ich damit leben,
dass du mir vielleicht nicht ganz zustimmst.
Und letzten Endes liegt die Kunst darin,
die Leute zu unterstützen, zu coachen
und die Leute auch in die richtigen Teams zusammenzupacken.
Also vielleicht den eher zurückhaltenden
oder ablehnenden jungen Mitarbeiter
mit begeisterungsfähigen älteren Mitarbeiterinnen
zusammenzupacken,
dass man da genau einen schönen Mix im Team findet.
Genau.
Und ich glaube, es gibt ja auch da wieder Leute,
die nicht wollen.
Ich glaube, von denen werden wir uns
über kurz oder lang trennen müssen.
Also all die Leute, die sagen,
nein, das will ich nicht.
Ich kann nicht umgehen mit so viel Transparenz.
Ich möchte nicht so eng
mit anderen Leuten zusammenarbeiten.
Ich glaube, das muss man respektieren.
Dass die Leute das nicht wollen.
Dann sind wir aber wahrscheinlich
die falsche Firma für diese Personen.
Und all die Leute, die sagen,
ja, ich will,
aber ich habe vielleicht die Fähigkeiten dazu noch nicht.
Die kann man dann eben mit Ausbildungsmassnahmen,
mit Coachings dazu bringen,
dass die prima in einem solchen Setup funktionieren können.
Also können versus wollen auch.
Du hast ja die erste Gruppe,
die du angeschaut hast.
Also ich sage denen so die No-No’s.
Ich meine, ich bin selber wahrscheinlich
auch schon mal No-No gewesen.
Aber dann ist es auch schön,
dass wenn man selber einsieht,
dann ja eigentlich ist es nicht der richtige Ort für mich.
Ich werde woanders glücklicher.
Ich mache manchmal so die Unterscheidung,
es gibt die Skeptiker auch,
die haben zum Teil auch gute Gründe.
Aber dann gibt es ja auch,
die nenne ich so die Die-Hearts.
Also Die-Heart ist so,
wenn jemand die Frage stellt,
wo möchtest du in fünf Jahren sein?
Und dann kommt die Antwort,
ja, ich will genau dort sein,
wo ich jetzt bin.
Also die fühlen sich extrem wohl
in ihrer Komfortzone.
Sie sagen,
ja, habt ihr dieses Phänomen auch?
Dann Leute, die,
sie sind nicht aktiv dagegen,
aber sie fühlen sich einfach extrem wohl
in ihrer Komfortzone.
Ich finde es eine gute Aufteilung,
die du machst.
Und solche Leute gibt es sicher auch.
Das ist ganz klar.
Und dort ist die Kunst,
die dann trotzdem zu begeistern
und trotzdem zu überzeugen,
dass es der richtige Weg ist.
Und da habe ich auch schon
ganz viele schöne Beispiele von Leuten,
die zuvor nicht aktiv dagegen waren,
aber vielleicht auch nichts dafür gemacht haben,
die wir dann mit schönen Beispielen
begeistern konnten.
Und wenn du die mal transformiert hast,
das sind deine größten Supporte
dann auch für dich.
Spannend.
Ja, also,
ich weiß nicht,
wie es dir geht, Alex.
Ich bin durch mit meinen Fragen.
Ich denke,
wenn ich so zurückblicke,
haben wir wirklich wieder
viele Dinge angesprochen.
Ich finde,
es ist wieder ein sehr interessanter Podcast
wieder geworden.
Oder hast du noch Fragen?
Ja.
Ich habe keine Fragen mehr.
Nein, ich fand es auch,
ich fand das super spannend.
Jetzt auch anhand von,
in der Praxis war es schon ein Kunde,
der eigentlich auch schon,
also aus dem Swisscom,
die schon ein Weilchen unterwegs ist
auf dem Gebiet.
Und das ist natürlich besonders wertvoll,
denke ich,
für die Zuhörerinnen und Zuhörer.
Aber soweit keine Fragen mehr.
Martin, dann würde ich sagen,
dann einen herzlichen Dank,
dass du dir die Zeit genommen hast,
dass du so ausführlich berichtet hast
über das,
was ihr so macht bei der Swisscom
oder auch gemacht habt,
dass ihr über euren Weg.
Und ja,
vielleicht sieht man sich ja auch mal
in der Realität.
Also von mir einen herzlichen Dank
und auf Wiederhören.
Besten Dank auch.
Macht’s gut.
Tschüss miteinander.
Yes,
tschüss.
Okay.
tresing mit einem
von 은

Folge 9: DevOps Missverständnisse

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode von „DevOps auf die Ohren und ins Hirn“ diskutieren Alex Lichtenberger und Dierk Söllner sechs häufige Missverständnisse über DevOps. Sie erklären, dass DevOps weder ein neues Framework ist noch die agile Produktentwicklung ersetzt, sondern diese ergänzt und sich gut in das IT-Service-Management einfügt. Die Rolle des IT-Betriebs wird durch DevOps verändert, aber nicht überflüssig gemacht, und obwohl Automation ein wesentlicher Bestandteil von DevOps ist, geht es dabei um mehr als nur „Everything as Code“. Zudem klären sie, dass Entwickler keinen direkten Zugriff auf Produktionsumgebungen haben, sondern der Prozess hochautomatisiert und kontrolliert abläuft.

Inhalt

  • DevOps als Philosophie, nicht als Framework
  • Verhältnis von DevOps zur agilen Produktentwicklung
  • Kompatibilität von DevOps mit IT-Service-Management
  • Die Rolle von Operations in DevOps und das Konzept von NoOps und NewOps
  • Bedeutung der Automation in DevOps und darüber hinausgehende Aspekte
  • Missverständnis über Entwickler mit direktem Zugriff auf die Produktion
  • Verschiedene DevOps-Praktiken und -Prinzipien

Shownotes

  1. DevOps Days: devopsdays.org
  2. ITIL (IT Infrastructure Library) für IT-Service-Management: ITIL
  3. Scrum als agiles Framework: Scrum Guide
  4. Scaled Agile Framework (SAFe): Scaled Agile Framework

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zu einer neuen Folge des Podcasts
DevOps – auf die Ohren und ins Hirn.
Mein Name ist Alex Lichtenberger.
Ich begrüsse die Zuhörer und Abonnenten auch im Namen von Dirk Söllner.
Der sich dann gleich vorstellen wird.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir sprechen alle DevOps-Interessierten an, die mit dem Medium Podcast etwas anfangen können
und gerne etwas dazu hören, sei es beim Autofahren, im Zug oder abends im Hotel oder zu Hause.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern.
Die in DevOps enthalten sind.
Mit diesem Podcast sollen die Hörer und Hörerinnen das vielleicht etwas schwammige Thema DevOps besser verstehen und auch erklären können.
Wir liefern Vorschläge, Konzepte und Interviews mit Experten und Praktikern,
damit sie persönlich durchblicken und ihr Unternehmen erfolgreicher machen können.
Heute machen wir wieder mal einen Podcast zu zweit, ohne externen Gast.
Das heisst dieses Mal nur Dirk und ich.
Nun zum Thema vom heutigen Podcast, das ist inzwischen der neunte Podcast, DevOps-Missverständnisse.
DevOps ist ja schon seit fünf bis sechs Jahren geprägt, dass ja kein Framework ist, kodifiziert.
Jeder versteht ja auch ein bisschen was anderes darunter und entsprechend gibt es ja sehr viele Missverständnisse.
Als Beispiel.
DevOps ersetzt die agile Produktentwicklung oder DevOps macht den IT-Betrieb überflüssig.
NoOps oder DevOps ist ein neues Framework.
Das sind so Punkte, die der Dirk und ich, wir haben uns das mal aufgelistet, auch aus unserer Praxis, aus Beratung und Schulung, was wir so aufschnappen.
Ja, und wir wollen diese Missverständnisse mal durchgehen und auch vielleicht einen oder anderen missverständlich.
Ja, bevor wir da jetzt mit mal one-by-one durchgehen, vielleicht noch kurz Dirk, willst du auch noch was kurz sagen?
Ja, Alex, vielen Dank für die Einleitung. Ich will kurz was sagen, vielleicht auch ein bisschen länger nachher zu den fachlichen Themen.
Ja, Dirk Sönder ist mein Name. Ich stelle mich jetzt auch ruhig auch nochmal vor, weil wir ja doch mehr Zuhörer bekommen und auch Zuhörer bekommen, die uns, die mich und dich, Alex, auch noch gar nicht so aus der Praxis kennen.
Also insofern.
Dirk Sönder. Ich betreibe verschiedene Webseiten. Eine unter anderem die Webseite devops.de, also mit zwei Dees, wo auch dieser Podcast dann verfügbar ist.
Mittlerweile haben wir ihn ja auch bei iTunes platzieren können. Also auch die hohen Weihen der bekannten Podcast-Portale haben wir ja dann geschafft.
Und insofern kriegen wir auch Rückmeldungen und ich wollte die Chance heute mal nutzen, mich auch bei den verschiedenen Rückmeldungen zu bedanken.
Bei den Hinweisen, wo Leute aufhören.
Wo wir etwas verbessert haben, wo wir also schon Dinge verändert haben und mit den kleinen oder auch größeren Tipps, sodass wir den Podcast immer mehr auch an die Wünsche und Anforderungen der Zuhörer anpassen können.
Also insofern einen vielen Dank oder einen herzlichen Dank an die Zuhörer und an die Abonnenten.
Gut, vielen Dank, Dirk. Dann legen wir mal los, deine unsere wunderbaren Liste.
Da haben wir als erstes, sehe ich, DevOps ist ein neues Framework. Dirk, was meinst du?
Ja, ist ja wirklich ein interessantes Missverständnis aus meiner Sicht.
Ich könnte mir vorstellen, dass das von dem einen oder anderen Hersteller oder Anbieter von Schulungen unter diesem Stichwort quasi verkauft wird.
Aber für mich ist das eben kein neues Framework.
Das macht es für mich auch so interessant, diese Sichtweise, dass es eben kein neues Framework ist, weil ich glaube, dass wir schon genug Frameworks haben.
Die muss ich jetzt nicht alle aufzählen. Wir wollen auch die Namen nicht alle nennen.
Also ich glaube, dass wir genug Frameworks haben. Wir haben genug Wissen.
Wir haben genug Wissen aufgeschrieben. Wir haben genug Wissen in der Praxis.
Wir müssten jetzt nur einfach mal drangehen, das in der Praxis umzusetzen, das, was an Wissen da ist, was an beschriebenen Frameworks da ist.
Und deswegen glaube ich, dass es eben kein neues Framework ist.
Ich sehe es jedenfalls nicht als ein Framework. Ich sehe es als etwas, was so Best Practice ist, dass die Unternehmen ihr eigenes Best Practice ermitteln.
Die Welt wird immer komplexer. Das heißt, aus meiner Sicht könnte auch überhaupt, wenn wir ein Framework hätten,
ein Framework allein kann meiner Meinung nach die Komplexität, die wir haben und die ja stetig zunimmt, gar nicht mehr abdecken.
Das heißt, wenn ich sage, es ist für mich kein neues Framework, heißt es für mich, ich kombiniere verschiedene Dinge.
Ich glaube, das haben wir auch immer schon mal wieder dargestellt. Das zeigt sich auch bei unseren Gästen.
Wir haben ein bisschen IT-Service-Management drin, repräsentiert durch ITIL.
Wir haben ein bisschen Agilität drin, durch Scrum unter anderem repräsentiert.
Und wir haben Lean-Management drin mit Kaizen.
Das heißt, die verschiedenen Frameworks und Ansätze, die es gibt, die kombinieren wir einfach nur.
Und vielleicht noch der letzte Punkt aus meiner Sicht jetzt für diesen ersten Einstieg in dieses Missverständnis.
Ich denke auch, dass DevOps etwas ist, was man in der Praxis umsetzen muss, was man erfahren und erlernen muss.
Es hilft nicht, irgendeinen Best-Practice-Ansatz zu haben und den sozusagen nur zu kopieren.
Ich glaube, das ist zum Beispiel etwas, wo…
Wo ITIL auch Schwierigkeiten hervorgerufen hat, wenn ein Unternehmen nur auf die Idee kommt, das zu kopieren.
Es spricht nichts dagegen, von Best-Practice-Ansätzen zu lernen, genauso wie ich von anderen Unternehmen lernen kann.
Also lernen ja als Best-Practice, aber eben das Wichtigste ist, man darf nicht kopieren, meiner Meinung nach.
Und deswegen halte ich es eben nicht für ein Framework, sondern einfach eine Philosophie.
Ja, also da sehe ich eigentlich genau gleich wie du.
Und das ist ja auch eben das Problem.
Mit dem Wort Framework oder auch Best-Practices.
Ich würde DevOps auch eher als Bewegung ansehen und als Emerging-Practices.
Sehr stark wird das ja geprägt durch die verschiedenen DevOps-Events, sei es die DevOps-Days, DevOps-Meetups, die ja inzwischen auf der ganzen Welt stattfinden.
Und wo halt wirklich, wie du sagst, auch aus der Praxis heraus neue Ideen…
Das sind eher so Emerging-Practices.
Ja, die kommen, die dann die Philosophie von DevOps unterstützen.
Und schlussendlich bewährt sich auch das, was Erfolg hat.
Und dann eben das Schöne, wie dann die verschiedenen Dinge dann zusammengebracht werden.
Elemente aus Agile, Lean und Service-Management und anderen.
Und in zwei Jahren schaut dann DevOps wahrscheinlich wieder anders aus, wie es heute ausschaut.
Das macht für mich persönlich jetzt auch den Reiz aus.
Ja, wahrscheinlich ist auch die Frage…
Ob man es überhaupt jemals mit einem Snapshot beschreiben kann.
Wenn es immer in Bewegung ist, dann ändert es sich ja auch.
Und ich glaube auch, das zeigen so meine Diskussionen, dass jedes Unternehmen das ein bisschen anders für sich sieht.
Ich habe in meinen Schulungen, da legen wir ja Wert auf der einen Seite auf Kultur, aber auch auf Automation.
Also zwei grundsätzlich unterschiedliche Bereiche.
Und dann gibt es Schulungsteilnehmer, die beschweren sich, dass wir viel zu viel über Kultur sprechen.
Das Ganze wäre ja…
Da gibt es sehr viel Automation.
Und dann gibt es welche, die genau das Gegenteil sagen.
Die also sagen, hey, ihr habt super toll die Kultur drin.
Hebt hervor, was Kultur bedeutet.
Automation, das kann ja im Prinzip jeder.
Da rede ich über irgendwelche Tools.
Also auch die Sichtweise der Teilnehmer, der Schulungsteilnehmer in diesem Falle, ist total unterschiedlich.
Und das finde ich eben schön, wenn man damit umzugehen weiß.
Ich weiß natürlich auch, dass es schwierig ist, im Unternehmen eine Richtung vorzugeben,
wenn man quasi kein klares Ziel hat.
Ich glaube, es wäre ein schlechter Rat, das Ziel quasi, das fehlende Ziel zu ersetzen,
indem man einfach blind eben ein Framework kopiert, was auf ganz vielen Seiten beschrieben ist.
Man muss einfach probieren, man muss immer wieder anpassen.
Und wie gesagt, die aktuelle Zeit ist heute so komplex.
Die Herausforderungen sind so unterschiedlich, dass ich eben auch im Unternehmen mich immer wieder anpassen muss.
Ja, dann wollen wir uns mal den nächsten auf der Liste anschauen.
Was denkst du?
Können wir machen.
Ich bin bereit.
Aber du bist ja dran, ne?
Ja, genau, ich bin dran.
Dann schaue ich mal da.
DevOps ersetzt agile Produktentwicklung.
Ja, auch ein weit verbreitetes Missverständnis.
Ja, das Problem ist wahrscheinlich mit dem Wort ersetzt.
Ich würde eher sagen, DevOps erweitert oder ergänzt die agile Produktentwicklung.
Weil agile Produktentwicklung ursprünglich natürlich aus dem Dev, aus dem Development raus,
inzwischen auch nicht schon in die Jahre gekommen, kann man sagen.
Agiles Manifest 2001, Scrum, Kanban, eigentlich noch älter.
Und wenn man so die Entwicklung anschaut, also die 90er Jahre, da hat man ja typischerweise noch wasserfallmässig Projekte abgewickelt.
So Projekte sind dann gut und gerne zwei, drei Jahre.
Und dann sind eben die Entwickler, die haben dann zuerst den Move gemacht, haben gesagt, ja, wir müssen da, wenn jetzt mal die Konkurrenz das gleiche in einem halben Jahr macht, da haben sie angefangen auf agil umzustellen.
Aber eben agil selber, beispielsweise auch in der Umsetzung dann mit Scrum, ist ja nicht ausreichend, wenn das ganze System ja nicht erlaubt,
dass man beispielsweise alle zwei.
Wochen oder häufiger effektiv mit dem Produkt und mit dem Service live gehen kann.
Und aus dem raus hat sich ja dann ganz natürlich hat sich eigentlich DevOps entwickelt.
DevOps als natürliche Weiterentwicklung von agil, dass man zum Beispiel sagt, ja, man versucht zu mehr zu automatisieren, auch so die Qualität zu steigen, indem man beispielsweise Tests automatisiert,
indem.
Man früher auch Operations im im Zyklus reinholt dann und das hat schlussendlich hat das die ganze agile Entwicklung bereichert, indem dann halt auch die Qualität gestiegen ist.
Also auch wenn man, denke ich, mit Leuten aus der agilen Welt, die schon seit seit langer Zeit im agilen Umfeld arbeiten, die sagen, ich hab’s wahrscheinlich auch letztes Mal eine Daten Startup gegründet, schon vor x Jahren über DevOps.
Ja.
Ja.
Ja.
Ja.
Und da hat er gesagt, ja, okay, DevOps sagt ihr dem.
Ja, wir machen das schon seit 15 Jahren.
Das ist jetzt natürlich so die die Sicht der agilen.
Na und jetzt gibt natürlich aus Operations Sicht auch oder, dass sich die dann ich denke sich dann Richtung Agilität entwickeln können und was auch noch dazu.
Ich denke auch klassische Phasen, wenn man jetzt Phasen mäßig, Wasserfall mässig vor geht.
Kann man ja auch von automatisieren,
und von dem kulturellen Change von DevOps profitieren.
Was deshalb ersetzen, denke ich, ist das falsche Wort.
Es ist eher, würde ich sagen, es bereichert, ergänzt die agile Produktentwicklung.
Ja, da würde ich dir zustimmen.
Dieses Wort ersetzen ist wahrscheinlich das, was so am meisten stört
oder was einem sofort ins Auge springt.
Ich würde es auch sehen.
Es ist eine Art Fortsetzung, es ist eine Erweiterung,
dass ich die agilen Teams eben erweitere, dass ich die agile Arbeit erweitere.
Und natürlich ist viel Agilität in DevOps drin, aber eben nicht alles.
Und das finde ich eben auch wichtig, immer wieder zu betonen.
Sonst könnte man ja sagen, okay, ich nehme irgendein agiles Produktentwicklungsteam,
packe da so ein, zwei Betriebsleute mit dazu und dann habe ich ja schon DevOps.
Das wäre ja eben auch etwas zu kurz gesprungen.
Also insofern ist für mich eben auch wichtig, nochmal zu sagen,
dass wir da auch schon viel IT-Service-Management drin haben.
Das hören vielleicht die agilen Entwickler nicht so gerne.
Und wir haben auch wirklich viel Lieblingsarbeit.
Lean drin, Lean-Management.
Und auch da, denke ich, sind viele wichtige Aspekte,
die einfach das Ganze ergänzen an der Stelle.
Also insofern habe ich immer wieder gesagt,
agil, Lean und IT-Service-Management.
Und vor allen Dingen, es ersetzt eben dann nicht die Produktentwicklung,
sondern es bereichert das.
Ja, der Gene Kim hat ja mal schön gesagt,
es braucht Entwickler, die so denken können wie Operation-Leute
und Operation-Leute, die so denken können wie Entwickler.
Es bereichert dann auf beide Seiten.
Ja, und wenn man jetzt mal überlegt, die agile Produktentwicklung,
also wenn wir das mit Scrum mal gleichsetzen,
ist schon interessant, wie ich finde, in dem aktuellen Scrum-Guide 2017,
da wird schon mehr auf DevOps und auf Automation und andere Themen hingewiesen.
Das heißt also, da haben Jeff und Ken schon so ein bisschen mehr den Blick
auch auf das, was aktuell sich quasi am Markt tut,
mit Ansätzen, eben nicht mit Frameworks, aber mit Ansätzen.
Genau.
Und insofern,
denke ich, gibt es auch ganz wichtige Dinge, die aus der Agilität kommen,
die aus dem Scrum kommen.
Wenn wir einfach mal schauen, bei Scrum haben wir ja potenziell auslieferbare Produktinkremente.
Ein richtig schön sperriger Begriff, der auch nicht immer einfach zu erklären ist.
Aber aus Sicht von DevOps ist es für mich ganz einfach.
Das, was die Scrum-Teams liefern, das liefern sie jetzt eben nicht in irgendeine Testumgebung,
sondern sie liefern es in die Produktivumgebung.
Also, ich sage mal, verbal gesehen nur ein kleiner Schritt,
aber inhaltlich ist es natürlich dann viel.
Ich bin mit dabei, um quasi bis in die Produktivumgebung zu liefern als Team an der Stelle.
Also, das ist, was du auch sagtest, es ist die Fortsetzung.
Wir erweitern die Aufgaben der agiligen Teams einfach, um auch ein bisschen Produktivsetzung.
Software is always in a releasable state.
Das ist eine der Definitionen von continuous delivery.
Und wenn man sich das mal so auf die Zunge zergehen lässt,
was heißt in a releasable state, kann man sogar so interpretieren und sagen,
ja, es ist sogar betragen.
Also, ich arbeite so, auch wenn ich zum Beispiel agil arbeite,
dass ich jederzeit live gehen könnte.
Und zwar auch so, dass es dann im Sinne jetzt von Service Management
halt nicht funktionale Anforderungen wie Security, Performance etc. das erfüllt.
Ja, ich habe in meinen Schulungsunterlagen so einen Satz drin stehen,
dass wir eben, was du sagtest mit dem continuous delivery,
dass wir quasi die Release-Setzung oder den Release,
den Release-Plan, die Produktivsetzung,
dass wir das damit eben in die Hände des Business legen.
Das Business könnte das Release live gehen lassen,
wenn wir das eben erfüllen, was du eben gesagt hast.
Und die gucken immer etwas ungläubig,
was manche können sie sich noch nicht vorstellen,
aber das ist ja genau das Ziel, wo wir hinwollen.
Das stimmt, ja.
Was ich dann häufig mache, auch wenn jetzt Teams,
sagen wir, die mit agil arbeiten, zum Beispiel nach Scrum,
dass wir zusammen antworten,
mit der Definition of Done arbeiten.
Wir machen das jeweils im Rahmen von Retrospektiven
und überlegen uns, was heisst jetzt Done für uns?
Oder Done hat früher vielleicht mal geheissen,
ja, okay, wir haben Acceptance-Kriterien, sind erfüllt,
da haben wir das weiterentwickelt, okay, Peer-Review,
da haben wir gesagt, okay, jetzt tun wir mal,
Done heisst beispielsweise, wir haben auch Performance-Tests durchgeführt,
also die, logischerweise muss man die dann automatisieren,
oder wir haben gesagt, ja, gewisse Security-Anforderungen,
die immer wieder kommen, die werden auch Teil von Done,
und das ist so eine Reise, und irgendwann kann man dann
vielleicht wirklich sagen, ja, unser Done, also jederzeit auch,
wir könnten jederzeit live gehen, oder so ist es eigentlich,
aus dieser Sicht ist es schon eine natürliche Weiterentwicklung
von Agilität, aber wie gesagt, klassische Projekte, denke ich,
die können auch davon profitieren.
Ja.
Zum nächsten, oder?
Drittes Missverständnis, was wir hier für uns so aufgeführt
und aufbereitet haben, DevOps passt nicht zu IT-Service-Management.
Das ist natürlich unsere Hauptdomäne oder unsere historische Domäne,
deine und meine, und auch das, finde ich, ist eben ein Missverständnis.
Das heißt, DevOps-Praktiken, meiner Ansicht nach,
können natürlich kompatibel zu IT-Service-Management gestaltet werden,
weil wir natürlich viele Ziele, die wir mit IT-Service-Management,
verfolgen, mit DevOps auch verfolgen und durch DevOps-Praktiken unterstützen.
Allein schon das Thema Automation, wie viel Aufwand und Ärger
wir uns im IT-Service-Management ersparen können,
wenn wir Dinge automatisieren, finde ich das schon einen ganz wichtigen Punkt.
Also insofern passt DevOps aus dieser Sicht heraus schon mal sehr gut
zu IT-Service-Management.
Und wenn ich mir dann so ein, zwei Teile mal rauspicke vom IT-Service-Management,
dann das ganze Thema.
Also CMDB, CMS, Configuration Management, das sind natürlich alles Dinge,
die Pflege dieser Datenbank, das war immer schon ein Automatisierungsgebiet,
wo man eigentlich nur wirklich sinnvoll arbeiten konnte,
wenn man das automatisieren konnte.
Und dadurch, dass ich jetzt die Entwicklung mit Eime ziehe quasi,
da habe ich ja noch bessere Daten, noch genauere Daten.
Und wenn ich den ganzen Fahrrad Continuous Delivery automatisiere,
dann habe ich auch automatisch eine,
die bessere CMDB.
Also auch da, finde ich, ist es wirklich ein sehr gutes Beispiel dafür,
dass DevOps eben IT-Service-Management sehr gut ergänzen kann, unterstützen kann.
Ja, und da können dann eben auch die Entwickler,
die können, vor allem die können was lernen.
Weil historisch, du hast ja DevOps Wall of Confusion,
jetzt sagen wir, okay, die Operations-Leute müssen lernen,
agiler zu werden, zusammenzuarbeiten mit den Entwicklern.
Aber auf der anderen Seite ist es auch ein Bereich,
in dem die Entwickler sich ja historisch nie für IT-SM interessiert haben.
Aber ich denke schon, also ein Kandidat ist zum Beispiel auch das Problem-Management.
Problem-Management, denke ich, eine der Practices aus dem IT-Service-Management,
die dann hilft, ganz im Sinne jetzt auch vom Second Way, vom Gene-Came-Feedback,
von rechts nach links, wiederkehrende Störungen,
da auch dann…
Proaktiv, oder das an der Wurzel zu fassen
und Probleme zu beheben und Störungen zu verhindern.
Configuration-Management sehe ich auch so.
Andere, denke ich, Gebiete, zum Beispiel das Event-Management,
zum Beispiel das ganze Continuous-Monitoring,
wo, sagen wir, auch wenn man jetzt ITIL als Framework anschaut,
da hat es super Tipps drin, die helfen,
wie man ein Continuous-Management,
Continuous-Monitoring aufbauen kann,
ohne dass man jetzt das Rad neu erfinden muss.
Ja, richtig.
Also, was du auch sagtest beim Thema Störungen,
beim Incident-Management, sehe ich ganz genauso.
Ich habe im DevOps ja das Ziel, schnell Störungen zu erkennen
und auch schnell reagieren zu können.
Und da wird jeder ITIL-Freak sagen,
genau das ist das, was wir auch wollen an der Stelle.
Also, insofern gibt es da wirklich große Übereinstimmungen
und man kann sich gut ergänzen.
Und wenn ich ergänzen nochmal…
Ich finde aber auch im Umkehrschluss,
dass IT-Service-Management auch sehr schön
das Thema Agilität unterstützen kann.
Denn wir haben dort, wie du auch sagtest,
tolle Tipps, tolle Practices zum Thema,
wie gehe ich mit Kunden um?
Was sind Services?
Wie beschreibe ich Services?
Service-Level-Management?
Wie vereinbare ich Services?
Das sind alles Dinge, die man quasi im DevOps
sehr schön aus IT-Service-Management übernehmen kann
und weiterentwickeln kann.
Weil das sind alles Sachen, die in den Bereichen,
z.B. Lean-Management und Agile, eben nicht auftauchen.
Also auch da denke ich, kann IT-Service-Management
auch etwas dazu beitragen, um das ganze Thema rund zu machen.
Also, ich finde auch definitiv, ITSM hilft.
Aber es gibt auch dann viele Aspekte,
wo es bei jedem Framework manchmal hilft, manchmal nicht.
Ich denke, die große Inspiration für DevOps
kommt schon vor allem aus dem Lean,
dann aus dem Agilen und natürlich auch ein bisschen
aus dem IT-Service-Management.
Aber ich würde es genau in der Reihenfolge formulieren.
Aber das ist jetzt so meine persönliche Meinung.
Ja, klar.
Also insofern, aber wir haben ja zu Anfang schon gesagt,
es ist kein neues Framework
und jedes Unternehmen muss die eigenen Erfahrungen machen.
Und je nachdem, wie die Erfahrungen im Unternehmen sind,
also ob es groß ist, ob es klein ist,
ob es viele Provider hat, ob es viel selbst macht,
es gibt sehr viele unterschiedliche Rahmenbedingungen,
und die haben einen Einfluss darauf,
wie gestalte ich denn meine DevOps-Organisation,
wenn ich überhaupt in so eine Richtung gehen möchte an der Stelle.
Ja, also insofern, ich glaube auch schon,
dass man aber auch, da haben wir vielleicht
ein bisschen unterschiedliche Einschätzungen.
Ich glaube schon, dass auch so Themen wie Governance
und das ganze Thema Management, also quasi als Überbau,
dass das auch Dinge sind, die wir aus dem IT-Service-Management
sehr gut übernehmen können, quasi als Rahmen,
in dem die DevOps-Teams dann,
sauber und gut strukturiert arbeiten können.
Das ganze Thema Portfolio, Service, Katalog.
Natürlich kann ich mich hinstellen
und kann die Teams das bestimmen lassen,
bin ich auch mit dabei,
aber die bestehenden Strukturen im Unternehmen,
die sind ja da, und da, denke ich,
hilft es schon noch, solche etablierten Prozesse zu haben
und die auch zu nutzen.
Aber man muss sie sicherlich anpassen
und DevOps-Teams da so reinbringen,
also reinmerchen.
In dem Kontext auch, du hast das Portfolio-Management,
erwähnt, also das Scaled-Agile-Framework.
Ich weiss nicht, wie es in Deutschland ist,
aber in der Schweiz ist es,
also ich glaube jetzt bei grossen Unternehmen,
Enterprise-ITs, wo eigentlich dann auch die Governance
sehr stark geprägt wird durch solche Frameworks.
Also Portfolio, Programm und dann auf Projekt- oder Team-Ebene
ist dann halt Scrum oder Kanban
und dann halt ergänzt durch DevOps-Mechanismen.
Ja, richtig.
Aber auch da wieder, was wir zu Anfang hatten,
eigentlich ist es ja ein Luxus-Problem.
Ich kann mir als Unternehmen überlegen, was nehme ich?
Nehme ich jetzt Governance aus Safe,
nehme ich Governance aus Covid beispielsweise,
haben wir ja nicht nur ITIL.
Also ich kann mich eigentlich bedienen,
das ist natürlich aufwendig
und das ist auch mit viel Arbeit verbunden.
Man muss Gehirnschmalz investieren.
Aber wir waren ja bei dem Missverständnis,
DevOps passt nicht zu IT-Service-Management
und das passt nicht so.
Also das passt sehr gut,
und kann sich sehr gut gegenseitig befruchten.
Ja, da sind wir uns einig, denke ich.
Sehr schön.
Mhm.
DevOps macht den IT-Betrieb überflüssig,
respektive NoOps.
NoOps, da habt ihr vielleicht schon den Begriff schon mal gehört.
Das ist ein ursprünglicher Begriff,
der wurde geprägt vom CEO von Netflix.
Der Name fällt mir jetzt gerade nicht mehr ein.
Aber er hat eigentlich gesagt,
ja, für ihn DevOps,
also er heisst es auch,
er braucht keine Operation mehr.
Das ist so der Begriff auch vom Full-Stack-Developer.
Der hat alles selber im Griff.
Shift, Left,
der kümmert sich auch um die ganzen nicht-funktionalen Dinge.
Und Operation ist eh alles,
das dann Infrastructure as Code,
das kommt alles aus der Cloud raus.
Und ja,
gut, da muss man erstens mal dazu sagen,
heute, wie Netflix funktioniert,
das ist definitiv nicht mehr so.
Auch die haben Operation.
Und Operation ist ja,
man darf das jetzt, denke ich,
weniger als Funktion anschauen,
sondern es gibt, sagen wir,
gewisse traditionelle Aufgaben, oder?
Die müssen auch, sagen wir,
im DevOps-Team oder im DevOps-Konstrukt
wahrgenommen werden.
Ich denke, was sich schon ändert,
ist die Rolle von Operation.
Also Operation,
und das ist übrigens auch interessant,
eine der ursprünglichen Ideen von IT-Service-Management,
Operation muss viel früher im Zyklus,
im Lebenszyklus von Produkten und Servicen
berücksichtigt werden.
Also Shift, Left.
Das kann dann schon de facto bedeuten,
dass halt klassische Operation-Abteilungen schrumpfen.
Also nicht mehr so die Denke,
ja, etwas wird entwickelt,
wird übergeben an jemand anderen,
über Prozesse etc.,
sondern halt die Aufgaben,
die müssen weiterhin wahrgenommen werden.
Aber früher Shift, Left.
Und dann ist auch, ich denke,
im Verständnis von DevOps ist,
oder das sehe ich zumindest oft in der Praxis,
ist Operation,
also im DevOps ist sehr stark auch der Enabling,
sagen wir, Infrastructure Layer.
Also die ganze Infrastruktur zur Verfügung stellen.
Cloud, also das kann dann auch eine private Cloud sein,
oder dann halt Public Cloud,
da braucht es auch die Governance dann dazu.
Und mit Infrastructure as Codes,
den ganzen darunter liegenden Layer,
damit dann die Teams,
you build it, you own it,
da effektiv auch beispielsweise Continuous Delivery machen können.
Ohne diesen Layer ist das nicht möglich.
Also es findet dann,
ich denke in der Zukunft ist es nicht mehr die Aufgabe von Operation,
Code in die Produktion zu nehmen,
das zu betreiben,
sondern das den anderen einfacher zu machen,
damit sie das selber machen können.
Und auch andere,
also wenn jetzt von No Ops,
finde ich deshalb auch einen schlechten Begriff,
weil es wird weiterhin,
es wird Störungen geben,
es wird weiterhin klassische,
Monitoring-Aufgaben.
Die Frage ist einfach, wo wird das dann wahrgenommen?
Es ist dann, denke ich,
nicht mehr ein separates Department,
weil das etwas, was ja DevOps definitiv nicht will,
sondern ich glaube Operation muss sich einfach,
ja, muss sich ein bisschen neu orientieren.
Und ich habe es glaube ich schon mal gebracht,
da ist dann eben nicht No Ops,
sondern New Ops eher.
Aber die müssen dann auch entsprechend offen sein,
sich zu wandeln,
statt wie anhin oft halt dann zu mauern,
zu sagen ja,
immer nein zu sagen und sagen nein,
das kommt jetzt nicht in die Produktion,
sondern auch sich da zu öffnen.
Und wenn das nicht der Fall ist,
dann wird dann eben aus,
dann wirklich No Ops draus,
weil dann,
das sehe ich auch oft,
Entwicklungsabteilungen,
die dann das Zepter selber in die Hand nehmen
und,
und sich dann die Dinge auf dem Markt selber beschaffen,
beispielsweise via Public Cloud etc.
Also deshalb,
DevOps macht,
denke ich,
nein,
macht den IT-Betrieb nicht überflüssig,
aber der IT,
die Rolle des IT-Betriebs wird sich wandeln
oder wandelt sich bereits.
Ja,
ich glaube auch,
dass sie sich schon aktuell schon stark wandelt.
Da ist ja auch ein gewisser Druck da durch,
durch Cloud-Anbieter,
du hast es ja eben schon gesagt.
Das heißt,
eine gewisse Notwendigkeit ist da.
Das, was du eben sagtest mit dem Mauern,
nein, das kommt nicht in die Produktion.
Das kann natürlich sein,
dass man gemauert hat aus Prinzip,
aber es kann ja auch sein,
dass man die Gründe gehabt hat,
warum es nicht in die Produktion geht.
Und das finde ich eben einen weiteren Punkt.
Du hast ja gesagt,
sie müssen sich wandeln und das,
oder die Arbeit muss sich wandeln.
Und das finde ich eben dann nur als Vorteil für Ops,
dass die Erfahrung und die Verantwortung,
das Verantwortungsbewusstsein,
das, was wir einfach viel früher in den Lifecycle einbeziehen
und dass wir das jetzt auch wirklich umsetzen.
Du hast ja gesagt,
das auch schon gefordert.
Ja,
es ist ja auch nichts Besonderes zu sagen,
hey,
viel früher einsteigen.
Aber ich glaube,
dass wir jetzt an dem Punkt sind,
wo wir in den IT-Organisationen feststellen,
die Notwendigkeit ist da
und die Sinnhaftigkeit wird auch so gesehen.
Also insofern,
New Ops,
ja,
New Ops heißt,
sie bringen ihre Erfahrung mit ein,
sie bringen ihre Verantwortung,
ihr Governance-Thema,
ihr Governance-Thema mit ein
und sorgen dafür,
dass wir viel früher diese Dinge beachten
und damit auch mehr Qualität produzieren.
Und,
was ich ja auch nochmal ganz interessant finde,
es gibt ja ganz viele ungeliebte manuelle Tätigkeiten im Operations.
Das sichert zwar Arbeitsplätze,
aber ist nicht unbedingt sinnstiftend an der Stelle.
Also insofern,
auch da wieder das Thema Automation,
dadurch,
dass wir eben quasi über DevOps,
auch ganz stark über Automation reden
und es auch umsetzen,
ändert sich ja auch das Thema Ops.
Sprich,
wir kriegen eben,
wir haben den Entfall von vielen manuellen ungeliebten Tätigkeiten,
einfach weil wir Dinge automatisieren
und dazu muss aber auch Ops die Erfahrung mit einbringen
und muss auch die Anforderungen an die Automatisierung quasi formulieren
und mit in den Teams entsprechend eben formulieren.
Ja,
also da finde ich auch,
ja,
aber das produziert dann auch sehr viele Ängste.
Sagen wir,
Leute,
die halt im Vergangenheit
sehr viele repetitive Aufgaben gemacht haben
und da ist jetzt ein gewisses Automatisierungspotenzial,
da,
dass sich dann die Leute halt die Frage stellen,
ja was,
was,
was passiert mit mir in der Zukunft?
Jetzt kann man das natürlich als Gefahr sehen,
einerseits,
aber auch als Chance.
Also primär würde ich jetzt,
für mich würde ich sagen,
ja auch,
dass der Job spannender wird.
Aber die,
das Problem ist natürlich dann mit den Skills.
Das sieht man auch schön,
zum Beispiel im Testing.
Früher sehr viel,
sagen wir Testausführende,
während heute,
klar die,
weil ja viel Automatisierung,
auch Testautomatisierung,
das heisst,
es braucht wenige Testausführende,
aber Leute,
die dann die Skills haben,
zum Beispiel Tests zu automatisieren
oder in die Richtung.
Und dann ist dann immer die Frage,
ja,
die Leute wollen vielleicht,
aber sie können nicht von den Skills her.
Das ist dann schon,
schon auch problematisch.
Auf der anderen Seite ist ja,
Industrialisierung ist etwas,
das vermutlich schon seit 200 Jahren stattfindet,
aber die Jobs sind ja nicht weniger geworden,
es sind immer mehr geworden.
Und ich glaube,
in der IT ist auch,
obwohl jetzt immer mehr automatisiert wird
oder Komoditisierung durch Cloud,
die Jobs werden mehr,
aber es ist halt mehr,
es wird anspruchsvoller,
denke ich.
Und da ist auch die Frage,
können sich Operationsleute,
die,
sagen wir,
sich in automatisierten Bereichen bewegt haben,
also die jetzt automatisieren,
können sich da weiterentwickeln?
Und wenn nicht,
dann ist es halt für die schon schwieriger.
Ja, das glaube ich auch.
Aber da stelle ich fest,
zumindest bei uns in Deutschland,
dass wir ja schon verantwortungsvolle Firmen haben,
verantwortungsvolle IT-Organisationen,
die sich ihrer Verantwortung eben bewusst sind
und auch dafür sorgen,
dass die Mitarbeiter diesen Weg mitgehen,
wenn sie sich eben öffnen.
Das hast du ja auch schon zu Anfang gesagt.
Sie müssen sich öffnen
und sie müssen das als Chance sehen.
Wer dort mauert,
der hat vielleicht früher die Produktivsitzung gemauert
und jetzt mauert er sich dann seine eigene Sackgasse.
Ja, ich finde,
da gibt es so ein schönes Dreieck.
Dürfen,
wollen und können.
Das eine ist ja,
wir dürfen,
klar,
die Firma sagt doch,
also ihr dürft,
wir wollen das sogar,
dass ihr euch in die Richtung entwickelt.
Und dann ist schon die Frage damit,
aber will er das überhaupt?
Und vielleicht,
ja, okay, will er es,
aber da gibt es auch die Fälle,
wo man aus dem Testausführen,
dann kannst du nicht von morgen auf heute
einen Testautomatisierer machen.
Das sind komplett andere Skills.
Da kann dann eben schon noch der Hund begraben sein.
Weil da finde ich einfach dann auch wichtig,
deswegen haben wir auch diese Missverständnisse,
die wir mal rausgepickt haben,
dass man den Betriebsleuten klar macht,
dass man das Wissen schon noch hat,
was man noch braucht.
Natürlich verändert sich die Arbeit,
aber das Wissen,
die Erfahrung,
die die gesammelt haben,
das sind Schätze,
die kann ich einem Entwickler,
kann ich ihm das gar nicht erklären.
Also die Erfahrung,
die der Betrieb mitbringt,
die braucht man auch bei Übergangsphasen in die Cloud,
wenn man wirklich die Cloud,
also wenn man eine externe Cloud hat
oder wenn man eine eigene,
eine private Cloud aufbaut im Unternehmen.
Das Wissen brauche ich ja auch an der Stelle.
Also insofern,
da sind wir uns eben auch einig,
der DevOps,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
man muss ja auch,
da sind wir uns eben auch einig,
der DevOps macht den IT-Betrieb nicht überflüssig,
sondern verändert die Arbeit
und wir können nur hoffen,
dass sich die Leute mitgenommen fühlen,
dass sie mitgenommen werden
und dass sie sich einbringen können.
Ja,
ist eine Chance schlussendlich.
Ja,
ja Mensch,
das fünfte,
das fünfte Missverständnis,
einen können wir noch
oder zwei.
DevOps ist eigentlich nur Everything as Code.
Das heißt,
wir reden eigentlich bei DevOps nur über Automation.
Also auch das,
das ist ein Missverständnis.
Denn,
das denke ich,
haben wir schon durch die vorherigen Missverständnisse
ein bisschen klar gemacht,
wir reden eben nicht nur über Automation.
Natürlich haben wir bei DevOps oder mit DevOps
einen ganz hohen Automationsanteil,
aber das ist eben nicht alles,
weil wenn ich jetzt beispielsweise über die Prozesse
nicht nachdenke,
dann automatisiere ich ja nur Teilschritte
eines gesamten Prozesses.
Das heißt,
ich brauche einen Gesamtüberblick über alle Prozesse,
über den gesamten Ablauf,
über die gesamte Wertschöpfungskette,
das heißt,
Automation,
sehr schön,
aber ich muss eben die gesamte Wertschöpfungskette im Blick haben,
muss diese drei Wege,
muss den Rückfluss einfach über die gesamte Kette sehen.
Also insofern,
ja,
Automation,
aber es reicht eben nicht,
nur einen Teil zu betrachten.
Ja,
ich denke,
also DevOps ist sicher nicht möglich ohne Automation.
Ja,
da hatten wir auch früher schon mal drüber gesprochen.
People,
Prozesse,
Technologies,
schlussendlich ein Aspekt dann.
Und wir brauchen ja auch Kultur.
Also das ganze Thema,
was wir aus der Agilität kennen mit Experimenten,
mit Fehlerkultur,
mit Dingen mal ausprobieren und so weiter.
Also die vielen Dinge,
die wir aus der Agilität kennen,
die muss ich in eine DevOps-Kultur einbringen,
genauso wie ich auch die Betriebsaspekte in diese Kultur einbringen muss.
Also ich glaube wirklich einen großen Mehrwert
oder das Sahnehäubchen ist zum Beispiel einfach,
eine gemeinsame Kultur zu schaffen,
eine Kultur,
wo sich alle wiederfinden,
wo es dann eben auch wirklich Spaß macht
oder vielleicht wieder Spaß macht,
für die IT zu arbeiten.
Du hast ja immer so schöne Zitate vorhin gebracht
und ich habe da auch ein schönes Zitat gefunden
von dem Christopher Little,
der hat eben gesagt,
bei DevOps geht es nicht um Automatisierung,
genauso wie es in der Astronomie nicht um Teleskope geht.
Also ich brauche das zwar,
aber es gibt ein bisschen mehr an der Stelle.
Also insofern,
ja,
Missverständnis ausgeräumt hoffentlich an der Stelle.
DevOps ist,
DevOps ist mehr als Automation.
Das muss ich jetzt gleich noch toppen,
nochmal mit einem Zitat.
A fool with a tool is still a fool.
Ja stimmt, richtig.
Von wem kommt das eigentlich?
Von Herrn Kupf unbekannt.
Keine Ahnung,
ich glaube das ist so ein bisschen allgemein gut,
aber da gibt es sicher einen,
der das zuerst gesagt hat.
Man muss mal gucken,
wo man den findet.
Also insofern,
Everything as Code,
ja auf jeden Fall,
aber es ist eben nicht alles.
Wollen wir noch einen?
Also Zeit haben wir glaube ich noch.
Der ist ja so von der Reserve list.
Ja, mach mal.
Knapp 40 Minuten.
Ja, der tönt im ersten Moment ein bisschen blöd,
aber ich bin halt ab und zu stoßig auf diese Aussage.
Entwickler haben direkten Zugriff auf die Produktion.
Nein, natürlich nicht.
Aber zuerst einmal,
woher kommt dieses Missverständnis?
Also einerseits,
ist halt wenn man hört,
wie Continuous Delivery, Continuous Deployment,
z.B. Amazon,
die machen 5000 Deployments am Tag.
De facto,
wenn Entwickler Code eingecheckt und das hat alle Tests durchlaufen,
das geht in die Produktion.
Das ist dort so,
bei anderen Firmen auch.
Und dadurch kann ja dann das Missverständnis,
jetzt hat der Entwickler direkt Zugriff auf die Produktion.
Aber wenn man jetzt,
gut, das ist halt ein bisschen jetzt technisch auch,
aber wenn man sich Continuous Delivery anschaut,
die DevOps Pipeline ist ja weiterhin so und muss auch so sein,
auch aus Governance Gründen.
Der Entwickler entwickelt auf einer Entwicklungsumgebung
und was ja weiterhin stattfindet,
ist dann der Transport und die ganze Change Control,
einfach in einem hochautomatisierten Grad.
Das heisst,
wenn das wird dann direkt überführt in eine Testumgebung,
es werden automatisierte Tests durchgeführt,
also alle,
die das V-Modell kennen,
das fängt dann beim Unit Test System Test etc.
Dann aber auch,
was ja früher vergessen gegangen ist,
nicht funktionale Tests wie Performance, Security, Continuity etc.
Und dann,
wenn das alles erfolgt,
dann wird das in eine zum Beispiel Produktionsumgebung überführt.
Vielleicht auch nur für ein paar wenige User,
je nachdem welche Teststrategie das man fährt.
Man kann ja dann sagen,
ja,
dann lässt es mal als Piloten laufen
und dann,
wenn kein negatives Feedback,
wird es dann ausgeweitet auf den Rest.
Aber in dem Sinn ist ja auch ganz im Sinne von DevOps,
dass es wird,
dass es kein direkter Zugriff auf die Produktion,
dass uns das weiterhin separiert,
Change Control,
aber halt einfach im,
wenn wir jetzt technisch oder prozessmässig gesprochen,
einen hohen Grad an Automatisierung.
So, also das ist jetzt so meine Sicht.
Ich weiss nicht wie du Dirk,
bist du auch schon über diese Aussage gestossen,
Entwickler haben direkten Zugriff auf die Produktion.
Das kommt manchmal bei,
wenn wir über das Thema Governance sprechen,
dann kommt das manchmal,
aber so wie du es im Prinzip gesagt hast,
kommt dann immer auch als Erklärung
und ich glaube,
dass die meisten das dann auch an der Stelle auch verstehen.
Ja, genau.
Ja Mensch,
dann haben wir heute sechs Missverständnisse
und ich glaube,
wir sollten die nochmal aufzählen
und zwar eben,
dass wir sie so formulieren,
damit keiner rausgeht aus dem Podcast
und sich quasi das Missverständnis merkt.
Also ich fange mal an mit meinem ersten Missverständnis
und formuliere das mal positiv.
DevOps ist kein neues Framework.
DevOps ist eine Philosophie,
aber kein neues Framework.
Dann versuche ich das im genau gleichen Stil für den nächsten,
nämlich DevOps ergänzt und ersetzt nicht
die agile Produktentwicklung.
Jawohl, dann mache ich weiter mit dem dritten.
DevOps passt zu IT-Service-Management.
DevOps kann gut von IT-Service-Management ausgehen.
Man muss IT-Service-Management lernen und umgekehrt.
Also DevOps passt sehr wohl zu IT-Service-Management.
Dann DevOps macht IT-Betrieb überflüssig aka NoOps.
Nein, die Aufgaben von Operation wird es weiterhin brauchen.
Ist halt einfach das Bild von Operation,
das klassische Operation,
das sich wandeln muss Richtung NewOps.
Jawohl, da bin ich wieder dran.
DevOps ist mehr als Automation.
DevOps ist nicht nur Everything as Code.
DevOps ist mehr als Automation.
Und DevOps besteht zwar zu einem hohen Teil aus Automation,
aber es gibt noch viele andere wichtige Dinge.
Insofern, DevOps ist mehr als Automation.
Dann Entwickler haben direkten Zugriff auf die Produktion.
Nein, natürlich nicht.
Das ist Blödsinn.
Ja.
Jetzt hast du mich aber geschockt.
Ja.
Jawohl, sehr schön.
Ja, dann haben wir doch wieder eine Podcast-Folge hier gemeinsam über den Weg gebracht.
Das ist jetzt die letzte Einstellige.
Also insofern, mir macht es Spaß.
Ich finde es schön.
Es ist ein schöner Austausch.
Und man sieht ja auch und hört an den Feedbacks,
dass es bei den Kunden auch ankommt,
dass es Leute gerne hören.
Gut, dann sind wir jetzt durch, Alex.
Ich habe ja gesagt, mir hat das Spaß gemacht.
Mir macht es immer wieder Spaß.
Beim nächsten Mal.
Beim nächsten Mal haben wir dann wieder einen Gast
oder vielleicht sogar auch mehrere Gäste hier im Podcast.
Wir haben ein Unternehmen.
Und das Unternehmen wird uns ein bisschen was aus der eigenen Praxis berichten.
Insofern verraten wir den Namen mal noch nicht.
Es ist aber ein ganz interessantes Unternehmen.
Der eine oder andere wird es vielleicht kennen.
Aber ja, seien Sie gespannt.
Seid ihr gespannt auf den nächsten Podcast.
Ich verabschiede mich.
Auf Wiederhören, auf Wiedersehen, wo auch immer.
Dir war Dirk Söhner.
Ja, vielen Dank auch von meiner Seite.
Es hat mir auch wieder riesig Spass gemacht.
Und ja, ich freue mich auf den nächsten Podcast.
Dann hört man sich wieder in einem Monat.
Bis dann, auf Wiederhören.
Tschüss.
Tschüss.
Tschüss.
Tschüss.
Tschüss.

Folge 8: Das Phoenix Project und DevOps Handbuch

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Podcast-Episode diskutieren Dierk Söllner und der Gast Thomas Demmich, der Übersetzer des „Phoenix-Projekts“ und des „DevOps-Handbuchs“, detailliert über DevOps. Sie erörtern verschiedene Aspekte wie die Übertragung von Produktionsprinzipien auf die IT, die Herausforderungen bei der Implementierung von DevOps in Unternehmen, und die Bedeutung einer Fehlerkultur. Sie reflektieren auch über die Charaktere und Ereignisse im „Phoenix-Projekt“ und wie diese die Realitäten in IT-Organisationen widerspiegeln, während sie gleichzeitig praktische Ansätze aus dem „DevOps-Handbuch“ hervorheben.

Inhalt

  • Einführung und Vorstellung von Thomas Demmich
  • Definition und Bedeutung von DevOps
  • Diskussion über das „Phoenix-Projekt“ und Charakteranalyse
  • Einblicke in das „DevOps-Handbuch“
  • Automatisierung und Herausforderungen in DevOps
  • Bedeutung von Fehlerkultur und technischen Schulden
  • Anwendung von DevOps-Prinzipien in realen IT-Umgebungen
  • Abschließende Gedanken und Aha-Effekte

Shownotes

  1. „Das Phoenix-Projekt“ BuchLink
  2. „Das DevOps-Handbuch“ BuchLink
  3. Gene Kim (Autor)Link
  4. O’Reilly Verlag (Thomas Demmich arbeitet als Übersetzer für sie) – Link

Transkript (automatisiert, daher keine Gewähr 🙂 )

Herzlich Willkommen zu einer neuen Folge des Podcasts DevOps – Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich begrüße die Zuhörer und Abonnenten auch im Namen von Alex Lichtenberger.
Der ist leider heute Abend krank, den hat die Grippe ins Bett geworfen, also insofern haben wir heute eine Premiere für diesen Podcast.
Die Premiere ist nur einer der beiden Gastgeber am Mikrofon, aber ich denke, das kriegen wir hin.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir sprechen alle DevOps-Interessierten an, die mit dem Medium podcasten.
Und gerne etwas dazu hören, sei es beim Autofahren, in der U-Bahn, S-Bahn oder abends im Hotel oder auch vielleicht zu Hause.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Und für diese Folge haben wir was ganz Besonderes.
Wir haben Gene Kim. Na gut, wir haben natürlich nicht Gene Kim selber.
Wir haben die deutsche Stimme von Gene Kim, Thomas Demick, der die Bücher von Gene Kim,
übersetzt hat, das DevOps-Handbuch und das Phoenix-Project.
Also haben wir heute ein Fachgespräch mit der deutschen Stimme von Gene Kim.
Mit diesem Podcast wollen wir eben die Hörer und Hörerinnen etwas näher und etwas besser an das etwas schwammige Thema DevOps heranführen.
Wir wollen Dinge verstehen und erklären und wir liefern Vorschläge, Konzepte, Interviews mit Experten und mit Praktikern,
damit wir Sie, liebe Zuhörer, liebe Zuhörerinnen, persönlich,
weiterbringen, damit Sie persönlich durchblicken können und Ihr Unternehmen und Ihr Team erfolgreicher machen können.
Heute haben wir das Thema, wie ich eben schon gesagt habe,
The Phoenix Project und begrüßen dazu Thomas Demick, den deutschen Übersetzer.
Und in diesem Podcast werden Sie etwas über die Inhalte vom Phoenix Project hören,
einen Roman über DevOps.
Wir werden Ihnen ein bisschen die einzelnen Charaktere näherbringen, etwas über Sarah und über Eric erzählen, etwas über Patty und Wes.
Wir werden auch ein bisschen was über die anderen Charaktere sprechen.
Wir werden über das DevOps Handbuch sprechen.
Wir werden zum Beispiel darstellen, was das bedeutet, sichtbar machen von Arbeit, was es bedeutet, über technische Schulden zu sprechen.
Wir werden versuchen, den Aha-Effekt so ein bisschen rauszuarbeiten, den die Autoren für sich damals hatten, um dann das Buch zu schreiben.
Wir werden ein paar andere Dinge ansprechen, die in dem Buch beschrieben sind.
Wir sprechen über die vier Arten von Arbeit.
Wir sprechen über die drei Wege, über das Drei-Wege-Modell.
Also insofern werden wir hoffentlich eine schöne Podcast-Folge produzieren,
die die Leichtigkeit des Romans ein wenig übernimmt und ein wenig auf diesen Podcast überträgt.
Lieber Thomas, vielen Dank für die Unterstützung und deine Begleitung heute.
Herzlich willkommen zu unserem Podcast hier, DevOps auf die Ohren und ins Hören.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
immer zu Anfang eine kurze Vorstellung unseres Gastes und dann die Frage,
wie würdest du DevOps definieren?
Also insofern würde ich sagen, lass uns loslegen, lieber Thomas.
Starten wir mit der Vorstellung und mit deiner Einstiegsdefinition von DevOps.
Ja, hallo. Also ich bin Thomas Demmich.
Ich bin eigentlich Entwickler, nebenberuflich auch Übersetzer,
vor allem für O’Reilly und den D-Punkt-Verlag mittlerweile.
Arbeite sonst hauptberuflich in einem großen deutschen Softwareunternehmen,
habe in, ich glaube, vorletztes Jahr ist das jetzt schon das Phoenix-Projekt übersetzt
und auch dann danach das DevOps-Handbuch.
Fand das sehr spannend und sehr interessant und freue mich darüber jetzt mal zu reden.
Du hast es ja schon gesagt, DevOps-Handbuch, Phoenix-Projekt.
Geht es um das Thema DevOps? Wie würdest du DevOps definieren?
Kann man das überhaupt definieren? Würdest du das beschreiben?
Ich würde das definieren als engere Zusammenarbeit zwischen der Entwicklung
und dem darauffolgenden Operations-Unternehmen.
Wobei versucht wird, eben möglichst viel zu automatisieren
und möglichst viele Zeitfresser und Hindernisse aus dem Weg zu räumen, nach und nach.
Ja, sehr schön. Das ist auch schon mal ein interessanter Punkt.
Zeitfresser, ich denke, ich weiß, woher du diesen Begriff hast
und die Hindernisse aus dem Weg räumen, das sind ja schon Dinge,
die aus dem Buch auch so hervorgehen.
Aber vielleicht mal so zu Beginn noch eine ganz andere Frage.
Gar nicht so fachlich.
Wie wird man Übersetzer und wie muss ich mir als jemand,
der die übersetzten Bücher liest, wie muss ich mir das vorstellen?
Was macht ein Übersetzer oder wie arbeitet der?
Ich bin das geworden, weil mein Vater es schon war.
Der hat das gemacht damals, musste dann damals noch zu Windows 2000-Zeiten
gleich so vier Bände auf einmal übersetzen bzw. betreuen
und hat mich damals gefragt, ob ich das nicht auch mal machen will.
Dann habe ich damals einen von den Bänden übersetzt
und der damalige Lektor war halt angetan davon
und hat mich, als bei der damals gerade den Verlag gewechselt hat, mitgenommen.
Und dann habe ich, ich glaube, erst für Hansa übersetzt und für METP.
Und das ist dann irgendwann, ist das eingeschlafen
und dann habe ich mich mal bei O’Reilly beworben sozusagen,
habe da einfach mal angefragt, habe eine Probeübersetzung gemacht
und seitdem bin ich seit vielen Jahren irgendwie schon da.
Insofern, du hast ja ein Privileg, glaube ich, du bist ja etwas ganz Besonderes.
Ich denke, du bist einer der wenigen auf der Welt,
der quasi das Original und die deutsche Übersetzung gelesen hat.
Also insofern bist du da schon was Besonderes.
Nicht nur die deutsche Stimme von Gene Kim,
sondern auch jemand, der, wie gesagt, beide Bücher gelesen hat.
Gut, das heißt, die Arbeit als Übersetzer,
wie stark nimmt dich das ein oder wie stark beschäftigt ist es in deiner Freizeit?
Es sind im Prinzip dann die Abende, die ich damit verbringe.
Also nicht den ganzen Abend, aber immer schon so,
zwei, drei Stunden, aber eben nicht jeden Abend.
Also ich gucke, dass ich dann, wenn es geht,
das terminlich so absprechen kann mit dem Verlag,
dass ich quasi dann auch eine Fünf-Tage-Woche habe,
sodass ich dann immer ein, zwei Abende die Woche nichts tun muss
und auch kein schlechtes Gewissen haben muss, wenn ich mal nichts tue.
Okay, ja. Aber es ist schon anstrengend sozusagen oder schon auch durchgetaktet?
Ja, es ist schon anstrengend auf Dauer dann.
Also es macht immer Spaß, wenn ich was Neues anfange
und wenn ich dann auch wieder gleich wieder,
wenn ich dann auch wieder was Neues anfange,
immer wieder was am Stück kriege, ist das auch schön natürlich.
Aber wenn dann mal Pause ist, ist das auch nicht schlecht.
Aber nach so zwei, drei Monaten Pause, das kommt ja auch mal vor,
freue ich mich dann auch wieder, wenn ich dann mal wieder was machen kann,
weil ich es einfach auch spannend finde, weil es immer wieder mal was Neues ist.
Die Themen ja auch immer wieder variieren.
Das ist im Vergleich zu dem, was ich in meiner,
sagen wir mal, in meiner Brotarbeit tue,
ist das halt quasi ein Spielbein für mich.
Ja, ja, das ist doch interessant.
Ich finde es auch schön, wenn man ein bisschen noch was quasi
nah am Fachlichen dran hat.
Weil ich gehe immer schon davon aus,
dass du auch das eine oder andere von deinen Übersetzungen
auch mitnehmen kannst fachlich.
Also du kriegst ja quasi das Lesen bezahlt.
Ja, also ich denke, ich habe in vielen Bereichen,
habe ich mal was erfahren.
Ich bin nirgendwo so richtig tief drin.
Also es ist jetzt, es gibt immer,
auch in meinem Umfeld auf der Arbeit,
immer genug Leute, die irgendwas auf jeden Fall deutlich besser können.
Aber ich habe von allem schon mal gehört.
Und das finden viele irgendwie finden,
das muss ich auch zugeben,
viele sind spannend, wenn die davon hören,
was ich halt nebenbei noch mache.
Und die freuen sich auch immer wieder mal,
wenn ich dann ein fertiges Buch mitbringe,
die dann da drin auch lesen können.
Ja, okay.
Wenn wir jetzt mal auf das Phoenix Project gehen.
Also ich finde, das ist ja ein wahnsinnig tolles Buch.
Wie ging dir das, als du das zum ersten Mal so bekommen hast
und dann gelesen hast?
Es wird ja als Roman beworben oder dargestellt.
Würdest du es auch als Roman bezeichnen?
Oder ist das für dich auch eher ein,
ein Fachbuch?
Also wie war so dein erster Eindruck,
als du das Buch bekommen hast?
Es ist schon ein Roman,
finde ich auf jeden Fall.
Ein Roman mit einer, mit einem,
ja, wie soll ich sagen,
nicht mit dem erhobenen Zeigefinger,
aber mit einem, der versucht halt,
eine Message rüberzubringen.
Der versucht ja, Informationen zu vermitteln,
die Leute dazu zu bringen, zu sagen,
Mensch, das kenne ich doch bei mir genauso.
Vielleicht sollte ich das mal irgendwie auch angehen.
Aber es ist, im Endeffekt ist es eine Geschichte,
eine schöne Geschichte, die erzählt wird,
in der sich, glaube ich, wirklich viele IT-Leute,
viele IT-Leute wiederfinden.
Ganz viele, glaube ich.
Und beim Übersetzen,
also habe ich dann auch schon gemerkt,
es gibt immer wieder Stellen, wo ich dann auch kurz gezögert habe,
weil es, weil mir dann irgendwie
was komisch vorkam.
Aber letztendlich
wird damit alles erzählt oder vieles
erzählt, was jetzt dann nachher auch im Handbuch quasi
etwas trockener aus, aus fachlicher
Sicht dann nochmal ausführlicher beschrieben wird.
Ja, okay.
Gut, dann würde ich sagen, es ist ein Roman, weil er einfach
eine Geschichte erzählt, könnte die
Geschichte, könnte dieser Roman
in der Wirklichkeit so stattgefunden haben
oder ist das auch zu viel Fiktion
für dich mit dabei? Also die, sagen wir mal so,
der Zeitrahmen,
den finde ich etwas herausfordernd.
Den kann ich mir so nicht vorstellen in der Realität,
aber es ist halt ein Roman. Es ist eine
Erzählung. Ja, okay.
Und die
ziehen letztendlich,
also zumindest auf der IT-Seite ziehen mehr oder weniger
alle mit.
Die Bösen sind ja dann quasi auf der
Business-Seite eher.
Ja, okay.
Ich glaube gerne, dass viele das gerne
mitmachen, aber ich vermute eher, dass auch immer
mehr eher dann welche dabei sind,
die das irgendwie doof finden oder
nicht richtig finden oder das irgendwie aus
Prinzip nicht mitmachen wollen.
Und das geht da ein bisschen unter, aber
es soll ja halt auch,
es soll halt die Geschichte erzählt werden und da finde ich
das in Ordnung. Ja, okay.
Du hast ja vorhin schon auch so ein paar
Details ausgesprochen,
Zeitfresser und so weiter. Eben hatte ich ja
noch danach gefragt, wie du das so empfunden hast.
Wenn du jetzt,
wenn dich jemand fragen würde, der
von IT vielleicht nicht so viel Ahnung
hat, ein guter Freund, ein guter Bekannter,
würdest du ihm dieses Buch
empfehlen, quasi eben,
weil es ja ein Roman ist und
sagt, Mensch, wenn du mal wissen
willst, wie das in manchen Firmen abgeht, liest du
mal dieses Buch durch? Ich glaube schon,
also im Vergleich zu irgendeinem Fachbuch auf jeden
Fall, aber auch da
ist es, glaube ich, so, man profitiert eher davon,
wenn man schon mal das alles irgendwie mitgemacht hat,
zumindest am Rande.
Ich kann mir vorstellen, dass das auch für die
Businessleute durchaus von Interesse ist, weil die dann
nämlich mal sehen, warum dann irgendwas nicht so läuft,
wie sie es sich vorstellen.
Dieses Klassische,
das ist doch aber eigentlich ganz einfach, ja,
aber aus historischen Gründen ist das eben doch
nicht so einfach.
Aber ich denke, so für jemanden, der so
von ganz, gar nichts
mit bisher zu tun hatte, ist das Problem,
dass er
auch da vieles nicht verstehen wird, warum
das denn jetzt so kompliziert ist.
Wie es in der Realität halt
dann auch ist.
Ja, okay.
Also ich habe mit
vielen Kollegen gesprochen,
Beraterkollegen an der Stelle und
die haben eigentlich immer so
ähnlich so beschrieben,
ihr Lesegefühl. Sie haben
dabei geweint und gelacht, also
gelacht unter dem Motto, das habe ich alle
schon genau so erlebt und als Berater
weiß man ja, dass diese Dinge in
vielen Firmen passieren. Die Firmen
sagen ja immer, das ist nur bei uns so schlimm und dann,
ich sage dann immer, nee, das ist überall so schlimm,
in unterschiedlichen Ausprägungen.
Also die haben geweint und gelacht und gelacht,
wie gesagt, weil sie es erlebt haben und
geweint, weil sie einfach sagen, hey, es könnte
ja, wenn man den Roman mal
richtig umsetzen könnte, könnte ja so
einfach sein, das alles sozusagen in Griff zu
kriegen an der Stelle.
Ja, also ich gehe auch davon aus, dass
das eigentlich letztendlich
in so gut wie allen Firmen so ist,
mehr oder weniger. Ich bin halt
nur nicht immer ganz sicher, ob dieses, also
ich glaube, man profitiert auf jeden Fall, wenn man
versucht, DevOps umzusetzen
bei sich, soweit es eben geht.
Aber ich denke, es gibt auch immer
wieder Szenarien, Situationen,
in denen das dann schwierig wird, das
komplett umzusetzen. Also ich bin
halt im UI-Umfeld unterwegs
bei uns. Da sehe ich
zumindest, wie knifflig
das ist, sagen wir mal,
Code, also Tests zu automatisieren,
die dann mit Browsern zu tun haben,
zum Beispiel, weil das
nicht so einfach ist.
Okay, ja. Ja klar,
also wenn es einfach wäre, könnte es ja
jeder, okay, hast du vielleicht
ein paar Beispiele, weil Browser ist ja
ein schönes Beispiel dafür. Also,
wenn man irgendwie so eine Control-
Bibliothek hat,
dann, also zumindest bei uns im Umfeld
ist das so, da werden dann die Tests automatisiert
und dafür werden dann automatisch
Screenshots erstellt und dann verglichen mit der
letzten Version. Und wenn jetzt
zum Beispiel der Browser sich entscheidet,
eine neue Rendering-Engine zu nehmen und das um
zwei Pixel zu verschieben, dann ist erstmal alles rot,
alle Tests.
Okay.
Erstmal alle und dann muss man ja sehen, ist das jetzt nur rot,
weil es sich um den Pixel verschoben hat oder hat
sich doch irgendwas geändert, sowas zum Beispiel.
Ja. Also das sind halt
so Dinge, da kommt man
glaube ich eher an seine Grenzen.
Oder, wo ich
vorher beteiligt war, da ging es um
so eine Integrationsumgebung,
in der Code
aus, also oder halt im Prinzip
Services aus verschiedenen Umgebungen
integriert wurden.
Und da haben wir sehr viele
Mocs geschrieben und
da hatte ich dann teilweise das Gefühl, dass
mit 90% der Zeit dafür draufging,
die Umgebung zu simulieren,
damit, um zu gucken, ob der
eigene Code funktioniert. Das hat jetzt nicht
explizit was mit DevOps zu tun, das ist mir schon klar,
das ist ja eher dann das,
überhaupt das Automatisieren und ich weiß auch, dass es
trotzdem sinnvoll ist, aber ich fürchte, da
kommt man irgendwo an eine Grenze,
wo es dann letztendlich doch zu teuer
wird und man vielleicht dann
doch einfach sagen muss, okay, wir laufen,
wir nehmen in Kauf, dass wir ab und zu mal
irgendwas kaputt machen und dann müssen wir es halt dann
reparieren. Ja,
das ist richtig und das ist dann natürlich auch
das Schöne an einem Roman, da muss man sich um
diese Banalitäten nicht kümmern.
Da schreibt man einfach die Geschichte weiter.
Ja, aber immerhin im Roman
kommen ja auch Szenen vor, in denen dann
sie haben schon versucht und trotzdem ist es noch
mal alles drunter und drüber gegangen.
Ja, das stimmt und das sind auch die
Realitäten wieder an der Stelle.
Also was ich
in diesem Roman so schön finde, sind die
verschiedenen Personen.
Ich habe auch wieder
von vielen gehört, die im Unternehmen
sind, die haben gesagt, wenn ich
jetzt meinen Kollegen sowieso sehe
auf dem Flur, dann weiß ich,
hey, das ist Brent oder das ist
der oder das ist der. Also die haben
eigentlich die ganzen Protagonisten
in dem Buch, finden sie wieder
in ihrem eigenen Unternehmen. Geht
dir das auch so? Ja.
Also ich
sehe das ja nun eher,
man könnte vielleicht sagen, sie sind ein wenig
teilweise zu schablonenhaft, aber sie sollen
ja halt auch einfach den Leuten
Wiedererkennungswert bieten und das
tun sie damit natürlich schon. Ich denke, niemand ist
exakt so wie in dem Buch.
Der Brent, der irgendwie an allem
mitwirbelt und
von allen gebraucht wird. Also
ich denke, so ein Brent kennt
tatsächlich jeder in der Art und Weise
vielleicht nicht so extrem. Es ist vielleicht ein bisschen
überzeichnet. Eine Sarah, die
von Business-Seite aus immer
versucht, irgendwie zu
intrigieren.
Stimmt auch.
Aber das soll natürlich
helfen, dass man die Leute wieder
erkennt. Und vielleicht freut man sich dann auch,
dass die Leute in der eigenen Firma nicht ganz so
extrem sind wie in dem Buch.
Ja, gut. Also klar, eine Freude
dann, eine ganz kleine Freude natürlich.
Und wenn man dann auf dem Flur
im Unternehmen daran vorbeigeht,
ey, guck mal, da kommt wieder die Sarah.
Kann man doch mit der Geheimsprache sprechen.
Ja, okay. Also Brent und Sarah hast du angesprochen.
Was ist
als Charakter noch für dich so hängen geblieben?
Wer ist noch so schön darstellbar?
Wer lebt in dem Buch?
Die Patty, die
irgendwie Operations sozusagen
durchzieht, aber dann auch immer
vernünftig ist und immer organisiert ist.
Solche Leute gibt es, glaube ich, auch in vielen
Unternehmen. Ich glaube, wenn es sowas nicht gäbe, dann würden
die Unternehmen ganz schön untergehen.
Und den Wes, der halt tatsächlich
auch schräg ist und sagt, was er
denkt, aber eigentlich dann doch sehr
hilfreich und häufig auch gute Ideen hat.
Also die gibt es eigentlich, sind die alle
offensichtlich.
Der CEO, der Steve, der ist
für mich zu weit weg, als dass ich das jetzt ernsthaft
vergleichen könnte.
Der Eric, der ist ja so
eine Art irgendwie
Jedi-Vater.
Das ist, glaube ich, jetzt wirklich
so eine Figur,
die, glaube ich, jetzt in der Realität dann doch eher selten
hervorkommt. Aber ich finde,
sie passt gut dazu, um so die Geschichte ein bisschen
oder um die Geschichte voranzutreiben
und
der Hauptfigur Bill
dann einfach die richtigen Stichworte zu geben.
Ja, und wahrscheinlich
auch, du hast auch gesagt, die Geschichte vorantreiben,
und immer an den richtigen Stellen
die richtigen Erläuterungen geben.
Und wenn ich mir das anschaue,
also ich habe mir das Buch,
als ich es mir durchgelesen habe, habe ich gleich angefangen,
als die immer in der Fabrik sind
und einfach diese
Geschichten erklärt werden
über die verschiedenen Arten der Arbeit
und so weiter. Da habe ich mir gleich so
Post-its dran gemacht, so kleine
Zettelchen, wo ich weiß, ich kann diese
Geschichtsteile in der Fabrik
quasi nochmal, immer mal wieder nachlesen,
weil ich das einfach schön erklärt finde,
an der Stelle.
Es passt halt auch gut, dass das gerade eine Firma ist, die tatsächlich
richtige Fabrikhallen
hat.
Das haben ja viele IT, also
Firmen im IT-Umfeld dann ja doch
eher nicht mehr, aber
natürlich ist das
da sehr geschickt und es gibt es natürlich
ja natürlich auch, also dass die IT-Abteilungen
in echten produzierenden Firmen
dann Probleme haben.
Ja, das ist richtig, das ist ja wohl
richtig, jawohl. Was ich so
schön finde, sind die vier Arten der
Arbeit. Hast du da für dich auch
Parallelen entdeckt? Kannst du das nachvollziehen?
Ja.
Ja, in meinem Umfeld ist es so, dass
wir quasi nur IT-Projekte haben,
aber ich
sehe das bei unseren Kunden durchaus,
dass das ja dann nochmal mehr oder
weniger getrennt ist und dass
IT Sachen machen muss, wo Business
sagt, wofür brauchen wir das, aber es ist halt notwendig.
Also ich sehe das im Prinzip
so auch, gerade die ungeplante Arbeit
dann im Rahmen von Änderungen gerne
vor allem. Ja.
Über die man halt erst stolpert, wenn
ja, wenn sie dann vor einem
steht und es nicht weitergeht.
Ja, dann wird das ja in dem Buch sehr schön
dann weiterentwickelt, wie man mit dieser
ungeplanten Arbeit umgehen sollte,
dass man die eliminieren sollte,
Engpass-Theorie und so weiter.
Jetzt hast du natürlich
nicht den direkten Bezug zu
DevOps. Wäre das denn, oder ist das
für dich nachvollziehbar aus dem Buch, wo das
im Buch so erklärt wird, auch wenn
es ein Roman ist?
Ja, also
ich finde das auch gut.
In meinem Umfeld
wird jetzt gerade damit begonnen
im Prinzip, das möglichst tatsächlich
zu automatisieren, zu gucken, wo bleibt es denn
hängen.
Dieses Continuous Integration,
Continuous Deployment
wird versucht anzustreben
im Rahmen des historisch machbaren
oder aus historischen Gründen
eingeschränkten.
Und da sehe ich auch, dass tatsächlich es
anscheinend wirklich gut ist, wenn eben
der Bild plötzlich nicht mehr vier Stunden,
sondern nur noch eine dauert,
um eben mal schneller zu testen,
ob das, was man da eingecheckt hat, in Ordnung ist.
Da sind wir halt noch nicht bei
irgendwie,
und bevor ich eingecheckt habe,
ist auf jeden Fall alles einmal durchgelaufen.
Aber ich sehe das auch so.
Und auch die ungeplante Arbeit,
dass es gut ist, die zu
reduzieren durch
vor allem automatisieren und vereinfachen.
Das denke ich auch.
Ja, nun wird ja in Ihrem Buch
immer die Parallele
bezogen quasi, dass die IT
ja eigentlich genauso arbeiten könnte,
genauso arbeiten sollte und organisiert
werden sollte, wie ein
Produktionsunternehmen. Und dann
kenne ich den einen oder anderen ITler, der sagt,
nein, nein, nein, nein, das ist bei uns alles ganz anders
und wir sind ja Wissensarbeiter.
Wie stehst du zu dieser
Übertragbarkeit?
Ich denke, es gibt ja nicht schwarz und weiß.
Ich denke, man kann sich
viele Anregungen
vom Band holen,
aber eben
nicht alles tatsächlich, weil es dann doch
also ich kann mir eher vorstellen, dass es
es ist ja noch mehr Kreativität dabei
als beim reinen Herstellen nachher.
Und es passieren, glaube ich, auch eher
ungeplante Dinge als beim Herstellen.
Was hoffentlich dann nach
einer Einschwingphase dann so läuft,
wie man es sich vorstellt.
Wo man dann noch optimieren kann.
Aber ich habe das Gefühl, im
IT-Umfeld sind
eher immer wieder mal etwas andere Dinge.
Es gibt immer wieder mal was Neues.
Aber
dieses
das kann ja gar nichts, ist überhaupt nicht so wie
im herstellenden Bereich. Das finde ich
eben nun auch nicht. Also ich denke schon, dass man da vieles
also zumindest, dass man sich inspirieren
lassen kann davon, ja.
Also im DevOps-Handbuch wird da noch mehr
drauf eingegangen, auf diese Enden-Cord und sowas.
Das ist vielleicht gar nicht so schlecht.
Ich denke nur, das Verhältnis
zur
Produktionsstraße ist dann doch
ein bisschen anders, was Änderungen angeht.
Also die Häufigkeit von Änderungen.
Ja, okay. Du hast das
zweite Buch angesprochen, das DevOps-Handbuch.
Du hast ja auch gesagt,
da gibt es dann nochmal so ein bisschen Erläuterungen
dazu. Das heißt, jemand,
der diese Aha-Effekte hatte
aus dem Phoenix-Project, das, was die ja auch
als, was die Autoren ja auch wollen,
der kann diese Aha-Effekte auch im DevOps-Handbuch
quasi nochmal vertiefen.
Ja, ich denke, das
Phoenix-Project, das ist
quasi zum, ja, damit die Leute sagen,
Mensch, das ist ja tatsächlich so wie bei uns.
Aber wenn man sich dann ernsthaft damit
befassen will, dann muss man eigentlich das
DevOps-Handbuch dazu lesen. Das ist dann
das, was tatsächlich die Grundlage bietet.
War eine von den, oder eins von den
beiden Büchern einfacher zu übersetzen, oder
nimmt sich das nichts?
Unterschiedlich einfach. Also das
DevOps-Handbuch ist ja nun wirklich
eher ein Fachbuch und
ich will jetzt schon mal sagen, Fachbücher
lassen sich im Allgemeinen, wenn man
das Thema halbwegs beherrscht,
leichter übersetzen. Während der,
das Phoenix-Project halt als Roman,
da ist es, dann geht es mal flapsiger zu, dann
werden lustige Sachen gesagt.
Das ist, ich finde es anspruchsvoller.
Also ich finde, bewundere auch jeden
ernsthaften Literaturübersetzer, weil das
dann nochmal ein ganz anderes Niveau ist, meiner Meinung nach.
Ja. Und das
Phoenix-Project ist jetzt keine hohe Literatur,
aber es ist, ich fand es einfach
in der Hinsicht anspruchsvoller.
Ja, wir haben jetzt eben so ein paar über die Charaktere
des Phoenix-Project gesprochen. Wir haben
über die
vier Arten von Arbeit gesprochen.
Und dann ist natürlich noch,
ich finde, ein ganz wichtiger Punkt, das sind, so ist
dieses Drei-Wege-Modell von dem,
Kim, kannst du da mal was zu erläutern?
Ja, im Prinzip
gibt es einmal den,
muss man sehen, dass man seine Arbeit
quasi in den Flow kriegt, dass die
also eben läuft, durch
Automatisierung, dass nicht die Sachen
dauernd in irgendwelchen Queues hängen und darauf warten,
dass der Nächste sich darum kümmert.
Ich glaube, das ist auch ein zentraler Punkt von diesem
ersten Weg, dass es einfach
gar nicht das Problem ist, irgendeine
Aufgabe mal schnell zu erledigen, sondern dass
das Problem ist, wenn die Aufgabe von vier Leuten
nacheinander erledigt werden muss, dass dann
die immer viel zu lange in irgendwelchen Warteschlangen
rumhängt.
Der zweite Teil ist dieses,
dass man kontinuierlich Feedback
braucht, um eben den Prozess
wiederum zu verbessern, um
zu erfahren, der, der nach mir
damit zu tun hat, kämpft immer wieder und dann
wäre es vielleicht besser, wenn wir da was anpassen könnten.
Und das dritte ist immer
kontinuierliches Lernen, Experimentieren,
wenn man irgendwelche Sachen
erforscht, dass man dabei möglichst wissenschaftlich
vorgeht und nicht nur nach Bauchgefühl.
Das sind im Prinzip diese
drei Wege, denen man nach und nach
folgen soll. Also erstmal den Flow einrichten,
Flaschenhälse erkennen, Batchgrößen
reduzieren, dann Feedback
regelmäßig einholen und das
auch berücksichtigen und
dann gucken, dass alles, was man
auch im Kleinen herausbekommen hat, dass
das für alle hilft und alle davon
profitieren können und lernen können.
Ja, okay. Wenn du jetzt diese
drei Wege so mal vergleichst
oder die mal so betrachtest,
denkst du, dass man die quasi sozusagen nacheinander
durchschreiten kann oder
wie kann ein Unternehmen
quasi mit diesen drei Wegen arbeiten?
Kannst du dir da was vorstellen?
Also ich würde mal sagen, die bauen
aufeinander auf. Also
ohne einen vernünftigen Flow
braucht man mit dem, also
helfen die nächsten beiden Schritte dann gar nicht mehr
so sehr, weil dieses
Feedback einholen ist
natürlich immer sinnvoll, aber
wenn man dadurch seinen Flow
verbessern kann und den gesamten
diesen Ablauf dann
fehlerfreier oder schneller machen kann, für
alle, dann hilft
das erst dann richtig.
Und das Lernen und Experimentieren
ist natürlich auch immer sinnvoll, aber auch da
denke ich, dass das
auch vom Flow und von dem Feedback dann
auch, also dass es
dann am besten funktioniert, wenn man das
als Grundlage hat schon.
Ja, okay.
Du hast eben so ein schönes Wort gesagt, Lernen und
Experimentieren. Nun sind
ja nicht alle Unternehmen so erfreut
drüber, dass man eine
Fehlerkultur einrichten muss, dass man
experimentiert und so weiter.
Was hast du aus dem Buch da
so ein paar Dinge rausgezogen, wo
du für dich abgerechnet hast? Das
macht eigentlich Sinn, mit so einer Kultur zu
arbeiten? Ja, ich
also ich habe das nach
dem Buch, sehe ich das noch eher, dass das sinnvoll
ist. Wir haben das auch schon bei uns
im Umfeld schon mal vorher versucht und
ich würde sagen, man kann
das, wenn man die Möglichkeit hat, auch im
Kleinen durchaus versuchen, im eigenen Team,
wenn einem das von außen auch
ermöglicht wird, aber
wenn die so insgesamt in der Firma
das nicht, sagen wir mal, honoriert
oder unterstützt wird, dann ist das natürlich
schwierig. Dann kann man das für sich vielleicht
einfach zum eigenen Vorteil nutzen oder zum
Vorteil des eigenen Teams dann was machen, aber
ich glaube, das bringt nur dann was, wenn man,
wenn das tatsächlich akzeptiert wird, auch von
außen, auch nach außen hin, also nach außen
heißt außerhalb des Teams oder außerhalb einer Abteilung
oder so. Ja. Denn das
bringt nicht so viel, wenn man irgendwie zwar selbst
dann so vorgeht und
sagt, es tut uns leid, wir
haben jetzt gesagt, wir können nur das und das machen,
das andere wird zu viel und dann gesagt wird, ist ja schön,
aber wir brauchen es trotzdem. Und man es dann
doch machen muss, notgedrungen.
Es muss schon sein, dass so weit
wie möglich das umgesetzt werden kann
und man nicht nur mit seinen eigenen zehn Leuten
oder so das versucht umzusetzen,
weil dann klappt es meistens
auf Dauer doch nicht, weil man ja mit den anderen doch
interagieren muss. Ja, ich
empfehle in meinen DevOps-Trainings
immer das Buch als Lektüre
und eigentlich würde ich mich so hinstellen
und sagen, das sollte eigentlich eine Standardlektüre
für IT-Manager
sein.
Nein. Siehst du das auch so,
abgesehen davon, dass du vielleicht als Übersetzer ein bisschen
voreingenommen bist?
Ja, würde ich auch sagen. Also natürlich
bin ich auch voreingenommen, aber
würde das auch tatsächlich jedem ans Herz
legen und durchaus auch
auch Managern ans Herz legen,
die mit IT zu tun haben, eben im
Business-Umfeld. Ja.
Vielleicht auch, um damit ein bisschen mehr
Verständnis zu wecken. Und
denkst du, dass man dann,
wenn man in den Situationen ist, die du
eben gerade beschrieben hast, dass es
eben nicht ausreicht, wenn ein Team alleine
sich so aufstellt,
wenn es quasi zum Business oder so
eben genau die Schwierigkeiten hat, dass man
dann sagt, hier, lest euch mal das Buch
durch und dann reden wir weiter. Also glaubst du,
dass man mit dem Buch auch Überzeugungsarbeit
leisten kann, konkret?
Ich glaube schon. Ich weiß, ich glaube
auch, da hängt es dann wieder von der Firmenkultur
ab, inwieweit nachher
nicht gesagt wird, ja, da habt ihr schon recht,
aber es hilft uns nicht, weil wir brauchen
es trotzdem. Und ich glaube, es mag
bestimmt Firmen geben,
die dann sagen, stimmt, habt ihr recht, lasst uns das mal
probieren. Aber ich fürchte, es gibt auch welche,
die dann sagen, das ist doch alles
Quatsch, wir brauchen das jetzt einfach und seht zu,
wie ihr fertig werdet. Ja, gut.
Gibt es noch andere Punkte, die du dir
so aus diesem Buch herausgezogen
hast, die du von dir aus noch so ein bisschen
darstellen würdest? Also ich
fand interessant, wie sie halt
beim Deployen immer am Anfang
sehr gehadert haben und nachher immer
noch gekämpft haben, aber es dann besser wurde.
Das sehe ich
bei mir im Umfeld auch tatsächlich so und
das fand ich durchaus
interessant, wie das da ablief.
Also ich meine, bei uns ist es nun nicht mehr so,
dass irgendwie dann sich morgens die Pizzaschachteln
stapeln, aber
es wurde doch früher
mehr gekämpft. Mittlerweile wird es halt besser,
weil mehr automatisiert ist, weil
tatsächlich in kleineren Einheiten
deployed wird.
Und uns hilft natürlich noch ein bisschen das in dem Umfeld, wo ich
tätig bin. Was wir machen,
wird erstmal von anderen genutzt
und das, was die machen, wird dann wiederum
von anderen genutzt und das erst geht an den Kunden,
letztendlich, wirklich ernsthaft.
Da haben wir natürlich immer noch einen gewissen
Puffer.
Wobei natürlich das Ziel ja wäre, dass
wenn ich da, ich, klar, ich kenne euer
Umfeld nicht, aber letztendlich wäre ja das
Ziel, dass ihr das, was du machst,
in einem Team passiert, was direkt mit
dem Kunden interagiert.
Das stimmt, aber dafür
sind wir zu groß, würde ich
vermuten, um das direkt zu machen.
Es gibt bei uns auch Gruppen, die
näher, also die
letztendlich, sagen wir mal, auch UI-Entwicklung
machen und trotzdem nah am
Kunden sind, aber
ist halt, ich glaube,
ab einer gewissen Größe, auch ab einer gewissen,
sagen wir mal, Entwicklungsgröße,
wird es dann tatsächlich schwieriger, weil
zumindest ich sehe dann durchaus, dass es auch
von Vorteil ist, wenn man
mehr Schichten hat, in denen das
vorgegeben ist, in denen, wenn man sagt,
die Buttons müssen ein bisschen anders werden,
dass dann auch alle Buttons anders werden und man
nicht die halben Entwicklermannschaft anschreiben
muss, dass sie jetzt alle bitte was anpassen sollen.
Also,
da,
ich glaube, irgendwann wird es dann schwierig,
einen guten Weg
zu finden zwischen, es muss alles
exakt vorgegeben
sein, wie etwas umzusetzen ist
und
es wäre schön, wenn das
halt nah am Kunden ist. Da muss man irgendwie
einen Zwischenweg finden, der, glaube ich,
nicht immer geht.
Ja, ich glaube auch, dass es gar nicht
den Zwischenweg gibt oder den
goldenen Mittelweg. Das muss ein Unternehmen
für sich herausarbeiten.
Muss man auch einfach mal ein bisschen organisatorisch
probieren und dann glaube ich auch, dass es
auch immer wieder so Pendelbewegungen gibt.
Das heißt, man probiert das mal aus.
Man hat ein paar Erkenntnisse, man hat Erfolge,
man hat auch Restriktionen, die man
dann eben bemerkt und dann muss man eben
gegensteuern oder weiterentwickeln
und denke mal,
das ganze Thema agile Entwicklung
und das ist ja die Basis von DevOps,
zumindest im Development-Bereich,
ist ja, glaube ich,
auch das Thema, wie skaliere ich das?
Wie gehe ich jetzt mit mehr als neun oder
zehn oder elf Entwicklern um?
Das, glaube ich, ist ja auch die große Herausforderung
für viele andere Unternehmen, wenn ich noch
nicht mal den Betrieb mit dazu nehme.
Also rein nur, wie skaliere ich agile
Entwicklungsteams, wenn ich wirklich ein paar mehr
Leute dabei habe?
Ja, also ich habe schon das Gefühl, dass es sinnvoll ist,
dass die möglichst autark agieren können.
Aber wenn man halt in einem
Umfeld tätig ist, in dem man
noch viel mehr beachten muss
oder in dem noch viel mehr Leute mitspielen,
dann wird es halt schwierig.
Oder wenn es darum geht, zum Beispiel
eine Barrierefreiheit sicherzustellen,
dann ist es natürlich
gut, wenn die dann trotzdem auf alles
achten und nicht sagen, ach, das machen wir nächstes Mal, weil
das können wir jetzt gerade nicht.
Ja, okay. Wenn ich mal ein bisschen auf das
schaue, was du in deiner
Brotarbeit genannt
tust, wenn du an deine Kollegen
denkst oder auch an dich,
würdest du das Buch oder hättest du das Buch gelesen
oder gekauft
oder glaubst du, dass das halt ein Buch ist, was
für einen Entwickler vielleicht gar nicht mal
so interessant ist?
Ich glaube,
interessant ist es. In meinem
speziellen Umfeld sehe ich
jetzt nur eher, dass
das jetzt
auch tatsächlich, was da drin steht, mehr oder
weniger, sagen wir mal, verfolgt wird. Also
jetzt weniger das wirkliche DevOps,
aber so ein Continuous Delivery,
dass das angestrebt
wird und anscheinend auch gut ist.
Ja, okay, gut.
Hast du noch andere Punkte, die so für dich,
die du rausgezogen hast, die du auch vielleicht mit deinen
Kollegen besprochen hast, die du in deiner Arbeit
eingebracht hast?
Also ich habe mich neulich mit unserem Architekten
unterhalten, gerade da über das,
über den Podcast auch und
über das DevOps und da
kamen wir halt auch drauf, dass
das halt gewisse Grenzen
gibt, was ich vorhin schon sagte mit UI-Tests.
Ist alles möglich, aber wird
dann halt irgendwann ganz schön teuer.
Wo ich mich dann frage,
ist das dann einfach so teuer, wenn man es
ordentlich machen will oder muss man in Kauf nehmen,
dass man dann irgendwo dann unsauber wird?
Das geht jetzt in dem Buch natürlich ein bisschen
unter, weil da geht es um dieses schwierige,
schwierige Aspekte weniger.
Ja, ja.
Das sind ja eher Sachen, die sich leichter machen
lassen. Ich könnte mir auch vorstellen,
dass das dann, dann gibt es vielleicht schon
einen Business Case, der irgendetwas durchrechnet,
aber der geht ja immer nur von irgendwelchen Annahmen
aus. Das heißt, vielleicht wird es
dann so sein, dass ein Team sich so entscheidet,
also wenn sie autonom entscheiden
können und ein anderes Team oder
ein anderer Bereich wird anders entscheiden.
Also das würde ich jetzt mal so tippen,
weil ich glaube nicht, dass es genau die Wahrheit
gibt, die man auch im Vorfeld
genau berechnen kann.
Ja, natürlich. Also
ich denke, das Autonome, das finde ich
gut. Das scheint auch bei uns
so mehr oder weniger zu funktionieren
oder das zumindest
hingenommen wird, wenn dann die
Product Owner
aus einzelnen Bereichen sagen, das ist
gut, das machen wir. Das hört sich zwar auch gut an,
aber das können wir einfach im Moment nicht machen. Und dann
wird das auch akzeptiert. Das mag
dann aber eher an der Kultur liegen der Firma
und weniger daran,
wie gut man dadurch vorankommt, weiß ich natürlich nicht.
Ja, wir haben ja schon einiges
rausgezogen aus dem
Phoenix Project. Gibt es noch andere
Punkte, die du hast, Thomas? Vielleicht auch aus
dem DevOps-Handbuch? Also aus
dem Phoenix Project finde ich
eigentlich gut und ich glaube auch
hilfreich in der täglichen Arbeit ist, dass
versucht wird, Aufgaben sichtbar
zu machen. Dass man sich wundert,
warum irgendwas denn dann zwei Wochen dauert, wo das
doch nur eine kleine Änderung ist
und dass man das mal zeigt,
aus wie vielen Schritten das besteht, wie viele Leute
beteiligt sind, damit dann auch
vielleicht eben die Stakeholder
aus dem Business sehen, oh, okay, ja,
das ist jetzt doch nicht so einfach, wie ich dachte.
Das
ist, glaube ich, was, was
helfen kann. Zumindest kann man
sich dann besser fühlen, wenn man das mal gemacht hat und
die anderen sagen, ist mir egal, ich will es trotzdem,
dann kann man zumindest, ist man sich sicher,
dass man sich nicht da vertut und sich
nicht wundert, warum das alles so lange dauert.
Und
die technischen Schulden, dass
man die tatsächlich angehen sollte, das ist, glaube
ich, eher aus dem DevOps-Handbuch,
dass man, wenn man mal schnell was
macht, das ist in Ordnung, aber
das kommt irgendwann wieder meistens
und dann tut es richtig weh.
Das sehe ich auch tatsächlich bei mir im Umfeld.
Ja.
Man baut Sachen ein, die irgendwie
in dem Moment gerade geholfen haben,
aber sich im Nachhinein
nur ganz schlecht wieder rausnehmen lassen und dann
alle ärgern. Und die
muss man regelmäßig, glaube ich, angehen, um die
abzuarbeiten. Ja,
was ich so an dem Begriff der technischen
Schulden auch so schön finde, ist,
dass man damit,
wenn das Business
darauf eingeht, dass man denen damit das
erklären kann. Also ganz
klar, Business, wenn du das haben willst,
lieber Stakeholder, das können wir machen,
aber wir bauen eben Schulden auf damit.
Das ist genauso, als wenn du dir jetzt ein Haus
kaufen würdest. Du kannst dir Geld
von der Bank leihen, dann musst du einfach
Zinsen bezahlen. Du hast Schulden, die du
abstottern musst. Und wenn du kein Geld
verdienst, dann wird das Haus auch gepfändet
und so weiter. Also dieser Vergleich
zwischen technischen Schulden und der
Realität finde ich sehr, sehr schön,
Idee. Und ja, das sehe ich
wie du. Das wird sehr schön beschrieben,
sehr schön plastisch beschrieben.
Ja, und was ich auch einen tollen
Schritt fand, da weiß ich
nicht, wie realistisch das machbar ist, ist,
dass die mal eine Zeit lang sagen, wir machen gar nichts
Neues. Wir bauen jetzt mal zwei Wochen lang oder so,
wie lange das war, alles ab. Oder versuchen
zwei Wochen lang nur Sachen zu erledigen, die
wir schon immer mal machen wollten oder immer mal
machen mussten eigentlich, um
damit eben dann ordentlich Schulden abzuarbeiten.
Irgendwann geht es wahrscheinlich, kommt man nicht
drum rum, dann wieder neue Sachen zu machen. Aber
ich denke, das ist
was, was ich zumindest sehr
charmant finde und sehr hilfreich.
Also
ich habe das einmal erlebt bei
einem Scrum-Team, die
wirklich einen Sprint von zwei Wochen, also
das war wirklich eine sehr überschaubare
Größe, dass sie in einem
Sprint von zwei Wochen sich mal nur
um die Problems gekümmert haben.
Also nur darum mal gekümmert haben,
Bugs zu beseitigen,
die sie immer wieder mit Workarounds gefixt
haben und wo sie gesagt haben, wenn wir da mal
Zeit hätten, dann könnten wir das mal
richtig beseitigen. Und die Zeit hat
man ihnen in der Entwicklungsphase
nicht gegeben. Aber als dann so ein gewisses
Grundgerüst da war, da haben sie wirklich
dann mal in einem Sprint von
zwei Wochen wirklich nur
Storys bearbeitet, die eben diese klassischen
ITIL-Problems beseitigt
haben oder nur daran gearbeitet.
Und das Schöne fand ich jetzt auch
im Vergleich dazu,
das ist im Buch ja auch so beschrieben,
dass das quasi auch aus dem Team herausgekommen
ist. Das Entwicklungsteam hat keine
Ahnung von ITIL gehabt. Die haben sich nicht um
IT-Service-Management gekümmert.
Die haben aber einfach für sich
gesagt, wir haben jetzt hier wieder einen Bug,
den haben wir beseitigt, Quick und Dirty,
weil wir ihn schnell beseitigen müssen.
Lieber PO, das sollten
wir mal in Ruhe angehen und eben
genau diese Schulden beseitigen.
Also ein Beispiel habe ich so
für diese zwei Wochen.
Ob das Team so ganz glücklich war, sich zwei Wochen
nur darum zu kümmern, das weiß ich jetzt gar nicht
mehr, weil man ja eigentlich
versucht, das immer so ein bisschen zu mischen an der Stelle.
Ja, das ist natürlich
auch eine Variante, dass man tatsächlich, wenn man das
kann, so und so viel Prozent
der Kapazität
der eigenen dafür dann
pro Sprint beiseite zu legen
und dann das immer wieder was, also
quasi kontinuierlich was zu machen.
Das ist, denke ich, die andere Variante. Aber ich könnte
mir vorstellen, dass man so, und wenn man es nur einmal
im Jahr macht, irgendwann in der Zeit,
wo dann gerade mehr oder weniger
es etwas ruhiger ist,
dass man dann einfach Sachen mal abarbeitet.
Ich glaube, das tut einem auch gut. Natürlich ist das
spannend, da neue Sachen zu machen, aber
ich glaube, man fühlt sich danach richtig gut, wenn
man dann mal Sachen ordentlich gemacht hat
wieder. Ja, also ich habe
schon einen oder anderen Entwickler getroffen,
der gesagt hat, technische Schulden
sind mir suspekt. Also der fand
diesen Begriff gar nicht gut an der Stelle, aber ich glaube,
das sind ganz wenige Entwickler, die so denken.
Ja, ich glaube aber, also der
Begriff ist, da kann man bestimmt auch darüber diskutieren,
aber ich glaube, was dahinter steckt, das dürfte
fast alle stören. Ja, okay.
Ja, klar, natürlich. Also dieses,
mach mal schnell,
das stimmt schon so.
Ja, und was
auch noch ein Aspekt von dem Buch ist, ist dieses
Change Management, was
manchmal dann vielleicht ein bisschen eskaliert,
aber was
in einem gewissen Rahmen, glaube ich, tatsächlich
notwendig ist, um eben
zu vermeiden, dass der eine eine Änderung
macht, die dann alles andere
kaputt macht, aber
ihm ist das gar nicht bewusst vorher.
Ich glaube, das kann man nicht ganz
vermeiden, weil sonst landet man
nachher in einem wirklich bürokratischen Monster.
Aber so in einem gewissen Rahmen
ist das, denke ich, sehr hilfreich und kann
viele Situationen entschärfen.
Ja, ich glaube, dass du mit dieser Aussage,
die ja von einem Entwickler
kommt, vielen
Leuten aus dem IT-Service-Management
und IT-Umfeld aus der Seele gesprochen hast,
weil die natürlich
sich jetzt auch fragen, ja, das ist ja wunderschön,
alles agil, alle schöne bunte Zettel,
alles visuell, aber wir brauchen auch
ein paar Prozesse und das glaube ich auch, das ist einer
der Prozesse, der unheimlich wichtig
ist und den man nicht einfach abschaffen
kann. Also selbst wenn man die Verantwortung
in Teams gibt, ein paar Sachen
muss man schon noch über Prozesse
regeln und ja, das ist, denke ich, einer
der Kernprozesse, die man
trotzdem geregelt kriegen muss, auch
wenn man die Teams eben autonom
aufstellt und eine andere
Art der Arbeit propagiert.
Ja, ich glaube, das ist auch so ein bisschen, also das
jetzt im Phoenix-Projekt kommt das, glaube ich, mehr oder weniger
kaum vor, so ein Scrum of Scrums oder
wie das manchmal genannt wird.
Das ist ja auch nicht Thema des Buches, aber
auf jeden Fall muss, glaube ich, jede
Firma oder jede Organisation
irgendwie für sich einen Weg finden,
diese möglichst
autonom agierenden Sachen trotzdem
zu organisieren.
Das ist richtig, das stimmt, ja.
Und klar, man muss natürlich die Dinge auch
zusammenbringen und das ist eben im Kleinen
wie im Großen zu tun. Also insofern,
ja, die Frage ist, wie man es
organisiert, aber du hast auch recht, im
Buch war es nicht das Thema und unser Thema
ist ja das Buch. Also insofern,
ich glaube, wir haben ziemlich viel,
ähm, angesprochen aus dem Buch und
ich hoffe auch, dass wir, ähm,
dem einen oder anderen, der das Buch noch nicht gelesen
hat, so ein bisschen das in den Mund fässrig
gemacht haben. Was mich eben
bei diesem Buch begeistert hat,
war, dass ich diesen Aha-Effekt
hatte. Den Aha-Effekt, den die vier Autoren
sehr schön zu Anfang in ihrem Vorwort
beschreiben, dass die alle irgendwann
so einen Aha-Effekt hatten und gesagt haben,
hey, wir müssen das anders
machen. Und, ähm, ich hatte
quasi nach dem Lesen des Buches meinen
Aha-Effekt. Ähm,
wie sieht das bei dir aus? Hast du auch deinen Aha-Effekt
bei der Übersetzung gehabt oder
hast du den vielleicht schon vorher gehabt?
Ich,
wir haben vorher schon zum Teil agil
gearbeitet. Da hatte ich schon viel
Aha. Ähm, und
beim Automatisieren von Tests
und all solchen Sachen, das ist
also beim Buch selbst jetzt gar nicht so
sehr, da hatte ich eher Wiedererkennungseffekte,
dass ich gedacht habe, hey, das kennst du doch von irgendwo her.
Und wenn es vor zehn Jahren ist oder so, also ich habe
auch schon in kleinen Firmen vorher gearbeitet, da
ist das dann nochmal anders Aha gewesen.
Und ich habe, ich habe jetzt im Nachhinein
diesen Aha-Effekt, wo ich in meinem Umfeld sehe, wie
Dinge aus, die in dem Buch vorkommen,
auch in
meinem Umfeld versucht werden, umzusetzen.
Und
das finde ich dann, da denke ich,
ach, guck mal an, das kenne ich doch irgendwo her.
Ja, okay. Also bei mir ist das jetzt so ein bisschen
verzögert, weil ich selbst
weniger
damit zu tun hatte bisher, sagen wir so.
Aber ich kannte halt von
früher vieles und ich sehe jetzt in meinem Umfeld,
dass durchaus da Aktivitäten,
Ablaufen, die dem aus dem
Buch oder aus dem DevOps-Handbuch auch
durchaus entsprechen. Ja,
okay. Ja, das ist doch schön. Also insofern ist
das schon ja schon ein bisschen Bezug zur Praxis
oder vielleicht nicht nur ein bisschen, sondern ein bisschen mehr auch.
Gut, das heißt also,
einwandfreie
Kaufempfehlung für das Buch,
wie gesagt, auch wenn du,
wenn du, für beide ja eigentlich,
für beide, also das denke ich, müssen wir mal
festhalten. Wir haben zwar das Phoenix Project
als Aufhänger genommen, aber ich glaube, es ist
auch rausgekommen, dass das Phoenix Project,
diese Aha-Effekte produziert,
die die Sache einfach ein bisschen plastischer
und lesbarer näherbringt
und wer wirklich tiefer einsteigen will
und Praxis haben will, der braucht natürlich
das DevOps-Handbuch. Ja, das
auf jeden Fall. Also ich würde das
Phoenix-Handbuch tatsächlich jedem ans Herz
legen, eigentlich, der mal länger im IT-Bereich
gearbeitet hat oder mit
IT zu tun hat. Das DevOps-Handbuch
ist, glaube ich, also
wenn man sich ernsthaft damit danach dann damit
befassen will, dann ist das DevOps-Handbuch auch
unvermeidlich, unverzichtbar.
Aber dann wirklich, weil wenn man
damit was, wenn man sich da richtig mit,
wenn man da richtig einsteigen will.
Ja. Gut.
Thomas, dann danke ich
dir für diese schöne dreiviertel
Stunde. Ich fand das sehr, sehr kurzweilig.
Ich glaube, das haben wir sehr gut hinbekommen.
Und würde sagen,
viel Spaß und Erfolg mit
den weiteren Büchern. Ich hoffe, da kommt noch
ein bisschen was vom Gene Kim
für das Thema DevOps. Und
dann bis zum nächsten Mal.
Ja, vielen Dank für die Einladung. Ich habe mich auch
sehr gefreut.
Vielen Dank.

Folge 7: DevOps bei der SwissRe

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

DevOps in der Praxis: Wie wird DevOps bei einem der größten Rückversicherer der Welt umgesetzt? Wir haben Tobias Weinmann zu Gast im Podcast.

Inhalt

  • Vorstellung von Tobias Weinmann und seiner Rolle bei Swiss Re
  • Definition und Bedeutung von DevOps-Transformation
  • Die „Three Ways“ im DevOps-Kontext: Flow, Feedback, und kontinuierliches Lernen
  • Einsatz und Herausforderungen von Cloud-Technologien bei Swiss Re
  • Der Ansatz von Swiss Re zur DevOps-Transformation, inklusive Bottom-Up und Top-Down Strategien
  • Konkrete Beispiele für DevOps-Initiativen: Value Stream Mapping, Lean Change Management, Minimal Viable Processes
  • Diskussion über die Rolle von Technologie und Kultur in der DevOps-Transformation
  • Der Umgang mit Legacy-Systemen und neuen Applikationen im Kontext von DevOps
  • Die Rolle der Cloud im DevOps-Ansatz von Swiss Re
  • DevOps als Balance zwischen IT-Service-Management, Lean-Management und agilem Vorgehen
  • Gesamtbild der DevOps-Reise bei Swiss Re

Shownotes

  1. DevOps-Transformation bei Swiss Re
  2. „The Phoenix Project“ Buch (https://itrevolution.com/book/the-phoenix-project/)
  3. „DevOps Handbook“ Buch (https://itrevolution.com/book/the-devops-handbook/)
  4. Swiss Re Unternehmen (https://www.swissre.com/)
  5. Definition und Prinzipien von DevOps
  6. Agile Methoden und Scrum
  7. Cloud-Technologien in der Versicherungsbranche
  8. IT-Service-Management
  9. Lean-Management
  10. Minimal Viable Architecture und Prozesse
  11. Datenbankmanagement und Automatisierung
  12. Continuous Integration und Continuous Deployment (CI/CD)
  13. Value Stream Mapping
  14. Lean Change Management

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Hallo und herzlich willkommen zum DevOps-Podcast auf die Ohren und ins Hirn.
Ich begrüße Sie. Mein Name ist Dirk Söllner.
Wir haben hier heute zu Gast den Tobias, der von der Swiss Re sich gleich vorstellen wird,
wenn ich sage, wir ist das Alex Lichtenberger, mit dem ich gemeinsam diesen Podcast erstelle.
Also insofern würde ich sagen, Tobias, stell dich doch einfach mal bitte kurz vor.
Ja, hallo. Mein Name ist Tobias Weinmann.
Wie Dirk schon gesagt hat, ich arbeite für einen der größten Rückversicherer weltweit bei der Swiss Re.
Und ich habe dort die ehrenvolle Aufgabe, mich Vollzeit dem Thema DevOps zu widmen,
was ich seit ein bisschen mehr als einem Jahr jetzt mache und befinde mich dort auf einer sehr spannenden Reise.
Oder wir als Unternehmen befinden uns dort auf einer sehr spannenden Reise.
Ein bisschen zu meinem Hintergrund.
Ich bin schon sehr lange bei der Swiss Re, habe einige Sachen gesehen.
Ich habe in der Entwicklung, Softwareentwicklung angefangen und hatte dann,
von diversen Verantwortlichkeiten auch im betrieblichen Umfeld,
war unter anderem verantwortlich für die ganzen Entwicklungsplattformen, Versionskontrollsysteme, CICD-Systeme und so weiter.
Und ja, bin jetzt, wie gesagt, dort gelandet, DevOps Transformation Lead in einer vergleichsweise großen IT-Organisation.
Und vielen Dank, Tobias. Herzlich willkommen auch von meiner Seite.
Mein Name ist Alex Lichtenberger.
Vorstellen muss ich mich, glaube ich, nicht mehr.
Heute haben wir ja das Thema DevOps Transformation bei der Swiss Re.
Das heisst, ein Praxisbeispiel aus der Unternehmenswelt.
Und ja, bevor wir da reingehen, wir haben ja immer zu diesem Running Gag oder die Standardfrage an unsere Gäste,
dieses Mal auch an dich, Tobias.
Was verstehst du unter DevOps Transformation?
Unter DevOps, kann man das überhaupt definieren, oder wie würdest du das definieren?
Ich versuche es mal mit nur zwei Worten.
Nachhaltige Geschwindigkeit.
Also nicht Geschwindigkeit oder Schnelligkeit um jeden Preis, sondern,
und auch nicht sicher und stabil, egal wie lange es dauert, sondern eben beides zusammen.
Also für mich ist DevOps eigentlich ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oft Janeiro.
Wird es auch mit der Idee assoziiert, Optimierungen für Kosten?
Wird es auch mit der Idee assoziiert, Optimierungen für Kosten?
Sehe ich aber nicht so.
Ich sehe wirklich Optimierungen für der Geschwindigkeit.
Aber halt nicht um den Preis von Qualität, Sicherheit und Compliance.
Und wenn ich noch ein bisschen weiter ausholen darf.
Also ich sehe, also den Startpunkt, wie muss auch so in der Lektüre viel sieht wirklich auf diesem Cor.
Country Konflikt.
Also wenn man mal die Top-Prioritäten aus IT-Executive-Sicht anschaut,
es ist natürlich Rapid Change, also wir wollen eigentlich schnelle Veränderung,
aber gleichzeitig wollen wir Stabilität, Zuverlässigkeit, Sicherheit und so weiter.
Also so die funktionalen und nicht-funktionalen Aspekte.
Und jetzt ist es aber typischerweise so, dass halt die Leute, also Teile der Organisation,
sich eher in diese Richtung Rapid Change orientieren
und andere Teile in der Organisation Richtung Stabilität, Zuverlässigkeit und Sicherheit.
Und wenn halt nicht da alle wirklich an einem Strang ziehen,
findet man sich möglicherweise dann halt in so einer Abwärtsspirale,
die ja auch oft beschrieben wird in einem DevOps-Kontext.
Also man macht dann tatsächlich die schnelle Veränderung,
aber die Systeme werden eben nicht stabiler und zuverlässiger und sicherer,
sondern das Gegenteil ist der Fall.
Und dann werden oft die Kontrollen hochgefahren
und im Endeffekt wird man eigentlich langsamer und nicht schneller,
wenn man nicht die Sachen wirklich konsequent gemeinsam adressiert.
Und wenn man auf die Three Ways schaut, für all die,
die das Phoenix Project oder das DevOps Handbook gelesen haben,
das sind für mich auch sehr zentrale Themen.
Also der erste Weg.
Die Principles of Flow oder auch anders gesagt,
die systemische Sicht, Systems Thinking.
Da geht es natürlich um Sachen wie Limit, Work in Progress oder Release Cadence.
Aber für mich ist da wirklich ein zentrales Thema,
auch mit Silos zu brechen und wirklich zu schauen,
dass sich halt alle an einem schnellen Fluss orientieren.
Also dass man wirklich auch sagt,
Sicherheit oder Compliance sind wichtige Themen,
aber nicht zu jedem Preis.
Also nicht Hauptsache sicher, egal wie lang es geht,
sondern der Fluss muss wirklich gewährleistet sein.
Und der zweite Weg, Principles of Feedback.
Da geht es ja darum, dass man möglichst schnell eigentlich Feedback gibt,
bei allem, was man tut, dass möglichst früh die Rückmeldung passiert.
Also Negativbeispiel.
Man merkt erst, dass ein Produktionssystem nicht mehr funktioniert,
wenn der User halt anruft und sagt, da tut was nicht.
Also das möglichst früh bekommendes Feedback.
Und darunter liegt für mich eigentlich die Idee,
dass man ein möglichst sicheres Environment schafft.
Also ein Environment, wo man schnell Änderungen machen kann,
ohne Angst zu haben, dass irgendwas zerbricht
und nachher nicht mehr funktioniert.
Und der dritte Weg, Third Way,
Continued Learning and Experimentation,
ist für mich wahrscheinlich der zentralste Punkt,
bei DevOps, weil ich glaube, dass wir uns in einem Environment bewegen,
das zunehmend komplex wird, wo wir uns immer schneller bewegen
und wo es eine gewisse Unsicherheit gibt.
Was meine ich damit?
Cloud ist ein Riesenthema bei uns, bei der Swiss Re,
aber auch, würde ich sagen, überall in der Industrie.
Und Cloud bietet viele Möglichkeiten, aber es macht gleichzeitig die Systeme
auch komplexer, weil sie halt verteilter werden.
Wenn wir uns Microservices-Architekturen zum Beispiel anschauen,
da gibt es viele Möglichkeiten, aber es gibt auch viele neue Herausforderungen.
Und die Unsicherheit, die ich erwähnt habe,
die bezieht sich sowohl auf das technologische Umfeld
als auch auf das Business-Umfeld.
Dort muss man auch eben flexibler sein.
Man muss sich möglichst schnell den neuen Gegebenheiten anschauen.
Man muss sich ganz schnell anpassen können.
Jetzt habe ich ein bisschen weit ausgeholt.
Um noch einfach zu sagen, wie wir DevOps interpretieren,
da ist ganz wichtig, dass wir es halt als ganzheitliches Konzept sehen.
Also wir versuchen uns immer entlang den Dimensionen
Culture, People, Process und Technology zu bewegen.
Da gibt es auch ein paar interessante Sichtweisen.
Oftmals ist es halt so, dass man es ein bisschen zu einseitig betrachtet.
Dass man sich zu sehr auf die Technologie konzentriert
oder vielleicht zu sehr nur auf den kulturellen Aspekt.
Man sollte wirklich versuchen,
es ist unsere oder meine Meinung,
halt wirklich entlang all dieser vier Dimensionen zu gehen.
Danke, das fand ich eine sehr spannende Beschreibung.
Also was ich herausgehört habe,
also Ziel nachhaltiger Geschwindigkeit,
dann die Umsetzung über die Three Ways
und dann eben, dass ihr auch,
weil viele sehen ja DevOps nur als Tool-Angelegenheit,
dass du eigentlich sagst,
schlussendlich müssen alle Bereiche stimmen,
People, Process, Technology.
Und was jetzt auch,
ein bisschen hast du es schon angetönt,
das Warum, du hast es ein bisschen erwähnt,
Cloud ist wichtig bei euch
und dass sich die Änderung,
also immer mehr Änderungswünsche.
Und die Frage wäre jetzt,
wenn wir so den Link noch mehr zur Swiss Re machen,
was waren dann für euch schlussendlich
die Treiber, oder dass eine IT der Swiss Re gesagt hat,
okay, wir möchten jetzt uns Richtung DevOps bewegen.
Tobias.
Also ein Treiber ist sicherlich die Agilität,
also sich möglichst schnell verändernden Voraussetzungen
anpassen zu können.
Und in dem Zuge halt auch neue Ideen auszuprobieren,
möglichst schnell,
und die dann auch möglichst schnell wieder verwerfen,
so sie sich dann als falsch,
oder als nicht richtiger Pfad rausstellen.
Und dann haben wir,
also wir sind wie gesagt im Rückversicherungsgeschäft tätig.
Wir haben nicht jetzt,
wir haben zwar auch Consumer Exposure,
aber das ist nicht so wesentlich.
Wir arbeiten eigentlich mehr im B2B Umfeld.
Aber unsere Kunden,
also zum Beispiel Erstversicherer,
oder größere Unternehmen,
die sind natürlich viel stärker,
oder sind auch sehr stark,
oder noch stärker als wir,
in dieser digitalen Transformation.
Dort ist der Druck viel größer,
und die Veränderung findet statt.
Und wir müssen da mitgehen.
Also wir wollen eigentlich dann stetig dort am Ball bleiben.
Und gleichzeitig eben auch neue Ideen direkt an den Markt bringen.
Also vielleicht auch dann direkt wirklich im B2C Business
noch mehr Fuß fassen.
Das ist bei uns im Moment noch eher kleiner.
Und was halt bei uns intern,
um den Weg gehen zu können,
organisieren wir uns auch neu innerhalb der IT
und auch über die IT hinaus.
Also das IT wächst eigentlich näher ans Business ran.
Wir gehen weg von Shared-Funktionen.
Also wir hatten eine sehr dicke Shared-Infrastruktur-Organisation,
die jetzt eigentlich,
wo wir uns immer mehr zu einem föderierten Ansatz entwickeln,
weil ich die, wir sagen den Business-Domain ITs,
also die IT-Organisationen,
die den entsprechenden Business-Domains zugeordnet sind,
wo die wirklich End-to-End-Verantwortung
für den Betrieb von den IT-Lösungen übernehmen.
Und um das zu ermöglichen,
müssen wir eigentlich DevOps-Prinzipien umsetzen im Unternehmen.
Okay, du hast eben davon gesprochen,
Transformation Lead,
auf dem Weg digitaler Transformation.
Habt ihr ein Ziel?
Wie weit seid ihr?
Seid ihr schon fertig?
Kannst du da mal ein bisschen was zu sagen?
Also fertig sind wir sicher noch nicht.
Und ich persönlich bin halt auch immer,
ich sage, die Leute,
die schon mutmaßlich ein ziemlich komplettes Bild von dem Ganzen haben,
die challenge ich eigentlich immer.
Weil ich sage, wir können das noch gar nicht so genau sagen,
wie das denn in einem Zeithorizont von ein bis zwei, drei Jahren aussieht.
Oder?
Weil das alles in Bewegung ist
und wir auch noch sehr viel lernen müssen, oder?
Also wir können, die Zeit ist einfach nicht die,
dass wir jetzt sagen können, es ist alles schon klar.
Wir müssen nur das und das und das machen
und dann sind wir genau dort, wo wir hinwollen.
Also von dem her, um deine Frage zu beantworten,
wir sind mittendrin und wir wissen,
dass es noch eine geraume Zeit so weitergehen wird
und dass auch eben diese hohe Geschwindigkeit an Veränderungen,
die wird mehr zum Alltag.
Also wir werden uns mehr in diesen Schnellwechselmodus gewöhnen,
als dass wir dann irgendwann sagen, jetzt sind wir fertig mit dem,
wann kommt die nächste große Transformation?
Wie reagiert denn das Business da drauf?
Weil ich häufig, wenn ich in Scrum-Trainings bin
und auch in den Projekten drin bin,
man ja der IT vorwirft, dass sie nicht liefert,
dass sie keinen Ziegel hat
und letzten Endes ist ja das genau,
was ich bei dir raushöre,
aktuell der Fall.
Zumindestens könnte man euch vorwerfen,
ihr wisst gar nicht, wann ihr fertig seid.
Insofern wieder mal planlos.
Naja, das kommt dann auch drauf an,
auf was man das jetzt anwendet, diese Aussage.
Also digitale Transformation, glaube ich,
sind wir uns einig, das geht ja durch das ganze Unternehmen.
Das ist ja nicht nur ein IT-Thema.
Und ich gebe dir schon recht,
also es ist nicht so jetzt unbedingt,
dass das Business jetzt sagt,
jetzt lass uns hier das zusammen machen
und jetzt wissen wir schon genau, wo es hingeht,
sondern ich habe da oft das Beispiel mit dem,
wenn es darum geht, jetzt gerade wieder in einem DevOps-Kontext zu sagen,
hey, lass uns doch mal die Release-Cadence erhöhen.
Lass uns doch mal nicht Quarterly-Releases machen,
sondern jeden Monat oder alle zwei Wochen
oder wenn es geht, noch öfters.
Und oft ist halt eine Reaktion auf der Business-Seite dann,
ja, eigentlich wollen wir eher weniger Releases,
weil Release bedeutet für uns eigentlich Aufwand.
Also wir müssen dann irgendwie,
werden dann zum User-Acceptance-Test eingeladen,
müssen vielleicht noch eine Ausbildung machen
und dann, wenn es übers Wochenende,
dann braucht es ein ganzes Wochenende,
um das Deployment zu machen
und am Montagmorgen gibt es dann wieder Probleme.
Also Bottom-Line-Release wird assoziiert mit Arbeit, Aufwand und Problemen.
Und da, das ist auch ein Teil meiner Aufwand,
meine Aufgabe halt auch zu erklären,
dass mittelfristig eigentlich eine höhere Release-Cadence bedeutet,
dass die Releases kleiner werden, weniger spürbar,
weniger Risiko mit sich bringen
und dann eben sich nicht so anfühlen,
wie sich jetzt so ein Quarterly-Release anfühlt,
wo man dann das Gefühl hat,
hey, ich möchte es eigentlich eher weniger als mehr machen,
sondern dass es sich eher so anfühlt,
es wäre dann ein Zielbild,
wie ich eigentlich Releases auf einem Mobile-Device wahrnehme, oder?
Ich nehme da immer mich als Beispiel.
Am Anfang auch gesagt,
ja, hm, das verschiebe ich mal lieber,
bevor ich da irgendwie das Knöpfchen drücke
auf meinem Mobile-Device,
um das Upgrade machen,
aber mittlerweile ist das ja was,
wo man quasi automatisch macht
und wirklich im laufenden Betrieb,
weil man weiß,
die Applikation verändert sich nicht fundamental
von einem Release zum anderen.
Also jetzt nur eine Anekdote,
ein Beispiel,
aber das ist eben auch das,
wo zustimmen,
ja, das Business und die IT
muss da noch mehr zusammenwachsen,
aber das ist eben auch ein Teil,
ein Bereich, wo DevOps helfen kann.
Aber zeigt auch,
dass ein Teil deiner Arbeit ist ja auch,
dann mit den Leuten sprechen,
mit den Stakeholdern sprechen
und aufzeigen, was DevOps bedeutet
und das bei ihnen zu bekommen.
Genau.
Ja, und wenn wir jetzt
über die DevOps-Transformation
bei der Swiss Re sprechen,
also wie,
also du hast erklärt, schön,
die Treiber auch.
Warum ist das überhaupt ein Thema
bei einer Swiss Re?
Bei euch ist es natürlich anders
wie jetzt bei anderen Unternehmen,
weil es ist ein Business-to-Business-Umfeld
und ihr habt aber auch,
sagen wir, die interne IT-Perspektive,
sagen wir mal,
ein bisschen weg von,
sagen wir, dem Shared Service,
sondern mehr im federalistischen Ansatz.
Und jetzt von der Transformation her,
wie seid ihr da vorgegangen?
Oder wie,
deine Aufgabe ist ja,
die Transformation vorwärts zu treiben
innerhalb der IT.
Wie geht ihr das an?
Also angefangen haben wir eigentlich,
und es hat immer noch den Charakter
eher mit einem Bottom-up-Ansatz,
also dass wir wirklich an der Basis anfangen,
auch anhand von kleinen Beispielen
und das dann wirklich Bottom-up
in die Organisation versuchen reinzutragen.
Und jetzt, als ich angefangen habe
vor einem Jahr,
da hat eigentlich,
hat man, sage ich mal,
auf Executive-Ebene noch nicht so prominent
über DevOps geredet.
Das wird auch heute noch nicht so jetzt
ganz riesengroß geschrieben im Sinne von,
wir haben jetzt eine riesen DevOps-Strategie,
obgleich jeder Einzelne im Executive-Team
natürlich weiß, was DevOps ist
und das auch unterstützt und weiterbringen möchte.
Ich sage da oft,
wir haben so eine Art Sandwich-Situation eigentlich.
Also wir bringen das von unten nach oben
anhand von wirklich konkreten Beispielen.
Und es hat aber auch den Executive-Bein und Support.
Also ihr bringt, sagen wir,
von unten nach oben mit konkreten Beispielen,
aber gleichzeitig auch so mit Top-Down
oder das Management-Commitment zu bekommen.
Wenn wir jetzt so von unten nach oben,
also da, was habt ihr da konkret?
Gibt es da ein paar Beispiele,
was ihr so gemacht habt?
Ja, also da kann ich gerne ein paar Beispiele bringen.
Also wir haben ganz am Anfang haben wir,
und das machen wir auch bis jetzt noch,
wir haben mit Value-Stream-Mappings angefangen,
wo wir wirklich Leute aus der Infrastruktur,
Shared-Infrastruktur, aus dem Bereich IT-Audit,
Governance-Compliance und natürlich
aus der Applikationsseite zusammengebracht haben
und dann wirklich mal den Technology-Value-Stream
also Change-Inception, also von der Idee bis hin zu Change
wirklich verfügbar in Produktion,
den ganzen Ablauf angeschaut und analysiert haben
und daraus dann abgeleitet wirklich kleinere Verbesserungsansätze.
Das kann oftmals sein,
dass einzelne Schritte einfach weggestrichen werden,
weil man sieht, wenn man dann auf das Ganze mal schaut,
ja, die braucht es eigentlich gar nicht.
Oder halt auch Verbesserungen im Sinne von Automatisierung,
im Sinne von Automation oder APIs zu den Infrastruktur-Plattformen,
dass man wirklich dann die Automation in einem Pipeline,
CICD-Pipeline-Kontext umsetzen kann.
Typischerweise und so auch bei uns ist das halt oft
so eine zusammengestöpselte Toolchain aus verschiedenen Systemen,
wo dann oftmals halt auch Portale oder User-Interfaces involviert sind,
wo es halt schwierig ist,
so einen ganzen End-to-End-Ablauf wirklich zu automatisieren.
Also wir haben das gemacht mit verschiedenen Business Domain ITs
und das Schöne war, dass sich dann wie ein gemeinsamer Backlog entwickelt hat,
wo wir uns halt, wo wir jetzt uns durcharbeiten sukzessive.
Was wir auch gemacht haben, ist dann, wir haben das Flash Builds genannt,
weil wir so ein bisschen, sag ich mal, an vielen Orten,
auch speziell ein bisschen in der Infrastruktur,
dort plant man traditionell ein bisschen in größeren Zyklen, oder?
Weil dort halt auch viele Investments gemacht werden,
wenn man neue Hardware kaufen muss,
obgleich wir auch unsere Datacenters runterfahren.
Aber dass wir wirklich ein bisschen mit dieser langen oder, ja,
Monate- bis Halbjahresplanung brechen konnten,
haben wir dann Flash Builds gemacht.
Also wirklich so, was können wir erreichen innerhalb von einer Woche,
um wirklich ein bisschen auch aus dieser, ja, dadurch, dass wir,
ich habe dem Analysis Paralysis gesagt, oder?
Weil wir dadurch, dass halt oftmals die Investments so groß sind
in technische Lösungen, in Enterprise-technische Lösungen,
dass man sich dann wirklich ewig lang hin und her überlegt
und mit allem, mit jedem redet und schaut,
was könnte denn jetzt die beste Lösung sein,
weil man natürlich nicht ein großes Investment machen möchte,
ohne sich ganz sicher zu sein.
Mit dem zu brechen und mal was wirklich Kleines anzufangen.
Und wir haben das dann Minimal Viable Architecture genannt.
Also wir haben da in dem Fall jetzt wirklich mit einem ganz einfachen
Cloud-Native-Muster angefangen.
Wir haben eigentlich ein Open-Source-API-Gateway genommen,
haben dann mit eine Microservices-Architektur implementiert,
auf Basis von Docker.
Und das war es eigentlich, wo wir dann wirklich die Leute drum herum
konzentriert haben und so einen gemeinsamen Arbeits-Context
geschaffen haben.
Und auf Basis von dem, was dabei rausgekommen ist,
haben wir dann wirklich weitergearbeitet.
Also mittlerweile sind die Technologie-Bausteine,
die da entstanden sind, in einem höheren Reifegrad.
Also wir arbeiten uns da jetzt sukzessive vor.
Und ein anderes Beispiel, mehr so aus der Prozess-Ecke,
läuft bei mir so unter dem Überbegriff Lean-Change-Management.
Ist ja sehr interessant für Leute mit einem IT-Service-Management-Programm,
die Service-Management-Background.
Also dort haben wir halt den Prozess für Change-Release-Deployment
angeschaut.
Der ist bei uns im Wesentlichen über ServiceNow implementiert.
Und haben dann festgestellt, wenig überraschend, dass das halt
mit so einer hohen Release-Cadence, mit CI-CD und so weiter,
nicht kompatibel ist.
Und haben dann uns auch zusammengesetzt mit den Haupt-Stakeholders,
also mit den Applikationsleuten, mit Leuten von IT-Audit
und mit den Prozess-Ownern von den jeweiligen Prozessen
und haben dann einen Minimal Viable Process definiert.
Und das war eigentlich ganz interessant, weil was wir da gesehen haben ist,
und ich habe das Delegation of Concern genannt,
das ist nicht zu verwechseln mit dem schönen Software-Design-Pattern,
Segregation of Concern, sondern was ich gesehen habe,
ist so, es gibt einen Prozess-Owner für den Change-Release-Deployment-Prozess.
Der redet mit den Leuten auf der Applikationsseite.
Die deponieren ihre Requirements.
Und er redet aber gleichermaßen auch mit den Leuten auf der Governance,
auf der IT-Audit-Seite.
Also es ist wie so eine Art Proxy.
Aber gleichzeitig, jetzt komme ich zu dem Punkt Delegation of Concerns,
die Leute auf der Governance-Compliance-Seite schmeißen so ihre Requirements,
da zum Process-Owner und auf der Applikationsseite genauso.
Und er steht dann so in der Mitte und muss da irgendwie eine Lösung finden.
Und der Schlüssel bei uns, was dann auch zu diesem Minimal Viable Process geführt hat,
war auch ein Value-Stream-Mapping, wo wir wirklich alle Leute an einen Tisch gebracht haben.
Und dadurch, dass eben auch die Leute auf der Applikationsseite direkt mit den Leuten
auf der IT-Audit-Seite geredet haben, hat sich wie ein neuer Solution-Space,
wo sich zusätzliche Optionen ergeben, die man sonst vielleicht gar nicht so einfach gesehen hätte.
Und ganz konkret, was wir gemacht haben dort ist,
wir haben zum Beispiel das eigentliche Change-Management angeschaut
und sind dann zu einem Schluss gekommen, dass nur weil es nicht in ServiceNow stattfindet,
heißt es nicht, dass es nicht stattfindet.
Es findet einfach in anderen Tools statt, bei uns mehrheitlich in Jira zum Beispiel.
Und wir haben uns dann darauf geeinigt, dass wenn der Product-Backlog und das Sprint-Planning,
also wenn wirklich vernünftig mit Jira gearbeitet wird, dass das ein implizites Change-Management ist
und das dann nicht mehr noch in einem separaten Tool nachgeführt werden muss.
Und das ist aber jetzt wohlgemerkt auch nur der Anfang, aber wir haben jetzt wirklich
eigentlich einen wesentlichen Schritt dahin gemacht, dass wir den Prozess wirklich entschlacken.
Und den Prozess mehr um die Continuous-Deployment-Pipeline oder Delivery-Pipeline orchestrieren und nicht umgekehrt.
Das waren ja ein paar schöne Beispiele, insbesondere dieses Minimal-Viable-Process-Architecture.
Finde ich ja eine ganz gute Übertragung dieser Prinzipien.
Und als du das eben so erzählt hast, habe ich mir gedacht, da ist mir die Frage hochgepoppt, wie würdest du das sehen?
Also ich sage immer, DevOps ist im Prinzip eine vernünftige Mischung zwischen IT-Service-Management, Lean-Management und agilem Vorgehen.
Wenn du das auch so siehst, meinst du, dass man da auch aus deiner Erfahrung heraus quasi so gewisse Prozentsätze verteilen kann?
Also im ersten Moment klang es bei dir sehr stark nach Lean, dann kam aber schon wieder auch Scrum mit dazu.
Also die Frage ist, kann man das irgendwie aufteilen und wie siehst du, wie sich DevOps aus klassischen, bisher bekannten Disziplinen zusammenfasst?
Also da, ich würde sicher da nicht mit irgendwelchen Prozentzahlen, würde ich mich sicher nicht festlegen.
Also da spielt alles ein bisschen mit rein und ich sage halt immer, das Wichtigste ist eigentlich der gesunde Menschenverstand.
Also man darf sich da nicht zu sehr auf die eine oder andere Weisheit oder Methodologie verlassen.
Ich glaube, man muss es immer individuell anschauen und dann entscheiden.
Das höre ich gerne.
Gesunder Menschenverstand hilft.
Das war jetzt schon ein bisschen eine sehr schweizerische Antwort.
Aber das mit dem gesunden Menschenverstand ist international, das muss man schon sagen.
Und du bist ja schon ein Weilchen in der Schweiz.
Genau, ja.
Und du hast jetzt schön, also es sind so drei Bereiche, so Value Stream, dann das mit dem Flash Build und dann Lean Change Management.
Aber immer was die drei Bereiche gemeinsam haben.
Also am Anfang gesagt, so statt Analysis, Paralysis, also statt zu Tode argumentieren, auch mal, einfach mal klein anfangen.
Aus dem, also so auch das Bein der Leute bekommen, aus dem raus wachsen, verbessern.
Und das ist ja auch so ein typischer Ansatz aus dem Lean.
Also man macht einen Value Stream, mal End-to-End verstehen von der, du hast auch schön gesagt, von der Inception bis zum Rollout.
Man hat auch schön den Three Ways.
Man hat ja, die Leute haben ein gemeinsames Verständnis, wie arbeiten wir zusammen.
Aus dem verbessert man dann Schritt für Schritt.
Und das ist ja so stark, auch im Moment ist es noch ein Bottom-Up Ansatz.
Ist aber auch etwas, wenn wir zum Beispiel schauen in der Vergangenheit bei vielen Firmen, wie agile Transformationen stattgefunden haben.
Da haben ja einfach mal Teams angefangen mit Scrum zu arbeiten.
Das war recht erfolgreich.
Und die anderen Teams haben das dann automatisch adaptiert.
Aber irgendwo muss ja dann immer der Punkt kommen, wo dann auch das Management sagt, ja okay, da wollen wir jetzt.
Das ist auch, sagen wir, Teil unserer Strategie, dass wir den Weg gehen wollen.
Und wo steht ihr in Bezug auf das, also das jetzt, sagen wir, das Management bei Ihnen, dass es auch jetzt von oben bewusst gesteuert wird?
Oder ist das etwas, das ihr jetzt dieses Jahr angehen wollt?
Jetzt, wir haben vereinzelt Business Domain ITs, die wirklich das auch in ihrer Strategie manifestiert haben.
Also explizit auch eines von den Top-Level-Punkten und andere, wo das mehr so implizit ist.
Also wo dann schon DevOps auftaucht als Element der IT-Strategie, aber nicht ganz so explizit.
Und das hängt auch ein bisschen damit zusammen, dass die,
die Strategien, wir haben natürlich eine Gruppen-IT-Strategie, aber die Business Domains an sich sind unterschiedlich
und entsprechend sind auch teilweise die IT-Teile unterschiedlich ausgerichtet und haben da unterschiedliche Schwerpunkte drauf.
Und um den anderen Teil der Frage zu beantworten, also wir sind schon noch jetzt an einem Punkt, wo wir halt mit Referenz-Applikationen,
wir sagen dem auch DevOps Co-Owner,
also das sind wirklich so DevOps Advocates in den Business Domain ITs, mit denen ich eng zusammenarbeite,
die für gewisse Applikationen oder Portfolios zuständig sind, wo wir wirklich so die Referenz nicht unbedingt,
ja doch Implementation kann man schon sagen, jeweils machen.
Und auf Basis von dem wollen wir es dann eigentlich später auch ausdehnen und erweitern.
Und vielleicht ist es auch noch, also wir haben die Applikationen, mit denen wir zusammenarbeiten,
sind tendenziell halt eher in diesem, werden neu gebaut oder sind also keine Bestands-Applikationen oder Legacy-Applikationen
und das ist dann noch ein Feld, wo es für uns sehr spannend wird oder wenn wir wirklich dann mal mehr traditionelle Applikationen anpacken
und uns die noch weiter modernisieren im Sinne von DevOps-Prinzipien.
Habe ich das richtig verstanden, dass ihr im Prinzip diese DevOps-Ansätze wirklich nur bei neuen Applikationen anwendet?
Das heißt, ihr habt es noch nicht übertragen auf Bestands-Applikationen und insofern auch noch nicht unbedingt auf eine großartige Organisationsveränderung?
Ja, also sagen wir mal, die Referenz-Implementationen sind jetzt eher mit neueren Applikationen.
Das hängt aber auch damit zusammen, dass halt viele ältere Applikationen sind halt im Run-Modus.
Also da werden nicht massiv neue Features implementiert, sondern die werden halt am Laufen gehalten, sage ich mal.
Und dort will man halt noch nicht jetzt so die großen Investments machen.
Aber man muss auch sagen, also die Applikationen, wo wir jetzt wirklich entlang von DevOps-Prinzipien arbeiten,
das sind nicht nur Cutting-Edge-Applikationen aus Technologiesicht.
Also wir haben eine, die ist schon eine Microservices-Architektur, wo auf unserer Private Cloud läuft,
wo aber WebSphere, also so Sachen sind da mit dabei.
Das ist noch die modernste in Anführungszeichen.
Aber wir haben auch welche, wo wirklich Batch-Verarbeitung, ETL, Data Warehouse, auch Enterprise-Datenbank-Lösungen.
Sind zwar neue Applikationen, aber nicht jetzt auf irgendeinem Cutting-Edge-Public-Cloud-Technologie-Stack.
Und solche haben wir dann aber wiederum auch, oder? Also welche, die wirklich schon auf einem hochmodernen Tech-Stack sind.
Aber wie gesagt, eher Applikationen, die noch im Build-Modus sind, nicht Applikationen, die im Run-Modus sind.
Weil dort halt die Schwelle zu investieren, ist halt dort höher, oder?
Du hast ja auch erwähnt, Cloud ist bei euch ein Thema. Ihr habt, glaube ich, auch eine Cloud-Initiative am Laufen.
Wie siehst du da den Kontext jetzt Cloud und DevOps, respektive bei euch konkret jetzt?
Ja, also das eine, also es spielt wie ineinander und gehört zusammen.
Es gibt ja wie so zwei Ansätze, die wir da, oder zwei Sichtweisen.
Also man kann ja einerseits sagen, DevOps entfaltet die Wirkung und erst richtig, wenn man Cloud als Betriebsmittel hat.
Also wenn man die Cloud-Möglichkeiten ausschöpfen kann.
Zum Beispiel Immutable Infrastructure und so weiter, Infrastructure as Code.
Das kommt erst so richtig zum Tragen, wenn man Cloud-Mittel nutzen kann.
Oder man sieht es umgekehrt.
Also man kann wirklich Cloud nur nutzen, wenn man DevOps-Prinzipien und Methoden anwendet.
Wir sehen es mehr so, wir haben eine sehr starke Cloud-Ausrichtung in unserer IT-Strategie.
Also das wird da sehr groß geschrieben.
Entsprechend wird DevOps mehr so als Mittel und Ansatz gesehen, um wirklich diese Cloud-Strategie zu implementieren.
Also einer der Gründe, um Cloud zu machen, ist eigentlich auch,
DevOps und dann Cloud als Enabler für DevOps. Richtig?
Genau.
Und wenn ich jetzt die Sicht, also viele Software-Entwickler, für die ist ja so ihre Vision, also sie wollen,
wenn sie Code einchecken, also sie können eh virtuell ganz schnell, sie bekommen eine Umgebung und da werden automatisiert Tests ausgeführt.
Alles eigentlich darunterliegen ist alles Infrastructure as Code.
Und für die ist eigentlich dann ein bisschen eine Blackbox.
Oder ob das dann aus dem eigenen Datacenter kommt oder ob das so diese Tendenz von Know-Obs.
Der Software-Entwickler würde am liebsten dann alles aus der Public Cloud beziehen, Azure, Amazon.
Aber das ist ja bei euch, also ich sage das ja nicht, wenn wir noch die Branche besser verstehen.
Also Rückversicherung ist ja auch sehr stark reguliert. Also welchen Weg geht ihr da?
Mehr Public Cloud oder ist das dann Private Cloud?
Ja, im Moment, also ein Großteil der Applikationen wird sich jetzt erstmal in eine Private Cloud bewegen.
Eben aus den erwähnten Gründen. Aber die Strategie sieht eigentlich vor, wo immer möglich, gehen wir eigentlich in die Public Cloud.
Wo das nicht möglich ist, in die Private Cloud.
Und von dem Last Resort, dass irgendwas ordentlich passiert,
was On-Premise bleibt, redet man eigentlich gar nicht, oder?
Also eigentlich ist Public Cloud first und dann als zweite Möglichkeit halt Private Cloud.
Und wie es sich jetzt manifestiert, ist halt wirklich so, dass ein Großteil jetzt in die Private Cloud geht.
Eben wegen den erwähnten Regulatorien, die halt sehr stark sind im Financial Services Sektor und speziell im Versicherungssektor.
Alex hat eben nochmal ein Stichwort eingebracht, Know-Obs.
Und so wie du es auch ausgeführt hast, Alex, klang es für mich so ein bisschen,
als ob die Entwickler sich eigentlich gar nicht um Obstthemen kümmern wollen. Nicht unbedingt.
Gab es denn bei euch Erfahrungen, oder wie sind eure Erfahrungen, wenn die Entwickler, die eben neue Features bauen wollen, auf IT-Betrieb treffen?
Also wenn sie auch den Betrieb sicherstellen müssen. Was sind da so eure Erfahrungen mit den Entwicklern?
Aus dem, was ich jetzt erfahren habe aus vielen Gesprächen, ist eigentlich, dass ein Applikationsentwickler
möchte eigentlich Applikationsentwicklung machen, oder?
Also die sind im Regelfall schon eher an den funktionalen Aspekten von der Applikation entwickelt.
Also ich persönlich sehe wieder ein bisschen ein neues Profil.
Das ist jemand, also so ein Ops-Engineer, wo er sich eher an der Applikation orientiert,
wo er sich aber auf die nicht-funktionalen Aspekte konzentriert.
Die verschiedenen Entwicklertypen arbeiten dann zusammen in einem Team.
Das ist so das, wo ich so ein bisschen vermute, wo die Reise hingeht.
Aber es ist noch ein bisschen schwierig zu sagen.
Um die Frage zu beantworten, wie Applikationsentwickler reagieren.
Also das kommt dann, nachdem so wir dürfen jetzt alles und machen alles selber,
kommt irgendwann oft ein Punkt, wo so ein bisschen auch nicht Ernüchterung,
aber wo die Leute dann sehen, was das denn alles bedeutet.
Also diese, ich glaube, diese No-Ops-Idee.
Irgendwann kommt dann da die Ernüchterung, oder?
Wo man dann sagt, okay, aber ganz das alles wollen wir dann doch auch nicht machen, oder?
Und ich rede von dem klassischen Applikationsentwickler.
Ich glaube an Teams, an Applikationsteams, wo es halt Entwickler gibt.
Alles sind Entwickler, aber halt welche, die sich auf die funktionalen Aspekte konzentrieren
und andere auf die nicht-funktionalen.
Das bedeutet Monitoring, Automation, CI-CD-Pipeline und so weiter.
Okay, das heißt, die Entwickler,
von denen du gesprochen hast, die lernen dann durch DevOps,
dass Ops doch nicht ganz so einfach ist und ja,
manchmal auch ein bisschen langweilig wahrscheinlich,
aber trotzdem schon eine Herausforderung und wollen es dann wahrscheinlich doch eher auch abgeben
oder einfach im Team auch vielleicht so ein bisschen hin und her schieben.
Ja, so könnte man das zusammenfassen, ja.
Und es ist halt, es ist alles auch noch ein Lernprozess, oder?
Weil das verändert sich halt doch sehr stark.
Also das muss sich alles setzen und man muss gute Setups am Ende vom Tag finden, oder?
Wie man das nachher betreiben kann.
Ja, ist schlussendlich, also DevOps-Transformation ist ja eine Reise.
Das ist ja, auch wenn man so liest oder hört, was andere im Bereich Enterprise IT,
DevOps-Transformation machen, ist ja nicht so, dass man von Anfang an Ziel bildet, sondern es ist eine Reise.
Und jetzt auch anknüpfen, was wir vorher diskutiert haben halt,
dass sich auch Operation ein bisschen neu finden muss, neu definieren und eben sicher nicht No Ops,
weil das ist sicher nicht die richtige Lösung, sondern eher würde ich sagen so New Ops,
was auch immer das konkret heisst, ja.
Und was ich jetzt vielleicht noch spannend finden will, wir haben ja darüber gesprochen,
was habt ihr da konkret gemacht, eben so Value Stream Mapping, Flash Build,
dann das Lean Change Management, wenn wir vielleicht ein bisschen tiefer gehen.
Also ich persönlich bin Fan noch von diesem Value Stream Mapping,
weil es ist auch etwas, wo man relativ schnell dann auch Verbesserungen erzielen kann,
dann einen gewissen Drive reinbringen kann, weil die Leute sehen das und wollen dann weitermachen.
Kannst du, Tobias, vielleicht ein Beispiel von so einem Value, also du musst es ja nicht beim Namen nennen,
aber in welchem Bereich habt ihr denn das Value Stream Mapping gemacht, welche Art von Applikation?
Also was ist dann konkret so aus solchen Value Stream Workshops,
was ist da dann herausgekommen an konkreten Verbesserungen?
Also eins ist sicherlich das gewesen mit dem Lean Change Release Deployment Management.
Das war ein Finding, das wir dann konkret halt jetzt in diesem Minimal Viable Process Beispiel umgesetzt haben.
Dann haben wir auf der Datenbankseite angefangen,
und dort wirklich das auch mehr aus einer, also wir haben einen gewissen Automationsgrad,
was das Ausführen von Datenbankskripten oder das Verwalten von Datenbanken anbelangt, haben wir schon,
aber eben nicht in einem End-to-End Automationskontext oder in einem Pipeline-Kontext.
Und das war eigentlich in so gut wie allen Value Stream Mappings, die wir gemacht haben, ein großes Thema.
Dort haben wir jetzt wirklich auch schon konkret erste Schritte gemacht,
wo Applikationen dann wirklich aus der Pipeline kommen,
aus der Pipeline raus im Prinzip ihre Datenbank Changes deployen können.
Und dann gibt es eben, ein anderes Beispiel wäre noch Monitoring,
dass man wirklich das Monitoring, das Produktionsmonitoring eben auch aus der Pipeline quasi abschalten kann,
dann Veränderungen vornehmen kann automatisiert und zum Schluss das Monitoring wieder anstellen.
Und ja, ab dergleichen gibt es noch mehrere kleine Beispiele, würde ich sagen.
Aber das ist auf der Prozessseite mit dem Change Management und auf der Datenbank
Seite, das sind wohl die grösseren Blöcke bisher, würde ich sagen.
Ja, aber das sind doch konkrete Verbesserungen.
Und ihr seid ja, habe ich verstanden, auch so vorgegangen, dass ihr mich halt dann als Team zusammengesetzt habt,
vielleicht Leute, die vorher noch nicht so miteinander gesprochen haben, also verschiedene Departments.
Man hat gefragt ja, der End-to-End Stream, wer ist da involviert?
Und zuerst mal ein Bild bekommen, wie läuft es jetzt und dann aus dem heraus Verbesserungen identifiziert.
Wie habt ihr das gemacht?
Also das Interessante war für mich, ich habe auch fast bei allen Value Stream Mappings eigentlich gesehen,
dass jeder, also dass zum Beispiel Leute, die in einem grösseren Applikationsteam zusammenarbeiten,
auch jeweils untereinander was voneinander gelernt haben.
Also eigentlich nicht mal nur Leute, die jetzt da normalerweise nichts miteinander zu tun haben,
sondern alle haben irgendwie was gesehen oder Einsichten bekommen in das,
was der andere macht.
Und was mir so hängen geblieben ist, ist das Beispiel mit dem, das war eine Batch-orientierte Applikation,
wo die Testzyklen sehr, sehr teuer sind.
Also konkret ein voller Testzyklus hat, glaube ich, acht Stunden oder so gebraucht.
Also zeitmäßig sehr teuer und entsprechend konnte der nicht so oft durchlaufen.
Wir haben dann herausgefunden, dass eben pro Release dreimal dieser Testzyklus durchlaufen wird
und dass in dem ersten Testlauf hunderte von Fehlern entdeckt werden.
Und dann werden die Fehler behoben, dann hat man vielleicht noch 50% oder 30% von den Fehlern im zweiten Testlauf
und im dritten läuft dann alles durch.
Und dann haben wir wirklich in einer Gruppe eigentlich geschaut, ja, was machen wir denn damit?
Und haben dann gesehen, eigentlich wäre es doch gut,
wenn man wirklich möglichst viel von dem Testing nach links verschieben kann,
dass das nicht alles nur an diesen teuren Testläufen hängt, oder?
Weil man hat gesehen, das war halt für sie die einzige Möglichkeit, das zu testen, aus ihrer Sicht,
und das war sehr teuer, also hat man alles dort reingesteckt.
Und die Schlussfolgerung war eigentlich, dass wir dann wirklich versucht,
möglichst viele Tests schon vor diesen teuren Testzyklen zu machen,
dass dann der erste teure Testzyklus halt zum Beispiel nur noch,
50% der Fehler finden muss, dass man vielleicht am Ende vom Tag mit zwei teuren Testzyklen statt mit drei laufen kann.
Und natürlich ist das dann in der Theorie sehr einleuchtend und naheliegend
und in der Umsetzung halt etwas schwieriger, aber schon allein die Einsicht hätte man glaube ich nicht gehabt,
ohne dieses Value Stream Mapping, wo dann wirklich alle, die in diesem Value Stream mitarbeiten,
das an einem Tisch sitzen und das anschauen.
Das klingt doch gut. Das finde ich auch einen sehr schönen Lerneffekt,
auch aus dem Phoenix Project Buch, aus dem Roman, dass man wirklich den Value Stream,
den Wertstrom sich anschaut und daraufhin eben entwickelt.
Und damit ja letzten Endes auch über die Silo-Grenzen hinaus das Ganze mal betrachtet.
Ja, jetzt gucke ich mal auf die Uhr, Alex. Sonst ist das immer dein Job, auf die Uhr zu gucken.
Jetzt gucke ich mal auf die Uhr. Ich habe keine Fragen.
Das war ein super tolles Gespräch und wenn du keine Fragen hast, Alex, dann können wir ja auch langsam beenden.
Also ich habe auch keine Fragen mehr. Ich fand das super spannend.
Das sind auch die wertvollsten Beiträge, die wirklich aus der Praxis kommen.
Also was machen die Unternehmen effektiv, wenn es um DevOps geht?
Also von dem her vielen Dank von meiner Seite, vor allem von Tobias.
Sehr gern.
Dann auch von mir vielen Dank. Ich habe mitgenommen eine sehr tolle Definition von DevOps.
Nachhaltige Geschwindigkeit oder Geschwindigkeitssteigerung. Finde ich sehr, sehr interessant.
Werde ich bestimmt übernehmen in Vorträgen oder in Schulungen oder in Erläuterungen.
Und was ich interessant fand, war die Erkenntnis, dass das viele kleinere Verbesserungen sind.
Also das ist ein Weg, den man gehen muss, wo man viele kleinere Verbesserungen hat,
wo man viele Schritte hat, wo man Erfahrungen hat und dass das kein so riesen Programm ist, was man aufsetzt.
Das fand ich sehr, sehr interessant. Und davon von mir auch herzlichen Dank an dich, Tobias.
Sehr gern. Danke euch.
Und dann noch ein Ausblick auf den nächsten Podcast. Dirk, willst du das machen?
Respektive haben wir da noch mehrere Optionen im Moment, oder?
Ja, das hast du geschickt gemacht. Das muss ich wieder sagen.
Wir wollen kein neues Thema haben. Also wir haben die Option, jawoll.
Und wie es immer so ist, so am Jahresanfang, jetzt wo wir heute diesen Podcast aufnehmen, das startet so langsam.
Also insofern, der nächste Podcast kommt bestimmt wieder zur Mitte des Monats, wieder dann Mitte Februar.
Aber das Thema ist noch nicht ganz klar.
Ja, das stimmt.

Folge 6: DevOps und Microservices

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode diskutieren die Gastgeber Alex Lichtenberger und Dirk Söllner zusammen mit dem Experten Eberhard Wolff ausführlich über die Rolle und Bedeutung von Microservices in der DevOps-Welt. Sie erörtern, wie Microservices die IT-Infrastruktur modernisieren und die Effizienz in der Softwareentwicklung steigern, indem sie eine stärkere Modularisierung und Entkopplung ermöglichen. Es wird besprochen, wie Unternehmen schrittweise von monolithischen Systemen zu einer Microservices-Architektur übergehen können, wobei Herausforderungen wie Betriebskomplexität und Teamdynamik angesprochen werden. Die Episode schließt mit einer Diskussion über organisatorische Veränderungen und die Rolle von DevOps in diesem Kontext.

Inhalt

  • Einführung und Vorstellung von Eberhard Wolff
  • Definition und Bedeutung von Microservices
  • Verbindung zwischen DevOps und Microservices
  • Herausforderungen und Vorteile von Microservices
  • Praktische Beispiele und Anwendungsfälle von Microservices
  • Schrittweise Migration von monolithischen zu Microservices-Strukturen
  • Organisatorische Veränderungen und Kultur im Kontext von DevOps und Microservices

Shownotes

  1. Microservices: Definition und Prinzipien – https://martinfowler.com/articles/microservices.html
  2. Independent Systems Architecture Prinzipien – https://innoq.com/en/isap/
  3. Eberhard Wolff’s Buch über Microservices – (URL je nach spezifischem Buchtitel)
  4. Eberhard Wolff’s Buch über Continuous Delivery – (URL je nach spezifischem Buchtitel)
  5. Docker und Kubernetes als Infrastrukturthemen –
  6. Domain-Driven Design – https://dddcommunity.org/

Transkript (automatisiert, daher keine Gewähr 🙂 )

Folge 5: Der State of DevOps Report 2017

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge des Podcasts besprechen Alex Lichtenberger und Dierk Söllner ausführlich den „State of DevOps Report“. Sie thematisieren die Kernergebnisse des Berichts, darunter die Rolle von transformationaler Führung, die Auswirkungen von DevOps auf Organisationsgeschwindigkeit und -stabilität, die Bedeutung von Automatisierung und kontinuierlicher Auslieferung sowie die Herausforderungen der Implementierung von DevOps in Legacy-Systemen. Besonders hervorgehoben wird der Wert von Microservices und Modularisierung sowie der Übergang zu einem Lean Product Management-Ansatz.

Inhalt

  • Einführung in den State of DevOps Report
  • Schlüsselerkenntnisse des State of DevOps Reports
  • Bedeutung von transformationaler Führung in DevOps
  • Beziehung zwischen Geschwindigkeit und Stabilität in DevOps-Praktiken
  • Rolle der Automatisierung in DevOps
  • Herausforderungen bei der Implementierung von DevOps in Legacy-Systemen
  • Bedeutung von Microservices und Modularisierung
  • Lean Product Management und Agilität
  • Zukünftige Entwicklungen und Trends in DevOps

Shownotes

  1. Puppet
  2. DORA (DevOps Research and Assessment)
  3. Scrum Guide Revision 2017

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Hallo und herzlich willkommen zu einer weiteren Folge von dem Podcast
DevOps – auf die Ohren und ins Hirn.
Ich begrüße Sie wieder als Hörer und hoffe, dass wir mit unserer neuen Technik
Alex und ich haben ein bisschen investiert in neue Technik
dass wir mit unserer neuen Technik noch besser die Qualität rüberbringen können
dass die Form stimmt und an dem Inhalt sind wir ja eh immer dran.
Wir haben heute das Thema State of DevOps
den Report, den wir so ein bisschen auseinandernehmen werden
den wir ein bisschen zusammenfassen werden
und insofern würde ich sagen, heute haben wir keinen Gast
Sie haben heute die Chance, Alex und mich mal wieder ganz alleine zu hören
und insofern Alex, gebe ich gleich mal rüber an dich.
Ja, danke Dirk. Herzlich willkommen auch von meiner Seite aus der schönen Schweiz
Es ist ja inzwischen schon der fünfte Podcast, den wir machen
und ja, ich glaube, vorstellen muss ich mich nicht mehr gross
also in dem Sinne, ich freue mich auf das heutige Thema und das Gespräch mit dir.
State of DevOps Report, habe ich eben gesagt, ist unser heutiges Thema
Ja.
Wir beide kennen den ganz gut
wir nutzen ihn auch in unseren Schulungen, in unseren Workshops
aber vielleicht gibt es den einen oder anderen Hörer, der diesen Report noch nicht kennt
oder nur mal so am Rande was davon gehört hat
insofern denke ich, Alex, erzähl doch mal ein bisschen was zum Report.
Ja, gerne. Also das State of DevOps Report ist inzwischen das vierte Mal, dass der erscheint
das ist eigentlich eine Studie, ein Reality Check
also werden Unternehmen gefragt, was macht…
was macht ihr effektiv im Bereich DevOps zu der Erhebungsmethode
kann ich dann gleich noch was sagen
also es ist eigentlich so sehr ähnlich
einige von euch kennen vielleicht den State of Agile Report
der ja dann im Bereich Agile schon seit vielen Jahren schaut
ja, was sind effektiv Praktiken, die die Unternehmen anwenden
was machen die genau
also wie gesagt, der Reality Check
und nun das gleiche im Bereich DevOps
ursprünglich wurde der DevOps Report, der wurde vom Puppet herausgegeben
Puppet ist ja ein bekannter Tool-Hersteller, auch im Bereich DevOps
die haben dann aber gesagt, weil das dann zu…
zu, sag ich mal, vom Hersteller kommt
und dann ist dann die Glaubwürdigkeit auch ein bisschen ein Problem
dann wurde eine neue Organisation gegründet, die DORA
das steht für DevOps Research and Assessment
also…
ein Institut, die diesen DevOps Report dann neu jährlich rausgibt
und vielleicht ganz kurz, eben wie wurde der Report gemacht
also da wurde wirklich darauf geachtet, dass halt sehr breit eine Umfrage stattfindet
also einerseits mal von der Demographie her
also es wurde…
also ich weiß, der Report ursprünglich aus den USA kommt
ist schon die Hälfte der befragten Unternehmen aus den USA
dann ein Drittel etwa…
Europa und 10% Asien und der Rest dann…
der Rest der Welt, also Südamerika, Australien etc.
was auch darauf geachtet wurde
also im Sinne, dass es nach der Repräsentative ist, die Resultate
die eigentlichen Branchen, also es wurden unterschiedlichste Branchen
Unternehmen aus unterschiedlichen Branchen befragt
also einerseits mal Technologie natürlich
etwa ein Drittel dann die Finanzindustrie
Retail, Telekommunikation, Bildung
also die ganze Breite ist abgedeckt
und was sie dann eben gemacht haben
sie haben nicht nur Unternehmen befragt
jetzt die wirklich…
sagen wir DevOps
gut, man kann nicht DevOps machen
aber man kann Continuous Delivery
also Firmen, die einerseits schon wirklich DevOps Praktiken anwenden
aber auch andere traditionell geprägte
um dann auch einen Vergleich zu machen
was ist dann der Effekt von DevOps
da wären wir dann…
da wären wir dann später auch noch drauf kommen
vielleicht für diejenigen, die auch den DevOps Report runterladen wollen
man kann das machen auf…
entweder auf der Webseite von Dirk
auf devops.de
kann man den aktuellsten Report runterladen
oder sonst auch bei meiner Seite
devops.ch
da könnt ihr dann effektiv reinschauen
ja, ich werde ihn bei mir eben genau bei den Shownotes
zu diesem Podcast bereitstellen
dass derjenige, der neben unserer Stimme auch noch ein bisschen was lesen will
auch die Chance hat, das mal im Detail nachzulesen
gut, ja Alex, danke für die…
für die Einführung dazu
ich habe ja gesagt, wir beide nutzen das in unseren Trainings
und in den Schulungen
ich finde es immer sehr, sehr interessant
und wir werden ja auch im Verlauf des Podcasts
noch ein paar wirklich interessante Ergebnisse rausfinden
oder darstellen
und das…
da bin ich schon mal gespannt drauf
gibt es…
zu Anfang gibt es ja so eine schöne Zusammenfassung
so eine Art Summary
was sind denn 2017 die wichtigsten Erkenntnisse gewesen
die Key Findings?
ja, also ich kann das ganz kurz zusammenfassen
wenn wir das eine oder andere noch vertieft anschauen
so sechs Key Findings
also das erste Key Finding war
Stichwort Transformational Leadership
damit ist gemeint, dass halt die Firmen, die erfolgreich DevOps machen
weg vom Tayloristischen traditionellen Management
Richtung DevOps Lean Leadership
also selbst organisierte Teams
und dann mit dem Leader, der dann halt mehr die Vision vorgibt
also eine andere Art von Führung
die auch zentral zu sein scheint für den Erfolg von DevOps
das andere ist auch wiederum die Feststellung
Firmen, die DevOps machen
die sind signifikant
also einerseits schneller
Time to Market
aber gleichzeitig auch die Stabilität
die…
die verbessert wurde
das dritte Key Finding
Automatisierung
also das…
das Automat…
die Firmen sagen, die…
die erfolgreich…
diese High Performing Organisations sagen
Automatisierung ist…
ist zentral für uns
das hat einen…
einen Unterschied gemacht
und dann der nächste
der ist…
ja sorgt dann für Diskussionen manchmal
Stichwort bimodale IT
dass man…
die Firmen kommen weg vom Gedanken, dass
es gibt ein Teil der IT, die macht DevOps
und der Rest nicht
dass man…
die Aussage ist
DevOps applies to all Organisations
dann ein weiteres Key Finding ist
ich würde mal sagen
DevOps is not enough
also es ist natürlich, wenn man unten dran Monolithen hat
architektural wird schwierig
dann DevOps umzusetzen
das heisst, was viele Firmen
Key Finding
man arbeitet an der Architektur
Stichwort SOA
Microservices
Modularisierung
und das letzte Finding war
ist noch das Thema
Lean Product Management
also die Art und Weise wie Produkte
dann weiterentwickelt werden
also dass die
sagen wir das Stichwort Agilität
oder Lean Product Management
auch eine zentrale Rolle spielt
weil viele sehen ja dann
DevOps sagen wir als eine
Erweiterung vom agilen und Lean Gedanken
und das wird da bestätigt
also das sind so zusammenfassend
die Key Findings
und ja vielleicht macht es jetzt Sinn
dass wir vielleicht ein Thema
gerade dann tiefer reingehen
weil das ein Thema
das ja in den vergangenen Reports immer
im Zentrum stand
nämlich
anknüpfen
auch zu den Zielen von
DevOps
DevOps schneller
besser
und hier jetzt der
DevOps Report
also wenn wir jetzt da
diejenigen die den
Report vor sich haben
müssen man auf Seite
muss ich jetzt selber schnell suchen
Seite 21
das wurde ja wiederum bestätigt
eben massiv
kürzere Durchlaufzeiten
und gleichzeitig auch die Stabilität
die erhöht wird
also in der Praxis
durch Umfragen bestätigt
und da könnte man vielleicht
ein bisschen
Dirk diskutieren
also wenn wir jetzt die
das anschauen
da steht zum Beispiel
46 mal häufiger werden
Deployments gemacht
440 mal schneller
Lead Time
96 mal kürzere
Störungsbehebungszeit
das ist sehr beeindruckend
da können wir vielleicht
ein bisschen diskutieren
Dirk auch das
ja das warum
also ich finde es auch interessant
weil das sind Zahlen
die natürlich wirklich
aus der Praxis kommen
die erhoben wurden
und wenn ich an meine
Schulungen denke
dann gibt es dann schon
den einen oder anderen
oder auch bei Vorträgen
den einen oder anderen
der sagt
das kann bei uns aber
nicht funktionieren
das kann bei anderen sein
Facebook schafft das
und Google schafft das
aber wir können
das nicht schaffen
und insofern finde ich
es interessant
und hoffe auch
dass die
Masse
die
Anzahl der Teilnehmer
weiterhin steigt
und dass die
Anzahl der Teilnehmer
weiterhin steigt
dass man einfach
auch da nochmal
Firmen mit reinbekommen
die jetzt eben nicht dabei sind
und für mich ist das
eine Bestätigung
dass das geht
dass das gehen kann
natürlich geht es nicht
von jetzt auf gleich
du hast es ja auch gesagt
so Microservices
ich habe
häufig noch
monolithische
Applikationen
die vielleicht
in einer großen
Datenbank arbeiten
oder wo ich
auch vielleicht SAP
im Einsatz habe
aber prinzipiell
wenn man daran arbeitet
das überschaubarer
zu machen
von den Teams her
dann denke ich
kann man dahin kommen
und es gibt
viele Firmen
die auch die ersten Schritte
dahin machen
das heißt
die haben dann
beispielsweise nicht
jeden Tag
hunderte von
Deployments
oder hunderte von
Produktivsetzung
von kleinen Änderungen
das was man ja auch
den großen
bekannten amerikanischen Firmen
dann nachsagt
die haben das nicht
aber
sie kommen dahin
dass sie eben
statt zweimal im Jahr
ein großes Release
ausrollen
dass sie schon
einmal im Monat
ein kleineres Release
ausrollen
die eben
diesem Weg folgen
aber natürlich
noch nicht so
ganz so schnell
wie das vielleicht
dann die Vorreiter da sind
und das hat ja dann
auch einen positiven
also ich glaube
das Beispiel
das du genannt hast
so ein häufiger Release
das hat einen
positiven Einfluss
auch auf die
Stabilität
im Sinne
also wenn man jetzt
im Report schaut
das Meantime to Recover
also die
Störungsbehebungszeit
ist im Schnitt
bei diesen
sagen wir
DevOps Firmen
96 mal kürzer
und deshalb
ich sage immer
wenn man jetzt
zwei Releases
im Jahr hat
dann
viel Spass
beim finden
einer Fehlerursache
weil es gibt ja
nach jedem Change
gibt es Störungen
und wenn man halt
dann eher kleine
Päckchen hat
dann ist
in der Regel
ist es dann
haben wir viel schneller
auch die Ursache
des Fehlers
gefunden
kann man schneller
einen Rollback
machen
oder gut
die Amerikaner
würden wahrscheinlich
eher fix forward
also das
heißt
39 mal kürzerer
Meantime to Recover
und für mich
auch für
schon
gekommen
aber
calex
mit
sowieso
mein
zu senken und wir werden hier 96 mal schneller. Wie gesagt, das ist ein enormer Wert, ein enorm hoher Wert, aber das zeigt, dass das geht, wenn man eben Dinge verändert und dann einfach startet. Also insofern, für mich ist das eben auch ein Argument zu sagen, auch der Betrieb, der ja vielleicht wirklich klassisch als der langsame Bereich dasteht, hast du ja gesagt, bimodal, sprechen wir nochmal drüber gleich,
dass auch der Betrieb eigentlich ein Interesse daran haben sollte, auch im Sinne von IT-Service-Management, von ITIL, zu sagen, hey, wir müssen uns um das Thema DevOps kümmern.
Genau, das sehe ich auch so. Es ist auch spannend, die Zahl, da wird auch eine Aussage gemacht, das Change-Fail-Rate, also im Schnitt jetzt die Firmen, die DevOps machen, dass die im Schnitt fünfmal weniger Fehler haben.
Und da ist auch eben, das Spannende ist immer die Diskussion, die ich mit den Leuten, also mit Kunden habe, aber auch in den Schulen, warum ist das dann so und bei DevOps ist ja, sagen wir, diese, hatten wir in früheren Podcasts darüber gesprochen, Shift-Left, also you build it, you own it und es wird sehr früh, es werden Tests, auch nicht-funktionale Tests werden und auch Antworten definiert und die Tests dazu automatisiert,
also einen starken Fokus auf ein starkes Test und ich denke, das ist so der Hauptgrund, wieso auch die, also nicht nur die Störungsbehebungszeit zurückgeht, sondern auch die effektive Fehlerrate zurückgeht, also im Kontext mit Test-Automatisierung.
Spannend, also das war jetzt so der Stabilität, wir haben ja alle mal gelernt, also dass wenn man schneller wird, geht die Stabilität runter und umgekehrt, wenn ich mehr Stabilität und mehr Change-Control,
dann geht es besser.
Ja, der Speed runter, aber hier wirklich das Faszinierende, beides geht ja, also DevOps will ja beides erhöhen und jetzt haben wir gesagt, ja, okay, Stabilität besser und dann eben dieses Lead-Time-for-Changes, also die effektiv, die Dauer, die, wie lange es geht, ein Change umzusetzen, sozusagen im Schnitt 440 Mal schneller, also es ist einfach jetzt mal aus der Umfrage raus und das ist natürlich auch wieder, ich würde sagen, das,
das magische Wort dahinter ist auch wieder Automatisierung, also vor allem auf Deployment-Seite, aber auch die ganze DevOps-Pipeline, also der, sagen wir im Idealfall der Entwickler-Check-In-Code und hintendran werden automatisiert die ganzen Tests ausgeführt, wenn man das richtig hinkriegt und quasi dann könnte jederzeit sagen, ja, jetzt meine Software ist in der Releasable-State und ich habe die Zahl, diese, auch wenn sie ein bisschen
Anfang war ich da skeptisch, habe gesagt, das kann ja nicht sein, also traue nie einer Statistik, die du nicht selber gefälscht hast, aber es ist schon, es lässt sich erklären.
Ja, ja, was ich interessant finde, du hast ja eben auf die Tabelle auf der Seite 21 referenziert, wenn man noch ein bisschen weiterblättert, es gibt da noch ein bisschen Unterteilungen, das heißt auf der Seite 23 gibt es die Unterteilung beim Change-Failure-Rate, also bei der Rate, wo Fehler mal nach einem Change
auftreten, 2017 im Durchschnitt fünfmal niedriger, wenn man es aber mal unterteilt in die einzelnen Organisationen, das macht ja der DevOps-Report, der unterteilt ja die Organisationen oder teilt sie ein in High-Performer, in Medium-Performer und in Low-Performer und wir alle wissen, was wir mit Low-Performer meinen, wenn wir über einen Menschen sprechen, also in diesem Fall hier haben wir den Low-Performer von der Organisation her und da ist das Interessante, die Change-Failure-Rate, die ist da im Prinzip
dreimal,
so hoch bei den Low Performern im Vergleich zu den High Performern.
Das heißt, diese fünffache, fünffach niedrigere Rate im Durchschnitt,
die wird nochmal ein bisschen genauer auseinandergerechnet,
indem einfach gesagt wird, dieser Wert wird quasi durch die Low Performer
nochmal nach unten gezogen.
Das heißt, die High Performer und die Medium Performer,
die sind zwischen 0 und 15 Prozent.
Also die haben relativ hohe Erfolgsquote bei Changes.
Ja, das wird ja sehr, und wir haben ja gerade einführend gesagt,
in der Erhebungsmethode wurden tausende von Unternehmen befragt,
aber eben in der ganzen Breite, also wirklich auch ganz traditionell
auf der anderen Seite die Unicorns.
Und da wurde dann so wie eigentlich ein Clustering gemacht
und dann diese Einteilung und die drei.
Das hilft auch noch fürs Verständnis.
Ja, also was ich interessant finde, ist für diesen Bereich die Aussage,
es geht, man kann Agilität, eine schnelle Lieferung,
verbinden mit Stabilität.
Wenn man das im Sinne eines DevOps-Konzeptes
und einer Philosophie macht, dann kann man das verbinden.
Das ist für mich eine zentrale Aussage und du hast es ja auch gesagt,
die kann man nicht vom Tisch wischen.
Man kann sie erklären und das versucht ja der DevOps-Report.
Ja, ich würde mal auf einen anderen Punkt gehen.
Du hast vorhin schon gesagt, Transformational Leadership
und das für die, die nachlesen wollen, finden wir auf den Seiten,
oder ab der Seite 12.
Das ist eben auch ein wichtiger Punkt,
dass man eben nicht nur die Uniformen,
nicht nur auf die technischen Dinge abzielt,
das war ja eben eher Technik oder geht ja stark in die Richtung Technik,
sondern auch in das Thema Führung.
Wie sieht eine Führung anders aus?
Und wenn man sich so, weiß nicht, bei Xingo, LinkedIn und sonst wo,
bei Twitter die ganzen Nachrichten anschaut,
dann wird einem ja als Führungskraft,
müsste einem ja Angst und Bange werden,
weil man alles falsch macht und weil man nicht modern ist.
Hier der Hintergrund ist Transformational Leadership.
Das ist eine Aussage, die getroffen wurde.
Wie hast du diese Aussage,
wie hast du diese Aussage interpretiert?
Was ist für dich Transformational Leadership?
Ja, also ich habe, als ich den Titel gesehen habe, gesagt,
hm, was könnte sich dahinter verstecken?
Aber als ich dann den Inhalt durchgelesen habe,
ich denke, man könnte hier auch genauso von Agile oder Lean Leadership sprechen.
Und ich denke, dass jetzt diese auch grundsätzliche Transformation,
die viele Unternehmen durchmachen,
als sich Richtung agile, selbstorganisierte Teams bewegen,
aber auch, also das eine ist ja, wie man sich als Team organisiert.
Aber es hat auch jetzt einen grossen Einfluss
auf auch das Selbstverständnis des Managements und der Führung.
Wie sehen wir unsere Rolle? Wie führen wir?
Und ich denke da, das ist auch der schwierigste Brocken,
weil wir kennen ja alle den Spruch
Culture eats strategy for breakfast.
Das heisst, die Leute, also man kann die schönsten Pläne haben,
aber wenn die Leute das nicht wollen,
auch das Management halte, nicht loskommen,
sagen wir, von der Art und Weise, wie sie die letzten 30 Jahre geführt haben,
dann scheitert das.
Es ist jetzt auch ein Kulturwandel, der stattfindet im Bereich Führung.
Und ich nehme da immer den Vergleich, also um das ein bisschen zuzuspitzen,
wenn man, ich übertreibe jetzt natürlich masslos,
aber es wird auch schon eigentlich im Report so gezeigt,
dass, wenn man das traditionelle Management,
tayloristische Management anschaut,
dann sieht man, der Manager, der Manager weiss, was gut ist für das Team.
He tells the team, das Team führt aus, wird über KPIs gesteuert.
Also die Welt der hohen vertikalen Gebäude, eben oben der Manager.
Und jetzt eben Transformational Leadership, sagen wir von der Idee her relativ alt,
aus dem Lean Leadership heraus, letztes Jahr, 160er Jahre,
das ist halt eher so die Welt der flachen Gebäude.
Da hat man einerseits das Team, das Team hat gemeinsames Verständnis, wie man arbeitet.
Das Team macht regelmässig Retrospektive, verbessert sich und macht auch Crosstraining.
Und was ist dann mit dem Manager?
Eben der Manager, man spricht nicht mehr vom Manager, sondern vom Leader.
Die Aufgabe des Leaders ist, sie sprechen dann auch eine Vision, eine Vision vorzugeben.
Was wollen wir?
Die Teams sind ja typischerweise um Produkte herum oder Services sorgen.
Was ist unsere Produktvision?
Und dann nicht den Leuten sagen, wie sie das erreichen sollen,
sondern welches Problem muss gelöst werden.
Und dann auch die richtigen Fragen stellen, den Teams helfen,
ihnen die Umgebung geben, dass sie sich weiterentwickeln können.
Und natürlich, ich meine, ich mache selber relativ viel Agile Coaching,
also auch Scrum Coaching, also helft den Unternehmen als Coach, sich Richtung Agile zu bewegen.
Und das ist dort genau der Move, den wir machen.
Also einerseits die Mitarbeiterebene, wie es versteht sich das Team selbst,
aber dann auch der Leader, wenn er zum Beispiel dann Scrum anschaut,
dann wird das in zwei geteilt, zum Beispiel Produktdonor,
der ist mehr für die Vision und die Anforderungen und der Scrum Master,
der schafft die richtige Umgebung.
Und spannend ist ja dann,
dass heute wird, dass er dann das nicht nur auf unten auf Team-Ebene,
sondern dass man das bis zu oberst oben skaliert.
Also man hat dann auch zu oberst auf C-Level,
wie die ihre, dass sie sich auch eher als Leader sehen
und eben nicht als Micromanager.
Das ist so, also auch aus dem Report, der Report sagt eigentlich ja,
dass die Unternehmen sehen diesen Teil als kritisch,
dieses Transformation Leadership als kritisch,
erfolgreich zu sein mit DevOps.
Ja, du hast es angesprochen.
Leadership ist ja ein Thema, was wir auch in dem agilen Umfeld haben.
Insofern, als ich das gelesen habe, fand ich zwei Dinge interessant.
Erstens, dass es ein Modell gibt,
nachdem man dieses Transformational Leadership quasi bewerten kann.
Auf dieses Modell beziehen sich ja die Autoren des State of DevOps Report
und das ist eben ein Aufsatz, der jetzt schon 13 Jahre alt ist,
an der Stelle, und der eben ein Modell beschreibt
mit fünf Charakteristika, wie Transformational Leader quasi auftreten,
wie sie denken, wie sie ticken und wie man eben genau das bewerten kann.
Und diese fünf Punkte finde ich sehr interessant.
Vielleicht ganz kurz, die Vision hast du eben angesprochen.
Charakteristisch für einen Transformational Leader ist eben,
dass er eine Vision hat, wo will die oder wo soll die Organisation
in fünf Jahren sein, als Beispiel.
Es geht um Inspiration.
Inspirierende Kommunikation, das hast du im Prinzip auch schon
ein bisschen angesprochen, eben keine Vorgabe,
sondern ein Transformational Leader kommuniziert in einer Art und Weise,
dass er damit die Leute inspiriert und motiviert.
Also er spricht die Leute eben an, eine inspirierende Kommunikation.
Das ist der zweite Punkt, der quasi in diesem Modell beleuchtet wird
oder der in diesem Modell betrachtet wird.
Dritter Punkt ist die intellektuelle Stimulation.
Das heißt, der Transformational Leader, der macht sich Gedanken über die Probleme
und erregt sich und auch seine Mitarbeiter quasi oder seine Teammitglieder an,
darüber auch nochmal nachzudenken.
Also er stimuliert letzten Endes auf einer intellektuellen Ebene an der Stelle.
Vierter Punkt, Supportive Leadership.
Das heißt also, ein Transformational Leader kümmert sich in einer Unternehmenspolitik,
unterstützenden Weise um die persönlichen Belange seiner Follower, seiner Teammitglieder.
Auch das geht so ein bisschen in Richtung Servant Leadership.
Ich komme gleich noch auf einen anderen Unterschied, auf einen wichtigen Unterschied
zwischen diesen beiden Konzepten, aber Supportive Leadership, der vierte Punkt.
Der fünfte Punkt, persönliche Wahrnehmung, sage ich mal.
Das heißt also, der Transformational Leader hat eine persönliche Wahrnehmung von dem Ganzen.
Also,
hier fünf Punkte, wie man einen Transformational Leader quasi charakterisieren kann.
Und ich habe eben schon gesagt, für mich ein zweiter Punkt, der noch wichtig ist,
als ich gelesen habe, Transformational Leader, habe ich gesagt, hey super,
wieder ein neuer Fachbegriff, wieder was Neues für Servant Leader.
Nein, es gibt einen Unterschied und das ist eben für all die, die Servant Leadership verstehen
und verinnerlicht haben, eben sehr schön beschrieben.
Auf der Seite 14 gibt es so eine kleine Box.
Es gibt einen Unterschied zwischen einem Servant Leader und einem Transformational Leader.
Und der Unterschied ist im Prinzip derjenige, dass der Servant Leader die Entwicklung,
die Performance seines Teams im Blick hat.
Also, er unterstützt die Entwicklung und die Performance seines Teams.
Also, fokussiert sich mehr auf das Team, wenn man das so will.
Hilft dem Team, indem er es eben führt.
Also, dienender Führer, er führt, indem er dem Team quasi dient.
Führt damit aber auch.
Der Transformational Leader, der versucht oder hat als Ziel,
dass sich die…
Follower, sein Team, sich mit der Organisation identifizieren
und eben versuchen, ihre Arbeit sinnvoll so zu gestalten,
dass die Organisation unterstützt wird.
Also, das ist schon, wie ich finde, eine andere Sichtweise.
Und insofern, das sind auch Themen, die man sicherlich nochmal,
ja, auch vielleicht in einem späteren Podcast mal genauer auseinandernehmen kann.
Da gehen wir ja wirklich in die Anforderungen an Führer.
Wobei, wenn wir Deutschen dieses Wort gebrauchen,
müssen wir ja mittlerweile immer noch vorsichtig sein.
Also, ein Leader…
Mal das englische Wort.
Also, ein Leader an der Stelle, der Transformational Leader,
ist ein bisschen anders unterwegs.
Und das, was eben der State-of-Dev-Ops-Report aussagt,
das ist ein Erfolgsfaktor.
Aber wie gesagt, es ist ein kleiner Unterschied,
aber ich finde auch einen wichtigen Unterschied zu einem Servant-Leader,
wie wir ihn aus der agilen Welt kennen.
Das fand ich jetzt so gut, dass du auch die Unterscheidung gemacht hast.
Es ist dann auch, auf welcher Ebene, also ist es mehr auf Team-Ebene
oder geht es darum, sagen wir mal,
dass…
Ja, ja, ja.
Es knüpft dann wieder an die Vision an.
Der Transformational Leader, der auch eine klare Vision vorgeben muss
und das dann in die Organisation reinbringen kann.
Und nicht einfach nur, sagen wir, der Servant-Leader,
der es dann mehr die Teams selber führt.
Haben wir noch andere Key-Findings, die wir ausführen können?
Also, der Report ist ja recht lang.
Aber ich habe mir…
Also, wir haben es ja auch im Vorfeld gedacht,
da müssen wir ein bisschen Fokus setzen,
dass dann der…
Das kann sich zwei Stunden lang werden.
Also, ein Thema, das vielleicht die Leute noch interessiert,
ist, weil…
Wir haben auch schon mal gesagt, man kann nicht DevOps machen.
Aber was man machen kann, sind die ganzen DevOps-Praktiken.
Das interessiert ja die Community immer sehr.
Also, da gibt es dann auch ein Kapitel dazu.
Das hat dann zwar das Kapitel, den Titel
Technische Practices.
Und da ist natürlich an erster Stelle
kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
Und da kommt man zu den Praktiken, die man macht.
das als Top-Trio.
Content ist jetzt halt mehr, er spricht von
Technologie, aber auch Prozessen.
Und vielleicht
ist es wert,
das könnte ich auch machen, aber
Continuous Delivery generell
ist ja, baut auf
Continuous, also die, die es vielleicht noch nicht
so kennen, baut ja auf
Continuous Integration auf.
Also bei Continuous Integration
die Praxis, dass man
als Entwickler, man arbeitet
an gemeinsamen Repositoren,
Cori,
und werden automatisierend
ein paar Basistests gemacht, das ist ja auch
ein bisschen alter Hut,
dann aber Continuous Delivery, so dieses
Mindset, dass
das, was, wenn ich
etwas mache, sagen wir als Ingenieur
oder Entwickler, ich will
Feedback bekommen, sofort
ist das, was ich
mache, richtig.
Also richtig, nicht nur jetzt im alten Sinn,
okay, mein Kollege
hat es reviewed, oder ich habe so ein
paar funktionale Tests gemacht,
sondern wirklich so weit, dass man
auch nicht-funktionale
Tests, also zum Beispiel
Security, Performance,
man baut das alles ein
und dass man
dann, eigentlich wird dann mit die Agilität
auch dann zu Ende getrieben,
ich bekomme sofort Feedback, ist es
wirklich dann oder nicht,
und wenn nicht, dann muss ich es eben korrigieren
und ich kriege dann nicht erst in drei Monaten
Feedback, wenn dann irgendwann
später ein Performance-Test
sagt, ist nicht gut. Also da ist jetzt
die Firmen fokussieren sehr stark
einerseits Infrastruktur,
Continuous Delivery,
da hängt natürlich der ganze unten dran,
man braucht
Cloud-Infrastruktur, also
dass man on-demand dann die nötigen
Testumgebungen bekommt, aber
dass auch man
investiert in Test-Driven
Development, früh schon
Tests, anfangen
als Test-Cases
definieren, automatisieren,
und
was da auch, steht glaube ich
auch drin, das kann man ja nicht von heute
auf morgen, sondern das ist auch wieder
ein Weg, das kann Jahre dauern,
wenn man aus dem Legacy kommt, sagt man
okay, jetzt automatisiere ich
mal den Teil, dann mal den Teil,
investiere ich in das,
und dann kommt man diesem Continuous
Delivery, dieser Vision
dann immer ein Stück näher.
Also es ist so, was ich rauslese
aus dem Report, dass es jetzt
extrem Fokus ist, auch bei den Firmen.
Ja, also ich
finde auch, und wir hatten ja gerade vor
ein paar Tagen das
Webinar von Jeff und
Ken Schwaber, von Jeff Sutherland,
Scrum Guide
Revision 2017, die Änderungen,
und da haben sie ja auch das Wort
DevOps auftauchen lassen,
das heißt also, der Scrum Guide
sieht auch, DevOps, da tut sich
was, und du hast eben so ein wunderschönes
Wort gesagt, dann, also wann
ist es fertig, wann ist es wirklich fertig,
und das ist eben das Schöne,
das ist der ganz feine Unterschied, der aber natürlich
viel nach sich zieht, wenn
ich rein nur auf Scrum mich
beziehe, dann bin ich fertig,
wenn die Definition of Done erfüllt ist,
und die ist aus Sicht von Scrum, wenn man
das Scrum ganz eng sieht,
dann, wenn der PO das abgenommen hat, dann muss
es noch nicht in Produktion sein,
und wenn ich dann sage, dann ist es
erst, also es ist erst dann fertig,
wenn es in Produktion ist,
und dort läuft, das ist nur ein kleiner
Schritt, aber ein
Riesenschritt, weil ich muss ja wirklich eine Menge
dabei tun, und das ist eigentlich auch
eine weitere Herausforderung, du hast ja gesagt,
wir reden über technische Praktiken,
Technical Practices, aber da hängt
natürlich auch Organisation und Mindset
wieder dahinter, ein Entwickler, der sagt,
habe ich entwickelt, PO
hat es abgenommen, bin zufrieden,
kann mich zurücklehnen, der muss sein
Mindset an der Stelle eben auch ändern, also
dann heißt, wenn es dann fertig
in der Produktion ist, und nicht auf einem
Entwicklungssystem oder auf einer
anderen Stage. Ja, also ich war gerade
in die, diesbezüglich war gerade
heute Morgen,
ein agiles Team, ich begleite
die, das hat sehr,
sagen wir, sehr Scrum-lastig, und
da habe ich mal gesagt, heute, ja, lass uns
mal ein bisschen über DevOps sprechen,
lass uns über die Definition of
Done sprechen, oder was
macht, würde es nicht Sinn machen, das jetzt mal ein bisschen
weiterzuentwickeln, also was ist
unser Verständnis über
Done, wollen wir uns mal Gedanken
machen, langfristig
gewisse Tests, Einbud
zu beziehen, also dass es dann auch
innerhalb vom Sprint ist,
effektiv erst dann,
wenn man auch weiss, ja,
es wird die Security-Tests
bestehen, es wird die
Performance-Tests bestehen,
und dann ist es eben spannend,
dass die aus den agilen Ecken,
die sagen, für sie ist eigentlich DevOps
doch nicht so neu, man hat zum Beispiel das
Wort Continuous Delivery, das ist ja schon
im agilen Manifest von
2001, taucht
das Wort ja schon auf, also
die Agilen haben ja schon immer gesagt, lass uns über das
Definition of Done, die
muss immer besser werden, immer näher zu,
aber das Problem ist, die Entwickler haben sich einfach nie
für den Betrieb interessiert,
und das ändert sich ja
jetzt, indem man dann, und da
reden wir dann nicht mehr über Technik, sondern
man beginnt
Betriebsleute in solche
Scrum-Teams zu integrieren,
dass sie eben auch ein Stake bekommen,
weil das sind die, dass man
dann diese operativen
Dinge auch bereits schon
in der Definition of Done
einwirkt, und da wir heute,
also da haben wir uns grundsätzlich
gesagt, ja,
lass uns Zeit investieren, das wird
ein langer Weg sein, aber dann immer
näher. Richtig, ja.
Langer Weg, weil ja auch die User-Stories,
die Anforderungen entsprechend kleiner
gepackt werden müssen, denn, wenn du hast
gesagt, Security-Test, viele andere
Tests, die kann ich nicht alle in einem
Zwei-Wochen-Sprint einbauen und die mal
eben dazu packen, das heißt, das ganze
Thema Testen und andere Anforderungen
drumherum, das muss ja auch
vorbereitet werden, dass das überhaupt
macht.
In einem entsprechenden
Sprint an der Stelle, also insofern
vollkommen richtig, da ist noch ein bisschen was
zu tun, aber auch meine
Sichtweise ist, oder meine
Erkenntnis ist, dass die Entwickler eigentlich
damit, ich sag mal so, kein Problem
haben. Wahrscheinlich sind das eher
bestehende Schranken,
bestehendes Simudenken, was
sie davon abgehalten hat,
quasi, oder wo sie abgehalten wurden,
sich auch um den Betrieb mit zu kümmern.
Da wurde einfach übergeben an den Betrieb
und du hast eben gesagt,
dass die Betriebsleute in die Teams
reingeholt werden. Das ist für mich
nochmal ein wichtiger Punkt, weil
ich würde jetzt nicht sagen, ich nehme
meine Betriebsmannschaft, teile die
fein auf, auf die einzelnen Scrum-Teams
und dann mache ich DevOps. Also das wäre ja
ein Missverständnis. Mein Verständnis
ist ja eigentlich eher, dass ich das
Wissen, das Betriebswissen in die
Teams packe. Ja, aber es hat mit
Verantwortung zu tun. Also meine, da gibt es
natürlich unterschiedliche Ansichten, aber
die meisten Kunden, mit denen ich zu tun
habe, die sagen wirklich, das hat der Gedanke
von Spotify. Man hat diese Teams
und die haben, you build it,
you own it. Weil solange
immer noch so ist, dass
jemand anders ist ja dann für den
Betrieb verantwortlich, dann haben
die nämlich gar nie ein Interesse, die
betrieblichen Dinge reinzunehmen. Also wir
versuchen, also nicht unbedingt
fest in die Teams, aber dass
die dann an,
wenn es um Planung geht, etc.,
zum Beispiel Sprintplanung, dass die
vertreten sind drin
und dass, also wir gehen dann so weit,
dass wir sagen, wir haben eine
und das Team hat dann auch betriebliche
Verantwortung. Es werden natürlich gewisse
Scherzdinge, die muss man immer separat
machen, also das ist klar.
Ja, also wir sind ja noch beim
DevOps Report, bei den Technical
Practices, was ich noch interessant finde
ist, du hast ja eben schon was zum
Continuous Delivery gesagt,
da ist auf der Seite 33
nochmal der Punkt
Fast Feedback on the Quality and the
Deployability. Genau.
Ein wichtiger Punkt, was ich da
schön auch am agilen Vorgehen
finde,
ist ja, und auch natürlich am
Lean Management ist, kontinuierliche
Verbesserung. Und kontinuierlich heißt für mich
immer in kleinen Schritten, in kleinen Häppchen,
ich sehe sofort, ob das funktioniert,
ob es nicht funktioniert, habe sofort ein
Erfolgserlebnis, habe sofort eben dieses
Feedback. Und dieses Fast Feedback,
was hier bei der Continuous Delivery
rüberkommt, finde ich eben auch sehr, sehr interessant,
dass eben die Entwickler, wie du es ja auch
gesagt hast, die kriegen schnell das
Feedback. Und egal,
ob das jetzt ein kleines oder ein größeres
Team ist, jeder im Team kriegt
dieses Feedback und kann daraufhin
sich seine Meinung bilden und kann eben
schauen, was muss man tun, um
mit dem Feedback quasi umzugehen
und mit dem Feedback zu arbeiten. Also
auch hier wieder,
es geht zwar um technische Praktiken,
die aber eben auch entsprechend
kulturelle, organisatorische
Veränderungen haben, Mindset-Veränderungen
und hier eben ein Fast Feedback,
also du kriegst ein schnelles Feedback als Entwickler,
ob das, was du gebaut
hast, auch wirklich funktioniert.
Und wie du es eben gesagt hast, nicht nur auf
Testumgebung, sondern
Security-Tests werden bestanden, andere
Tests werden bestanden, es funktioniert in der Produktiv-
Umgebung. Das finde ich eben auch das Schöne
und das Interessante.
Ja, wir haben ja, also wenn man schaut, Continuous Delivery
ist ja ein Punkt, was dann
als nächstes kommt, ist das ganze Thema
Architektur.
Also die
Aussage, dass auch dort jetzt
viel Veränderung
stattfindet. Wir haben ja kurz
über Modularisierung so angesprochen.
Gut, also ein weiterer
Punkt jetzt in dem Kapitel
Technical Practices,
zwar eben jetzt mit Klammer,
es geht ja nicht nur um Technik,
wie auch der Dirk schön gesagt hat,
es gibt Prozesse,
Kultur, du musst das auch unterstützen,
aber ein weiterer Punkt ist Architektur.
Und die Aussage
ist da,
dass die
Fähigkeit, also die, wenn man
sagen wir, man kann nicht
Continuous Delivery machen, man kann
nicht
in kleinen, selbstorganisierten Teams
und man kann auch nicht
inkrementell in kleinen Häppchen arbeiten,
wenn man unten dran immer noch Monolithen
hat.
Die ganze DevOps-Bewegung
kommt ja von diesen sogenannten Unicorns,
also wie Google, Netflix
und die hatten ja den Vorteil,
dass man die von Anfang an
die Architektur halt
DevOps-like gebaut
haben, nämlich
Modular,
in Microservices,
Clouds-Native
und wenn man das unten so,
die Architektur so ist,
dann hat man
es nach viel einfacher,
die anderen DevOps-Praktiken
umzusetzen.
Und ich hatte da auch,
wenn wir jetzt gut vom Report weg,
aber da fällt mir eine Anekdote ein,
oder eigentlich mehrere, ich habe sehr oft,
wenn ich beim Kunden
ein bisschen vorstelle,
DevOps und dann gerade bei den
Grossunternehmen, also bei uns zum Beispiel
die Banken, die machen schon sehr lange
IT in Deutschland, sagen,
das ist bei uns nicht möglich, weil
so Legacy und alles, wir können
die Architektur,
das ist
ein Rieseninvestment
und meine Antwort ist dann, also erstens,
die Frage ist nicht nur,
ist es möglich, sondern der Punkt ist
eben notwendig, wenn
sie jetzt, wenn sie
überleben wollen im kompetitiven
Umwelt, weil sie haben da eine Konkurrenz,
die machen das halt dann
einfach, das ist das eine
und das andere ist auch wieder Architektur,
das ist
das zu ändern, Richtung
Modularisierung,
das ist ein
extrem langer Weg,
also der kann sehr
lange gehen und das
Wichtigste ist einfach, dass man mal anfängt,
damit, man kann lange um den
Brei reden, aber das wollen wir auch hier wieder
in kleinen Schritten
dann die Architektur
graduell,
sie schreiben dann ja auch
auf Seite 36
loosely coupled
well encapsulated
architecture drives
IT performance.
Das braucht auch Zeit, aber es
ist wie, wenn die Architektur
nicht stimmt, in diesem
Sinne, dann gibt es
auch Schwierigkeiten, dann
continuous delivery und selbstorganisierte
Teams umzusetzen.
Also ich finde es interessant, deine
Anekdote an der Stelle, weil natürlich
kommt das Argument immer, das geht bei uns
nicht, weil wir eben
große Systeme haben, weil wir ein SAP
haben, was das nicht zulässt,
alles technisch gesehen erstmal
die richtigen Argumente, aber dann ist die Frage,
ja, können sich
Organisationen diese
Ausflüchte oder diese Erklärungen
noch erlauben oder ist nicht der
Wettbewerb so, der Druck von draußen so
stark, dass man einfach was tun muss
und das geht natürlich auch dann in Richtung
Disruption an der Stelle.
Also du hast
eben auch von den kleinen Schritten gesprochen,
wenn ich jetzt mal so ein bisschen weiterblättere,
Seite 43, da geht es dann, oder auch
Seite 42 geht es dann in Richtung
Lean Product Management und da
finde ich es eben auch interessant, dass
genau auch da so Erkenntnisse sind,
dass das ganze Thema
Lean Product
Management da mit
reinspielt, das heißt, ich
kriege bessere
IT-Performance hin, eine höhere IT-Performance,
wenn ich eben mit
kleinen Badges aber mitarbeite,
mit kleinen Teilchen, also die
und eben auch mit diesen kleinen Teilen
auch wiederum schnell Feedback bekomme und
das ist ja auch eben eine Erkenntnis
hier, die High Performer
sind High Performer oder
deswegen High Performer, weil sie es dann eben
schaffen, auch im Rahmen des
Deployments schnell das Feedback
zu bekommen und das Ganze
kriegt man eben nur hin und das quasi
gegenseitig die Beeinflussung,
man hat eine schlankere Produktion,
kriegt schnell da Feedback und das ist
wiederum dann die Voraussetzung, genau um
eben noch schlanker die Produktion zu
haben, also wirklich, dass
die IT-Performance quasi auch
eine Vorgabe ist und das
Thema Lean Product Management
treibt. Also auch hier wieder,
die Message mit
Small Badges, Short
Feedback Loops, ich denke, das zieht
sich so ein bisschen durch den Report
durch, über die verschiedenen
Themen,
auch im Thema Leadership,
im Thema dann
Continuous Deliveries, ja auch dann
Mittel zum Zweck, um dann
echtes Feedback
zu bekommen, schnell.
Und auch dann in den
Hard Fakten, die wir ganz am Anfang
besprochen haben, mit dem Schnelle
Bessere, das ist ja auch ein
Effekt von diesen
kleinen Badges, also in dem Sinn
dann kleine Päckchen,
kurze Release-Zyklen
und so dann schnelle Feedback-Loops zu bekommen.
Das zieht sich so ein bisschen durch, den ganzen
Report, fällt mir jetzt gerade
auf. Und mir fällt gerade ein, dass wir
vielleicht mal jemanden dazunehmen
sollten in so einem Podcast
zum Thema Microservices. Ich habe da
so ein paar Leute vor Augen, also
insofern habe ich mir ja gerade mal
notiert, dass wir auch mal das Thema
Microservices durch ein paar Experten hier uns
erläutern lassen sollen. Ja, genau, dass
man jetzt da mit ein bisschen Praxis
noch mehr, also Leute, jetzt die, also
wenn man die Report-Themen anschaut,
dann vielleicht den
einen oder anderen schnappt und der dann
auf Kundenseite was
dazu erzählen kann.
Ja, du hast vorhin noch mal
ein Stichwort genannt, was ich sehr, sehr interessant
finde, das Thema Bimodal, hat man ja gesagt,
Bimodal IT, wollen wir auch noch mal kurz
drüber sprechen und
da haben wir beide die gleiche Einschätzung.
Das hat unser kleines Vorgespräch
eben gezeigt. Wir sind da beide ein bisschen
skeptisch, ob das der richtige Ansatz ist
und wir beide haben auch vom Klaus Straub
das Interview oder den Bericht gesehen
von BMW,
der eben als IT-Verantwortlicher
sagt, Bimodal IT
ist für ihn kein Thema mehr oder ist
nicht mehr der richtige Ansatz
und insofern, Alex, warum denkst du,
ist das nicht der richtige Ansatz oder nicht
zeitgemäss? Ja, also ich bin auch ein bisschen
hin und her gerissen, aber ich hatte
ein interessantes Erlebnis
bei Kunden, die hatten die
Strategie eben Bimodal IT
und die haben gesagt,
Bimodal IT heisst ja
DevOps agil, ja,
für einen Teil der IT, aber den anderen
Teil lassen wir klassisch.
Und die haben auch das aus der Not
raus, mussten die die Strategie
haben, weil die haben gesagt, ja, wir haben
jetzt in bestimmten Produkte
Bereich, da wird
bald eine Konkurrenz kommen,
ernsthaft, ja, und wir müssen da
schnell,
wir müssen da Konkurrenz,
die wollten dann neue Leute,
neue Architektur, und da
die haben gesagt, mit der alten IT können
wir das gar nicht, also Bimodal IT,
da denkt man, ja, das macht Sinn
und ich weiss auch, dann haben sie
interviewt
ein paar Experten, das kam damals von
HR, oder, da ging es dann darum,
sie wollen so eine agile Story,
eben für den einen Teil der Bimodalen IT,
um die Leute zu begeistern,
für Agilität, für DevOps, und die haben mich
dann gefragt, ja, Alex, kannst du
das mal eben so, wie würdest du die Leute
für DevOps
begeistern?
Und dann habe ich dann, ja, mir überlegt,
und dann die Gegenfrage gestellt, ja, aber eigentlich
müsste, wieso erzählt ihr nur die Story
und nicht die andere für die andere,
das ist dann das alte Eis, ne,
dann plötzlich haben wir realisiert,
dass wie eine, entsteht
eine Zweiklassengesellschaft,
also der IT, oder, da gibt es die coolen,
agilen, die
jungen, die mit Potenzial,
und dann das alte Eisen, die alten,
die sind dann in der anderen
Legacy, die sind im anderen Teil, und da
ist ja klar, die meisten wollen bei den
coolen sein, aber es gibt dann wirklich so,
also auch emotional schlechte,
und die Firma hat sich dann tatsächlich
auch entfernt vom Bimodalen
Gedanken, die haben dann gesagt,
für uns ist die klassische
Welt langfristig keine Option
mehr, weil sie haben gesagt, und ich finde das auch,
oder man hat, weil DevOps ist,
das geht ums Schnelle, Besser, ich kann auch
in einem Legacy-Umfeld,
kann ich mir Gedanken
machen, wie, wie kann,
wo kann ich ein bisschen automatisieren,
wo kann ich Silos
abbauen, also ich glaube schon,
das ist ja die Aussage im Report auch,
DevOps ist eben
für überall,
also man kann es, es kann überall
nützen, nicht nur ein Teil der IT,
und ich,
ich unterstütze das, ich habe, inzwischen
bin ich mehr Fan, weil Bimodale IT
kommt ja von Gartner,
sie haben es inzwischen, kritisieren sie es ja selber,
sie haben da das neue Modell rausgebracht,
der Pace-Layered Approach,
den finde ich besser, das nimmt auch ein bisschen
die Emotion aus, sie haben einfach gesagt, ja,
das Multispeed-IT, sie haben gesagt,
ja, je nach Bedürfnis
vom Business, auch Änderungsdruck,
muss ich dann halt auch ein bisschen
die Methoden anders anwenden,
also sie sprechen von Systems of Difference,
Differentiation, das ist wirklich die,
diese IT in Business,
also die, die Produkte,
IT-Service, wo ich mich auch im Markt
differenziere, und dort ist das
wirklich die Welt von DevOps und Agile,
dort ist es ganz wichtig,
während andere ist es dann
nicht mehr so, sie sprechen
Systems of
Record,
zum Beispiel ein SAP,
oder ein, gut,
SAP kann auch unterschiedlich aussehen, aber
so die, ich meine nicht so eine Änderung, so, da, da, da, da, da, da, da, da, da, da,
dort ist das dann, ist das dann vielleicht doch nicht
so kritisch. Aber das,
das Modell finde ich dann eine Alternative
zur bimodalen IT,
das ist ja, bimodale IT, das Modell
ist halt ein bisschen schon
spaltet dann, die IT,
finde ich, das Negative.
Wie siehst du das, wie siehst du das?
Ich sehe es auch so, ich sehe es auch kritisch,
versuche ich auch in meinen
Vorträgen rüberzubringen, das eine ist das,
was du sagtest, und was der Klaus Straub hier auch
in seinem Interview gesagt hat,
Zwei-Klassen-Gesellschaft, da haben wir die,
die Leute, die sich alt vorkommen oder langweilig vorkommen, weil sie auf Stabilität achten.
Und wenn ich DevOps richtig verstehe und wenn ich auch die Aussagen aus dem State-of-DevOps-Report nehme,
dann sind das Punkte, die genau diesem Ansatz eben widersprechen.
Ich kann, das haben wir ja vorhin schon ausgeführt, ich kann schnell sein
und ich kann aber auch Stabilität sicherstellen durch mein Vorgehen.
Und insofern, das sind, also für mich sind die Kernaussagen aus dem State-of-DevOps-Report
widersprechend diesem Ansatz bimodaler IT.
Und ich komme ja auch immer mit meiner Metapher, mit der Geschichte vom Hase und dem Igel an der Stelle.
Die meisten werden das kennen, also der Hase, der sich eben über den Igel lustig macht,
über die kurzen Beinchen, dann machen sie ein Wettrennen und der Igel nimmt seine Frau mit dazu.
Und im Prinzip macht er das ganz geschickt.
Der Hase, wenn man die Metapher zu Ende liest, glaubt nach dem 73. Mal fällt der Hase nach dem Wettrennen tot um,
weil er eben wie ein Bekloppter.
Also hirnlos, aber schnell zum Ziel rennt und dort den antrifft, der einfach das Köpfchen eingesetzt hat.
Also für mich ist das eine schöne Metapher, benutze ich immer wieder, wo ich sage,
es ist aus meiner Sicht sinnvoll, das Richtige zu tun.
Und wenn ich das Richtige tue, dann bin ich damit im Prinzip auch schneller,
weil ich mir Nacharbeiten spare, weil ich mir extra Schleifen spare,
weil ich nur das tue, was wirklich benötigt wird.
Und dieses Richtige, das Richtige tun, das ist für mich eben auch Kern,
von DevOps und dann brauche ich keine Nacharbeiten und dann bin ich eben trotzdem schneller.
Das kommt quasi automatisch, wenn ich das Richtige tue, kommt automatisch die Schnelligkeit mit dazu.
Und du hast ja von deinen Kunden gesprochen.
Meine Erfahrung ist auch, in den Scrum Teams, wo ich auch Kontakt zu den Kunden habe,
also zu den Anforderern, die meisten sagen gar nicht, dass die Schnelligkeit für sie der Vorteil ist.
Die sagen, das ist zwar schön, aber die meisten sagen, jetzt habe ich endlich den Kontakt zu den Entwicklern
und ich kann direkt einwirken und ich kriege nicht irgendwann irgendwas vorgesetzt,
sondern ich habe die Chance, mitzuwirken und ich kriege deswegen bessere Software,
ich kriege bessere Ergebnisse und das ist das, was meine Erkenntnis ist aus den Scrum Teams,
die ich, wie gesagt, betreue, wo ich die Rückmeldung bekomme.
Die Kunden sind zufrieden oder zufrieden, weil sie eben das Richtige bekommen
und nicht unbedingt im ersten Schritt, weil sie es schneller bekommen.
Ja, übrigens fand ich eine super Metapher mit der Igel und Hase,
aber ich denke auch, dass dieses Aufgibseln,
auch das Missverständnis der DevOps, es geht auch um schneller, schneller,
aber ich denke, es geht wirklich primär darum, das Richtige zu tun,
weil ich kann ja lang, schneller, schneller und auch Kosten sparen.
Wenn ich zum Beispiel das falsche Geschäftsmodell habe, dann bringt mir das nichts.
Also ich denke auch eben, dass richtige Effektivität und weniger Effizienz.
Gut, natürlich braucht es am Schluss beides, wenn man als Unternehmen florieren will.
Ja, vollkommen richtig.
Also deswegen für mich ist natürlich, die Schnelligkeit kommt,
aber sie kommt quasi als Nebeneffekt.
Und du hast es ja selber gesagt, wenn ich schnell das Falsche mache,
da bin ich eine Zeit lang ganz schön schnell, aber irgendwann bin ich dann gar nicht mehr aktiv,
muss das passende Geschäftsmodell natürlich mit dazukommen.
Ja, hast du noch Punkte, hast du noch wichtige Themen aus dem State-of-Device-Report
oder kommen wir dem Ende näher?
Ja, also wenn man auf die Uhr schaut, ja, wir kommen dem Ende.
Es gäbe schon noch so das eine oder andere Topic,
aber ich denke, wir haben nicht so mal,
wir haben den Großteil abgedeckt und auch aus unserer Sicht jetzt die spannenderen Themen, oder?
Aber ich würde, also ich habe von meiner Seite eigentlich nichts mehr.
Und ich denke auch jetzt angesichts der Zeit sollten wir mal dann Schlusspunkt machen.
Ja, genau, zum Ende kommen, ja.
Was machen wir denn beim nächsten Mal?
Ja, das lassen wir uns mal überraschen.
Also wir haben ein paar Sachen im Köcher.
Wir müssen ja noch finalisieren, wer dann effektiv für ein Intro zur Verfügung stehen wird.
Also wir sind, wir sind agil unterwegs, richtig?
Ja, genau, agil kannst du sagen.
Sorry, ich spreche manchmal ein bisschen lang.
Wir sind agil, genau.
Wir sind agil.
Und heißt ja, wir haben einen Plan, aber den müssen wir eben vielleicht auch kurzfristig anpassen.
Also insofern, wir haben ein paar in der Pipeline.
Unser Product Backlog ist gepflegt, aber noch nicht ready, um es in den Sprint zu ziehen.
Gut, Alex, ja, also ich bedanke mich sozusagen bei dir für die Unterstützung an der Stelle
und würde sagen, das Schlusswort kannst du heute machen.
Mal wieder sprechen.
Ja, also danke auch von meiner Seite, Dirk.
Und ich hoffe, das wird auch für die Zuhörer, dass es für euch interessant ist.
Und ja, ich freue mich dann auf den nächsten Podcast.
Also in diesem Sinn bis zum nächsten Mal und vielen Dank.
Tschüss.
Tschüss.
Tschüss.

Folge 4: Metro Map – Wege durch die DevOps-Komplexität

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Episode des DevOps-Podcasts werden die Herausforderungen und Strategien der Implementierung von DevOps in Unternehmen erörtert. Die Gäste Volkert Jung und Sebastian Schulze von der Direktgruppe teilen ihre Erfahrungen und diskutieren insbesondere die „DevOps Metro Map“ – ein Instrument zur Visualisierung und Strukturierung der vielfältigen Aspekte von DevOps. Die Diskussion beleuchtet die Bedeutung von Kultur, Prozessen, Technologie, Innovation und IT-Service-Management in DevOps und betont die Notwendigkeit eines kontinuierlichen Lern- und Anpassungsprozesses innerhalb von Unternehmen.

Inhalt

  • Einführung und Vorstellung der Gäste
    • Vorstellung von Volkert Jung und Sebastian Schulze von der Direktgruppe
  • DevOps-Definition und Missverständnisse
    • Diskussion über die irreführende Wahrnehmung von DevOps als Jobtitel
  • DevOps in der Praxis
    • Herausforderungen und Realitäten von DevOps in Unternehmensstrukturen
  • Die DevOps Metro Map
    • Entwicklung und Ziel der DevOps Metro Map zur Visualisierung von DevOps-Komplexität
  • Wichtige Aspekte von DevOps
    • Rolle von People, Process, Technology und Innovation in DevOps
  • IT-Service-Management in DevOps
    • Diskussion über die Integration und Bedeutung von ITSM in DevOps
  • Zukunft von DevOps und die Metro Map
    • Überlegungen zur kontinuierlichen Weiterentwicklung und Anpassung der DevOps-Strategien
  • Abschluss und Dank an die Gäste

Shownotes

  1. Direktgruppe: Ein Beratungsunternehmen, das in den Bereichen IT-Infrastruktur, Softwareentwicklung und IT-Strategie tätig ist. Es ist bekannt für die Entwicklung der „DevOps Metro Map“. Leider konnte ich keine direkte URL zur „DevOps Metro Map“ finden, daher empfehle ich, die Hauptseite zu besuchen und gegebenenfalls direkt nach der Metro Map zu suchen. Direktgruppe Website
  2. DevOps Metro Map: Ein von der Direktgruppe entwickeltes Visualisierungstool, das die Komplexität von DevOps strukturiert. Eine spezifische URL ist nicht verfügbar
  3. Eric Ries – Lean Startup: Das Buch „Lean Startup“ von Eric Ries, das wichtige Prinzipien für die Entwicklung von Minimum Viable Products und Start-up-Strategien bereitstellt.
  4. IT-Service-Management (ITSM): Wichtig für die Implementierung von DevOps, ITSM ist ein zentraler Bestandteil für den effektiven IT-Betrieb. Informationen über ITSM und dessen Praktiken können auf Seiten wie AXELOS gefunden werden, die Best-Practice-Lösungen anbieten.

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zur vierten Folge vom DevOps-Podcast auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begrüße Sie zur Folge, bei der wir heute zwei Gäste haben.
Wir haben heute den Volkert Jung und den Sebastian Schulze von der Direktgruppe.
Und ich glaube, ich muss gar nicht viel einleitend sagen.
Volkert, kannst du kurz dich vorstellen? Kannst du kurz die Direktgruppe vorstellen?
Das mache ich doch gerne. Hallo Dirk, hallo Alex. Vielen Dank, dass ihr uns eingeladen habt.
Mein Name ist Volkert Jung. Ich bin Berater und Prokurist in der Direktgruppe.
Und ich möchte kurz was zum Unternehmen sagen, damit wir auch gar nicht viel Zeit verlieren.
Und dann schnell zu unserem Fachthema übergehen.
Die Direktgruppe ist ein Beratungsunternehmen aus Hamburg.
Wir sind seit 1998 auf dem Markt an verschiedenen Standorten mit über 200 Beratern in verschiedenen Themenstellungen.
Sei es von der IT-Infrastruktur über die Softwareentwicklung zur IT-Strategie
bis hin zur Online-Marketing oder SAP-Beratung bieten wir hier ein weites Feld an.
Für unsere Kunden ist es ein sehr wichtiges Thema.
Für unsere Kunden erbringen wir unsere Leistungen im großen Teil recht individuell.
Und in dem Kontext haben wir halt immer wieder Berührungspunkte mit agilen Ansätzen gefunden.
Genau mit dem Übergang, wie bringe ich entwickelte Produkte in den Betrieb und halte all diese Themenzahlen für uns auf die Ansätze ein, die DevOps verfolgt.
Und in diesem Kontext…
Beraten wir jetzt auch unsere Kunden.
Und damit gebe ich das Wort gern zurück an Dirk, damit wir hier inhaltlich einsteigen können.
Doch zuvor vielleicht noch Sebastian, magst du auch noch zwei Worte zu dir sagen?
Ja, hallo, guten Abend.
Vielen Dank, Dirk und Alex, für die Möglichkeit, uns vorzustellen.
Mein Name ist Sebastian Schulze.
Ich bin in der Direktgruppe seit über acht Jahren bisher tätig als Softwareentwickler und Teamlead in der Softwareentwicklung.
Und mache jetzt seit Anfang 2017 das Thema DevOps und Transformationsberatung.
Ich komme aus dem softwareentwickelnden Bereich der Direktgruppe.
Deswegen liegt mir das in der DNA und kümmere mich eben vornehmlich um Fragestellungen der Digitalisierung von Softwareentwicklungsprozessen, das heißt Continuous Delivery.
Im Wesentlichen…
Und da spielt es natürlich eine große Rolle, dass die große Klammer DevOps, wie kriegen wir hier die Zusammenarbeit im Unternehmen wieder neu geregelt und verbessert?
Wie werden Unternehmen wandlungsfähiger?
Wie kriegen wir in die Unternehmen eine entsprechende Kultur und bilden entsprechende notwendige Haltungen bei den Mitarbeitern und Führungskräften aus?
Ja, sodass deren Unternehmen wieder wandlungsfähiger und schneller werden in der Produktion von Software und IT.
Sebastian Volkert, vielen Dank für die Vorstellung.
Herzlich willkommen auch von meiner Seite, Alex Lichtenberger.
Ja, auch heute wieder das Thema DevOps.
Und ja, DevOps, ich denke, es herrscht ja generell Einigkeit, was wir damit erreichen wollen, auch warum DevOps ein Thema wird.
Aber DevOps dann auch, wenn es um die Umsetzung geht, ist das sehr wichtig.
Es ist sehr komplex.
Und da kommen verschiedenste Elemente zusammen.
People, Process, Technology, aber auch methodisch.
Agile, der Sebastian hat es erwähnt, dann aber auch Lean und Service Management.
Ja, und da hat, denke ich, die Direktgruppe, und das wird auch das Thema heute, eine super Visualisierung gefunden, um diese Komplexität auch ein bisschen Struktur einzubringen.
Also mit ihrer Metro Map, das heute so im Fokus.
Bevor wir aber…
Bevor wir dann auf diese Metro Maps zu sprechen kommen, wir stellen ja inzwischen bei jedem Podcast unseren Gästen die Frage, was ist DevOps?
Also deshalb auch an euch, Sebastian Volkert, die Frage, was versteht ihr unter DevOps?
Kann man das definieren überhaupt?
Wie würdet ihr es definieren?
Ja, bitte.
Ich übernehme mal das Wort zuerst.
Ich nehme vornehmlich wahr, dass es…
…eine irrenführende Wahrnehmung gibt, weil viele glauben, dass DevOps ein Job ist oder eine Jobbeschreibung.
Man sieht das häufig jetzt so in Stellenanzeigen oder so, dass DevOps-Engineers gesucht werden, wo meines Erachtens dysfunktional versucht wird, das mit einer Stelle zu erschlagen.
Ich vergleiche das ganz gerne damit, dass man ja auch nicht als Unternehmen hingehen würde und sagen würde, dass man das mit einer Stelle zu erschlagen würde.
Ich würde sagen, wir stellen jetzt einen Zusammenarbeitsspezialisten ein, der zukünftig die gesamte Zusammenarbeit in einem Unternehmen verantwortet und durchführt.
Insofern wird es auch das Thema DevOps nicht schaffen, zumindest nach dem, was ich mir da so vorstelle und viele andere auch.
Es geht hier vielmehr um ein Mindset, was eben diese Prozesse…
…Culture miteinander in Beziehung setzt und es einfach aus dem Wunsch heraus entstanden oder heutzutage weiterverfolgt, dass Unternehmen schnell und handlungsfähig werden wollen, was das Thema Softwarelieferung angeht.
Wir nehmen das häufig fest, zumindest stellen das fest, das tue ich bei meinen Kunden auch, bei denen ich als Berater auftrete, dass dort häufig gewachsene hierarchische Unternehmen…
…Unternehmenstrukturen da sind, wo IT weniger Enabler ist, sondern sich über die Zeit aufgrund bestimmter Einflussfaktoren vielmehr als Blockierer oder Verwalter darstellt, in denen so Not-My-Job und Verweigerungshaltung an der Tagesordnung sind oder zumindest von den Leuten, die IT in diesen Unternehmen in Anspruch nehmen, den Business Units, den Fachabteilungen…
…dass da das Gefühl entstanden ist, wir kommen hier nicht weiter, wenn wir uns an unsere IT wenden, da braucht es Jahre und das haben natürlich Mitarbeiter wie Entscheider erkannt, dass das in der heutigen Welt mit der Geschwindigkeit, mit der entwickelt wird, dass das nicht mehr so ganz passt und dass wir hier erleben, dass kleine Startups in der Wertschöpfung, was jetzt neue Technologien…
…Nutzung oder auch neue Geschäftsmodelle angeht, die großen etablierten Konzerne, die eigentlich genug Manpower und genug Geld dafür hätten, abhängen, was die Innovationskraft angeht und im Zweifel auch deren Geschäftsmodelle angreifen und das will man sich natürlich hier nicht bieten lassen.
Ich will nicht sagen, dass DevOps nur aus dieser Konzernsicht motiviert ist, aber für uns wandelt es sich.
Von diesem Kerngedanken kriegen wir nicht auch Infrastruktur agil, das war ja mal Keimzelle dieser DevOps-Bewegung, nachdem man ja Agilität in der Softwareentwicklung schon lange Jahre praktiziert hat.
Aber das ist für uns die Realität. Wir sind da bei Unternehmen und müssen erklären, dass es eben nicht nur Technologie ist, die DevOps darstellt oder diesen Gedanken, dieses Mindset, häufig auch als Philosophie bezeichnet,
…sondern im Wesentlichen das Zusammenleben.
…das Zusammenleben von, na klar, Development Operations, aber auch dem Business, was wieder lernen muss, gemeinsam zu funktionieren für gemeinsame Wertschöpfung.
Back to the Roots, ja. Dann die Frage, wie seid, also ihr als Direktgruppe macht ja schon eine ganze Weile Beratung, Technologie, IT-Beratung. Wie seid ihr überhaupt zum Thema DevOps gekommen? Was waren da so die Treiber dafür?
Würde ich sagen, wir haben da Verschuldung.
Wir haben da verschiedene Anknüpfungspunkte, weil wir in der Direktgruppe ja durchaus verschiedene Arten von Beratungen anbieten, was in dem IT-Spektrum, Volker wird das gleich bestimmt ergänzen, für mich als jemand mit Softwareentwicklungs-DNA war das klar geworden in den letzten Jahren, dass eben rein dieses agile Entwickeln nicht ausreicht.
Wir haben dann festgestellt, wir müssen uns selber stetig erneuern.
In der Art, wie wir Softwareentwicklungsprojekte machen. Für uns gehört es zwar immer zum, war immer ein Teil davon, dass wir die Software, die wir selber entwickelt haben für unsere Kunden, meist auch selbst betrieben haben.
Das heißt, uns ist es relativ selten begegnet, dieses klassische Silo-Denken, aber wir haben festgestellt, dass natürlich auch in unserer eigenen Organisation diese Silos entstanden sind.
Und haben dann…
Selbst daran gearbeitet, wie wir das wieder reduzieren.
So sind wir rein aus praktischen Aspekten, weil wir das selber brauchten, um am Markt überhaupt konkurrenzfähig zu sein.
Haben wir dann aber festgestellt, es gibt viele andere Unternehmen auch, die sich mit diesen Fragestellungen plagen und die nicht damit gesegnet sind, diese Erfahrungen gemacht zu haben.
Beziehungsweise die einfach von der Organisation selbst, vielleicht nicht ganz so wendig.
Wie wir das sind und waren.
Deswegen haben wir gesagt, wir möchten gerne unsere Erfahrungen und die, die wir jetzt auch noch sammeln.
Ich möchte nicht sagen, dass wir da die Weisheit mit Löffeln gefressen haben.
Auch wir haben noch viel zu lernen.
Dass wir das unseren Kunden auch als ein neues Portfolio-Element anbieten.
Und die Dinge, die wir da jetzt lernen, selbst lernen und bei Kunden sehen und wie wir uns da weiterentwickeln, fließen.
Wir fließen dann wieder in unsere eigenen Software-Entwicklungsprozesse ein.
Deswegen ist das so ein sich selbst befruchtendes System.
Was einen ganz wesentlichen Aspekt, ich habe es jetzt schon mehrfach wiederholt in meiner Rede, begünstigt, nämlich dieses kontinuierliche Lernen.
Ich denke, das steht für mich jetzt ganz persönlich auch im Zentrum des Ganzen.
Und so sind wir eigentlich dazu gekommen, was wir jetzt da machen.
Und der Volkert hat da jetzt nochmal eine ergänzende Sicht, glaube ich, draus.
Da möchte ich dich bitten, ergänz das doch bitte nochmal.
Letztlich hast du ja gut dargestellt aus der Perspektive Software-Entwicklung, Software-Herstellung und Inbetriebnahme die Aspekte, die zu DevOps gehören.
Aus meiner Beratungswelt und meines Teams komme ich mehr aus der Betriebs- und Organisations- und auch aus der Prozessseite.
Und stelle halt auch hier fest, dass durch neue Technologien, vornean natürlich immer wieder genannt Cloud.
Computing, verschiedene Erwartungen daran gestellt werden.
Und eine der Erwartungen heißt Geschwindigkeit.
Bestehende IT-Organisationen von großen Unternehmen, denen fällt es halt sehr schwer, hier die technische Integration zu realisieren und dabei auch gleichzeitig schnell zu werden.
Und dieses Schnellwerden ist da meines Erachtens ein ganz wesentlicher Treiber für Initiativen im Kontext DevOps.
Projekterfahrungen, Projektmanagement-Erfahrungen sammeln sich dazu, indem man halt,
Scrum-Elemente anwendet und dann iterativ auch Non-Software-Entwicklungsprojekte durchführt.
Also vielleicht IT-Infrastrukturprojekte, Server-Konsolidierung, Rechenzentrums-Zuladenlegung oder ähnliches.
Trotzdem hapert es immer wieder an der Geschwindigkeit.
Und diese Thematik wollen wir hiermit gerne aufgreifen.
Und den Punkt sehen wir da drin.
Innovation ist vielleicht noch eine weitere Thematik.
Die halt aus der Betriebssicht und aus der Entwicklungssicht vielleicht noch teilweise sehr weit weg erscheint, weil ja doch in der Praxis im Allgemeinen die Unterstellung formuliert wird, die IT ist viel zu weit weg vom Business und viel zu weit weg an neuen Geschäftsmodellen, die idealerweise digital sein sollen.
Und aus diesen drei Sichten heraus jetzt mal ein stärkeres Zusammenrücken hervorzubringen.
Und das sind Aspekte, die wir auch mit DevOps verbinden.
So und das führte uns dann zu dem Gedanken, da eine Visualisierung zu schaffen.
Und Alex und Dirk, ich glaube, an der Stelle kommt jetzt auch gleich eure nächste Frage.
Welches Ziel habt ihr denn überhaupt mit dieser Meta-Map verfolgt?
Das ist eine wunderschöne Karte, aber was habt ihr als Ziel damit verfolgt?
Also wir standen ja vor der Frage, als wir jetzt das Thema DevOps als Portfolio-Punkt für uns aufgenommen haben.
Wie kriegt man eigentlich ein gemeinsames Verständnis davon?
Gerade weil wir selbst ja auch verschiedene Sichten innerhalb der Direktgruppe hatten, aber auch mit den Leuten, die wir außerhalb unserer Organisation gesprochen haben, gab es halt immer wieder verschiedene Auffassungen.
Und wir wollten hier eine Möglichkeit schaffen, diesen Begriff DevOps mit allem, was dazugehört, vielleicht eher nicht dazugehört, mal zu strukturieren und haben uns versucht,
an einer Darstellungsform.
Die erstmal Diskussionsgrundlage gibt.
Klarheit schafft über das, was wir darunter verstehen und das, was unsere Ansprechpartner, Kommunikationspartner, Kunden darunter verstehen und haben da verschiedene Dinge ausprobiert.
Man versucht ja immer gerne in hierarchischen Schemata zu denken, wie so eine Ordnerstruktur und daran haben wir uns die Zähne ausgebissen.
Und dann haben wir festgestellt…
Alles, was für uns zum Thema DevOps assoziiert werden muss, müssen wir anders darstellen.
Und so sind wir in diese MetroMap-Darstellung gekommen.
Also ich höre da auch heraus, ich habe verschiedene Dinge ausprobiert und das ist ein Resultat aus dem Entwicklungsprozess.
Und vielleicht auch zum, genau bevor wir zum Aufbau der MetroMap kommen, vielleicht an die Zuhörer, weil das ist ein Podcast, das heißt, ihr könnt die MetroMap nicht sehen.
Also es lohnt sich da, das vielleicht sich jetzt auch…
Vor Augen zu führen, also zum Podcast, also einen Link zur Grafik selber.
Es lohnt sich natürlich, das auch noch anzuschauen.
Aber jetzt vielleicht Frage an euch, Sebastian und Volker, könnt ihr mal so den Aufbau dieser MetroMap kurz erläutern?
Ja, im Wesentlichen haben wir festgestellt, wir haben verschiedene Achsen, auf denen ja eine Einordnung von Begriffen…
… im DevOps-Umfeld einzuordnen sind.
Wir haben jetzt drei große Bereiche, auf jeden Fall klar, Development, die Entwicklung, der IT-Betrieb, Operations.
Aber was uns ganz wichtig war, auch das Business mit reinzunehmen.
Weil aus unserer Wahrnehmung, das teilen ja auch viele andere, wenn man sich so umhört, darf ja IT nicht den Eindruck erwecken, es wäre ein Selbstzweck, sondern es muss immer einen Nutzen.
Deswegen halt der dritte Pol ganz oben, das Business.
In diesem Dreieck haben wir versucht, die Begrifflichkeiten, die sich hier finden, einzuordnen.
Sicherlich ist die Einordnung nicht ganz trennscharf.
Ich hatte ja eben schon ausgeführt, Kategorisierungen gelingen da nicht so einfach.
Man findet immer Argumente für und gegen.
Und es basiert ja jetzt auf keiner empirischen Untersuchung.
Sondern es ist halt eine Meinungsverwaltung.
Außerdem haben wir festgestellt, gibt es noch fünf weitere Achsen, die wichtig sind, immer gern im DevOps-Kontext wiederzufinden.
Das Thema People, Technology und Processes.
Wir wollten aber ganz klar noch zusätzlich reinnehmen, dass für uns das Thema Innovation ein ganz wichtiges ist.
Innerhalb von DevOps, was wir gerne separat herausstellen wollten.
Und zusätzlich ganz wichtig ist, ist das Thema IT-Service-Management.
Weil man darf DevOps jetzt nicht als etwas darstellen oder betrachten oder verstehen, was jetzt im luftleeren Raum neu entstanden ist.
Sondern was ja auch auf Bestehenden aufsetzt.
Und insbesondere das Thema IT-Service-Management ist da wichtig, weil da gibt es ja viele Ansätze, viele Lösungen auch in der Vergangenheit.
Und der Gegenwart, die wir da besonders herausstellen wollten, weil uns dazu auch viele Leute fragen.
Und diese fünf Achsen stellen für uns hier die, ich nenne es mal U-Bahn-Linien dar, um im Bild zu bleiben.
Und deswegen haben wir die miteinander verbunden.
So, das ist der Grundaufbau.
Außerdem haben wir einen Kern, den wir abgetrennt haben, wie eine solche Tarifzone.
Wo wir sagen, für uns gibt es einen gewissen Konsens.
Dass bestimmte Dinge eher im Kern…
…von DevOps liegen und andere wichtig auch dazu gehören, aber für uns jetzt nicht den Kern ausmachen.
Deswegen haben wir hier versucht, nochmal so eine zentrale Tarifzone einzuziehen.
Ja, das ist ja dann das Interessante bei einem Podcast.
Wir reden über irgendetwas, was die Zuhörer nicht sehen.
Aber was wir jetzt schon gehört haben, ist, es ist eine Art U-Bahn-Linienkarte, die nicht nur DevOps hat, sondern auch das Business hat.
Und im Kern haben wir eben quasi die Tarifzone 1.
Also die Tarifzone 0 mit den wichtigsten Themen.
Was ich sehr interessant finde, sind diese fünf U-Bahn-Linien.
Und ihr habt ja auch gesagt, dass ihr das nutzt, um in die Diskussion zu kommen, um Dinge zu besprechen.
Ich sehe zum Beispiel, ganz interessant, wenn wir mal auf die Beispiele eingehen, dass zum Beispiel Service Operations,
was ja auf der ITSM-Linie, auf der IT-Service-Management-Linie liegt, dass das nicht zum Kern gehört.
Also vielleicht gleich die Frage.
Das ist nicht Kern von DevOps aus eurer Sicht.
Also wie diese Map entstanden ist, ist tatsächlich, dass wir uns mit Leuten auseinandergesetzt haben, die jetzt bei uns in der Organisation sind und die auch von außen kommen, sprich Kunden insbesondere, mit denen wir diese Ansätze reflektiert haben.
Und zur Vollständigkeit gehört auch, dass wir sagen, wir leben oder wollen auch mit dieser DevOps-Metro-Map einen Gedanken von Continuous Service Delivery.
Das heißt, das ist nichts, wo wir sagen, das ist für alle Zeit fest, sondern wir bessern das regelmäßig nach.
Gerade wenn wir neuen Input kriegen, der uns überzeugt.
Jetzt konkret auf das Service Operations gegangen, war für uns das Verständnis, Service Operations ist jetzt etwas, was grundsätzlich keine ganz neue Idee ist.
Wir finden hier bestimmt viele Dinge, von denen der eine sagt, ja, neu oder andere nicht neu.
Aber tatsächlich, wenn man jetzt den Unterschied…
…macht zwischen dem auf derselben U-Bahn liegenden Security, sind wir jetzt der Meinung, nach aktueller Entwicklungslage in der Community, was definiert man in DevOps rein?
Dann hat man jetzt mit diesem Begriff DevSecOps, hat man jetzt diesen Security-Begriff mit drin.
Deswegen haben wir den jetzt als eingebaute Security mit in den Kern gezogen.
Das Thema Service Operations betrachten wir jetzt hier als Macher.
Das ist auch sehr nah assoziiert, weil, wie gesagt, wenn ich von Continuous Service Delivery spreche, dann muss ich diesen Service auch betreiben.
Wir sind aber der Meinung, dass das auf dieser IT-Service-Management-Linie nicht mehr zwingend dazugehört, weil das etwas ist, was ich in der Vergangenheit auch schon betreiben musste in diesem Kontext Operations.
Deswegen haben wir uns entschieden, dass das die erste Station außerhalb des Kerns ist.
Ihr habt ja dasselbe immer gesagt.
Vorher ist es schlussendlich ein Produkt von der Meinungsbildung.
Aber es ist ja, man hat wahrscheinlich dann jeder ein bisschen eine andere Meinung.
Gehört es jetzt noch dazu oder nicht?
Aber das Schöne, dass man dann anfängt, darüber zu diskutieren, wenn man so das vor sich hat.
Das war auch noch eine Frage fürs Verständnis, auch der Map.
Ich sehe es jetzt im Sinne so wie eine Metro mit den Linienstationen.
Das hat einen bestimmten Grund, dass es genau in der Reihenfolge, also wenn ich jetzt beispielsweise People,
da sehe ich in Chord, in Know-how, Transfer, Collaborative Culture, Collective Ownership.
Hat das da irgendwas auf sich mit dieser Sequenz?
Also dieses Ordnungsprinzip ist natürlich schwer und es lässt sich häufig was reindeuten.
Aber man muss jetzt auch sagen, dass bis auf einige Highlights, die bewusst gesetzt wurden,
durchaus sich da Argumente reindeuten.
Warum das eine jetzt neben dem anderen steht, zum Beispiel das Thema Resilienz und Anti-Fragile,
das ist jetzt auf der People-Linie gelandet, dass wir gesagt haben,
Anti-Fragile ist etwas stärker noch als Resilienz, aber genauso gut könnte man Argumente dagegen finden.
Was interessant da hervorzuheben ist, aus meiner Sicht, ist jetzt die räumliche Nähe von diesen,
von diesen U-Bahnen.
Wie zum Beispiel, du hast es eben rausgepickt, Collective Ownership und Common Metrics.
Das ist jetzt auf der einen Seite auf der People-Ebene, dieses Collective Ownership,
das heißt, dass wir uns auch gemeinsam den Gegenstand, in dem wir arbeiten,
und die Business-Ziele und die technologischen Lösungen zu eigen machen
und damit auch eine Eigenverantwortung tragen.
Und damit sowas geschehen kann,
wollen wir auf dieser Linie IT-Service-Management das Thema Common Metrics sehr nah dran platzieren,
weil wir durchaus feststellen, ich gehe jetzt mal in dieses Bild rein,
der Wall of Confusion, die ja in DevOps häufig bemüht wird,
wo halt eine Wand ist zwischen Dev und Ops, wo man sagt,
wenn wir nicht auf gemeinsam harmonisierte Ziele hinarbeiten und die entsprechend ja dann auch für uns messbar werden,
auch interdisziplinär, dann könnte es uns schwerer fallen,
diese Collective Ownership für uns zu etablieren oder anzunehmen.
Deswegen haben wir gesagt, na, da könnte es doch vielleicht einen solchen Umsteige-Bahnhof geben,
um weiter metaphorisch zu bleiben.
Ja, das wäre jetzt so ein Beispiel.
Oder vielleicht noch ein schnelles Beispiel hinterher.
Im Kern finden wir auch eine sehr nahe Verbindung oder sehr nah angeordnet,
das Thema Change-Management aus dem ITSM und das Thema Continuous Integration,
was wir jetzt eher auf der Prozesslinie haben.
Da gibt es häufig Diskussionen und irgendwie eine thematische Nähe, die wir darüber darstellen wollen.
Vielleicht kann ich da nochmal ergänzen, genau den Punkt, den du gerade eben genannt hast.
Auf dieser Prozessebene haben wir einerseits Continuous Integration und Continuous Delivery draufstehen
und das verbunden mit einem IT-Service-Management und Change-Management.
Da lässt sich ja wunderbar darauf diskutieren, wie skalieren wir einen Change-Management-Prozess etabliert,
nach Eifel, seit 1998 bei einem Kunden vielleicht implementiert.
Wie skalieren wir denn das in eine Landschaft, die fortwährend Pakete bereitstellt, Software-Pakete?
Wird jedes einzelne Paket ein Change?
Wie wird er autorisiert?
Muss der durch einen Change-Advisor-Report gehen?
Das sind Aspekte, die man halt hervorragend hier draufstellt.
Worauf diskutieren kann.
Und eben One-Size-Does-Not-Fit-All ist sicherlich auch ein Aspekt,
wo doch mitunter individuelle Lösungen zu finden sind, die dann auf die jeweilige Unternehmung anzupassen sind.
Diese Diskussionsgrundlage finde ich sehr wichtig und bekomme auch häufig dann die Frage,
wie ist das hier mit der Reihenfolge?
Und muss da dann halt auch als Prozessberater sagen,
das ist hier keine Prozesskette, die mit den Stationen abgebildet ist.
Und wenn man sich selbst als Fahrer einer U-Bahn oder Straßenbahn bewegt,
fährt man die auch selten immer von Startstation bis Endstation vollständig durch.
Man fährt vorwärts und rückwärts, man steigt um.
Das wollten wir hier auch entsprechend mit anregen, diese Analogie entsprechend weiterzutragen.
Und dann die Nähe der Stationen, die hat ja dann die Bedeutung.
Also man sieht es auch schön, zum Beispiel Continuous Monitoring,
Technology, ja, und das dann verknüpfen mit Incident Problem Management, macht absolut Sinn.
Oder wenn man sich die Innovation-Linie, die gelbe oben anguckt,
dann findet man eine räumliche Nähe, auch auf einer Linie, von dem Thema Lean Startup und Minimum Viable Product,
was ja da von Eric Ries in seinem Buch Lean Startup verortet wurde.
Und dann kommen wir schon recht bald zu Design Thinking.
Also so eine assoziative Nähe ist da grundsätzlich auch,
zu finden, auch bei Culture of Failure und Fast Feedback Loops.
Aber was wir nochmal unterstreichen wollen, wir sind dankbar für jedes Feedback,
was das nochmal klarer macht, ergeben uns aber jetzt nicht einer Hoffnung oder Jagende hinterher,
dass wir hier den heiligen Gral von DevOps haben, sondern wir freuen uns halt immer,
wenn da eine Diskussion in Gang kommt und wenn es da auch mal kontroverse Meinungen gibt.
Und das gelingt ganz gut.
Ja, eine Rückmeldung.
Eine Rückmeldung von mir, was mir sehr gut gefällt, ist, dass das Thema IT-Service-Management bei euch zum Kern mit dazu gehört.
Ihr habt wesentliche Prozesse mit drin im Kern.
Ihr habt überhaupt schon mal eine IT-Service-Management-Linie.
Also insofern finde ich das schon mal sehr schön, weil ich glaube,
dass DevOps schon auch eine Art Weiterentwicklung sein kann von IT-Service-Management,
wenn man sich einfach mal auf Frameworks bezieht.
Also insofern finde ich das als Rückmeldung dazu, Sebastian, schon sehr, sehr interessant.
Ja, also danke für die Vorlage, Dirk.
Denn das Thema IT-Service-Management liegt mir halt auch am Herzen und zeigt halt auch auf,
ja, das hat vielleicht einen leichten Charme mit Patina,
aber hat auch irgendwie eine Berechtigung, wenn es nicht als Selbstzweck verstanden wird.
Und an der Stelle bewegen wir uns hier.
Also ein Incident- und ein Problem-Management ist halt weiterhin wichtig
und auch ein Configuration-Management ist weiterhin wichtig.
Und das gehört halt auch unbedingt zu einem Kern,
so ein Verständnis.
Ja, schlussendlich sind das ja alles Hilfsmittel.
Und auch im IT-Service-Management hat es ein paar super Ideen, die DevOps unterstützen.
Und das ist schade dann, wenn die Diskussion dann zum Teil emotional geführt wird.
Dafür gibt es dann schon die Szene, die dann sagt,
ja, DevOps ist der Tod von IT-Service-Management.
Also das sehe ich nicht so.
Da stimme ich absolut euch auch zu.
Genau, also wir haben da ja auch lange drüber debattiert.
Und ich glaube, nicht nur persönlich,
sondern es sollte auch Konsens innerhalb der Direktgruppe sein.
Und das, was wir auch in unseren Veranstaltungen mit Kunden da als Feedback kriegen.
Irgendwo liegt die Wahrheit dazwischen.
Das heißt, IT-Service-Management stirbt damit nicht aus.
Aber bestimmte Konzepte, beziehungsweise die Umsetzung dieser Prozesse
müssen vielleicht neu gedacht werden unter dem Eindruck der Möglichkeiten der Automation.
Ja, und jetzt komme ich mit einem Hinweis.
Mit einer Frage, wenn man sich das anguckt.
Das Thema Cloud.
Das habt ihr zwar mit aufgenommen, sehr nett, aber es ist nicht zum Kern.
Warum gehört denn Cloud bei euch nicht zum Kern von DevOps?
Ja, interessante Frage.
Bist du nicht der Erste, Dirk, der das fragt?
Wenn man argumentiert, dass man sagt, wir haben software-definierte Infrastruktur,
dann ist es bestimmt ein wesentlicher Enabler von DevOps.
Ohne dieses würde es weniger Möglichkeiten haben.
Nämlich die technologischen Möglichkeiten, der Fortschritt treibt ja überhaupt,
dass wir so etwas wollen, was für uns hinter DevOps steckt und dass wir das können.
Also sprich, Geschwindigkeit aufnehmen und vielleicht auch mehr in Wegwerf zu denken
als in Wiederherstellung.
Ohne Cloud wäre das bestimmt nicht möglich.
Aber wir sind der Meinung, dass jetzt Cloud alleine, gerade vor dem Hintergrund,
derkt.
Ja, dieses Public-Cloud-Gedankens, der da ja am nächsten liegt,
nicht unbedingt notwendig ist, um so etwas wie DevOps zu betreiben
oder in dieser Richtung sich zu entwickeln.
Weil es durchaus auch andere Möglichkeiten gibt,
DevOps zu, oder Werte, die DevOps ausmachen,
in einem Unternehmen zu etablieren.
Dafür braucht man nicht unbedingt die Cloud.
Das heißt, wir wollten damit ganz deutlich machen,
dass man nicht aufgeben muss, nur weil es in einem Unternehmen,
in Klammern noch, keine Cloud-Strategie gibt.
Das ist der Gedanke dahinter.
Ja, ich wollte noch einen Punkt noch einmal ausführen.
Natürlich schauen wir jetzt auf diese Linie, die den Core von DevOps aufzeigt.
Aber das ist halt erstens keine harte Linie, sie ist gestrichelt dargestellt.
Und alles, was auf der Metro-Map zu sehen ist,
sind für uns DevOps-relevante Aspekte.
Und das mag sicherlich außerhalb der Map noch weitere Dinge geben,
die da auch zugehörig sein können.
Aber all das gehört dazu.
Und oft ist natürlich auch die Frage, womit fange ich denn an?
Wenn ich schneller, wenn ich meine Kultur mehr in Richtung Innovation bringen will,
wenn ich ein anderes Werteverständnis schaffen will,
brauche ich dafür Cloud?
Und die Antwort heißt, nicht unbedingt.
Hilft bestimmt.
Und auch…
Auch andere Aspekte, vielleicht Start-up-Aspekte,
die jetzt auf der Innovation-Linie liegen,
die brauche ich auch nicht unbedingt.
Das ist aber auch gestrichelt.
Ja.
Und wenn ich das als praktisch überlege,
wenn ich jetzt in die Diskussion würde gehen mit einer Map,
kann ich es immer kritisieren und jeder hat seine Meinung.
Aber ich glaube, eben darum geht es nicht,
sondern die Diskussion und dann eben auch eine Lücke zu erkennen.
Also wenn man zum Kunden sagt,
ah, okay, ja, aber…
Collaborative Culture,
da haben wir jetzt überhaupt noch nicht dran gedacht.
Und dann das zu erkennen und dann daraus auch so etwas wie Massnahmen abzuleiten,
ist es richtig?
Verwendet ihr das auch in dem Kontext?
Absolut.
Und gerade hier haben wir ja oftmals einen Startpunkt von Continuous Delivery
und agiler Entwicklung.
Ohne das Mindset, ohne Collaborative Culture wird es schwierig.
Und genau deshalb steht der…
Steht die Station halt im Core-Bereich, wo wir sagen,
ja, das ist ein Aspekt, über den man unbedingt nachdenken sollte,
wenn man sich hier mit diesen Ansätzen beschäftigt.
Continuous Testing, da ist es auch…
Gut, kann man jetzt abdiskutieren,
aber für mich ist eigentlich Continuous Testing
ein zentraler Enabler für Continuous Delivery.
Ich will ja Tests automatisieren, Feedback Loops.
Wieso habt ihr…
Müsste man das nicht ein bisschen weiter nach rechts verschieben?
Oder was ist das Argument?
Dass ihr es da draußen habt?
Berechtigte Frage.
So wie du es beschreibst, würden wir das…
Also kann ich dem folgen und würde ich auch sagen,
das kann genauso gut drin sein.
Wir haben das Gefühl gehabt bei der Einordnung,
dass das Thema Continuous Testing ähnlich wie Bildautomation
insofern nichts Neues ist,
als dass wir schon…
schon seit vielen Jahren, sage ich mal,
automatisierte Unit-Tests im Zusammenhang
mit Continuous Integration betreiben.
Vor dieser Argumentation würde ich selber auch infrage stellen,
was tut denn jetzt Continuous Integration da?
Das gab es ja auch schon vorher.
Im Zusammenspiel aber mit dem Change Management
und dann dieser Nähe zur Continuous Delivery
kriegt es, sage ich mal, eine neue…
irgendwie eine Ressistance, will ich gar nicht sagen,
aber etwas nochmal ein anderes Gewicht,
und gehört deswegen da rein.
Ähnliche Argumentationen kann man bestimmt auch
mit Continuous Testing führen.
Deswegen würde ich mich da jetzt persönlich
auch gar nicht so festlegen.
Ich stelle fest, es ist sehr nah am Rand,
an der Tarifzonen-Grenze,
und ich würde mal ganz stark hoffen,
dass da kein Kontrolleur kommt und meine Fahrkarte überprüft,
wenn ich da am Rande unterwegs bin.
Insofern tatsächlich muss man auch sagen,
hier sind wir wieder auf dem Thema Deutung,
und mir ist ganz wichtig, dass man das nicht vergisst.
Und wenn man genau diese Frage stellt,
dann bin ich der Meinung, ist man grundsätzlich
mit dem Thema DevOps und dem Mindset in der Umsetzung
schon gut unterwegs.
Wir haben das ja auch schon in verschiedenen Formaten,
auch in Social Media bereitgestellt,
und da haben wir zum Teil lebhafte Diskussionen gehabt,
insbesondere auch ein Feedback, was wir jetzt häufig wieder kriegen,
woran sich die Leute denken, dass wir das nicht machen,
woran sich die DevOps-Metro-Map messen lassen muss
oder wo sie gemessen wird.
Die Frage, super, dass es da eine Einordnung gibt,
super, dass man eine Übersicht hat,
dass man eben eine Besprechungsgrundlage hat
in bestimmten Situationen, um nichts zu vergessen
oder zumindest Dinge bewusst nicht weiter zu verfolgen
oder zurückzustellen.
Aber was es natürlich auch nicht beantwortet,
ist die Frage, wie komme ich denn jetzt
in eine DevOps-Transformation rein?
Da wäre man falsch verstanden, wenn man jetzt sagt,
ich setze mich jetzt hier in die rote Linie und fahre mal los,
und wenn ich am Ende angekommen bin, bin ich DevOps.
Die Endhaltestelle bei DevOps ist, glaube ich,
sowieso noch nicht gefunden allgemein.
Und ich denke, wenn man das konsequent weiterdenkt,
dann wird es sie auch nicht geben.
Aber hier muss man halt nochmal klar schärfen,
wir schicken uns hier nicht an,
eine Blaupause für eine DevOps-Transformation zu machen.
Das ist viel vielschichtiger,
wenn man in so einen Prozess einsteigt,
sondern hier geht es tatsächlich um eine begriffliche Sortierung,
Einordnung, Gesprächsgrundlage.
Und ich glaube halt auch,
dass die Anlässe je Unternehmen sehr individuell sind.
Und deshalb ist es eben nicht eine Perlenkette,
die aufgereiht ist, die man abfährt, um am DevOps-Ziel anzukommen,
sondern jede Kundensituation, die wir in der Vergangenheit erlebt haben,
war ganz individuell.
Jeder Kunde steigt an einer anderen Stelle ein
und an einer anderen Stelle steigt er wieder aus
und bewegt sich dann aber doch immer in diesem Kernbereich.
Also ich glaube, man kann diese Karte sicherlich sehr gut nutzen,
um in Workshops zu thematisieren,
dass vielleicht einzelne Gruppen die einzelnen Linien erklären müssen
und eine Reihenfolge erklären müssen und so weiter.
Das ist einfach ein guter Ansatzpunkt,
eine gute Möglichkeit, sich mit den Themen,
mit den Begriffen und mit anderen Dingen zu beschäftigen.
Wir reden ja häufig auch über das Erweitern des eigenen Horizonts.
Das heißt, wir müssen ja erstmal die Vertreter
aus dem Business Development und Operations
überhaupt auf eine Gesprächsgrundlage kalibrieren.
Und es ist ja im DevOps-Bereich ja immer dieses
über den Tellerrand hinausschauen,
mit den anderen sprechen, gemeinsam aneinandergehen.
Und das gelingt in dem Zusammenhang hier auch zumindest
als erstmal Einstieg, der noch nicht zu schwergewichtig ist,
wenn man die Vertreter an einem Tisch hat.
Ich wollte noch eine kurze Anekdote ergänzen.
Bei einem Kunden hängt die Metro-Map als Poster an der Wand
direkt neben dem dreijährigen Release-Kalender.
Also das Poster des Release-Kalenders hängt da nicht drei Jahre,
sondern zieht sich halt auch zu einem Zeitraum.
Und es ist mit Bewusst und Intention dort angehängt
und löst wunderbare Gespräche aus.
Wie passt das jetzt zusammen?
Wir haben einen Release-Kalender in einer klassischen Form
und wollen schnell werden, wollen Aspekte aufgreifen,
die dann auf der Metro-Map stehen.
Und wie schaffen wir das?
Ich finde, das sind sehr konstruktive Diskussionen,
die sich daraus ableiten.
Das ist schlussendlich ein super Instrument.
Und wie gesagt,
um in die Diskussion zu gehen.
Und ich denke auch,
wie eingangs gesagt,
DevOps hat so viele Dimensionen.
Und dann auch,
weil oft wird DevOps sehr einseitig,
als eine reine Tool-Geschichte.
Aber andere sehen es als eine reine Kultur-Geschichte.
Und dann kann so ein Bild helfen,
um das Wort zu benutzen,
um eine holistischere Sicht zu bekommen.
Dirk, hast du noch Fragen dazu?
Also ich habe keine Fragen.
Es sei denn, die Frage,
wie wird die Map in fünf Jahren aussehen beispielsweise,
das ist sicherlich interessant.
Also vielleicht trifft man sich ja mal wieder in dem Podcast hier.
Aber für heute, denke ich, hoffe ich zumindest,
haben unsere Zuhörer einfach auch interessiert gemacht an dieser Map,
dass sie sich die anschauen, dass sie die nutzen.
Und vielleicht auch wirklich in mehreren Büros mittlerweile
dann so eine DevOps-Metro-Map
neben einem dreijährigen Release-Kalender hängen.
Und wenn wir jetzt bei dem Metro-Map,
Analogie-Bild bleiben, kann man natürlich sagen,
eine neue Linie lässt sich natürlich hier in dieser Form
viel agiler schaffen, als wenn man sich das in der Realität vorstellt.
Wenn man bedenkt, wie lange der U-Bahn-Bau in Hamburg
in Richtung HafenCity gedauert hat
oder was die Stadt Köln zur Anbindung der Südstadt veranstaltet,
inklusive eines Stadtarchivs,
was dort in Mitleidenschaft gezogen wurde,
kommen wir hier, glaube ich,
relativ schnell in die Richtung.
Schnell voran, sagen aber auch,
die Stationen, die wir hier aufgesetzt haben,
die haben hier erstmal einen gewissen Bestand,
sind aber doch recht flink darin,
gegebenenfalls die Linien noch zu ergänzen.
Gut, dann sage ich Dankeschön von mir
und auf Wiederhören beim nächsten Podcast.
Alex, was haben wir beim nächsten Mal als Thema?
Ja, das ist noch nicht definitiv.
Also wir haben ein paar interessante Themen im Köcher,
aber wir können es im jetzigen Zeitpunkt noch nicht definitiv sagen.
Aber wir würden das dann auf unserer Webseite,
dann, wo bald es bekannt ist,
publizieren, wer als nächstes dran ist.
Aber möchte ich mich auch herzlich von meiner Seite bedanken.
Also ich denke, es war wieder eine weitere Inspiration,
also Thema DevOps.
Und ja, möchte mich herzlich bei den beiden Gästen bedanken,
Sebastian und Volkert,
dass ihr euch die Zeit genommen habt.
Ja, vielen Dank auch an euch, an euer Interesse.
Und ich bin natürlich sehr gespannt,
ob das jetzt auch bei den Hörern hier auf Resonanz stößt.
Und wäre natürlich sehr erfreut,
wenn da das eine oder andere an Feedback
vielleicht dann auch an uns zurückfließt.
Vielleicht wird dann auch Dirks Spannung aufgelöst,
wie das Ding denn jetzt in der Zukunft dann sich weiterentwickelt.
Ja, genau. Ich bedanke mich auch.
Und in diesem Fall an die Zuhörer, denen wurde noch nicht gedankt,
dass sie es jetzt soweit bis zum Abschluss dieser Podcast-Folge
mit uns aufgenommen haben.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Wir freuen uns, wie gesagt, auf Interesse oder Feedback dazu,
um hier entsprechend Gedanken einfließen zu lassen
und die Diskussion vorzuführen.

Folge 3: Von der Anforderung in die Produktion in einer Stunde

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Podcast-Episode erörtern Olaf Garves und Ralf Knobloch von T-Systems MMS ihre Erfahrungen mit der Implementierung von DevOps-Prinzipien in ihrem Unternehmen. Sie betonen die Bedeutung von Schnelligkeit und Qualität in der Softwareentwicklung, diskutieren Herausforderungen und Vorteile der Integration von Entwicklungs- und Betriebsteams und unterstreichen die Rolle von Automatisierung, Continuous Integration und Continuous Delivery. Besondere Aufmerksamkeit wird der Überwindung traditioneller Silos zwischen Entwicklung und Betrieb geschenkt, sowie der Notwendigkeit, Kultur- und Einstellungsänderungen im Unternehmen zu fördern, um die Effizienz zu steigern und auf zukünftige Trends wie Container-Technologie und künstliche Intelligenz vorbereitet zu sein.

Inhalt

  • Einführung und Vorstellung der Gäste
  • Grundlagen und Philosophie von DevOps
  • Implementierung von DevOps bei T-Systems MMS
  • Herausforderungen und Vorteile der Integration von Entwicklung und Betrieb
  • Rolle der Automatisierung und Continuous Integration/Delivery
  • Überwindung von Silos und Kulturwandel im Unternehmen
  • Zukünftige Trends: Container-Technologie und KI in der Softwareentwicklung
  • Diskussion über Sicherheit und Datenschutz in DevOps-Umgebungen
  • Fallbeispiele und praktische Anwendungen von DevOps-Prinzipien
  • Abschlussdiskussion und Ausblick

Shownotes

  1. DevOps-Manifesto – Ein zentrales Dokument, das die Philosophie von DevOps beschreibt. DevOps Manifesto (ähnlich dem Agile Manifesto, da kein spezifisches DevOps-Manifesto bekannt ist).
  2. T-Systems MMS – Ein Full-Service-Projekthaus. T-Systems MMS
  3. Phoenix Project von Jim Kim – Ein Buch, das die DevOps-Prinzipien veranschaulicht.
  4. Docker – Eine Plattform zur Containerisierung von Anwendungen. Docker Offizielle Website
  5. Amazon Web Services (AWS) – Ein wichtiger Cloud-Service-Anbieter, der auch DevOps-Praktiken anwendet.

Transkript (automatisiert, daher keine Gewähr 🙂 )

DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zur dritten Folge unseres Podcasts
DevOps – auf die Ohren und ins Hirn.
Mein Name ist Alex Lichtenberger und ich bestreite diesen Podcast zusammen mit Dirk Söllner.
Der wird sich dann auch gleich vorstellen.
Ja, das Thema des heutigen Podcasts
DevOps in der Praxis – von der Anforderung in die Produktion in einer Stunde.
Das tönt ja schon mal sehr vielversprechend.
Ich möchte dazu auch ganz herzlich unsere beiden Gäste
Olaf Garves und Ralf Knobloch von der T-Systems MMS begrüssen.
Sie werden uns heute vorstellen, wie DevOps bei Ihnen bei der T-Systems MMS umgesetzt wurde.
Sie begleiten aber auch Kunden auf diesem Weg.
Also sicher ein sehr spannendes Thema.
Ja, dann würde ich mal sagen, bevor ich an den Dirk übergebe,
Olaf, Ralf, stellt euch doch mal vor, gleich mal zu eurer Person,
wer ihr seid, was ihr macht und dann auch zur Firma, was die machen.
Ja, sehr gerne. Hallo, mein Name ist Olaf Garves.
Ich leite ein sogenanntes,
Service-Feld, wo wir halt seit drei Jahren DevOps machen.
Meine Vergangenheit ist allerdings ein bisschen bewegter.
Ich komme aus einem Umfeld, wo ich auch immer schon interdisziplinär gearbeitet habe.
War früher Projektleiter für Software-Entwicklung,
habe dann eine Software-Entwicklungseinheit geführt
und dann kam mir der Gedanke, dass das Support-Geschäft
eigentlich auch eine ziemlich coole Idee ist, halt langfristig auch Umsatz.
Und Services zu bieten, weil unsere Kunden das auch verlangt haben.
Und daraufhin halt auch eine betrieblich orientierte Einheit mit aufgebaut.
Die ist inzwischen auch gewachsen.
Da steht auch ein Team dahinter, das habe ich nicht alleine gemacht.
Und als das Thema DevOps so vor vier, drei Jahren auch in Deutschland so auftauchte,
habe ich mich auch daran erinnert, dass ich ja früher auch mal Software-Entwicklung gemacht habe
und dass eigentlich die Zusammenarbeit eigentlich immer ein erfolgskritischer Faktor war.
Und so bin ich halt auch in das Thema DevOps auch reingekommen.
Ja, dann möchte ich mich als Zweiter vorstellen.
Ralf Knobloch mein Name.
Ich bin seit circa zweieinhalb Jahren bei der T-Systems MMS
und ich arbeite als verantwortlicher Lead-Architekt für das interne DevOps at MMS Programm.
Das Ziel dieses Programmes ist es, die MMS, die ein Full-Service-Projekt
House ist mit 1.800 Mitarbeitern und einer hundertprozentigen Tochter der großen T-Systems,
dass wir die Dienstleistungserbringung in den Dingen Software-Entwicklung,
Consulting, Test, Betriebsüberführung und den IT-Betrieb selber
möglichst so weit miteinander verbinden und automatisieren,
dass wir unsere Marktfähigkeit und Wettbewerbsfähigkeit am Markt
und in der T-Systems MMS weiter ausbauen.
Ich habe auch ein Leben vor der MMS.
Dort habe ich ein Cloud-Startup mit aufgebaut, wo ich auf die grüne Wiese
eine hochverfügbare Cloud-Lösung Software S-Code aufgebaut habe
und diese DevOps-Prinzipien umgesetzt habe.
Und noch davor war ich bei einem DAX10-Konzern und habe mich seit 2008 beginnend mit dieser DevOps
Thematik, Zusammenwachsen von und Automatisierung von Software-Entwicklung,
Test-Betrieb im Großkonzern verbunden mit vielen, vielen Dienstleistern beschäftigt
und konnte dort auch aus Sicht eines Großkonzerns erste DevOps- und Cloud-Automatisierungserfahrungen sammeln.
Wie gesagt, seit 2009 bis 2010.
Dort zu diesem Zeitpunkt konnte man den Begriff DevOps,
noch gar nicht so recht definieren.
Ich habe mit meinen Mitarbeitern damals, wo ich eine erste DevOps-Plattform,
die nannte sich Lifecycle-Management-Plattform, aufgebaut habe,
auch versucht, in der deutschen Wikipedia den Begriff DevOps zu definieren und zu bringen.
Diejenigen, die dort in 2010 den Begriff DevOps dann freigeben sollten, haben gesagt,
das ist kein richtiges Wort und haben das nicht verstanden, was zu diesem Zeitpunkt
sein sollte.
Das heißt, ich habe also einen recht frühen Umgang mit dieser, mit DevOps gefunden und
geprägt und bin auch dann von der MMS genau zu diesem Zweck, das Internet-DevOps-at-MS-Programm
bei der Umsetzung architekturell, technisch mit zu unterstützen, geholt worden und arbeite
immer noch in dieser Aufgabe.
MARKUS TRANTOW Ja, sehr schön.
Dann glaube ich, dann kannst du ja, Ralf, als …
Ralf, als erstes auch aus deiner Historie mal versuchen, wie man DevOps definieren kann
oder wie würdest du DevOps definieren, wie würdest du DevOps beschreiben?
RALF SCHMIDT Ja, ich würde, also mein Credo ist dabei immer, dass ich das DevOps-Manifesto
zu Rate ziehe oder heranziehe.
DevOps ist aus meiner Sicht eine Philosophie, die sehr viel Leidenschaft beinhaltet.
Es ist eine kulturelle, professionelle Bewegung mit Haltung und Wunsch.
RALF SCHMIDT Ja.
RALF SCHMIDT Ja.
RALF SCHMIDT Verちょ бы certificate
der EU.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SPEN iTunes, ja.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SPEN iTunes, ja.
Duke indications.
GRAetics.
der Software-Defined-Everything-as-Code-Bereitstellung
erfolgt, wo Sales Services entstehen
in der Infrastruktur, aber auch für Corporate
Integration oder Continuous Integration und Continuous Delivery
Pipelines. Und es ist auch
für mich eine Definition,
dass hier Software entsteht, die eigentlich, wenn alles gut
und richtig gemacht wird und DevOps gut umgesetzt wird, keinen oder kaum
Support benötigt wird im laufenden Run oder im laufenden Betrieb,
dass Teams aus Entwicklung und Betrieb auch
testintegriert zusammenwachsen und dass
Service-Verantwortungen entstehen, die die heute vorhandene
Silo-Trennung zwischen Entwicklung, Test und Betrieb zum Teil
aufheben, beziehungsweise wo diese Aufgaben
verschwimmen, weil der eigentliche
Entwickler versteht immer besser die Herausforderungen des Betriebes
und der Betriebler, der ja immer sagt
Never touch a running system, versteht langsam, dass man seine Infrastruktur
auch ständig kodieren und ändern kann.
Und wir haben dort ein Zusammenwirken von
System, das ist der Ausgangspunkt, hin zu unserer eigenen Philosophie,
wie wir im Programm, im DevOps at MMS-Programm arbeiten.
Every time change a running system.
Und das ist also eine totale Brain-Änderung an dieser Stelle.
Und das bedeutet auch, dass im DevOps eine kontinuierliche
Rückkopplung zwischen Entwicklung, Test und Betrieb erfolgt.
Und jetzt mal gemappt auf unser Unternehmen.
Also DevOps ist die eigentliche interne Digitalisierung
unserer eigenen Firma, also unseres IT-Full-Service-Projekthauses.
Ja, ich würde nochmal auf das eingehen,
was du eben gesagt hast, bevor wir dann zu Olaf nochmal rüber wechseln,
wie er DevOps sieht. Ich denke, und da haben wir ja noch ein bisschen Zeit,
das zu besprechen, ich denke, dass manchen Betriebler jetzt die Ohren klingeln
bei dem, was du eben gesagt hast. Und da haben wir bestimmt noch ein bisschen
Gesprächsthema. Olaf, wie würdest du denn DevOps definieren
oder beschreiben?
Ich würde das folgendermaßen beschreiben, dass natürlich
im Fokus der Kunden und die Funktion, die er benötigt für den
Markt, halt möglichst schnell, aber bei hoher Qualität
erstellt und in die Produktion gebracht werden.
In der heutigen Markt, im dynamischen Markt geht es
wirklich sehr schnell.
Und ich denke, das ist ein sehr, sehr wichtiges Thema,
weil es ist eine digitale Transformation, die sämtliche
Arbeits- und Lebensräume durchdringt. Es wird halt alles digital, es gibt
digitale Services. Und wer das halt so kennt von
seinem Smartphone, wenn da irgendwie eine App nicht so richtig funktioniert,
dann ist die in einem Wisch halt mal weg. Und das ist wirklich auch die
Veränderung, die wir auch selber als Dienstleister ja selber
unterliegen. Dazu hat die erst ja auch dieses Programm mit aufgesetzt.
Auf der anderen Seite möchten wir ja unsere Kunden auch damit beliefern,
damit die halt auch in einem Markt erfolgreich sind.
Und DevOps ermöglicht es wirklich in einer engen Zusammenarbeit
mit der Entwicklung, mit einer externen Entwicklung, das ist nicht unbedingt immer eine
interne Entwicklung sein, dass man da wirklich interdisziplinär zusammenarbeitet,
dass man auch die die das Verständnis
hat, gegenseitig. Und dass man auf Augenhöhe sich begegnet mit dem Ziel, auch mit dem Business, mit den Fachbereichen zusammen, mit der Testabteilung, dann ein gemeinsames Ergebnis auch zu liefern. Denn auf das Ergebnis kommt es drauf an und nicht, wer sozusagen jenseits der Mauer nun recht hat oder vielleicht was falsch gemacht hat.
Und was Ralf schon sehr richtig sagte, diese Feedback-Schleifen sind extrem wichtig, dass man sich gegenseitig Feedback gibt, Retrospektiven auch gibt und dass man sozusagen die Kultur des jeweils anderen, die früher vielleicht mal getrennt war, respektiert, aber auch da absolut Vorteile gegenseitig nutzt.
Und wir werden sicherlich später im Gespräch mal auf Beispiele kommen, wie sich das dann auch tatsächlich dann halt auch ausdrückt in der täglichen Praxis.
Ihr habt euch ja schon sehr früh mit dem Thema DevOps angefangen zu beschäftigen und wir werden dann die Beispiele und wie ihr das auch umgesetzt habt oder zum Teil vielleicht Kunden auch geholfen habt, darüber sprechen.
Eine Frage, die ich aber vorher noch spannend finden würde, ist eigentlich dann das Warum. Was waren eigentlich für eine T-Systems, MMS, weil DevOps hat ja keinen Selbstzweck.
Wir machen jetzt Agile oder DevOps und da gibt es ganz bestimmte Treiber.
Oft sind das auch externe Markttreiber.
Was hat euch, die Frage, was hat euch bewogen, das Thema DevOps schlussendlich anzugehen für die T-Systems, MMS?
Na ja, starte ich mal mit einer Antwort.
Da gibt es viele Antworten drauf.
Es wurde festgestellt, dass wenn wir als Projekthaus einen Full-Service,
also das Erbringen zu einem Kunden, also Entwicklung, Test und Betrieb, alles in einer Hand für einen Kunden machen,
dass die Überführung aus der Entwicklung dann auf ganz andere, im Betrieb teilweise auf ganz andere Eingangsvoraussetzungen getroffen ist.
Und das hat dazu bewogen zu sagen, oder das war unter anderem ein Treiber, lasst uns doch mal eine Infrastruktur definieren und finden,
sodass schon bei Beginn.
In der Entwicklung der Zielbetriebs- oder die Zielbetriebsumgebung genutzt wird.
Und diese Zielbetriebsumgebung, die muss natürlich feststehen und die muss Plattformen, Plattformen, damit meine ich zum Beispiel Cloud oder Server-Backend,
überall gleich funktionieren, ja, also gleich funktionieren sein.
Also ist egal, welche Cloud, sage ich jetzt mal, man nutzt.
Das entwickelt vielleicht auf einem Lohn.
Also bei einem lokalen Laptop oder PC, bei einem Entwickler entwickelte Software-Stück sollte überall gleichartig funktionieren,
möglichst bei den Plattformen, die man als Dienstleister oder als Projekthaus bedient.
Das war unter anderem ein Treiber.
Und ich glaube auch natürlich, dass es Kundennachfrage gab.
Ich selbst war ja auch mal auf einer Kunden- oder auf Kundenseite.
Und Olaf, du erinnerst dich sicher, wo ich sehr früh schon mal bei deinem,
du erst hier vorgesprochen habe und die Anforderungen, die man dort gerne umgesetzt bekommen hatte, skizziert hat.
Also auch Kundenanfrage, Kundenausschreibung, glaube ich, sind zunehmend der Treiber,
diese DevOps-Thematik stärker zu liefern und umzusetzen.
Und wir haben dadurch auch, glaube ich, das Ziel, alles oder mehr aus einer Hand liefern zu können.
Weil wenn man mit seiner, mit automatisierten Prozessen,
einem Kunden überzeugt bei der Dienstleister-Erbringung,
so gelingt es durchaus mehr als vielleicht nur Entwicklung oder nur Test oder nur Betrieb
von dem Kunden beauftragt zu bekommen.
Hat da der Wettbewerbsdruck, die Konkurrenz hat auch eine Rolle gespielt?
Also weil oft ist ja dann plötzlich ab einem Mitbewerber oder sagen wir mal Marktbegleiter,
der eben schon, der macht DevOps, der kann sehr schnell und konsistent,
solche Service auf dem Markt bringen. War das auch ein Treiber?
Wenn ich jetzt aus meiner Perspektive antworten darf, weil ich antworte ja sozusagen mehr aus der Produktion sozusagen,
der, wir haben mehrere externe Kunden, da ist es natürlich auch ein Treiber von den Fachseiten,
mit denen wir zusammenarbeiten, die natürlich auf dem Markt, wie gesagt, Marktanteile verteidigen.
Müssen oder halt wirklich auch sehr schnell sein müssen, weil halt neue Trends entstehen,
die halt schnell bedient werden müssen oder eine Marketingkampagne, die schnell umgesetzt werden muss.
Und viele Softwareentwicklungsagenturen, die für unsere Kunden arbeiten oder halt auch vom Kunden selber kommen,
die arbeiten ja schon bereits agil und die müssen halt einfach auch sehr schnell sein.
Das nützt nichts, dann mit einer dritten guten App im Markt zu kommen, wenn es schon eine sehr,
sehr gute gibt und die sehr schnell eine Verbreiterung hat.
Und diesen Trend sozusagen, da unterstützen wir natürlich unseren Kunden, damit er sozusagen einfach diese Agilität hat.
Der kommt auch sehr viel mit unterschiedlichen Entwicklungseinheiten.
Natürlich wäre das Ziel für uns als MMS prima, wenn der Kunde jetzt alles aus einer Hand nehmen würde.
Das ist auch der Fall bei vielen Kunden.
Es gibt aber auch Kunden, die bewusst sagen, nee, ich möchte eine gewisse Unabhängigkeit haben.
Ich möchte sogar unterschiedliche Entwicklungsdienstleister haben.
Und die funktionieren halt von der Kultur manchmal auch total unterschiedlich und haben sozusagen auch ihre eigenen Entwicklungsprozesse unterschiedlich umgesetzt.
Und für einen Großkunde ist es natürlich wichtig, dass sie doch einheitlich irgendwo aufgegleist werden,
damit sozusagen hier nicht diese Energien verloren gehen, sondern, wie Ralf das schon sagte,
dann hinterher auf einer konformen Infrastruktur dann auch landen und auch möglichst dort,
stabil betrieben werden kann.
Also es ist auf jeden Fall ein externer Marktdruck.
Wenn man jetzt die Konkurrenz sieht in Deutschland, denke ich mal, ist das Thema auf jeden Fall zunehmend verbreiteter und bekannter.
Und da ist durchaus auch für die MMS selber der Anspruch da, aber auch weiter Vorreiter zu sein.
Ralf, ich würde nochmal auf das eingehen, was du eben gesagt hast.
Du hast bei der Definition von oder Beschreibung von DevOps gesagt, es geht darum auch,
ein gegenseitiges Verständnis zwischen Dev und Ops herzustellen.
Und deine Antwort eben auf die Frage von Alex war ja auch, dass ihr für diesen Fall damals eine gemeinsame Infrastruktur definiert habt.
Wie haben denn die Entwickler darauf reagiert, dass sie sich ja quasi jetzt in ihrer Freiheit,
in ihrer künstlerischen Freiheit vom Betrieb etwas vorschreiben lassen mussten?
Das.
Das ist ein Gefühl oder dass es dort eine Vorschreibung gab, die Entwickler, das ist die Rückmeldung, die wir bekommen, sind jetzt eigentlich zufrieden,
dass sie sich in ihrem Projekt nicht, ich sag mal, Tage, Wochen, manchmal vielleicht sogar Monate lang um den Aufbau und die Konfiguration der Infrastrukturelemente kümmern müssen,
sondern dass sie dadurch, dass es eine standardisierte Infrastrukturbereitstellung gibt, die man auch per Code-Definition, also Infrastruktur,
DrS-Code verändern kann, dass sie sich sofort und viel schneller anders entwickeln, eines Services oder einer Anwendung machen können.
Sie müssen sich also nicht selbst Tage, Wochen lang mit dem Infrastrukturdesign und dem Aufbau des Ganzen beschäftigen.
Und sie fühlen das schon als eine echte Entlastung.
Okay.
Dadurch, dass diese Infrastruktur, wenn sie automatisiert ist, bereitsteht.
Und man das alles im Source-Code hat.
Also wir tun Infrastruktur auch per Source-Code beschreiben, wie ein Anwendungsprogramm.
Dadurch kann man diese Infrastruktur auch schnell nachnutzen, weil automatisiert aufgebaut.
Und wenn man sie verändern muss, nehmen wir mal an, ich brauche jetzt für einen Cloud-Service eine gewisse Skalierbarkeit,
weil dieser Cloud-Service zum Beispiel an bestimmten Zeiten des Jahres,
viel mehr genutzt wird, als in den Ferienzeiten,
dann kann ich diese Cloud mit einer variablen Serveranzahl in der Software-Definition versehen
und bin dann ganz schnell auch in der Veränderung einer kundenspezifischen oder anwenderspezifischen Infrastruktureinstellung unterwegs.
Und muss nicht, ich sage jetzt mal, Monate oder Wochen lang auf die Beschaffung eines Hardware-Servers warten,
beziehungsweise auf die Konfiguration des selbigen.
Dadurch, dass wir eben auch auf Cloud- und Virtualisierungstechnologien, Containertechnologien zunehmend aufsetzen.
MARKUS TRANTOWSKI Ja, das, was du eben als Vorteil beschrieben hast, was die Entwickler jetzt sehen,
das haben sie ja vielleicht noch nicht zu Anfang gesehen.
Also wie habt ihr diesen, den von mir vorgestellten Widerstand gebrochen?
Oder wie habt ihr die Leute überzeugt, die Entwickler, diesen Weg mitzugehen?
Oder war da gar kein Widerstand?
War da gar keine Abneigung?
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
Also, Widerstand war eigentlich aus meiner Sicht kaum welcher zu spüren. Es war wirklich teilweise ein Unverständnis, dass es einfach im Betrieb notwendigerweise eine aus Sicherheitsgründen Anforderung gibt, so wenig wie möglich Services oder Funktionalitäten in einem Serverbetriebssystem zu haben oder nur so wenig wie notwendig.
Der Entwickler hat gerne alles, was er irgendwo mal finden konnte, drauf konfiguriert und wollte das auch haben. Um, nehmen wir an, ein Debugging von einer Anwendung im laufenden Betrieb durchführen zu können und so weiter.
Und er hat auch dann nicht darauf geachtet, unter Umständen, dass man da mal ein bisschen ein paar Funktionalitäten runterschrauben muss, Ports zumachen muss, eigentlich nur aus Sicherheitsgründen.
Zum einen.
Zum anderen, die Entwickler haben eigentlich aber jetzt auch erkannt, das braucht natürlich ein bisschen Zeit, dadurch, dass sie die Infrastruktur auch als Code vorliegen haben.
Also sie speichern jetzt ihre infrastrukturelle Bereitstellungs auch mit dem Business Source Code zusammen ab, innerhalb eines Service oder eines Projektes oder für einen Kunden.
Und das kommt ihnen und ihrer Fähigkeit, alles zu jeder Zeit ändern, anpassen können oder zu wollen.
Entgegen.
Und natürlich der Betriebler oder die Betriebsleute, die haben dort ihre Gedanken oder ihre Forderungen nach Stabilität, nach Robustheit jetzt auch viel stärker eingebracht.
Und das ist ein Weg, den beide Seiten gehen können oder auch bei uns Stück für Stück gehen und wo dann auch Vertrauen entsteht.
Wir haben.
Aber auch um diese, dieses, dieses bessere Verständnis und das Wissen von einem anderen, also von Entwicklung oder DevOps zu übertragen, haben wir auch eigene Mittel innerhalb der MMS genutzt.
Zum Beispiel das Mittel einer Jobstation, wo in dieses DevOps Programm Entwickler, Tester oder auch Leute aus dem Betrieb in dieses DevOps Programm für eine gewisse Zeit rotiert sind.
Und dort mit ihren Spezialkenntnissen den anderen ihre Kenntnisse beigebracht oder auch überliefert haben und sich natürlich auch andere Kenntnisse angeeignet haben.
Wir haben auch Schulungen durchgeführt und vor allen Dingen, was aber das eine ist ja nicht nur technisches Wissen oder technische Fertigkeiten, sondern das gegenseitige Verständnis.
Und das ist das, wo ich auch sage, es ist eine Haltung, es ist eigentlich eine Philosophie, DevOps umsetzen zu wollen.
Und wir haben auch ständige Befragungen dieser Jobrotierer durchgeführt und die sind dann nach circa sechs Monaten, manche auch nach zwölf Monaten in ihr ursprüngliches Arbeitsgebiet zurück rotiert und haben natürlich dann das, was sie erlebt haben, ihre Ideen, auch ihre Haltung, die sie mittlerweile angenommen und verkörpert haben.
Es waren grundsätzlich sehr positive Rückmeldungen, die wir bekommen haben.
Die tragen das jetzt in die anderen Organisationsgruppen.
Mit zurück, dieses Wissen, was man mit DevOps alles machen kann, was geht und zu welchen, ich sage jetzt mal Beschleunigungen und auch schnelleren Lieferfähigkeiten das Ganze führen kann.
Ich würde es gerne mal ergänzen, was Ralf da gesagt hat, weil wir haben sozusagen auch dieses gegenseitige Verständnis auch ganz bewusst auch gefördert,
dass wir zum Beispiel in unserer Betriebsseite.
Das Team, was vorher für die Verantwortung für geschäftskritische Anwendungen, Application Management gemacht hat, Transitions durchgeführt hat, nach Heidel gearbeitet hat und in diesem Aspekt CICD Pipeline, also die Schnelligkeit der Software Delivery sicherzustellen, ist ein Software Architekt in das Team mit aufgenommen worden und man hat voneinander gelernt.
Und das ist auch das Wichtige daran, dass man da zusammenarbeitet.
Dass man ein gemeinsames Ziel hat, nämlich zum Beispiel diese CICD Pipeline aufzubauen für die Kunden Software und dieser Architekt beispielsweise, der ist dann natürlich mit dem Betriebswissen, was er zwangsweise mit aufnehmen konnte, dann halt in das nächste Projekt gegangen, also nächstes Kundenprojekt und halt auch umgekehrt die Betriebsmannschaft, die bei mir sitzt, hat halt auch eine neue Technologie.
Und dann hat man auch Aspekte der Softwareentwicklung mitbekommen.
Und so wachsen halt beide Bereiche wirklich tatsächlich mehr und mehr im Verständnis zusammen und erbringen halt sozusagen da dann auch einen ziemlich guten Job, weil das Ergebnis ist nach wie vor, es geht darum, hochqualitative Software in möglichst schneller Zeit in den Markt zu bringen.
Oder halt für interne Anwendungen, also ich rede jetzt, ich habe immer so die Brille auf, so nach draußen.
Das geht natürlich genauso darum, halt auch für interne Bereitstellung von IT-Services halt auch schnell zu sein und den Mitarbeitern halt auch entsprechende Software bereitzustellen.
Also gegenseitiges Verständnis, also der Jim Kim, der Autor des Phoenix Project, hat ja auch mal schön gesagt, eigentlich brauchen wir Entwickler, die eben denken können, wie auch wie Betriebsleute und Betriebsleute, die denken können wie ein Entwickler.
Also dieses gegenseitige Verständnis.
Und auch diese ursprüngliche Konfliktstabilität versus Flexibilität, um das aufbrechen zu können.
Also ich habe schon jetzt das Konzept, das ihr erklärt habt, auch mit der Team-Rotation, das da sehr hilft, um dieses gegenseitige Verständnis zu bekommen.
Das geht sogar auch an dieser Stelle in diesem DevOps-Programm, was wir intern in der MMS machen, soweit, dass wir erste leichte Organisationsänderungen probieren.
Wo eine Entwicklungsorganisationseinheit und eine Betriebsorganisationseinheit zusammen wirklich geschlossen werden und dann für Kunden gemeinsam arbeiten.
Also dort integrativ DevOps vertikal in einer vertikalen Entwicklungstest und hoffentlich dann auch Betriebsverantwortung zu erbringen.
Also das ist ein erster Organisationsprobe.
Und das ist ein erster Ballon, könnte man sagen.
Eventuell ist das ein Weg, wie sich Kunden, Erbringungsorganisationen wandeln könnten.
Und das kann man nicht pauschal, so jetzt wandeln wir mal das ganze Unternehmen, sondern das muss man mit kleinen Schritten, Organisationsschritten ausprobieren.
Was ist der richtige Weg?
Und wir sind ein 1800 Mann starkes Unternehmen.
Und da kann man nicht mal sagen, wir ändern jetzt mal die ganze Organisation.
Und wenn das nichts ist, dann probieren wir es nochmal.
Sondern es wird ganz bewusst auch getragen, committed von der Geschäftsführung, diese Organisationsprobierballon ausprobiert.
Also Ralf, ich finde, das ist für mich ein ganz wichtiger Punkt, weil ich, wenn ich jetzt unterwegs bin bei größeren Unternehmen, dann sind die häufig von jährlichen Reorganisationen geschädigt, die Mitarbeiter.
Jedes Jahr wird was Neues gemacht oder alle zwei Jahre.
Und das, was du eben gesagt hast, ist aus meiner Sicht immer ein ganz zentraler Punkt.
Ich habe nicht ein neues Framework, wo ich mich hinentwickeln muss, was ich sozusagen quasi umsetzen muss, wie ITIL oder Scrum, sondern ich muss schrittweise dahin kommen, diese Philosophie umzusetzen, dieses gegenseitige Verständnis hinzubekommen.
Und das eben schrittweise, mit kleinen Schritten und nicht mit einem Riesenprogramm, weil das geht in die Hose und dann gibt es das nächste Programm.
Und damit ist der Begriff DevOps.
Und das ist dann auch wieder verbrannt.
Kann ich bestätigen.
Ich hatte auch in einem Großkonzern, also auf der Kundenseite gearbeitet und im mittleren Management.
Und dort ist eine solche Umsetzung von oben dann, naja, ich sag mal durchgesetzt worden.
War auch erfolgreich, was Kosten und Schnelligkeit betrifft.
Aber das Mitnehmen der Leute ist dort nicht so gut erfolgt.
Also dort war der Erfolg da nicht so.
Mitnehmen der Leute bedeutet, dass sie sich also in einer veränderten Zuständigkeitssituation mit anderen Anforderungs- und Aufgabenbereichen schneller zurechtfinden.
Wir sind ja, oder die meisten Menschen sind ja so, dass sie Veränderungen nicht ganz so von sich aus wollen oder treiben.
Und das wurde dort mehr von oben dann verordnet und durchgesetzt.
Und so etwas, so eine Kulturänderung, die sollte nicht nur von oben vorgehen.
Und durchgesetzt werden, sondern das ist eine Kombination aus geführter Governance und dann auch wirklich Graswurzelbewegung,
die in einer gemeinsamen oder in einer mit wollenden Menschen umgesetzt werden sollte,
die willens sind, sich verändern zu wollen und die auch sehen,
dass eine solche Ausrichtung auf DevOps für alle Seiten auch etwas bringt.
Man wird schneller, wettbewerbsfähiger und lernt unheimlich ständig.
Immer.
Dazu.
So eigentlich ein Mix dann, wenn man über die Vorgehensweise, sprich für eine Transformation, so Top-Down, Bottom-Up.
Es ist klar, einerseits Management-Commitment ist wichtig, aber dann, ich glaube, das haben wir auch schon beim letzten Interview gehört.
Wir sehen auch hier in der Schweiz, wenn ich schaue, wie die Firmen DevOps umsetzen, es sind eben so kleine, kleine Schritte, jeweils Feedback holen.
Und auch die Leute dann, ich sage immer, die,
die Leute, die sind eigentlich offen gegenüber Veränderung, aber wenn es darum geht, dann sich selber zu verändern,
da kommt der Widerstand und der Trick ist dann irgendwie auch, dass man wie, wenn die Leute das Gefühl haben,
ah, das war ja meine Idee oder die auch dann, dann eben die Transformation selber agil zu machen,
dass die selber das vorantreiben, dass es dann auch getragen wird von den Leuten.
Also ich kann das nochmal bestätigen, das ist, wir sind Menschen, wir kommunizieren,
es gibt Missverständnisse, es ist halt auch Kultur, Bereichsdenken manchmal, Silo-Denken.
Und das ist sehr, eigentlich die Veränderung auf einer technischen Ebene herbeizuführen, ist eigentlich relativ einfach, in Anführungsstrichen,
weil da kann man, da kann jeder eigentlich gleich darüber sprechen, auch das Management, die verstehen das, die Mitarbeiter verstehen das,
aber so eine Kultur, das ist so ein wabbeliger Begriff, na, was ist denn das eigentlich?
Und ich finde es halt da extrem wichtig und das machen wir.
Das machen wir in der MS auch und das machen wir ja auch mit den Kunden, dass wir sagen, dass man frühzeitig alle Beteiligten an Bord holt,
dass man auch durch Community-Gründungen auch verschiedene Kanäle bereitstellt, wo wir darüber diskutiert werden können.
Das setzt natürlich eine offene und Kommunikationsbereitschaft Unternehmenskultur auch voraus
und die hat es dann halt letzten Endes dann auch leichter, solche Modelle sozusagen auch sukzessive schneller umzusetzen.
Als eine Unternehmenskultur, die vielleicht sehr stark hierarchisch geprägt ist.
Ich würde nochmal auf einen Punkt eingehen, auch vorhin noch ein bisschen aus der Einleitung, das, was ihr eben ja im Prinzip auch angedeutet habt.
Raif hatte gesagt, zur Definition, was ist DevOps? Das ist Leidenschaft, das ist Kultur.
Und dann noch weiter ausgeführt, es geht darum, Serviceverantwortung hinzubekommen und eben weg von,
von den Silos. Du hast es ja eben auch gesagt, Olaf, es geht um Kulturwandel.
Was mache ich denn oder welche Erfahrungen habt ihr denn mit Personen gehabt, mit Menschen gehabt?
Denn wir haben es ja mit Menschen zu tun, die eben nicht mit Leidenschaft zur Arbeit gehen,
die eben genau sich nicht verändern wollen, auch wenn sie vielleicht sogar einen Vorteil davon hätten.
Also habt ihr da so ein paar besondere Tricks entwickelt oder habt ihr etwas, wo ihr gemerkt habt, das hat bei euch funktioniert?
Also ich kann…
Ich habe ja nur eine Support-Abteilung verantwortet, die nach wie vor.
Und das sind durchaus auch als so zum ersten Mal die Themen wie DevOps angesprochen worden sind,
kamen da auch Bedenken, naja, da habe ich ja dann nichts mehr zu tun, wenn alles automatisiert ist
oder wenn halt einfach hier die normalen Betriebsaufgaben weniger werden durch die CICD-Pipeline.
Und ich glaube, da hat man als Führungskraft eine ziemliche Verantwortung.
Die sollte man auch wahrnehmen, man soll sich darüber auch klar werden.
Diese Veränderung kann nicht alleine von unten oder nur von oben passieren,
sondern die muss parallel geführt werden, so eine Diskussion.
Und ich habe tatsächlich mit meinen Mitarbeitern auch die Begeisterung wecken können.
Sagt, da gibt es neue Perspektiven, neue Chancen.
Denkt mal voraus, was das bedeutet.
Ihr könnt mehr Verantwortung übernehmen und man ist dann halt nicht mehr,
wie früher vielleicht so das Bild,
naja, man kriegt die Software über den Zaun geschmissen,
sondern nee, ihr seid auch bei diesem Prozess mit dabei, wie das passiert,
wie man halt zusammenarbeitet und dann halt auch am Ergebnis letzten Endes mit beteiligt.
Und dass das halt auch eine ganz andere Wertschöpfung ergibt,
eine viel höherwertige Wertschöpfung, als wenn man sozusagen einem nur sagt,
naja, mach das mal bitte jetzt hier, das ist eilig und das muss nachts installiert werden,
damit es morgen läuft und im Übrigen in der nächsten Nacht darfst du dann das nächste Release in Empfang nehmen.
Und das sind…
Ja, völlig von ab.
Und diese Begeisterung, die Ralf auch so schön erklärt hat,
das kommt dann insbesondere, wenn der Kunde dann wirklich auch sieht,
Mensch, ich habe die Software für meinen Fachbereich schneller deployen können.
Die Endkunden sind begeistert.
Und das wird dann halt als Feedback dann auch dem Team,
dem gemeinsamen Team auch wieder gespiegelt.
Und dann sind die auch richtig motiviert.
Okay, das heißt als Lerneffekt oder auch als Argument würdest du ansprechen,
abgesehen davon, dass es natürlich dann den Arbeitsplatz erstmal sichert,
weil wenn ihr es nicht gemacht hättet, hätten es andere gemacht,
dass es den Arbeitsplatz auch wertvoller macht, wertvoller auch für die eigene Tätigkeit.
Und das wären so quasi die beiden Argumente, die ich aus deinen Ausführungen, Olaf, mal rausziehen würde.
Also es geht wirklich darum, dass die Fähigkeiten des Mitarbeiters,
die müssen an dieser Stelle weiterentwickelt werden, weil aus betrieblicher Sicht und aus der Brille gucke ich,
ja hier auch hauptsächlich, müssen mehr Richtung Deployment,
mehr Richtung Entwicklungsverständnis gehen, weil ja auch die, wie Ralf das ja schon sagte,
die Infrastruktur, Cloud-Technologien, da wird es nicht mehr so sein,
dass man da den Server und sechs Wochen ist er da und dann muss er installiert werden,
sondern das ist tatsächlich auch auf Knopfdruck da.
Und der Systemingenieur von heute wird sich in einen DevOps-Ingenieur umwandeln,
der halt das Ganze orchestriert.
In dem Kontext hätte ich noch eine Frage, weil auch Dirk hat vorhin gefragt,
es gibt ja manchmal Leute, die wollen nicht, wie geht man die an?
Jetzt sprechen wir auch darüber, ja die Leute müssen sich weiterentwickeln,
aber manchmal können sie vielleicht nicht.
Also ein schönes Beispiel ist ja im Testing, also das manuelle Testing, das abnimmt
und jetzt mehr Richtung Testautomatisierung, Scripting, das braucht eine ganz neue Art von Skills,
aber vielleicht sind die Leute…
die dann gar nicht in der Lage, sich in die Richtung zu verändern, oder?
Habt ihr solche Fälle auch gehabt, wo ihr sagt, ja, das wird jetzt einfach schwierig, oder?
Also, der Ralf, ich hatte so etwas in dem Großkonzern natürlich auch in der ganz Frühzeit erlebt.
Man muss dann schon auch als Unternehmen ist man in der Verantwortung,
oder die Unternehmen sind eigentlich in der Verantwortung dort,
die Weiterbildung und der Mitarbeiter zu sorgen.
Natürlich gibt es auch eine gewisse Weiterbildungsresistenz unter Umständen,
die man feststellen, oder die ich auch erlebt habe.
Aber da helfen meiner Ansicht nach dann Überzeugungsgespräche und so weiter.
Der größte Hebel oder den besten Hebel, den ich immer gefunden habe, um dann bei Mitarbeitern,
Um dann bei Mitarbeitern, um dann bei Mitarbeitern,
Um dann bei Mitarbeitern, um dann bei Mitarbeitern,
wo das ein bisschen schwieriger war, die zu erzeugen,
war, dass sie durch die Übernahme neuer Skills ihren Marktwert eigentlich steigern konnten.
Und dass sie dadurch einen ganz anderen Selbstwert, ein Selbstwertgefühl kriegen und einen höheren Marktwert.
Denn wir wissen alle, dass Arbeitssituationen, dass man in einem Unternehmen anfängt und dort 40 Jahre bleibt,
dass das immer unwahrscheinlicher wird.
Und dass auch Arbeitgeberwechsel durchaus öfter stattfinden können, nicht müssen, aber können.
Und gerade wenn man mit dieser DevOps-Fähigkeit oder mit Fähigkeiten Entwickler-Test und Operations-Skills ausgestattet ist
und bei beiden immer oder bei allen drei Richtungen zunehmend die Softwareentwicklungsnotwendigkeit,
ob das Scripting oder Testautomatisierung oder Softwareentwicklung selber ist,
zunimmt, beziehungsweise dann das Wissen um solche neuen Technologien, die ja auch damit verbunden sind,
sei es jetzt Cloud, sei es Test, Driven Development oder was es da alles noch Neues gibt, Big Data-Technologien.
Also der Marktwert des Einzelnen erhöht sich.
Und das war aus meiner Erfahrung immer der größte Hebel, dass man dort ein bisschen Eigenmotivation schaffen konnte.
Okay.
Frage von mir noch mal zum Thema Sicherheit.
Das ganze Thema Sicherheit, Datenschutz und so weiter, das wird ja manchmal so dargestellt, dass das ein Showstopper ist für DevOps.
Oder dass es zumindestens die Schnelligkeit, von der ihr vorhin gesprochen habt, beeinflusst.
Seht ihr das auch so? Und wenn das bei euch auch ein Problem ist, wie geht ihr damit um?
Also da würde ich eine erste Antwort geben.
Dadurch, dass wir bei der…
Bei der Definition von den einzelnen Komponenten und Schritten in der Umsetzung dieses DevOps-Programmes,
von Beginn an die IT-Sicherheit als Design mit oder als Design-Abhängigkeit in den zehn…
Wir haben so eine Art zehn DevOps-Gebote uns gegeben.
Und Security by Design für alles das, was man dort an Automatisierung, an Standardisierung macht,
wenn man das von Beginn an berücksichtigt und auch die Sicherheitstests möglich macht,
wenn man das Testmöglichkeiten und Sicherheitsmonitoringmöglichkeiten automatisiert von Beginn an einbaut,
dann kann Sicherheit oder automatisierte Sicherheit auch zu einer Entwicklungsbeschleunigung führen.
Also ich kann das vielleicht auch nochmal von der anderen Seite beleuchten.
Ich sehe das nämlich ähnlich wie Ralf.
Es führt eigentlich zu mehr Sicherheit, weil nämlich durch die Automatisierung viele manuelle Schritte einfach entfallen.
Und da entstehen dann halt Fehler bei den manuellen Schritten.
Und dadurch, dass man sehr viel wiederholbar macht und halt automatisiert, wird eigentlich die Sicherheit da erhöht.
Dann ist es auch so, dass man in der CI-CD-Pipeline, also sozusagen technische Ausprägung von DevOps,
ja eine Reihe von Tests drin hat, die halt beginnen schon sehr früh im Code,
schon Code-Quality-Analysen zu machen bis hin zu Last- und Performance-Tests,
wo die Tests ja dann halt auch dazu führen sollen, bewusst dazu führen wollen,
die Software unter Druck zu setzen, damit halt Schwachstellen offengelegt werden können.
Und ein dritter Aspekt, den man vielleicht auch dazu sehen könnte,
die ganze CI-CD-Pipeline mit den ganzen unterschiedlichen Testverfahren, die da drin sind,
mit den Deployments, automatisierten Deployments von Stage-to-Stage,
das ist ja selber auch ein Qualitätssicherungssystem in der Gänze.
Es kann natürlich trotzdem vorkommen, das ist ja so, man macht die CI-CD-Pipeline ja auch so,
dass es halt schneller ist und nicht nur schneller, sondern natürlich auch mehr Deployments hat,
dass natürlich in der ersten Phase, so wie es bei jeder Software ist,
also auch die CI-CD-Pipeline ist natürlich auch Software,
dass dann natürlich Probleme schon entstehen können.
Und da ist halt aber auch wieder diese enge Zusammenarbeit, dieses enge Verständnis notwendig,
weil man dann ja auch sagt, es gibt eine gegenseitige Schuldzuweisung,
na, du hast ja hier irgendwie nicht aufgepasst, sondern es ist alles transparent,
man setzt sich schnell zusammen im interdisziplinären Modus und tut das halt dann auch lösen.
Okay.
Vielleicht noch auch ein Hinweis, also dadurch, dass man Dinge automatisiert und wenn ein Fehler auftritt
und diese automatisierten Tests, die man dann ja auch im Betrieb als Monitoring-Element einsetzen kann,
wodurch dann aus dem Betrieb immer wieder für einen neuen Software-Entwicklungszyklus
eine Rückwirkung da ist, dass man das Monitoring-Skript gleich auch wieder zum Testen in der Software-Entwicklung nehmen kann,
entsteht auch eine Über-die-Zeit-Situation.
Das heißt, man hat eine viel höhere Robustheit der Infrastruktur und des Applikations selber,
weil alle Tests, die ich einmal automatisiert habe, werden bei jedem Build oder Commit,
wie wir das nennen, wenn also eine Software eingecheckt wird, wird immer wieder durchlaufen.
Das heißt, die Testdurchlaufzahl, die Testabdeckung wird durch die Automatisierung auch wesentlich erhöht
und über die Zeit werden die Systeme immer robuster und damit auch immer sicherer, hoffentlich.
Also mit anderen Worten, weil im Titel des Podcasts steht ja auch von der Anforderung in den Betrieb in einer Stunde,
das könnte ja zur Schlussfolgerung verleiten, okay, dann geht die Qualität runter,
aber das ist ja nicht, also da, wie du jetzt gerade beschrieben hast,
die Robustheit und die ganze Testautomatisierung, dass sie dem entgegenwirkt.
Ein Beispiel, mal ganz konkret, das habe ich heute auch in einem internen Cloud-Tutorial gehalten.
Wir erstellen aus Software-Beschreibungen unsere Betriebssysteme.
Das nennt man ein Betriebssystem-Image.
Und dieses, bei dem Erstellungsprozess, der automatisch abläuft,
werden mehr als 400, 500 verschiedene automatisierte Infrastruktur-Tests für das Bauen aus einem Software-Repository,
wie Git oder Subversion, für das Bauen eines Betriebssystem-Images.
Genutzt und laufen ab.
Und dieses Bauen des Betriebssystems allein, die allein nur aus Software-Definition heraus erfolgt,
wird jede Nacht immer wieder für die unterschiedlichen Plattformen gemacht
und es tritt unter Umständen doch mal ein Fehler auf, da muss man danach suchen.
Und mit jeder weiteren Fehlerbehebung wird das Stück für Stück schon das Betriebssystem eines Servers,
auf dem Applikationen laufen, immer robuster.
Und ich sag mal,
damit auch hoffentlich immer performanter und vollständiger.
Wir wissen alle, Software ist nie fehlerfrei.
Wenn man sich die Lines of Code von der Software, die für eine Applikation gebraucht werden, mal aufaddiert,
das Betriebssystem, die Datenbank und so weiter, aus denen die alle bestehen,
da ist man sehr schnell für eine kleine einfache Anwendung,
da ist man sehr schnell dabei, dass man da mehrere Millionen Lines of Code hat
und die übereinandergelegt einen Riesenturm zu Babel an Lines of Code ergeben.
Und natürlich, wir wissen, dass die nicht fehlerfrei sind,
aber durch die ständige Automatisierung, durch das Härten und das Rausnehmen von Funktionen, die man nicht braucht,
das Abschalten von Funktionen, wird es sicherer, robuster, hoffentlich auch performanter über die Zeit.
Ich komme mal auf den Titel zurück.
Alex hatte da eben auch schon mal darauf hingewiesen.
Olaf, ich habe dich ja bei einem Vortrag mal gehört, wo du vor einer Zeit,
ich sage mal, versammelten IT-Service-Management-Mannschaft, vor ITIL-Freunden gesagt hast,
dass ihr wirklich von der Anforderung bis zur Produktivsetzung eine Stunde braucht.
Die haben ihren Mund nicht wieder zugekriegt und konnten sich nicht vorstellen,
wie man zum Beispiel in einer Stunde ein Change Advisory Board einberufen kann.
Also ist das so? Schafft ihr das? Schafft ihr das in einer Stunde Produktivsetzung?
Also Ralf hat es eben schon gesagt.
Also bei uns beginnt die Uhr zu ticken bei dem Commit.
In dem Moment, wo der Entwickler halt den frischen Code eincheckt, wird das erkannt aus dem System
und dann geht die Pipeline halt auch los und darauf bezog sich auch diese eine Stunde.
Und natürlich, wenn man jetzt sagt, die hohe Kunst ist es wirklich in einer Stunde zu machen oder auch schneller,
dann geht das. Wenn man aber jetzt sagt, man hat eine komplexere Anwendung, wo halt auch längere Lasttests stattfinden,
da muss man halt dann mehr Gehirnschmalz reintun, wie man die Tests parallelisieren kann,
beispielsweise um so eine Stunde dann auch zu erreichen.
Es gibt sicherlich auch Anwendungen, wo das auch schneller geht, wo einfach auch aufgrund der Vigna-Komplexität
dann halt auch einfach gewisse Stages auch wegfallen können.
Ich glaube, die besondere Herausforderung, die noch auf uns zukommen wird, ist das Thema Docker.
Ich tue das einfach mal voraussetzen, dass so ein gewisses Verständnis über Container-Technologie da ist.
Ich glaube, dass sich da auch nochmal ein Shift in der IT-Verständnis, in der Betriebsverantwortung tun wird,
die von so einer Layer-Verantwortung, da ist die Applikation und darunter ist der Betrieb
und der macht halt sozusagen die Systeme darunter, Datenbank, Infrastruktur,
dass sich das auch aus diesem Grunde auch nochmal ändert.
Das heißt, man wird in eine Betrachtung von Inside-Container und Outside-Container.
Und das Thema DevOps wird durch das Thema Docker noch sehr viel mehr beschleunigt.
Und ich glaube, da wird es noch eine ganze Menge an Gesprächsbedarf geben,
weil dann tatsächlich die Möglichkeit ist, Anwendungen überall zu deployen,
egal in welcher Cloud und in einer noch höheren Geschwindigkeit, wird natürlich dazu führen,
dass eine Unübersichtlichkeit auch entsteht.
Und ich glaube, deswegen ist das auch so richtig, diese Kulturaspekte noch zu betrachten,
dass man sagt, okay, man braucht über alles eigentlich immer eine gewisse Transparenz.
Wer macht denn da was? Wie ist die Qualität?
Ist dann Testdokument wirklich auch gemacht worden im Sinne einer Revisionssicherheit?
Also das wird alles, diese Governance darüber, die wird immer eine größere Rolle spielen.
Man wird auch immer mehr auf die Prozesse gucken.
Und das wird für mich sozusagen die zukünftige Herausforderung sein.
Also es wird nicht einfacher, glaube ich, sondern es wird eher noch komplizierter,
wo man dann halt auch wieder entsprechende Mitarbeiter braucht,
die auch mit dieser Komplexität umgehen können, das managen.
Die werden dann nicht mehr den Apache-Server neu starten,
sondern die werden sich mit solchen Themen auseinandersetzen.
Stimmt denn der gesamte Prozess? Wo hakt da was?
Ein weiteres Thema, was dazukommen wird,
auch was das Thema Robustheit auch angeht,
ist, glaube ich, die KI, also künstliche Intelligenz,
zu der Robustheit von Softwareentwicklung mit einzubeziehen.
Und ich glaube, das wird, wenn man so ein bisschen in die Zukunft guckt
und vielleicht trifft man sich ja in drei Jahren wieder im Podcast
und sagt, nee, das war alles Quatsch, was hier der Olaf erzählt hat,
KI ist noch lange nicht so weit.
Aber ich glaube, da fängt jetzt irgendwie so eine neue Generation an,
die wieder neue Herausforderungen angeht.
Und das ist dann, um diese Komplexität in den Griff zu kriegen,
wäre halt auch aus meiner Vision sozusagen KI auch ein Schlüssel dazu.
Weil allein in unserem Bereich betreiben wir knapp 50 ICT-Pipelines parallel.
Und das kann man auch nicht mehr alles manuell prüfen und checken.
Und wenn es dann halt um 100 Commits pro Tag geht,
dann potenziert sich das ja alles.
Man hat ja eine unglaubliche Masse von Durchläufen dann.
Und dazu brauchen wir halt auch Mechanismen,
auch Verständnis da, sozusagen den Überblick zu behalten
und halt nicht die Kontrolle zu verlieren, genau.
Ich möchte da nochmal auch einhaken auf die Frage
und kann das nur unterstützen, was Olaf sagte.
Die Frage war ja, was passiert mit dem Kasten,
mit dem Change Advisory Board?
Gewöhnlicherweise über die letzten Jahre haben sich Customer
oder Change Advisory Boards meistens in großen Firmen,
die in gewissen Outsourcing-Beziehungen standen
oder in großen Organisationen, auch wenn man ein Insourcing hatte,
der IT ausgebildet.
Durch die Beschleunigung von der Automatisierung
und dadurch, dass sich CI, CD-Pipelines,
die ständig übereinander automatisiert wirken und deployen,
und dadurch, dass ich Testalgorithmen habe,
die mit immer größeren Testabdeckungen dazu führen,
dass, wenn festgestellt wird durch Automaten,
das ist grün, das ist grün, das ist grün
und man dort eine gewisse Regel-Rollenauswertung,
KI-Intelligenz drüber legt,
dann können Rollout- und Freigabeentscheidungen,
die entweder durch ein Change Advisory Board
durch Menschen gemacht werden,
Stück für Stück auch ersetzt werden durch Automaten,
die, wenn sie dann sagen, alles ist grün,
rolle aus, mache eine nächste Stage
oder rolle es sogar in Produktion aus,
das mehr und mehr zu einer Reduzierung der Aufgabe
von menschlichen Entscheidungen im Change Advisory Board führt.
Und meine Messlatte, beziehungsweise unsere Messlatte,
auch für die MMS, ist eigentlich Amazon Web Services.
Amazon Web Services hat seinen Change Advisory Board Vorgang
von menschlichen Entscheidungen auf Roboterentscheidungen umgestellt.
Warum?
Weil die menschlichen Entscheidungen bei den ständigen Durchläufen,
die die Automatisierungs-Pipeline bei Amazon Web Services macht,
zu großen Fehlern geführt hat.
Das heißt, die KI- und Automaten, die CI-CD-Pipelines,
die mit hohen Testabdeckungen durchlaufen,
treffen größtenteils automatisch die Entscheidung,
rolle ich das jetzt aus, rolle ich das jetzt nicht aus?
Und dort werden wir mit KI- oder AI-Methoden im Betrieb
und auch in Change Advisory Board dazukommen,
Freigabeentscheidungen, die eigentlich ein Change Advisory Board trifft,
die Aufgaben eines menschlichen CABs weiter und weiter zu reduzieren.
Ich würde das nochmal aufnehmen, was Ralf gesagt hat.
Also das Ganze hört sich jetzt sozusagen so ein bisschen an,
als wenn das jetzt alles von alleine geht.
Ich glaube, es gibt ja auch mehrere Arten von Changes.
Und sicherlich kann ein Minor-Change oder halt ein Odd-Fix schneller durchlaufen
und da braucht man auch keinen Change Advisory Board.
Man kann gewisse Typen vordefinieren, wo es sozusagen so eine Art
Pre-Authorized-Change-Prozess gibt, wo das auch im Risiko auch bleiben kann.
Ich glaube, aktuell ist es so, ein Kunde, der wirklich eine wichtige Geschäftsanwendung hat,
der wird immer noch sagen, nee, ich brauche anderen Gewissen,
an einer gewissen Stelle brauche ich hier immer noch eine menschliche Freigabe.
Und das ist das, was wir unseren Kunden ja auch anbieten wollen,
dass sie sagen, okay, dass er natürlich immer die Hoheit darüber hat,
was er dann letzten Endes da auch im Markt auch deployt.
Wo ich Ralf aber absolut recht gebe, ist einfach in einem hochstandardisierten Umfeld,
da wird man ohne solche sehr starken Automatisierungen
und Selbstbestimmungen,
Selbstlernen-Systemen dann nicht mehr auskommen.
Bei einer großen individuellen Geschäftsanwendung,
da würde ich mal interpretieren, da wird es noch ein bisschen dauern.
Sehr schön. Also, ich gucke auf die Uhr.
Wir haben fast eine gute Stunde gefüllt und ich glaube,
da steckt ganz viel drin von dem, was ihr so berichtet habt.
Das muss man sich wahrscheinlich zwei- oder dreimal nochmal anhören,
weil ihr einfach sehr viel aus der Praxis berichtet habt.
Ich habe keine Fragen mehr.
Alex, wie sieht es bei dir aus?
Ich fand es unglaublich spannend.
Wir können natürlich lange weiter diskutieren,
aber vielleicht dann mal beim Folge-Podcast.
Keine weiteren Fragen.
Ja, recht vielen Dank.
Also, ich möchte mich auch bei euch bedanken,
dass ich hier bzw. dass wir hier teilnehmen durften
und unsere Meinung äußern konnten.
Sicherlich haben wir an der einen oder anderen Stelle
auch ein bisschen einen Ausblick in die Zukunft gegeben,
aber man muss sich weiterentwickeln.
Und nur dann, wenn wir wettbewerbsfähig bleiben,
dann hat unser Unternehmen auch gute Chancen auf Wachstum
bzw. weiterer Daseinsberechtigung.
Also, es bleibt spannend, definitiv.
Und DevOps ist ja eine Reise, nicht ein Ziel,
das man dann morgen erreicht hat.
Also, auch herzlichen Dank von meiner Seite.
Ja, ich danke auch.
Und ich sehe das genauso.
Eigentlich fängt das Spannende jetzt erst an.
Also, die IT ist jetzt sozusagen jetzt soweit,
wo man wirklich sagen kann,
jetzt beginnt auch eine aufregende Zukunft mit Chancen für alle.
Möchtest du vielleicht, Dirk, noch auf den,
wir haben ja noch einen nächsten Podcast geplant.
Jawohl, der nächste Podcast ist der,
den wir beim letzten Mal schon als nächsten angekündigt haben.
Also, wir sind gerade aktuell richtig agil in unserer Planung,
müssen uns immer auf veränderte Situationen einstellen.
Also, beim nächsten Mal hören wir dann,
was wirklich was zur MetroMap von der Direktgruppe.
Die wird ihre MetroMap vorstellen.
Und da werden wir auch wiederum zwei Gesprächspartner haben.
Wird bestimmt genauso interessant.
Wird dann vielleicht ein bisschen eher so in Beratung reingehen.
Aber trotzdem, wie gesagt, wird mit der MetroMap,
werden wir tolle Dinge besprechen.
Ich sage auch Dankeschön.
Und Alex, dann würde ich sagen, du mal das Schlusswort heute.
Ja, herzlichen Dank.
Ich denke, auch dieses Mal wird es super spannend.
Super spannender Beitrag.
Und auch, ich denke, aus der Praxis heraus,
die Herausforderung, die eine T-Systems MMS gesehen hat
und wie sie das dann effektiv umgesetzt hat.
Am Schluss ist auch, das Technische muss man natürlich auf die Reihe bringen,
aber dann der Faktor Mensch, der hat sich auch jetzt wieder gezeigt.
Also, die Leute, die begeistern, das Feuer wecken in den Leuten,
dass sie dann auch mitmachen.
Und ich fand irgendwie am Schluss dann die Diskussion Richtung,
ich meine da Artificial Intelligence,
das ist sicher so das nächste grosse Thema.
Da ist jetzt sehr viel mit Chatbots auch,
die jetzt eingesetzt werden.
Das wäre dann vielleicht auch mal ein spannendes Thema.
Aber in diesem Sinn, vielen Dank.
Vielen Dank.
Vielen Dank.