In my previous blog post, I described how we can use a simple model to assess where to position your applications in your future infrastructure. In the digital enterprise it’s not enough to position your applications correctly in a hybrid environment, it’s also critical to be able to adapt your applications so they address the continuously evolving needs of the business. Let’s now take a moment, using the same model, to identify how to approach the need of agility in your application portfolio.
Three components to an agile environment
To enable the delivery of new functionality quickly, three elements should be combined, cloud computing, agile development methods and DevOps automation. Why is that the case?
First, cloud computing provides developers with development and test environments through fast provisioning. These environments may be located in public or private clouds. Actually, using cloud and automated provisioning not only reduces the time it takes to provision an environment, it also tends to standardize the utilization of the tools which provides many benefits during runtime. In particular it facilitates operations and reduces human error as less variance in the environment set-up needs to be catered for. Also, by providing a single portal from which developers can provision the required environments (a cloud broker portal), company policies on where workloads are located can be enforced automatically.
Agile development methodologies not only foster much closer relationships between the business and the developers by integrating business people in the daily review of progress during sprints, it also enables quick delivery of additional functionality. Rather than having monolithic projects delivering large enhancements after long development periods, agile enables the delivery of a continuous improvement approach where small amount of additional functionality are made available to the end-users on a regular basis. Such approach has a tendency to positively surprise end-users by delivering useful additions every other week or every month.
DevOps greatly enhances the working relationship between development and operations. It automates many of the tasks required along the development process going from testing (continuous integration & testing) to deployment (continuous delivery & deployment) to operations (continuous operations). Automation brings with it speed, repeatability and consistency. When developers check-in code, that one can be tested immediately and automatically enabling developers to have a full report on the potential issues in the code when they return to their desk. Releases that used to take weeks and months can now be done in a matter of hours, enabling regular releases of smaller amount of functionality.
By having business and operations teams participating in the development process, we get end-to-end visibility across the whole development supply chain. I am intentionally using this term as many of the supply chain concepts used for years in manufacturing, can be implemented in software development and operations. By using lean and six sigma principles, the organization is made more efficient and responsive which is exactly the request of business teams when organizations move to the digital enterprise.
Implement DevOps, not a one-time activity.
DevOps is not just about automation tools, actually automation is the easy part. It’s about having development and operations people working closely together. This requires a mentality change. And that is not something that is achieved easily. So do not try a “big bang” approach by rolling out automation across the enterprise. Rather start small and grow from there with teams that are willing to take the risk and try something new. This immediately brings the question on where to start. Using the same model we discussed in my last blog post, let’s look at initial opportunities.
Systems of Engagements, the place to start.
DevOps adds most values in areas where regular releases are expected. The more releases, the more automation increases speed while reducing effort. As companies evolve to the digital enterprise they want to experiment with new business models, with other ways to interact with their clients and end-users. Business teams must be able to experiment as the outcomes of such new approaches cannot be guaranteed upfront. This points to systems of engagements, the systems that interact with the end-users. For that reason, systems of engagements are the right place to start.
In the move to the digital enterprise, the business wants to differentiate itself from competition to disrupt the marketplace. So, it is not just any system of engagement that is the best candidate. I would argue the best place to start is with CORE systems of engagement. Indeed, those are the ones that differentiate the company. Now, you may argue that, in the quest of finding new business approaches, the business teams may decide to take a non-core system of engagement and transform it to become the differentiator. This may happen, but by the fact of being transformed, this application becomes core to the business.
So, work closely with the business, understand what business processes they are looking to transform or create, identify the applications that support those processes and finally assess the development teams to understand which one is most capable of pioneering new development approaches such as agile and DevOps. This team is your candidate.
Non-core systems of engagements should follow suit. As we will see in the next blog entry, the idea is to use either SaaS or COTS based applications here, so the focus should be on continuous delivery and deployment automation.
Starting with Systems of Engagements gives your organization the opportunity to respond quickly to the demand of the business and deliver the new functionality required to enable the move to the digital enterprise.
And Systems of Innovation?
Systems of innovation could be considered as an alternative. However, these systems are originally developed for experimentation and there is no guarantee they will deliver lasting benefits to the company. From that perspective they are less visible throughout the organization. This is why I suggest to start with the systems of engagements. If you want to lead a mindset transformation, having a highly visible application being used to demonstrate the new way of working tends to be more effective. However, the approaches discussed for systems of engagements are also applicable here.
What about systems of record?
As we mentioned several times, systems of record tend to be rather stable, not changing that often. Developing automation takes time and effort. So, here the question is rather simple. If you only do a release once a year or even less, is it cost effective to develop the automation required to enable DevOps. Can the additional cost associated with the development of the automation be recovered through the reduction in time and effort when a release takes place? Frankly I doubt it. This is why I do not suggest to go full DevOps for systems of record. You may want to look at automating some of the testing if you have well defined test scripts available, but automating all the steps in testing and deployment is probably an overkill.
Building agility in your application portfolio
Again, the simple model described enables a comprehensive analysis of where to start implementing new development and operations approaches to deliver functionality faster responding to the increased pace of change in the business. As information technology becomes core and center to all activities performed by the enterprise, being able to quickly and reliably deliver functionality is critical. This is why understanding the positioning of your applications is critical.
Previous blog, Define your landing zones