Welcome to the Spring 2022 edition of the SalesforceDevops.net Industry Map. In this post, I present the companies that I have curated for Salesforce devops organized into a map of choices. The map is designed to be a devops educational tool and a decision framework for Salesforce platform owners, architects, developers, and low-code users.<\/p>\n\n\n\n
This is a companion post to Salesforce Devops Update – Spring 2022<\/a>. In that post I go into detail about what you need to think about when creating a Salesforce devops management program. This post focuses on the SalesforceDevops.net Industry Map and describes each category. Each part of the map is thoroughly described, with links to the lists of curated companies.<\/p>\n\n\n\t\t\t\t To help teach people about Salesforce devops and to provide an industry guide, I launched the SalesforceDevops.net Industry Map in April 2021. This was done to share a decision framework that helps Salesforce platform owners and architects pick good devops solutions.<\/p>\n\n\n\n For 2022, the map has been updated to rename and combine some of the layers. Two new categories were also added: cybersecurity and testing.<\/p>\n\n\n\n Here is how I came up with the map. Most people portray the software development lifecycle (SDLC) as a loop or sequence of events. I found describing the SDLC as a circle or infinity symbol constrained the ability to categorize devops functionality. Instead, I stacked the flow of activities. When drawing this map, I was inspired by networking architecture diagrams, like the 7-layer ISO stack. Each layer groups processes that communicate with processes in adjacent layers.<\/p>\n\n\n\n Each layer in the map describes a major category of functionality. The lower the layer in the stack, the more granular and finely detailed are the activities. Going up the stack increases in activity complexity and the number of lower-level stack components invoked. Like how a networking architecture functions, inter-process communication is usually limited to stack boundaries.<\/p>\n\n\n\n Cybersecurity and testing are critical devops functions which don\u2019t fit into layered categories. They envelop the devops processes at several levels. This is because continuous delivery pipelines integrate cybersecurity and testing activities at several different stages. <\/p>\n\n\n\n Check each section header and descriptive text for links to see the companies in most categories. Click here<\/a> to visit the entire map of products and services.<\/p>\n\n\n\n The top layer represents all the company executives and stakeholders who formulate the goals of the organization, perform company operations, and observe value stream metrics to inform executive decisions. This is where new projects must originate.<\/p>\n\n\n\n This layer<\/a> consumes the metrics and management information emitted by the Application Delivery Teams. Business processes are modeled and KPIs are identified. Data is used to link app metrics with the tangible value of each app. This gives the stakeholders and executives information used to make management decisions.<\/p>\n\n\n\n This is the key knowledge and actor layer. In an ideal scenario, this layer is occupied by the product team. Large companies often strive for better results with a Center of Excellence (CoE) dedicated to Salesforce or IT product management. Another modern approach to creating application delivery teams is to make agile-inspired scrum teams.<\/p>\n\n\n\n In other scenarios, organizations often employ consultants to build and assemble a new devops management program. Consultants of various sizes often play an important role in helping make the build-vs-buy decisions, and then to go on and implement a chosen devops solution. In the post-implementation phase of a devops project, organizations usually take over operations.<\/p>\n\n\n\n This layer<\/a> represents the project management resources devoted to IT projects. Application delivery teams often use Jira to share requirements, perform sprints, keep order, and move projects forward. This layer should emit the basic devops metrics, which enables companies to find high-performing teams.<\/p>\n\n\n\n This layer<\/a> was called Observability<\/em> in the last version. System reliability engineering (SRE) and incident management covers runtime error monitoring, critical issue resolution, log file management, and audience metrics. Salesforce has some built-in capabilities to cover these needs, and there are a handful of independent software vendors who manage Salesforce reliability. Salesforce users deserve better ways to know how people are using their applications.<\/p>\n\n\n\n This layer<\/a> is where the devops magic happens. It is like how the conductor of an orchestra commands the actions of their symphony. In this case, the musical instruments are the scripts and toolchains in the Devops, Developer & Low-Code Tools layer. Inbound messages to the orchestration layer trigger automated processes that create release artifacts, check & backup metadata, deploy release artifacts, and emit log files.<\/p>\n\n\n\n Pipeline orchestration requires a software system to be the orchestra conductor. For devops, the conductor is a server process running somewhere in the cloud. I call this server process the command server<\/em>. Vendors often refer to this functionality as a CI\/CD engine<\/em>.<\/p>\n\n\n\n It is within this layer where most of the SDLC activities occur. In Salesforce, there is a wide range of choices of how to compose new applications and manage devops. Those alternatives range from pure low-code choices to elaborate, DIY scripted environments.<\/p>\n\n\n\n Much application development occurs today within the confines of the Salesforce clouds\u2019 user interfaces. Low-code tools are also used with applications that run on top of Salesforce, including Salesforce Industries, nCino, and Veeva. Devops tools often run in low-code or no-code user interfaces, whether they are implemented in Salesforce or a separate SaaS application.<\/p>\n\n\n\n This category<\/a> includes the many tools and services used by Salesforce developers to create applications in Apex, VisualForce, JavaScript and other traditional programming languages. This layer also includes the hundreds of cloud native, or free open-source tools that are used by devops teams in DIY solutions.<\/p>\n\n\n\n Devops operations are responsible for major database and metadata updates. Data backup<\/a> is an important function that must be integrated directly into the devops pipeline management process.<\/p>\n\n\n\n Change Intelligence<\/a> is an emerging function within Salesforce devops that gives architects and developers insight into how a change may impact an existing org. This is a good example of using metadata intelligence to give architects and developers information to optimize development strategies.<\/p>\n\n\n\n The process of enterprise application delivery frequently involves moving data that lives somewhere between metadata and transactional data. For example, the data required to implement Salesforce CPQ is a dynamic dataset that requires updates and tracking. And, as Salesforce Customer 360 becomes more prevalent, pipelines will need to ingest more external data sources.<\/p>\n\n\n\n Salesforce devops pipelines require the creation and management of Salesforce sandboxes. There are special security and maintenance requirements for proper sandbox maintenance.<\/p>\n\n\n\n Salesforce profiles and permission sets present special challenges in many devops scenarios. Profile management<\/a> tools allow users to copy, manage, and deploy complex Salesforce profiles and permission sets.<\/p>\n\n\n\n This layer<\/a> represents a Git-compatible server, which is an online storage service for source code repository management, user access, branch management, code security, and deployment artifact storage. Some Salesforce devops solutions implement low-code-friendly repositories on the Salesforce platform instead of a traditional Git server.<\/p>\n\n\n\n There is a wide variety of testing <\/a>options available for Salesforce app producers. They range from tools to manage unit tests to ensuring end-to-end functionality after a Salesforce version update.<\/p>\n\n\n\n In the Salesforce world, cybersecurity <\/a>concerns should touch all operational activities, starting with identity management. For devops, cybersecurity concerns narrow down to security best practices used during the development of custom applications and the configuration of the Salesforce org. Those two concerns are called developer<\/em><\/a> and platform<\/em><\/a> cybersecurity<\/em>.<\/p>\n\n\n\nSalesforceDevops.net Decision Framework<\/h2>\n\n\n\n
Salesforce Devops Industry Map<\/h2>\n\n\n\n
Layer Descriptions<\/h3>\n\n\n\n
Stakeholders & Executives<\/h4>\n\n\n\n
Value Stream Management<\/a><\/h4>\n\n\n\n
Application Delivery Teams<\/h4>\n\n\n\n
Application Lifecycle Management<\/a><\/h4>\n\n\n\n
System Reliability & Incident Management<\/a><\/h4>\n\n\n\n
Pipeline Orchestration<\/a><\/h4>\n\n\n\n
Devops, Developer & Low-Code Tools<\/h4>\n\n\n\n
Low-Code Tools<\/h5>\n\n\n\n
Developer Tools<\/a><\/h5>\n\n\n\n
Data Backup<\/a><\/h5>\n\n\n\n
Change Intelligence<\/a><\/h5>\n\n\n\n
Data Transformation<\/a><\/h5>\n\n\n\n
Sandbox Management<\/a><\/h5>\n\n\n\n
Profile Management<\/a><\/h5>\n\n\n\n
Repository Management<\/a><\/h4>\n\n\n\n
Testing<\/a><\/h4>\n\n\n\n
Cybersecurity<\/a><\/h4>\n\n\n\n
Corrections? Left Off the List?<\/h2>\n\n\n\n