Join my daily Newsletter

Subscribe to get my latest content by email.

    I respect your privacy. Unsubscribe at any time.

    preloader

    Slicing your architecture without slicing your fingers

    • Tuesday, Feb 11, 2020
    blog-image

    [Reading time: 2 minutes 2 seconds]

    You know those good old-fashioned mandolin slicers (yes I had to look that term up)?

    The ones you can use to slice carrots or cucumbers or something, maybe for a salad?

    Whenever I use one, I’m really apprehensive. They’re really sharp, and really close to my fingers. It’s pretty much a given that I take off a slice of my finger when I attempt to use such a contraption.

    Well, people tell me that DevOps is such a great thing because transitioning to autonomous, cross-functional, product-centered DevOps teams allows you to to slice your product and become more effective.

    However, you can imagine if I come across the verb “slicing”, I’m wincing already. Shudder.

    Turns out this doesn’t just happen to me. A lot of people are apprehensive about slicing not just vegetables, but also products. How do you not end up slicing your finger and making a terrible mess?

    I mean, it sounds straight-forward: if you use e.g. DASA’s DevOps principles, you’ll come across one they call End-To-End Responsibility. So, clearly, each DevOps team must take complete responsibility for the thing they build, which means they must build it all themselves.

    Right?

    I mean, it makes some sense. The cross-functional team should clearly incorporate skills such as development, QA, UX, operations and so forth. But the question may be particularly pressing for operations: what’s the operations people’s job? where do you draw the line?

    I mean, you could tell every team to run their own servers. Sure, that sounds a lot like end-to-end responsibility. But then again, if we take end-to-end responsibility really seriously, maybe they should also have their own electrician, so they can wire their racks up themselves? (And of course we could be even more silly, and insist they design their own processors).

    So what’s a reasonable approach?

    Having a shared electrician sounds like a good idea, but what else can you share – without encroaching on the teams’ autonomy?

    A shared network? Actually, that doesn’t only sound reasonable, it sounds downright imperative. What good is a network that isn’t aligned with the network around it?

    A shared database? Phew… I don’t know? Maybe? It depends?

    Very confusing, all in all.

    What to do?