Establish Common Cultural Values

Context

Microservices are being adopted.

Problem

• Old habits are overwriting necessary steps towards a microservice-based architecture pr there is resistance against planned changes
  • E.g., there are manual adjustments to the production environment instead of automating them
  • E.g., the transactions over microservices are implemented, leading to a monolithic database

Solution

You need to change the culture as it is a key success factor many companies struggle with.

Organizational culture implies similar values and reaction patterns in certain situations. It helps us to decrease communication overhead but if faced with new non-compatible values it elicits resistance.

The following example organization-cultural values promise to ease the adoption of microservices:

• Embracing change, innovation, and experimentation in order to improve is required in order to cope with the immense knowledge need in microservice projects to ensure team autonomy.
• Automatization and standardization to cope with the service explosion that the teams will be faced with, as well as introducing traceability by removing manual actions.
• The consistency to stick to established best practices and standards is required to guarantee the quality of the software.

If those values are not embraced by a companies' culture chances are high that the existing culture will overwrite the necessary best practices required to make microservice-based architectures work.

The following steps can be taken to change the culture and introduce the desired values:

1. Have someone higher up in the company politics pushing and vouching for the cultural change
2. Create a spin-off team or company that precedes with the cultural change
3. The spin-off team conveys the new values to the other teams

Maturity

Proposed, to be evaluated.

Sources of Evidence

L7:

