Documentation Nexus IQ Server 1.17

So, let’s build on the third item we mentioned in the introduction, and first think about the intent of the policy we are going to create. Here are some questions to consider:

These questions are really just the start, but in short you should ask what applications, what causes a violation, and what action should be taken. For our example policy, we want to focus on architecture aspects, with key areas being Age and Popularity of our components.

Since architecture is our focus we are going to use it as part of the name for our policy. In addition we are going to add Age and Popularity to the name to be more specific. This will help us later when we start creating additional architecture related policies. Lets go ahead and create this policy:

Threat level is one of the easiest concepts we’ll cover in this chapter, yet it has the greatest chance to cause huge problems. At it’s core, this is simply a value for severity your business associates with a given policy. These values range from 1 to 10, each corresponding to range of severity, and a specific color:

To assign threat level to a policy, you will need to be in the policy edit mode (click on the editing icon). Next, use the drop down, which is located next to policy screen. This is displayed in Figure 7.6, “Editing the Policy Threat Level”.

When a threat level is selected by any component that has violated a policy will be displayed in the order of the severity of the violation. This is straight forward, but let’s take a look at the details and see where some issues can arise.

Just like taste is subjective, you have to realize that severity is subjective. What may be a level 10 for one part of the business may be quite different for another.

A bigger concern is what message you want to communicate to the recipients of the analysis. For example members of your team will naturally be inclined, to treat high severity as very important, and critical. If they see too many of these, the prospect of ever making any headway could be impacted in a negative way and you might dismay e.g. your developers to even get started on trying to fix the violations since there are just too many. As with any control mechanism it is probably advisable to be a bit lenient at first and start to get stricter at a later stage, when the worst problems are dealt with. Otherwise you could cause undue stress to development and management teams. The important thing is to keep in mind is how you will assign severity, and the impact it has on those reviewing violations.

Especially in the beginning, our recommendation is to reduce, if not exclude the high severity threat levels altogether. Remember, at the core, this number is purely for ordering how a violation will be displayed to a user reviewing the results of an evaluation (e.g. in the Application Composition Report). Because this needs to be interpreted, the actual value is very subjective. It’s easy to overwhelm members of your team by seeing large numbers of highly severe violations. It might even be reasonable to set severity to the lowest setting for a violation (Low - 1) in the beginning. This way, members of your teams can get used to seeing the results that are produced.

In our example policy, architecture quality is pretty important, but it’s not the most important issue, so we’ll leave the default threat level of 5. This will give us a violation higher up in the display, but it’s certainly not the worst.

In many cases, policies will be evaluated against all applications. However, as your applications become more diverse and there are various groups of applications with similar characteristics, you may find the need to develop policies for these specific cases. This will go hand-in-hand with the creation of tags, which application owners will apply to their applications.

Given the ability to create tags, there is an endless amount of refinement that can be done in order to focus a particular policy on a set of applications with similar characteristics. While we won’t get into the creation of tags here, thinking about this as a way to create more finely tuned policy is a good first step. For now, we’ll assume we have some pretty generalized architecture requirements for all applications, and want to make a policy that will match all applications in this organization.

By now, we should know that an easy way to look at conditions is to consider them the if part of an if/then statement. In contrast, a constraint is not part of the statement, but rather a container for conditions. This can come in real handy when you want to consolidate a policy, by grouping similar conditions.

But why do this?

Well, for one thing, it reduces time. Next, because constraints are displayed on the Application Composition Report, along with violations, it becomes easier for a member of your team to process information that is similar. Of course, it also has the added benefit of not having to create hundreds of small, one-off policies.

For example, in our Architecture Age and Quality policy, we may start with two conditions, one for age and one for popularity. This will work, but it’s likely better, especially if we want to expand that later on, we isolate these as separate constraints.

As a good practice, grouping similar conditions is the best way to build your constraints. Again, this will help de-clutter a multi-policy environment, as well as help someone reading any associated violations on the application composition report. For our example, we’ll be placing both conditions in the same constraint.

Now, before we move on, let’s take a look at some of the specific aspects of conditions that can tend to be a bit confusing.

Policy Type. A simple algorithm is used to automatically determine the type of policy you created. It is based on the types of conditions you include and is mainly used for reporting purposes. The rules to determine the type of a policy are:

Any vs. All. If a component meets any constraint, the policy is considered violated. However, inside each constraint, when you have more than one condition, you have the ability to require that a component must either meet all conditions or just any of the conditions to trigger a violation.

This is a straightforward concept, but it can produce vastly different results. For example, selecting Any as an option will tend to produce a lot more violations, it’s the equivalent of placing an or between each condition. In addition even if you resolve one violation for a component, if the component meets other conditions later on, it might cause it to still violate the policy. On the other hand, using All' allows you to establish that all conditions must be met. It’s like placing an and between each condition. In this case, if you address any of the conditions, the violation will be resolved.

Let’s look at an example that would further explain this, and then we will move on to creating conditions in our policy. Below, we have a couple of policies and a component. If we wanted to exclude components that were younger then four years and had less than fifty percent popularity, which would we want to use? Also, would the component listed violate this policy?

It may seem like these two policies are exactly the same, but there is a key difference, Any vs. All. So, our first policy states that if Any of the conditions are met that a violation will occur. Given that, our component violates this policy. This is good, but we only want a component to violate a policy when Age is less than three years, and popularity is below 50%. We understand that there may be circumstances where a component might need to fall outside one of those boundaries, but if it’s both, we know we have a problem. Our component is pretty popular, so it might be a case where this component, even though it is newer than we prefer, actually resolves an issue another component might have. For this reason, the best policy for us to choose is Policy 2, and our component would not actually cause a violation.

Now that you know about all the available conditions and how they can be combined to match all or any condition to create a constraint we are ready to determine what should happen if a constraint is met - the policy actions.

Policy actions and notifications allow you to perform a specific function when violations occur. In some cases this can include forcing a particular action in one of tools that interact with the Nexus IQ Server (e.g. Nexus Pro+.

Alternatively, notifications can be set so that when violations occur, any combination of particular email addresses, or the email addresses associated with the members of a particular role, will be notified.

Actions. Actions are organized by enforcement point, and enforcement points simply represent a stage in the development lifecycle of an application (i.e. Development, Build, Stage Release, Release and Operate).

For each stage there are two degrees of action you can assign to each enforcement point:

To add actions:

Notifications. When a new violation occurs, a notification will be sent. This includes any email addresses entered manually, as well as email addresses for the users that have been added to any roles selected.

To add notifications:

Stage. Both actions and notifications are set by stage. Each stage represents a point in the development lifecycle. If you have connected the Nexus IQ Server with an external tool (e.g. Nexus Pro+) the action and notification can be applied and could have direct effect on the tool. For example, a release can be prevented in Nexus Pro+). To better understand how actions and notifications can be used, a suggested action has been provided for each stage.

In the case of organization level policy (rules), which appears across many different applications, the application level policy is meant for precise scenarios where the policy is only intended for a single application.

Doing this takes into account something specific we want to identify or keep out of a single application, but not others. The more of these application level policies that are created though, means the more micromanagement, and in turn, opportunity for error, will occur. So, keeping them at a minimum, and only for those unique scenarios is ideal.

This is likely better conveyed in an example. Imagine two applications with 4 policies each. Two policies for these applications are identical. If you have this setup with two separate applications, any change to the identical policies has to be done once for each application. However if we move these policies to the organization that both applications belong to, we only have to change one. Now imagine a similar scenario with a larger number of shared policies as well as applications. Without organizations to inherit from this would become unmanageable quickly.