Software factory business model

The same is true for product development. For each solution, there should be an informed decision about the appropriate security measures and applied maturity that inform a trade off of the costs time, effort, team maturity and desired security in the product. There is no value in a maximum secure product that never gets released and nobody can afford.

Nor is there value in a poorly secured product that has significant usage risks. Specific maturity levels are specified for each security practice. The table below shows example maturity levels for static code analysis. A product risk level is the risk of potential security breaches. Risk is defined as probability that an event happens, multiplied by the impact of the event.

Probability attributes, for example, represent how attractive and easy it is to breach the system. Impact attributes represent the damages a breach can cause to the organization and to customers. The risk matrix defines the level of risk and each product can be assessed by a simple risk matrix. This defines a certain risk level to each product. By understanding the product risk level, the business can make decisions about the appropriate security practices and the required maturity level to be applied.

This is done for each practice with an example for static code analysis as shown below. Reading the table, for a product with low security requirements risk level 1 or 2 maturity level 1 or level 2 is acceptable.

For a product with high security requirements risk level 9 , we need to apply maturity level 4. Based on the result, the team can agree on the right improvement activities and potential required compromises to reach an optimum economic outcome. Once the security practices and their maturity levels are defined, we apply our models, shift left, bottleneck identification, and software factory by analyzing each practice along with our current pipeline implementation. To explain the approach, we use static code analysis practices as an example, but this can be applied to any other practice as well.

A good way to analyze the security practices is to compare your current pipeline position with the maximum shift-left position as described in the SAFe DevOps Health Radar. Threat modeling analyzes a system to answer vulnerability questions such as, Where am I most vulnerable to attack? What are the most relevant threats? What do I need to do to safeguard against these threats? Threat modeling anticipates future potential threats and avoids or addresses them during feature design. If performed after the implementation, any changes in code and design would be too expensive and time-consuming, if possible at all.

Security IDE plug-ins give developers direct feedback while writing code. This promotes learning and is the least expensive way to both discover and fix vulnerabilities.

Integrating the IDE plug-in to the static code analysis backend makes usage simpler by registering reviewed false positives to avoid repetition. A good plug-in also contains a knowledge base with further explanation about potential vulnerabilities and educates developers while they write code. Another advantage of IDE-level integration is the ability to directly add annotations for the scanner to the code, to mark false positives, and avoid new reappearances during refactoring.

Code reviews are the only way to assure certain code qualities, but they come with delayed feedback. Code reviews happen after analyzers uncover their issues, allowing the human code reviewers to focus on issues they cannot find. And, patterns from multiple code reviews can provide opportunities to automate rules inside the code analyzer.

Pair work provides real-time feedback directly during design or coding. It also raises and broadens the skillset for the entire team as teammates learn from each other, especially when pairs change over time or severity experts temporarily join a team. Static code analysis uncovers potential vulnerabilities. Later, a developer review filters out and marks false positives, classifying vulnerabilities based on criticality and tracking them in the vulnerability backlog.

Third-party scans : What is true for your own source code also applies to third-party code. Any library or component should be evaluated by static code analysis, particularly those that are dynamically or intentionally updated during the build process.

Fuzz testing is used to bombard components at their interfaces with random data to test input parsers and their behavior for unexpected data including special characters, high volume, etc.

Code signing establishes authenticity and ensures that consumers can only execute unmanipulated code. Depending on the technology, code signing is performed for each build or the final code package. In some languages, code signing can change the behavior of the code and should be part of the build and testing process. Infrastructure scans find weaknesses in computing infrastructure including malware and passwords in application servers, databases, or other services, and open ports, as well as outdated components such as old SSL, SMTP, and DNS versions.

Dynamic scans as part of end-to-end testing and in staging are used to discover vulnerabilities such as unnecessary open ports, configuration issues with components, outdated patch levels of operating system and other used components or packages, unwanted potential privilege elevation, default passwords for applications and services, authentication issues, stack overflow, denial of service attack and brute force vulnerabilities, SQL injection, cross-site scripting, weak HTTP cookies, etc.

Malware scans should be used for SaaS infrastructure and before packaging any component. Penetration testing pen testing attempts to breach IT systems by simulating any kind of hacker attack.

This type of testing requires highly skilled professionals who can apply the same tools and techniques that real hackers would use. Any vulnerabilities found are tracked in the vulnerability backlog and fixed according to priority.

