Fortunately, there are some general practices and guidelines that can provide
useful reference points. The elements described in the list above fall into a few
general categories:
• Support for Cloud Customers
• Core Platform Development
• Operations • Strategic Direction/Roadmap
It is not uncommon to have departments or groups aligned with these catego-
ries. Here is one example:
Product Ownership
Request Management
Feature Prioritization
Platform Dev
Architects New Capabilities
Build and Tests Code
Builds Tools
Cloud Customer Support
Cloud Customer Signups
Help Desk and Issue Tracking
Platform Services User Guides, Docs
Customer Feedback and Requests
Cloud Ops
Systems Monitoring
Cloud Services Account Deployments
Capacity Analysis
Security Audits
Release Management
The groupings often differ from one enterprise to another, in structure as well
as naming. Some organizations will create a separate tools development team,
rather than rolling that function into Platform Development. While the final
organizational structure will vary, the important point is this: A range of addi-
tional critical functions should be addressed by dedicated groups, rather than
simply be extensions of your developers’ responsibilities. For example, it is
probably not a good idea for automation engineers to spend time on cost trend-
ing, or for someone who is great at test frameworks to write microservices
how-to documentation. Not only is it more efficient to have dedicated groups
for these functions, but different skill sets are appropriate as well.
What About DevOps?
Some of you are now saying: “Wait a minute! Isn’t DevOps supposed to be
breaking down the walls between Development and Operations?” That’s a
great question. Before we go further, (and without getting too deep into defini-
tion debates!) let us look at the fairly generic definition of DevOps as currently
cited in Wikipedia:
64 | THE DOPPLER | FALL 2018