Skip to main content

Education Programs

Context​

Microservices are being adopted. Each microservice is managed by exactly one team. The team is responsible for the whole life cycle of their microservice(s). Microservices require the introduction of many new technologies like containers and cluster managers, or using different programming paradigms like workflow choreography instead of workflow orchestration.

Problem​

  • Lack of knowledge and experience in development teams how to do microservices
    • e.g., how to split microservices, how do implement distributed architecture, how to do DevOps, ...
  • Lack of knowledge on management and accounting level
    • e.g. leading to resistance in the face of decisions with no immediate tangible return of invest

Solution​

Establish an education program for the microservice teams, but also on the accounting and management level.

On the one hand, applying microservices requires broad knowledge of different domains in the development teams in order to take full responsibility over the microservice(s) lifecycle. Building up this knowledge can be done via education programs. Pick an experienced coach with a certain standing that has the technical depths to go into details with the developers. They have to know the pains of the developers and show them how to resolve them.

On the other hand, applying microservices comes with its economical costs which requires acceptance on the accounting and management level. In the course of the persuasion process (assuming the wish to do microservices comes from the bottom up), but also for future decisions on accounting and management level, the responsible people need to understand how microservices work and what effect they can have on the whole organization. Pick a reputable business man as coach that can maneuver on the management level, convey concepts like beyond budgeting that have no immediate tangible return of invest, and can convince in favor of the required investments if necessary.

Education programs can either be developed in-house or be bought in, e.g., via consultants.

Maturity​

Suggested, evaluation required.

Sources of Evidence​

LM43:

  • Context: SLR findings about microservices in DevOps
  • Organizational problems related to culture, peopls, cost, organization, and team structure
  • Among others, training for new skills
  • S24 suggests to arrange training programs for employees for learning and adopting microservices in DevOps

Interview A:

  • Microservices cost them 6-digit amount, esp. coaching, conception etc.
  • If you say microservices, you have a long road ahead
  • Strictly used education programs and experimentation phases
    • Motivated by the expectations devs will deliver very complex stuff
    • Wanted to be live up to that, not embarrass themselves
    • But it didn't come like that - devs didn't deliver complex stuff
  • Management has problems to understand that there are no final deadlines
    • Forced to be agile since experiments: step-wise progress
  • If coaching
    • Plan resources for internal persuasion effort
    • Directions: accounting, executive board, management
    • Spent years to do politics: no fix budget => see results
    • They need to understand what they decide about in order to make the right choices
    • Just hiring some devop engineers won't do
    • Combine with organizational framework like SAFE
  • Coaches need to have acceptance
    • Senior consultants or senior coaches
    • No need for chatterboxes ("Dampfplauderer")
    • Needs to have the technical depth to show the technical alternatives to devs
    • Act as reputable business man in the face of the management
      • Negotiate over big sums (in big enterprise companies)
      • have economics background

Interview D:

  • Context: Organizational steps towards adopting microservices
    • Depends on market, how high the pain is (e.g. retail high pain)
    • Concerns governance models, how you govern your whole IT and company
  • Concepts like beyond budgeting, betacodex => management and controlling level
    • Project progress reports and yearly budgenting not suitable for fast reaction speed
    • => usually the pain is not high enough to establish that, e.g. automotive sector in Germany was protected a long time from competitors (thanks to lobyism), same for energy supplier
    • Iron triangle: fast, good, pricy - choose two
      • => usually loosen on "fast" / reaction speed => not speaking about microservices/DevOps
    • [A lot of more points here...]
  • There needs to be awareness what microservices entail
    • Need for education to see challenges of distributed systems, on management, business but also IT level.
    • Happens too rarely: 99% of IT people don't have the knowledge required
      • Whole IT departments built on single-processing single-thread deterministic mindset
      • Problem: doesn't hold true once moving across system boundaries => probablistic part added
    • Hypothesis: people could learn it, but there is not enough time