Straight to business - I've participated in a very interesting discussion about development architecture recently: which scenario works better & brings more benefit to the organization:

  1. each team is responsible for all their deployment / maintenance mechanisms separately (let's call it Scenario A)
  2. there's a dedicated DevOps ('Development Architecture') team that is responsible for deployment / maintenance mechanisms (they provide them for other teams) - for the sake of clarity, it will be Scenario B

Both solutions have their PROs:

  1. In Scenario A:

    • there are minimal external dependencies
    • x-functional team is able to do all their work on their own
    • if their deployment mechanism don't work well, they are the ones to get the fastest feedback (& it's very clear who had broken things)
    • the design of application architecture & development architecture goes in par: there's minimum friction and the smallest chance to desync
    • deployment solutions are fit for particular scenarios ("best of breed") - no need to be over-generic
    • teams know how their software works since A to Z: it helps in fighting down the works on my machine syndrome

  2. OTOH, in Scenario B...:

    • so-called 'functional' teams can focus on actual 'business' functionality - no need to bother with development architecture
    • dedicated team cares for coherency, versatility & generic model in development architecture (that helps with minimizing the maintenance costs)
    • you don't have to invest in DevOps knowledge within each 'functional team' - and we're not talking about typical developer knowledge here: yes, DevOps is special
    • development architecture is less likely to get the lower priority as it's DevOps team's primary target ('functional' teams care more about business-related user stories)
    • in case of many, interconnected applications, it's far easier to set up the ownership & responsibility for test environments that way

Ok, all these are valid points, but we're not getting anywhere closer to the straight answer ...

Which scenario is better?

Yepp, that's because there's no simple answer: both scenarios can work (or not) in pretty much every conditions:

  • if you distribute development architecture duties between the teams, but they don't realize how important it is (or in other words - what will happen if they neglect it): you're in trouble

    • loosing the regime of continuous integration will deteriorate the quality of application(s)
    • lack of automation will cause non-determinisms & kill the predictability (and stability)

  • if you centralize these duties in DevOps team, but you won't give them any enforcing power, they will eternally struggle to tidy things up, but cumulated carelessness of other teams will make these efforts vain

  • OTOH, if you set up a supreme DevOps 'Overlords', there's always a chance they won't listen to functional teams and they will force development architecture that will sacrifice meeting the actual 'functional' teams' needs for having simplier, more generic deployment workshop

  • ... and if you distinguish a DevOps team but they won't build a proper rapport with 'functional' teams you'll end up with endless tug of war:

    • 'functional' teams will accuse DevOps of slacking / faulty deployment mechanisms (easy to say, when they just deliver the sources & they don't have to care about how it gets deployed)
    • DevOps will always blame 'functional' teams - because it's them who have introducted breaking change or didn't use the deployment mechanisms in a proper way

For my taste, Scenario A (distributed responsibility) still have more PROs, but to make it actually work well, there are some critical pre-requirements to be met, including clear & stable (extremely rarely changing) ownership over code products.

Hints

Here are some hints that can help you out with at least reducing the pain:

  1. Be very cautious without distributing the responsibility: 'functional' teams HAVE to feel pain (pretty much immediately) if they break deployment pipeline. If Scenario B is just your way to outsource the pain out of 'functional' teams, it (the pain) won't play the role of control mechanism (are we doing it right or wrong?) anymore.

  2. Even in Scenario A (or even - especially in Scenario A ...) set some reasonable ground rules to be followed (common sense ones - execution timeouts, configuration as artifacts, everything in source control, etc.). Some people just tend to walk short-cuts (because of they are people ;P)

  3. Make sure that there's just one common way to deploy each piece of software. It may be different for each program / system / module, but for each program / system / module it has to be JUST ONE way. And all interested have to know that

  4. Whoever does the deployment, the golden law of DevOps is always in-game: if it hurts, it means you're not doing it as frequently as you should

  5. For a typical 'functional' teams the choice between putting some effort in polishing the business functionality or development architecture will always be very clear: it's you who have to actually come up with a way to make sure that development architecture doesn't get the 'nice-to-have' priority constantly.

Share this post