Whether an organization chooses to handle software development and implementation in-house or use a trusted third-party vendor, undertaking development tasks can be a risky endeavor. There is always a risk that the deliverables from a new software project won’t satisfy the underlying business need. In addition, projects can suffer from scope creep when business users and subject matter experts don’t have full visibility into the path of development and overall design. Missed deliverables and scope creep are major reasons why many in traditional management roles consider IT to be a resource sink, instead of a profit-driving business unit.
Keeping the development process aligned with the business is where DevOps (Development-Operations) comes into play. Rather than being a new process or framework for handling software development and implementation, DevOps is a cultural shift that has traditional IT roles breaking away from the IT silo. Rather than developing in a bubble, based on specifications provided by Business Analysts and Program Managers, the development group responsible for delivering functional software now consists of business users and subject matter experts.
Creating multi-disciplinary teams is not new, but the tendency of IT groups to retreat within their comfortable silos, while not necessarily detrimental, can prevent organizations from using their resources to their fullest extent. DevOps teams which include both the development/IT resources necessary for product delivery and business users who understand the needs and processes of the business can help deliver solutions which are more closely aligned with the organization’s business objectives.
DevOps Teams – Two Options For the Same Problem
The key component of thinking about IT development in the DevOps mindset is bringing IT and business together. There are no hard and fast rules regarding how DevOps teams are structured. Some organizations create permanent DevOps teams that bring together development and experienced business specialists. These teams exist as a permanent fixture in the organization, and tackle varied types of projects across the entire enterprise, whether it’s a custom line of business application or expanding remote file sharing or document retention systems. However, permanent teams can just as easily become just another team that is a silo; which is what DevOps attempts to prevent.
The more common practice is to create DevOps teams for specific projects or programs. In many instances, these teams have full authority to design, code, test, and deploy the software needed by the business, in a streamlined and very responsive manner. The IT resources may work on other IT projects, and the business users may spend the majority of their day doing their business-aligned jobs, but when the need arises this team comes together to tackle whatever request is coming from the business. By aligning these teams based on the project or product being delivered, an organization can ensure efficient maintenance, upgrades, and enhancements by those that know the product best.
As previously discussed, undertaking large IT development projects can be a daunting undertaking. When approached properly, these efforts can have a positive impact on the organization’s bottom line, and as such require the attention they deserve to be successful. By bringing IT and business users together under one umbrella to tackle the challenge, risks can be more easily managed and the delivered product can help the organization meet its strategic goals.