Traditional development is becoming incompatible with modern business
Software improvements are needed constantly by business to maintain competitive advantage and keep costs low. Making software improvements introduces downtime while production objects get replaced with newer improved versions. Where files are improved there is more downtime as data is copied and mapped from old to new file structures.
Traditional development has its own silo where software improvements are made and then passed to QA. QA test them, typically with simulated production data and hand over a pack to Operations containing the software improvements, installation routines and instructions.
Traditional Operations also has its own silo. Operations are reluctant to receive too many packs a year because they can disrupt day-to-day business. Operations would typically insist that the number of packs be kept low and only handed over at pre-defined, off-peak times. This traditional development process has its limitation:
|Expensive||There is a significant time lag between the customers (the business) ideas and the improvements being deployed to production. This too often results in consumption of budgets to develop features which are no longer needed by customers.|
|Unproductive||There can be large disconnects between customers and developers. Developers tend to put in place the structure of software first and only second implement customer ideas. This can create significant, unproductive delays and compromises.|
|Inflexible||Traditional development methods can be rigid to change. Customers change their requirements often because the business changes often. This can mean resistance to change from Development followed by much extra effort and delay.|
|Bottlenecks||At each step of the traditional process rigorous approvals are required. This translates to project delays on top of management delays.|
|Non-transparent||Managers of traditional development projects get inundated with status reports about improvements but nothing on business productivity. This means they become ineffective at keeping score.|
DevOps is all about fast incremental application improvements. Businesses are discovering that they prosper more with this approach than the traditional, slower, all-at-once approach because it delivers value sooner. This saves and makes the business money. Since traditional development is built around departmental silos with sometimes conflicting priorities, the biggest barrier hampering DevOps adoption is getting these silos to work together and embrace a new way of working.
The biggest barrier hampering DevOps is getting everyone to work together and embrace a new way of working
Foster collaboration between departmental silos
DevOps emphasizes collaboration amongst people from different teams. It is important therefore that tools can be easily used by different groups on a project by project basis. Tools must also fair well with short development cycles and have superior testing abilities which enable production ready code and mature deployment capabilities. A solution is to identify the main bottlenecks hampering the DevOps strategy and choose tools which help eliminate these to get the greatest and fastest payback.
By 2016, DevOps will evolve from a niche to the mainstream employed by 25 percent of global 2000 organizations
A powerful feature of all Arcad tools is they share a common open repository. The open repository is a shared metadata repository which provides an environment-wide shared knowledge base used by all Arcad tools. The open repository holds detailed information about software components (artefacts) which simplifies component management. Also inter-relationships between components which simplifies cross-reference analysis, auto-recompile of dependencies and integrity checking of modifications. The repository is updated dynamically so no maintenance actions are required.
When an information repository is open and available cross functionally the DevOps magic starts to happen
Arcad tools make it easier for multiple self-organizing teams to work on specific new functionality in parallel and at all stages of development from idea to delivery. This is made possible because component knowledge and access no longer needs to belong to any one silo. Good DevOps tools should not create walls between Development, QA and Operations, they should allow information to be shared between teams. The goal of DevOps – an infinite feedback loop of continuous deployments – can then more easily be achieved.