Define the information you need: code scan vs. survey

One of the very first items you should determine is the information you need to gather from your application portfolio: code scan results only, survey only, scan and survey. CAST Highlight is flexible enough to allow you some changes over time in your campaigns, but it is always better to start “clean” with your first wave of applications to reduce the “back & forth” with your application owners. Options to choose from, which can all be enabled/disabled, are:

• Code only: your main interest at this point is getting insights on Software Health & Size, Cloud readiness and Software Composition Analysis (third-party component risk detection such as vulnerabilities, license issues, technology obsolescence).
• CAST’s survey-based indicators (Business Impact, Application Categories, or Software Maintenance Estimate or all of these surveys in within the same campaign): you want to gather information through surveys sent to application owners on information such as Business Impact and Software Maintenance for purposes of performing Application Portfolio Management, Application Rationalization, etc.
• Custom surveys: CAST Highlight allows you to create custom indicators fed by surveys that do not exist in the product out of the box. It can be an indicator on a specific process in your organization, an application risk rating, metrics from an Incident Management system, etc. In all cases, it is preferable to first design your indicator and underlying surveys prior to launching your first campaign.

Based on the above, you’ll know the kind of requirements for your campaigns (code only, survey only, code and survey) and also the user audience typology (technical contributors who will scan the code and possibly answer technical questions, app owners who know business context of the application, etc.).

Define the frequency of analysis: automated or not?

While the Business Impact or the number of FTEs working on an application don’t change much over time, you may also want to scan the code base more frequently to detect – for instance – possible vulnerabilities introduced within each development sprint. Conversely, you may just want to take the pulse of your app health every major release which happens once each quarter.
Answering the questions below will also help you refine your campaign configuration and identify the need for scan automation (e.g. integrating our CLI or Docker image to your CI/CD pipeline, integrating our API to extract your statistics on incidents to feed a custom indicator, etc.):

• Do you expect to gather survey/scan data at the same frequency?
• If so, is the frequency high enough to leverage automation capabilities?

On automation, I would say that if the data collection frequency is higher than once a month, then automating the process is worth pursuing. Otherwise, the “classic” concept of campaigns will work fine as the app onboarding workflow is completely distributed. The exception would be if you have a centralized team dedicated to scanning a large number of apps and answering surveys.

Define your onboarding strategy: top down vs. bottom up

One of the key aspects that will make your early days with CAST Highlight even more successful and insightful is how you plan to onboard applications within your organization, and eventually how to turn this into an internal communication plan. Depending on your onboarding strategy, campaigns can be articulated differently:

• Top-Down/Executive Program approach: you are or have in your company a Software Intelligence sponsor who will communicate to app teams on the benefit they will get, with a clear timeline for completing code scans and surveys. In this scenario, one global campaign would be typically defined with all apps with the same closing date.
• Bottom-up/Self-Service mode: app teams share a culture of continuous improvement and proactively submit their software code base to get Software Intelligence analytics. In this scenario, teams manage their own campaign and/or upload code scan results by using the command line or our Docker image.

Regardless of your longer term strategy, we recommend you start with a subset of your portfolio prior to expanding across the board. You can start with a product team, a business unit, a department, etc. by grouping apps by domains in CAST Highlight. A domain is a container of applications and users and can be included with a single click when creating your campaign.

Now that you have defined the information you need, the frequency of analysis and the app onboarding approach, you can create a template for your future campaigns. In CAST Highlight, you can create campaigns and keep them as templates that you can duplicate and use as an ongoing campaign.

Define the user & access typology: who does what

Although it is not directly tied to campaign management and would certainly deserve a dedicated post, one last aspect to consider before kicking off your first campaign: the key participants and their roles in the campaign. It is critical to define the appropriate roles for each user in CAST Highlight (i.e., what they can see and do). Below are the types of user roles you can define:

• You have nothing to hide, results are visible across your user base: Simply assign all users as “Domain Contributors” at the root level of your portfolio. They will be able to see all app results, upload scan results, and answer surveys.
• You have nothing to hide within a defined scope of apps (ideally grouped into a domain): assign users as “Domain Contributors” within the corresponding domain they should be able to access.
• Application results should be restricted to app teams: in this case, assign users the “Application Contributor” role and attach them to the right application(s). This requires a bit more administration work if this is done manually. However, CAST Highlight comes with product addons that leverage the API to automate portfolio object creation and updates (see our Excel Bulk import tool).
• No fly on the wall, contributors can only contribute and will not see any results: this case is very specific and more often used by advisory firms in merger & acquisition contexts. Users will be assigned the “Domain Blind Contributors” role.

Additional advice & common pitfalls to avoid

• Take baby steps with a first group of apps (e.g. a first department made of 50 or 100 apps) with the full content scope (e.g. code scan + CAST surveys and surveys needed to feed your custom indicator). Validate the full cycle to confirm there is effective consumption of Software Intelligence analytics. Then extend to the rest of portfolio.
• CLI can’t contribute to a campaign. CLI is meant for automation (automated scans). So, if you want to use the CLI, then you’ll have to create a survey-only campaign to capture survey answers separately from the scan results.
• Leverage our public API to automate as much as you can. You will have to invest a bit of your time and perhaps refresh your scripting skills. But, it may save you more time down the road!
• For running a new analysis of the same campaign at a different time, use campaign cloning when the scope does not change much. It is less error-prone than manually duplicating it by creating a new campaign.
• For better experience in trends, we recommend to not mix campaign and command line scans for a given application over time.
• Do not invite too many portfolio managers at the same level of your portfolio to avoid multiple campaign launches, overlaps, etc.
• Get key users CAST Highlight certified. This certification program takes just a few hours to complete and will help ramp up users on analytics consumption dramatically.