As pen testing is mainly a creative and manual process, it is difficult or even impossible to fully automate and perform it in small increments. Because it is one of the few practices that we cannot easily shift-left, make these the common alternatives:. Continuous security monitoring monitors systems to find potential security breaches. This is usually done by a security information and event management SIEM system that incorporates advanced analytics such as event correlation, user behavior analytics, network flow insights, artificial intelligence, and incident forensics.

With the collected data, security analysts can derive the proper actions and generate applicable security compliance and audit data. The security response team gathers information about newly discovered vulnerabilities security mailboxes, security bulletins, white hat hackers, etc.

Application providers issue security bulletins to inform customers about newly found vulnerabilities and any necessary measures to mitigate or fix them. Here is one example of how the software factory can provide significant productivity and quality improvements. This approach can apply to other practices as well.

Static code analysis is a great candidate for a software factory service. Because a single static code analyzer does not cover all potential vulnerabilities, several different analyzers should be used.

Selecting and maintaining all these tools and related integrations would cause a cognitive overload of teams and if done in all teams, be an unnecessary duplication of work. So, product teams usually work with a suboptimal subset or just a single analyzer, unless there is an engineering service that provides a mature and reliable solution.

Specific subject matter experts can build a standardized engineering service that can be automatically plugged into the CI pipeline. Because the service is already preconfigured and consolidates results in a single vulnerability data and knowledge base, the engineering services team can centrally maintain updates and new content.

Plus, the service can be extended with standard dashboards and reporting, a knowledge base, audit reports, IDE plug-ins, alerts and notifications, risk assessment support, and others. A key piece is the ALM tool integration to systematically track and prioritize found vulnerabilities and issues.

The whole setup can be integrated into the larger factory services for standard monitoring, backup, disaster recovery, and resource optimization via infrastructure on demand IoD , and a service portal. With this approach, all product development teams can benefit from the enhanced maturity and broader coverage of the scanning and the reliability and quality of the service. Consuming it as a service reduces the cognitive load, and instead of investing the time in tooling, integrations, and maintenance, the product team can invest in further security training and knowledge gathering.

History shows that product teams can set up associated tools but lack the time to care about backup, compliance requirements, or disaster recovery of used systems. Those activities either consume extra time or simply never get implemented, and both options are not very desirable. Employing a shared service allows engineering teams to centrally manage these challenges and build professional and robust solutions.

Single teams can still pilot innovations in the context of a community of practice CoP and distribute them later to all service consumers without much additional effort.

Achieving benefits associated with shift left and eliminating bottlenecks requires a new mindset—a different way of thinking. For starters, we need to engage governance personnel early in any SAFe transformation—without them in the shared organizational mindset, they can slow adoption. Instead of enforcing obsolete doctrine or creating unreachable requirements, the governance function becomes the trusted advisor working with the teams to understand required measures, help them learn required skills, and establish the required environment for success.

Special reviews and checkpoints that hinder product development flow are eliminated; the responsibility for security moves to the teams. As soon as teams understand that they have full responsibility for the security in their solution, they will proactively seek assistance and make decisions in the best interest of the business.

This includes complete transparency for status and progress, including exposing agreed KPIs. In this model, security governance becomes responsible for creating an environment for teams to be successful and advancing the maturity of the organization by:. Security is usually hosted in an InfoSec or cybersecurity department with teams that are often surprised by these new Agile initiatives and naturally resist new demands.

This is understandable because, from a local optimization point of view, the benefits are not obvious. SAFe helps here to explain the global optimization approach and organizing around value. These kinds of changes are substantial organizational changes and senior management must understand and drive the change by explaining the benefits of the new mindset and approach to the organization and by incentivizing desired behavior.

They might not be intended as full-time roles but can be offered to appropriate candidates, such as a Solution Architect at the large Solution level, a System Architect at the ART level, and a team member on the Agile Team. Enterprise software development is a complex endeavor that requires applying multiple different models, principles, and practices. Figure 10 provides an overview of those discussed in this article and highlights the interdependencies between them.

Figure 10 also shows the application of SAFe Principle 2 — Apply systems thinking and the value of understanding the bigger picture instead of focusing on local optimization. Armed with SAFe guidance, DevSecOps practices, and discussed models, organizations can effectively accelerate flow and increase value to the business. Necessary cookies are absolutely essential for the website to function properly.

