DevOps approaches highlight the value of early and frequent releases into production.
In extreme cases, it is continuous deployment.
In order to achieve this – or even progress towards this, the underlying application as well as the portfolio architecture should be aware of such evolution.
The discipline of Enterprise Architecture recommends structured approaches to layer the solutions and ensure that multiple perspectives are addressed adequately.
Building applications today is a lot more complex even for enterprise internal applications, as they need to cater to the expectations of the changing profiles of the workforce, changing patterns of technology adoption – including the trend to BYOD (Bring your own device) as well as the need to integrate information from multiple sources to infer patterns for better decision making.
Agile approaches have helped development teams become more productive and engage the customers throughout the life cycle.
One of the common misconceptions about Agile is that there is no need for spending time on architecting the solution.
That is not correct. While some portions of the detailed architecture [or design] could evolve over time, the core non-functional requirements need to be considered in making choices on technology, design patterns etc.
Additional aspects related to the application being fault-tolerant, or, in more advanced implementations, self-healing etc. will require run time tracking and logging of application behavior and analysis of causes that can be rectified.
In the Ops side, the concept of a KEDB [known error database] has delivered significant benefits in making the first level support more productive – leading directly to increased user satisfaction on quality closures of their requests.
For the software to also benefit from this, new technologies, including AI techniques need to be considered.
Agile approaches recommend that managers unlearn some of the techniques of command and control and learn approaches to let go and lead teams. Similarly, application architects need to unlearn some of their practices and transcend to enterprise views.
These views must necessarily include the run time or production perspectives also.
To conclude, I would like to say that a DevOps journey should start with an analysis of the enterprise architecture and be based on a flexible foundation so that the benefits of rapid and frequent deployments can indeed bring in benefits to the business users.
