Roles and Responsibilities for a web hosted production system

Question

I've been asked to doc what I think should be the breakdown of roles and responsibilities for our production system hosting the companies web application. This is partially so we an start to assign responsibility a bit more formally and so we can avoid things not slipping through the 'I thought you did that' gap. So...

I thought I'd ask you lot what you think they should be.

As evidence of some work on my part this is an overview of my current thinking. Each line is a separate role/responsibility. Although one person may have one or more roles if one role is split across multiple people it'd be reasonable to have one main point of contact for it.

• DBA
• OS etc installed on new machines
• Network setup
• Software installed as part of our service (Tomcat etc)
• Installing/configuring our software
• Troubleshooting/incident investigation (may call on others with specialist knowledge)
• Monitoring, ie installing a configuring monitoring software to support others in their roles
• Capacity planning
• Overall responsibility, the guy with his nuts on the black as they say

There are various cross cutting responsibilities I guess (ie security) which perhaps are coordinated by someone responsible even if the work is done by several people.

Any thoughts, additions, removals or tweakings of the above. I freely admit to be somewhere outside my sphere of expertise on this stuff.

Answer 1

The size of the company and the industry largely influences the structure of the IT department. In some cases, a little too much. My professional focus is an Internet technology infrastructure.

I encourage the separation of duties between primary production and internal intranet support. Even with a technology company, there will be internal only applications and support demands. Often, helpdesk would fit within internal intranet support. Depending upon the size of your environment, you could potentially justify separating the duties in production between architecture and maintenance.

I like the junior to senior level approach, which is documented well by SAGE's job descriptions for system administrators. This is a reasonable rule of thumb to follow in general.

In a smaller environment, separating duties too much will not be justified and may encourage siloing within a department. Smaller environments benefit from shared knowledge and responsibilities. As the company and IT department grows, it may make sense to start separating duties more specifically.

Key areas, which often benefit from some separation of responsibilities:

• Application stacks
• Database
• Network
• Security

I would suggest creating a spreadsheet listing the key responsibilities within your department. This could be more general and identify specific areas that have more support associated with them, such as the phone system or ticket system. Have staff assigned as primary and secondary, so as that the immediate knowledge can be shared in addition to the documentation. This will clarify responsibilities and they can be moved around to prevent boredom as well as enable learning within the group. Some example categories for the responsibility matrix would be:

• SLA Accountability
  • Uptime reports
  • Change control processes

• Backups

  • Policies
  • Systems
  • Database

• Operating Systems

  • Windows
    • Small patches
    • Large upgrades
    • Performance tuning
  • Linux
    • Small patches
    • Large upgrades
    • Performance tuning
• Monitoring
  • Alert system
  • Historical monitoring
  • Web analytics
• e-Mail
  • Spam box
  • End user box
  • Production application relay

This list goes on and on, which will be specific to your infrastructure and the needs within your company.

I would recommend considering a skills analysis as well, asking your staff to rate their skill level on different technologies compiled into a spreadsheet. The rating is not definitive and would not affect performance reviews. This could identify potential gaps in your current skill-set, which is where focus can be for training and future hiring.

Answer 2

You're pretty close for a first draft, without further details about your application. Here's how to get the rest of the gaps: Make a diagram with every component in, or that supports/feeds/depends on, your application. Make sure you've got a name or team that's responsible for each piece. Have at least someone else, and preferably not on your team do the same thing from scratch - make sure you get different perspectives. This includes management - they will likely have an entirely different viewpoint from the IT folks, and it may be very valid. It may also be some CYA crap, and that may still be valid :-)

Here's some other ideas that may or may not apply to you:

1. AV/Security/patching/regulatory compliance. Some of this may already overlap with your OS/monitoring/network folks. Security and/or regulatory compliance may need to be its own staff.

2. Documentation - or each team may be required to do its own.

3. Who handles communications with the customers? Is there a ticketing system for problems from the customer? Is there a designated team that handles announcements of maintenance or unplanned downtime? If the customers are external, is there an internal accounts team or salespeople that like to be notified about these things?

4. Who handles decisions about upgrades, enhancement requests and bug reports? This could be "product" or "portfolio management" and will probably heavily overlap with the business folks.

Answer 3

Maybe not within the scope of what you want, but what about the app itself? E.g.: 1) What about content (if any)? I.e.Which roles can draft, approve and release content.

2) Which role decides who can draft/aprove/release content? Which role then implements that ie. sets up the users with appropriate access to draft/approve/release

3) Also access control. Which role is responsible for approving new users and deciding what access they get and then which role is responsible for implementing that once it has been decided? I.e. actually granting the appropriate permissions to allow the user the access they should have.