• Adopt a culture of automation (Newman's principles)
• Decentralization & automation

L14:

• Microservices and DevOps
• Automation is key to DevOps Success

L17:

• Issue in people's mind when changing architectures
• "[...] older developers do not always belief in recent technologies" => more conservative than younger ones
• "Feelings" for legacy system, reluctant to accept change
• Rearchitecting perceived as risky

L19:

• Automation mandatory due to service explosion
• Importance of culture of leveraging automation
• Most challenged item in the list
• "Docker container is accelerating automation culture in every step of software development lifecycle"

L23:

• Microservices as a shift of IT to DevOps culture

L25:

• Automation and DevOps to cope with service explosion

L32:

• Organizational structure & culture important factor
• In order to make microservices work
  • Remove the handoffs between RE, devs, testers, ops, ...
  • and build autonomous teams

L41:

• Importance of automation (and infrastructure) due to many moving parts needed to be managed and be connected

L42:

• Changing mindset of devs among most relevant challenges
• Shift of paradigms (not just one DB, service calls, ...) => different way of thinking

L43:

• Culture as a factor in case study
• low resistance to change culture, change is promoted
• culture change enabled by technical tools and technologies
• CSE (continuous software engineering): tools are key!
• Automation to improve development, including safety considerations

L44:

• Automated provision is crucial in building and deploying distributed systems

L52:

• Microservices come with need for a strong DevOps culture => decentralization, deployment frequency
• Freedom of technology choice supports culture of innovation and experimentation

LN42:

• Among others: resistance to change can endanger migration to microservices
• challenges can be technical, economic, and psychological

LN43:

• code ownership leads to developers pride
  • commits devs to long-term involvement instead of thinking the problem is someone else's problem
• When taking full responsibility of service, teams needs to adopt DevOps mentality

LM43:

• Context: SLR findings about microservices in DevOps
• Organizational problems related to culture, peopls, cost, organization, and team structure
  • Among others, change employee habits toward team work and sharing of responsiblity

LM48:

• Context: microservice migration describes an examples project (FX Core) and compares back to monolith
• Agile methodology suits well for migration process
  • iterative approach
• Had to establish agile culture
  • otherwise: risks and threat and success may sum up
• DevOps and MSA indivisible pair: deliver apps and services at high velocity
  • adequate training for introducing
  • requires technological, organizational, and cultural prerequesites
    • if not present, should be developed
  • investing in DevOps is a good idea in general
    • after migration even more critical

Interview A:

• Rethink IT: question how we want to do software
• Younger people easier to motivate for (architecture) change than older ones
• Automation is key (DevOps, CI/CD)
• Culture as key success factor
• How they started
  • devs with root priviledges on production, no versioning + documentation, know-how not distributed
  • No tracability at crash
  • => Need for DevOps
• Need for one to push it in company politics
  • Reserve time and resources for changing culture even though no tangible return of invest (as a challenge)
  • Founded new team with people who burned for it
• One "DevOps" team to set and example and convey the mindset
  • Support dev teams on their journey to gain full responsibility
  • Help with automation
  • Very patient, tell it over and over again => takes time and effort
• Makes experiences together that it decreases the pain
  • Overcome the dev vs ops mindset
• Mindset
  • Quality gates need to be respected
  • Traceability (version control even of configs, trace compatibility in pipelining)
  • We want to speak over the same thing
  • Automation and standardization is key
  • Commitment to stick to the things that are discussed
    • Don't make exceptions! Even not for management
    • If does not satisfy, rethink processes and adapt
  • Continuous improvement, question the processes
• Overcome personal sensitivities of individuals as challenge
  • Let a consultant moderate
  • But the change has to come from within eventually

Interview B:

• Need to make overarching macro architecture

Interview C:

• development of culture (e.g. autonomy) is a process
• changing culture is a major challenge
• same culture => similar behavior
  • e.g. interviewee works with different groups in a company and all tell the same: "needs to pass approval process" (as a hurdle for designing a system without approval processes => autonomy)
• (+) replaces communication (understanding each other blindly)
• (-) change not suiting to culture => resist
  • overwrites best practices and platforms, and others stuff
• Mindset
  • Remove "transactions are holy"
• Analogy to jelly
  • a single finger (change) is swallowed by the whole jelly
  • you need a whole fist to change it
• Strategies to change culture
  • Someone in higher company politics to enable the cultural change
  • Spin-offs with new fresh people (20-30 people)
    • within company: problems with work council (no free selection of people)
  • Either integrate back (the fist into the jelly) or let it run in parallel
  • Examples are Mercedes (separate IT spin-offs), Trump

Interview D:

• Context: you want to do DevOps?
• tradeoff triangle (the CAP theorem for managers): fast, good, cheap / reaction speed, quality, cost efficiency
  • choose two; if three you don't optimize one of them
  • if cost fix, quality high => neither talking about DevOps, nor microservices; but industrializing software development (maximize throughput for money)
  • DevOps: optimize rection speed against market without compromising quality => whole different discussion => ends in microservices
  • more lightweight approach: site reliability engineering (SRE) => dev speed vs. production stability
  • need for CIO having your back, CIO has to have whole C-level on board and Configuration
  • technical help, methodical help, but you can't push thru change, has to be done by them => you can only change yourself
  • need to take whole team with them
• upscaling of teams easier than cutulral change
  • probably the most challenging part => rethinkg IT
    • only done if enough pressure
    • only doable if backing by management level
    • everything else results in sth half-cooked
  • cultural change => unlearn old (reaction) patterns and learning of new ones
    • very difficult,
    • very effortful,
    • much resistence,
    • much instinctive feeling (Fingerspitzengefühl),
    • many positive experiences,
    • only few negative experiences,
    • ideally combined with environment of psychological safety allowing to do mistakes without being punished
• failure culture will establish itself => it's a different type of culture, other mindset how to approach things
  • chaos engineering can help: lets see how system reacts in a controlled environment

Interview F:

• Automatization is generally very important: everything you can be automated must be automated
  • to reduce human error
  • because you don't want to do it manually
  • define standards by automation (test, linter, ...)
  • interpretation: cultural value of automation
• Context: company culture; were automation and quality assurance there from scratch or did it emerge over time?
  • bigger company belonging to a corporation in the automobile sector: wasn't there in every department
  • in their department it was there already for longer
    • "freaks" because they were doing cloud stuff that is not running in the car where automotive processes don't apply, more flexibility
    • => was easier to establish these things even though there were no requirements towards it
    • many experienced people who didn't want to work differently
  • he change to that department as he was personally interested into software craftsmanship and agile, and there he could work like that
  • protecting the mindset is exhausting but it pays off
    • need to build these smaller areas where you can work like you envision it even though there are many people involved
    • no everywhere possible to establish these principles because people are in control that have no palate for it
  • at his new employer: it is the stanrad there, but other environment of product development under their control
• Context: how to establish cultural values (accept costs without immediate roi)
  • lead architect decided it and had the suiting reputation
    • nobody butted in