These cookies ensure basic functionalities and security features of the website, anonymously. The cookie is used to store the user consent for the cookies in the category "Analytics". The cookie is used to store the user consent for the cookies in the category "Other. Many people criticize the Agile movement on the grounds that software development is very different from manufacturing and so the metaphor might be more harmful than helpful.

Because they believe it is harmful, people have pulled back from the metaphor and only used what seems to be appropriate for teams of programmers. However, do those people know anything about what manufacturing, especially Lean Manufacturing, is even like?

How do they know that software engineering on a team is not like building a car? My experience on development teams, and talking to other developers, is that only a few know anything about manufacturing. They only imagine what building a car must be like: turning the same screw on 1, different cars every day. I explore three different interpretations and their consequences.

I think the most popular way to imagine a dev team as a factory is to see it as a set of features moving down an assembly line, getting gradually closer to deployment. The feature goes from conception, to design, to scheduling into the sprint, to development, through code review, then testing, and finally deployment.

Ideally, the process always flows forward as each step is completed. This way of rationalizing the process is strangely soothing, especially to a manager who would like to track progress. Number of tickets deployed, or its proxy Velocity, feels like a nice metric to get a feel for how the features are coming along.

To flesh out the metaphor, the people working the process are like factory workers. Work comes to their station, and they do it. So a feature gets to QA, QA tests the software, then hits a button for it to proceed to the next step. Each worker is a cog in a greater machine, and no one has to know more than their job.

So what are the consequences of this model? They are like so many Lucille Balls desperately trying to keep up. People are rewarded for velocity. All they know is that it was upstream from them and if they pass it on, they can push that button. And so problems get pushed down the line. The teams get divided by function. That means design is separate from dev is separate from testing, etc. Instead of working together, this metaphor can create animosity between the groups as they blame each other for problems.

This is a metaphor that I have never really seen before, but I think it has some merit. Instead of seeing the team as a factory, you see the software as a factory. If car factories deliver cars, your accounting software delivers accounting. A smoothly running factory means smooth accounting. That means invoices move down an assembly line. Programmers build that assembly line.

If our software is the factory, then how do we correspond the various roles? Well, at the bottom, invoices and payments are the partially completed cars moving through the assembly line.

Continuous improvement is a foundational pillar of DevOps. When you deploy smart automation to accomplish software factory goals, teams deliver on a commitment to always improve and provide faster, more comprehensive services and upgrades to customers when and where they need them.

First, determine whether the product scope makes sense for a software factory and can be implemented successfully. Understand two key components:.

Next, define the scope. Using machine learning the software factory will compare product specifications against previous products to draw inferences about the most efficient development strategies that can be automated. Then, automated programs can map differences between two designs and update based on changes in scope. The various mechanisms that can be used to develop the implementation depends on the extent of the differences in implementation between existing products.

Deploy or reuse existing constraints for default deployment and configuration of the resources required to install and execute the product. Finally, smart automation can create and reuse testing components such as test cases, data sets, and scripts and implement instrumentation and measurement tools that offer important data output. Human skills like collaboration and creativity are just as vital for DevOps success as technical expertise.

This DevOps Institute report explores current upskilling trends, best practices, and business impact as organizations around the world make upskilling a top priority.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion. See an error or have a suggestion? Please let us know by emailing blogs bmc. With our history of innovation, industry-leading automation, operations, and service management solutions, and unmatched flexibility and choice, we can help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.

December 4, 5 minute read. What is a software factory? A software factory relies on reducing the amount of interaction from developers so they can focus on higher-level technical challenges within the organization, such as: Monitoring and maintaining the automated framework Ensuring that enterprise data is secured Today, companies across all industries are trying to become more like these leading tech companies.

This harmonious environment is conducive to: Higher levels of satisfaction and success Better technology utilization Fast communication of information, resulting in fast decision making All and all, implementing a software factory with machine learning and artificial intelligence helps enterprise businesses achieve this goal.

In addition to creating a better work environment for dev teams overwhelmed by high software production goals, creating a software factory is the most efficient use of enterprise resources because it ensures that: Learning occurs before the next round of software. Any learned methods are applied in future builds.

Components of software factories These components comprise a software factory: Recipes. Automated processes to perform routine tasks with little or no regular interaction from the developer.