Sharing IT Best Practices with youSharing IT Best Practices with you
This article describes the role of the functional and technical design in a DevOps context.
A feature is a description of a piece of functionality that should not cost more than half a DevOps cycle time. A feature is described in terms of the business. Features are the epic building blocks and are differentiated in stories.
A story is a technical description of an object to be realized or the configuration of an object. A story is comparable to a Request for Change (RFC).
A functional design describes what needs to be built. A functional design usually contains the following aspects of an application:
A technical design describes how to build the application. A technical design usually contains the following aspects:
A much-discussed debate with starting DevOps teams is whether the product backlog can be programmed immediately or not. Why is there a need for a functional and technical design? It only costs money and they are never up-to-date afterwards. And if these designs are already necessary, how does this fit on the idea of incrementally and iteratively producing a product and / or service? And what if the customer makes changes to the product backlog by leaving and adding features? The concepts of functional and technical design seem to be outdated. This article discusses the fact or fable of operating with a functional and technical design and the relationship with features and stories.
The DevOps process (see article DevOps process) does not provide a phase for a design. From the planning phase, the coding phase starts. This is also what many DevOps teams do. From a feature, a database is created, a function written in Java and a build is performed. Thus, many steps are skipped as included in the functional and technical design templates. The question is whether this is wrong or wise. The answer lies in what may be the value of a functional and technical design for the DevOps team.
The following numbered list shows the default added value. Evaluating this one by one for validity within a DevOps context can determine what the residual value is of the functional design.
The business case of the Functional design as deliverable is:
Ad 1. This part of a functional design is still relevant to a DevOps team. This must be determined in the funnel and determination of the roadmap. The DevOps team is benefiting from this because insight is gained in the adjacent applications and a chain test can be performed before going live.
Ad 2. For the DevOps team, the coarse decomposition is already present by the themes in the roadmap (see article DevOp plan – the deliverables)
Ad 3. This part of the functional design cannot be defined in advance. It depends on the choices that are made in the DevOps cycles. The functional design can be supplemented by realization of the feature. This is a check on the DoD.
Ad 4. The UP / PBA provision is part of the business case. They are a prerequisite for starting an Agile project by means of DevOps.
Ad 5. This part of the functional design cannot be defined in advance. Only the information areas and type of information can be determined in advance. On the basis of this, the interfaces with other applications can also be predetermined (application landscape picture). The data model, however, evolves with the choices made in the DevOps cycles. The data model must therefore evolve based on cycles. This is a check on the DoD. Note that database management has proclaimed for years that up-front definition of data model is a must for a well-functioning application and certainly if it is an incremental developed application. Growing a data model is therefore a risk of the first order. A countermeasure is to redesign the data model including data migration with a rollback scenario per application version if needed. Such a redesign is expensive and a rollback scenario is error-prone. The better the data model is mapped in in advance, the less risk there is for a loss of performance.
Ad 6. In the world of DevOps the contingency management is the key. The focus is laid on the contingency of the Minimum Required Information set (MRI). However, it must be remembered that data processing in most organizations is so complex that it is much easier to do everything or nothing for contingency. If necessary an application may be classified as business critical or not. On the basis of this, you can also make a split between implementing contingency measures for an application or none.
Ad 7. The product back log cannot fulfil this role correctly. Features that are realized should be preserved. But together with the open features, they form unrelated objects. Consequently, the consistency of things is lost.
Based on the above analysis, it appears that parts of the functional design fits the top-down analysis of the application (funnel roadmap release plan). Other components of the functional design should evolve with the realization of the application. The functional design can best performed per realized feature. So once a feature is broken up into stories, the update of the functional design must also be considered. As a result, this document remains up-to-date and also looks at possible risks to be controlled during the realization of a feature. DevOps “done” means “functional design has been updated”.
The question that arises, however, is whether for every application there should be a functional design. The answer is no. But once there is a funnel, roadmap and release plan, there must also be a functional design. Because features are objects that describe the “what”, it may be reassured that the features are part of the functional design. In fact, the features should be provided with meta data so that they can be used to generate a functional design. If the functional designs are also included in the code repository as text blocks and are provided with a version, a functional design can be generated based on the repository and product backlog. Thus, the functional design is an artefact that is recorded in the artefact repository just like the object code.
But there are also applications that do not require a functional design. With this, features remain applicable, which describe in themselves the functional design. For uniformity, it is also useful to generate functional designs for those applications.
The business case of the Technical design as deliverable is:
Ad 1. In practice, concepts as docker and cloud services are getting more and more common. Amazon has already introduced API’s for message queueing and nonSQL databases. The need for a detailed overview is greatly reduced. However, if the designer starts the functional design in the funnel and expands it during the roadmap and release planning, then the design of the technical products (infrastructure, system software, tools et cetera) may take place as well.
Ad 2. With the advent of IAAP and PAAS services, the NFR is no longer as critical as before. Security is another story. It is still necessary to look carefully at where information is stored through the infrastructure and whether it is permitted by law and regulation.
Ad 3. The deployment pipeline must be modified if other requirements are imposed on the infrastructure such as security measures and rights. These must be known timely in order to prevent disturbance of the flow of the DevOps team.
Ad 4. Like with the functional design, it is necessary to share knowledge. This knowledge sharing must also bridge time and distance.
Based on the above analysis, it appears that part of the technical design, like the functional design, fits well with the top-down analysis of the application and use of the infrastructure. The technical design will also evolve with the realization of each feature. So once a feature is split into stories, the adjustment of the technical design must also be considered. As a result, this document remains up-to-date and also looks at possible risks to be controlled during the realization of the features. DevOps “done” therefore means “the technical design is up-to-date”. The stories reflect the technical implementation of the features. So, the technical design must be able to be generated based on text objects that are related to stories in the repository. The technical design must also be included as an artefact in the artefact repository.
Functional and technical designs are counter measures for risks that cannot be neglected. However, these designs should be determined in outlines during the funnel – roadmap and release planning. The details of the functional design are captured by the means of features. Features must be described with meta-data attributes so that they can be generated and become part of the artefact repository. The expansion of the functional design should be on feature base instead of cycle base. The same is valid for the technical design. The technical design however is generated based on the stories rather than the features.
Discuss with us about this article on LinkedIn.
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.