Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Alternate title: 

DevOps Principles

As part of my DevOps updates here is Part 5: DevOps Principles.

Upto 80% of unplanned outages are related to software based errors, issues and defects. A large part of these unplanned outages can be reduced by ensuring that all appropriate non-functional requirements are considered in line with the functional requirements right at the start of the solution design. This is a key component for DevOps.

Dealing with non-functional characteristics too late in the project can increase capital expenditure (capex), increase timeline and can cause relationship issues between business, development and operations. There are a number of key reasons why non-functional requirements are not considered as important or as worse as “a given”:
  1. At the start and during the design and build phase typically non-functional characteristics are not considered, as these are not in the forefront of the design and build activities.
  2. Separate project teams / towers can cause a slip between architects, designers and developers covering functional and non-functional aspects.
  3. Lack of an appropriate governance model that ensures both the development of functional and non-functional requirements and
  4. Lack of a detailed list of all possible infrastructure near criteria needed to cover all non-functional characteristics.

Ensuring that the correct non-functional characteristics at the right time are being considered, an Infra Architect should be involved as early as possible in the project. The earlier the Infra Architect is involved the higher the chances of averting the issues outlined above.

Together with the client, and working with the Business Consultant/Analyst, it is the Architects role to cover both functional and non-functional requirements Non-functional requirements are all requirements that deal with the so-called “-ilities”:
  • Scalability: Ensure the solution supports the current and projected business volumes
  • Reliability: Ensure the solution provides an appropriate level of robustness in support of business processes.
  • Manageability: Ensure the solution can be managed and maintained efficiently and effectively.
  • Availability : Ensure the solution provides the required levels of service as well as performance characteristics

Typical non-functional requirements are :
  • 99.99 % availability per year outside maintenance windows (2h every month and 12h every 3 month)
  • 2h RTO (Return To Operation)
  • 30min RPO (Recovery Point Objective)
  • 24*365 operation with P1 response of 1h and fix target of 2h
  • 8h DRP (Disaster Recovery Process)
  • IL3 data (Impact Level 3)
  • Data retention 4 years with archiving of 6 month
Generically these non-functional can be categorised as follows into 7 main areas :
  1. Service Criticality
  2. Service Availability
  3. Service Reliability
  4. Service Responsiveness
  5. Service Demand Frequency
  6. Service Demand Profile
  7. Service Reporting and
  8. Regulatory Controls
Each has to be defined together with the functional requirements to ensure that the solution delivers the expected features with the right “-ilities”. What is important is to consider the functional and the non-functional requirements holistically.

This means that both the infrastructure design and the application design has to run hand in glove together. Splitting both will have unwanted effects such as delivering an active / active data centre setup when the application cannot operate and active / active mode.

At Capgemini we created a set of 137 DevOps Principles to connect Development with Operations.

About the author

Gunnar Menzel, VP Enterprise Architect
Gunnar Menzel, VP Enterprise Architect

Leave a comment

Your email address will not be published. Required fields are marked *.