Runtime Governance is a broad area of focus and involves many different kinds of people and processes. The complexity of runtime governance is perhaps the main contributor to why most projects are either fully or partially unsuccessful in meeting their objectives. If you consider the people involved, there are a variety of roles including project managers, DevOps, and also C*-executives who are interested in the outcomes of runtime governance. In terms of processes yet again there are many, such as continuous integration, system monitoring, and analytics for understanding overall performance, generated value, and ROI.
.png?version=1&modificationDate=1373876365000&api=v2)
While there are several aspects that require attention to get runtime governance right, one of the most important aspects is having a proper lifecycle management strategy. This is also perhaps the most misunderstood area in terms of runtime governance. The whole idea of a design/development lifecycle is to keep track of a project’s progression from Concept to Production. But once in production, such a lifecycle is not really going to help. However, more user-oriented systems such as API Stores and Gateways also require a concept of a lifecycle to manage a running system. This is not focusing on the development of a project but on its availability - for it to be used or accessed by an end-user. This is what gives rise to two separate kinds of state that you need to keep track in a system, namely, the State of Development and the State of Availability.
The State of Development is all about keeping track of whether a project is ready to go into a production or a “running live” setting. This involves lining up the development and continuous integration processes, as to whether the project is built properly, whether best practices have been followed and whether proper testing has been done. The lifecycle itself might be fully-automated, semi-automated or even manual. The level of automation does not create any harm in terms of finding answers to the kinds of questions related to readiness, however, automation can reduce a significant proportion of human error and produce more robust outputs within strict timelines. The only downside of automation is that it really leaves little room for manual override and limits the agility of the project creating a scenario where "system drives human" rather than "human drives system”.
The State of Availability is all about understanding whether your project is ready to be accessed by the outside world (or the world beyond the project team). Now, the interesting fact is that most projects become already accessible well before they go into the Production state, and you’ll often find conflicting situations with most of the all-in-one linear and continuous lifecycles that attempt to merge the concepts of development and availability together. This creates situations where process and tool don’t tend to be fitting. This leads to development teams exploring into their own sets of workarounds to make things happen. However, in a lifecycle management system that is well designed, the possibility of things available and the ability to keep track of development should both be possible at the same time. But, these concepts are not fully orthogonal, and the teams themselves should be able to decide on how these two things connect to each other.
Therefore, to solve the problem of two kinds of state, the lifecycle management of your project should be designed such that it takes both of these things into consideration. Both of these kinds of state will have multiple stages of progression and they will require concepts of checklists, validations, approvals and permissions for the model to be meaningfully governed. Therefore, from the tool’s point of view, there should exist the ability to support multiple parallel lifecycles at the same time, which can be separately tracked and monitored. Such a Governance Framework will be able to support both Continuous Integration Systems and Enterprise Asset Registries at the same time.
The State of Development is all about keeping track of whether a project is ready to go into a production or a “running live” setting. This involves lining up the development and continuous integration processes, as to whether the project is built properly, whether best practices have been followed and whether proper testing has been done. The lifecycle itself might be fully-automated, semi-automated or even manual. The level of automation does not create any harm in terms of finding answers to the kinds of questions related to readiness, however, automation can reduce a significant proportion of human error and produce more robust outputs within strict timelines. The only downside of automation is that it really leaves little room for manual override and limits the agility of the project creating a scenario where "system drives human" rather than "human drives system”.
The State of Availability is all about understanding whether your project is ready to be accessed by the outside world (or the world beyond the project team). Now, the interesting fact is that most projects become already accessible well before they go into the Production state, and you’ll often find conflicting situations with most of the all-in-one linear and continuous lifecycles that attempt to merge the concepts of development and availability together. This creates situations where process and tool don’t tend to be fitting. This leads to development teams exploring into their own sets of workarounds to make things happen. However, in a lifecycle management system that is well designed, the possibility of things available and the ability to keep track of development should both be possible at the same time. But, these concepts are not fully orthogonal, and the teams themselves should be able to decide on how these two things connect to each other.
Therefore, to solve the problem of two kinds of state, the lifecycle management of your project should be designed such that it takes both of these things into consideration. Both of these kinds of state will have multiple stages of progression and they will require concepts of checklists, validations, approvals and permissions for the model to be meaningfully governed. Therefore, from the tool’s point of view, there should exist the ability to support multiple parallel lifecycles at the same time, which can be separately tracked and monitored. Such a Governance Framework will be able to support both Continuous Integration Systems and Enterprise Asset Registries at the same time.
