An integrated product team (IPT) is a multitalented group of people from different disciplines responsible for delivering a product. IPTs are formed to tackle complicated projects with challenging requirements or to increase the quality and velocity of product creation or both.
Structure and Interactions
The integrated product team came about to ensure that all of the required roles, skills, knowledge, and personnel resources were either assembled on the team or readily available to the team to make product development, or software development, more efficient and effective.
IPTs commonly consist of software developers, quality assurance staff, product management, project management, and designers. Each specialty brings a unique focus, input, and decision-making to the software development process. Representation from all essential functional areas of the project should be included on an IPT. Each IPT member has decision-making influence over the product.
Formally, the integrated product team comes from integrated product and process development. However, the concept of an integrated product team has a place in other methodologies such as Agile and DevOps, too.
Integrated Product and Process Development
The integrated product team came from an initiative called Integrated Product and Process Development (IPPD). IPPD is a management technique that came out of industry to improve competitiveness and customer satisfaction. It is driven by the customer’s needs. It integrates software development activities, from requirements gathering and analysis to support, to optimize the overall software development process.
IPPD tenets provide insight into its purpose and practice. According to NPD Solutions, the key tenets of IPPD are as follows (www.npd-solutions.com/ippdtenets.html):
- Customer focus
- Concurrent development of products and processes
- Early and continuous lifecycle planning
- Maximize flexibility for optimization and use of contractor unique approaches
- Encourage robust design and improved process capability
- Event-driven scheduling
- Multidisciplinary teamwork
- Empowerment
- Seamless management tools
- Proactive identification and management of risk
All in all, these tenets describe a product development and team management style that focuses on customer needs and quality, one that is responsive to real-world situations and proactive in the identification and management of risk.
Agile Teams
An Agile team is a form of integrated product team. Clear and effective communication is the cornerstone of Agile methodology, and development concepts, techniques, and ideas are integrated within the team’s dynamic. The Agile team management and communication patterns connect them with other teams, expertise, and entities in an organization for necessary information flow and access to these resources as needed.
On the surface, an Agile team resembles the composition of members that you would see on any software development team, regardless of methodology. An Agile team is different, however, in that it places responsibility and decision-making capabilities on the members of the team. Agile teams are small in size, and they put much of the responsibility of product delivery on their members. Software developers, being the makers of the product, have a say in the direction and management of a project. Moreover, this authority extends to team members whose roles commit them to the process. Software developers are by their efforts committed to the process, whereas supporting or accessory participants are only just involved.
Like the integrated product teams formed out of the IPPD, Agile teams exist to produce high-value working software on a frequent, routine basis.
DevOps
With a focus on agility, automation, rapid development, and frequent delivery of working software, new working styles emerged. These forces coalesce development with automation and aspects of system administration and operations. This integration of disciplines and technology has come to be known as DevOps.
DevOps breaks down the wall between developers and operations. DevOps enables continuous integration and continuous deployment. DevOps accelerates software delivery and increases software quality and security.
Many of the DevOps practices, such as process automation, emphasis on testing, and frequent deployments, are similar to those used in agile and iterative methodologies. The distinction between the two is that DevOps is an implementation of these practices and that this implementation can be used within the practice framework of the various methodologies.
DevOps workflow operates much like an assembly line, and the driving force is to build quality into both the process and the software it produces. A complete DevOps assembly line is a specialized automated orchestration of software development and quality assurance activities. This automation of critical activities such as building, testing, and packaging provides many competitive benefits to an organization.
According to the 2017 State of DevOps report put out by the company Puppet, some significant benefits of a high-performance DevOps practice are a 5 times lower change failure rate, 96 times faster mean time to recover (MTTR) from downtime, and 440 times faster lead time from commit to deploy. These results equate to rapid software throughput and production as well as significant gains in stability. (For the full report, see https://puppet.com/resources/whitepaper/state-of-devops-report.)
These forces directly impact software development security. Software-based vulnerabilities can be identified and fixed by the development team. These vulnerability fixes can then be rapidly deployed to production. The DevOps continuous workflow verifies the quality, and security assurance tests rapidly deploy the updates into production. The responsiveness and comprehensiveness of testing make the DevOps workflow a great boon to software security.
Security governance is particularly important when establishing DevOps in an organization. Because of its multidisciplinary set of responsibilities, it is possible to grant the DevOps role too many privileges. DevOps role entitlements must be carefully controlled. When adopting DevOps, it is important to be aware not to create toxic combinations of role entitlements. The security principles of least privilege and separation of duties should be at the fore of DevOps role-entitlement designations. DevOps’s access to deployment environments should be limited to development, with restrictions on access to the test and production environments. The ability for DevOps to affect the operations environment, particularly a cloud environment that is closely associated with DevOps, should be controlled. Where DevOps requires the ability to create user identities, it should be limited in the privileges that it can grant those identities. Where DevOps can change the infrastructure configuration, these changes should be carefully reviewed before promoting the changes to higher deployment environments. With proper security governance and design of the DevOps role and workflows, however, the DevOps discipline naturally points to building security into the software development process.
DevSecOps
DevSecOps (www.devsecops.org/) is the merging of security with DevOps. It takes the DevOps role, automation infrastructure, and workflows and builds in security techniques and continuous attention to security.
DevSecOps is best summed up by the words of its manifesto, which describes how DevSecOps continually learns how security practitioners can contribute with less friction. DevSecOps seeks to innovate to ensure data security and privacy. It seeks to make security and compliance available as services. DevSecOps seeks to open new paths to promote security. In doing so, it proactively engages in security activities with the software. It actively seeks to find security issues and to partner with the organization to resolve them effectively and permanently.
DevSecOps provides a set of values that include an excellent summary understanding of what drives DevSecOps. These values also set the expectations that one should have when working with DevSecOps in an organization. The DevSecOps values are as follows:
- Leaning in over always saying “no”
- Data and security science over fear, uncertainty, and doubt
- Open contribution and collaboration over security-only requirements
- Consumable security services with APIs over mandated security controls and paperwork
- Business-driven security scores over rubber stamp security
- Red and blue team exploit testing over relying on scans and theoretical vulnerabilities
- 24/7 proactive security monitoring over reacting after being informed of an incident
- Shared threat intelligence over keeping info to ourselves
- Compliance operations over clipboards and checklists
Working with these values builds security into software development while also supporting the realization of responsive product adjustment, high quality, and rapid product delivery. DevSecOps is a significant improvement in the meeting of security with soft- ware development.
