CharlesRivet 120000F3RC Visits (3602)
here and here) and Scott (here).
If you look at the content of the blog, we have already either touched or hinted at agility in various areas of the whole development lifecycle.
We have now touched at the customer - product management - development - testing chain. This is what most people are thinking about when they think agile, or in IBM Rational's words: Agility@Scale.
But what happens after that? After the product has been developed and tested, it still needs to be deployed in the final operating environment! This is what we call "DevOps" (Development + Operations).
Now, agile does promote the delivery of working products after each iteration (e.g., after each scrum), but in the telecommunication service provider environment, you have to be sure of the quality before delivering to a running environment subject to serious operating requirements (e.g., the "Five Nines" uptime requirement). This typically imposes restriction on deployment of the products on running systems, even on lab systems. There is time needed to set up the lab environment and provision it, to select and update the tests to be performed, and to get the feedback to the development team.This obviously create a funnel, and if the time required for test setup and run is large, there will be problems as continuous builds from the agile development team pile up waiting for operation testing feedback. The whole process is no longer agile...
So what are we to do if we want the whole lifecycle chain to be agile? We need more automation!
Actually, we need more than automation. We need to have the product developer, tester, and infrastructure developer to work in parallel. We need each of these teams to be able to automate, respectively, product builds, test builds, and infrastructure configuration scripts. We need to ensure that when everything is ready, we can baseline these three assets so that the setup of the needed runtime infrastructure, the installation of the product, and then the execution of the test suites are automated and that the results are made available to all concerned.
Figure 1: DevOps Automation
And then we need to track and dashboard all of this to have a complete picture and so that we can govern the process to improve it.
Simple? Not really. Easy to implement? Also has its challenge, not the least of which is getting collaboration across what are typically siloed organizations within a communications service provider.
And once you have all this, there can still be improvements. Scott has already mentioned service virtualization in his Differentiate yourself with life cycle testing postings and that can certainly simplify testing of interaction with other services and systems. Another way to do this would be to combine this approach, virtualization, and a cloud-based environment. that is what we call IBM SmartCloud Continuous Delivery.
If you want to read more about Collaborative DevOps solutions, I would invite you to have a look at the Collaborative development and operations site.