To enable the rapid delivery of new functionality, three elements should be combined: cloud computing, agile development methodologies, and DevOps automation. Why is that the case?
- Cloud computing
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 but also tends to standardize the utilization of the tools. This provides many benefits during runtime. In particular, it facilitates operations and reduces human error as you need to minimize variance in the environment set up. Also, by providing a single portal from which developers can provision the required environments (a cloud broker portal), you can automatically enforce company policies wherever workloads are located.
- Agile development methodologies
Agile development methodologies foster much closer relationships between the business and the developers by integrating business people in the daily review of progress during sprints. They also enable 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 amounts of additional functionality are made available to end users on a recurring basis. Such an approach has the tendency to positively surprise end users by delivering useful additions every other week or every month.
- DevOps automation
DevOps automation 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 and testing) to deployment (continuous delivery and deployment) to operations (continuous operations). Automation brings with it speed, repeatability and consistency. When a developer checks a new code, it can be tested immediately and automatically. When the developer returns to their desk, this provides them with a full report on any potential issues in the code. Releases that used to take weeks and months can now be completed in a matter of hours, enabling regular releases of smaller amounts of functionality.
By having business and operations teams participating in the development process, you achieve 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 exactly matches the request of business teams when organizations move to the digital enterprise.
DevOps is not a once-off activity and it is not just about automation tools. In fact, automation is the easy part. More important is to have development and operations people working closely together. This requires a change of mindset – which may be tricky to achieve. 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 raises the question: Where to start? Using the same model we discussed in my last blog post, let’s look at initial opportunities.
One good place to start: systems of engagement
DevOps adds most value 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, finding new 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 suggests a good place to start is your systems of engagement, the systems that interact with end users.
In the move to the digital enterprise, the business wants to differentiate itself from the competition and even 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, these 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 very fact of being transformed, this application now becomes core to the business.
So, you should work closely with the business, understand what business processes they are looking to transform or create and identify the applications that support those processes. You should also 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. As we will see in the next blog entry, the idea is to use either SaaS or COTS (commercial off-the-shelf) applications here, so the focus should be on continuous delivery and deployment automation.
Starting with systems of engagement gives your organization the opportunity to respond quickly to the demands of the business and deliver the new functionality required to enable your move to the digital enterprise.
An alternative place to start: 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 recommend starting with systems of engagement.
If you want to lead a mind-set transformation, there may be value in using a highly visible system of innovation application to demonstrate the new way of working. In this case, the approaches discussed for systems of engagement are applicable here.
An unlikely starting point: systems of record
As mentioned previously, systems of record tend to be somewhat stable, not changing that often. Developing automation takes time and effort. So, here the questions are rather straightforward. 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. That’s why I don’t suggest going 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 overkill.
Building agility in your application portfolio
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 fundamental and central 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. We will explore this further in my next blog.