General discussion

  • Creator
  • #2297774

    Separation of duties: Development & Infrastructure


    by dmoufarrege ·

    We maintain a development group and an infrastructure group. Because of geographic proximity, the developers have been responsible for the functionality of our web production platform.
    As a result of other changes we are now implementing a joint responsibility for these systems between the two groups. Basically, we are looking for infrastructure to maintain the hardware, OS and services level software and configurations. Development will maintain the application packages they develop and the corresponding databases, etc.
    This separation seems simple enough. However, in reality we have already run into a few bumps.

    I am looking for input on the topic as well as policy templates that may be out there.

All Comments

  • Author
    • #2670663

      One Sandbox, Two Groups, Play Nice

      by oldefar ·

      In reply to Separation of duties: Development & Infrastructure

      A common issue, with a couple of solutions. The more common solution is that a management level above both groups dictates responsibility and becomes the arbitrator of any dispute.

      A better solution is one where both teams reach concensus on responsibility based on solid business and technical drivers. To do this, try the following approach.

      Define the business objective(s) for the Web production platform. Focus on business, not technology.

      Next, define the business requirement(s) in relation to the objective(s). Each requirement must have a valid link to one or more objectives or it isn’t a requirement. Again, this is more business focused so while it is okay to reference a platform or system here, don’t get wrapped up on technology yet.

      Now define technical objectives to your business requirements. Again, direct links are needed to include the tech objective.

      The tech objectives drive tech requirements. What exactly has to be accomplished to support the objectives? A requirement may support multiple objectives, and objectives may drive multiple requirements. Include things like move, add, change, security, disaster recovery. Include relationships between requirements, and include and sub actions. This is where the what and how of keeping your web production platform is clearly and fully detailed.

      Now, assign where responsibility for each requirement belongs based on good sense. For example, proximity might make support work better with one group than another even if the org responsibility would indicate otherwise.

      Document and publish the results. You have a direct link between the business objective(s) and the group responsible for a particular activity, a detailed process linking activities, and a clear justification as to why a particular group should accomplish a particular activity. This can serve as the frame work for future changes as business objectives, business requirements, technology, and organizational structures evolve.

      If the politics of your environment are too intense to use this approach, consider hiring an outside consultant to lead the effort. This way, you can achieve the result while preserving the prestige of the managers involved. They can all blame the consultant!

Viewing 0 reply threads