non-functional requirements

Every software development team uses tools to actually build and ship software applications. Developers use tools to write the application code. Operators use tools to deploy these applications to the cloud. Business analysts use tools to capture the right requirements to craft meaningful user stories. Everyone within the organization uses tools. And often, these tools are highly specific to a job or role, and many of them have individual preferences.

For this reason, proper tool selection is very important. This is especially true for large enterprises, who often have a long list of requirements for each tool, like integration with identity and access management, traceability and logging of actions for compliance, and more.

So, choosing a tool is obviously not as simple as just using the first tool on the list. In this article, you will find guidelines to select a tool for the enterprise.

Enterprise grade?

A lot of tools claim to be “Enterprise Grade”, but what does it actually mean? When searching the internet, it’s difficult to find a clear and solid answer. The phrase is used within a wide variety of contexts and websites give different views about it. For this article, the context of “enterprise grade” is used as follows.

At the first place, the tool should be able to be used by end-users throughout the organization. A tool which can only be used by a subset of the developer teams and not by all other departments like legal, compliance and operations is not an “enterprise grade” tool. Besides this, other organizational units like subsidiaries and potential (external) partners should be able to use the tool as well.

Furthermore, the tool should be able to implement proper RBAC-based permissions to distinguish different groups of end users (base upon roles and adhering to the least privilege principle). In addition to this, proper Identity Access Management (IAM) integration (e.g. Azure Active Directory, Okta or Google integration) is very important to handle user management. Without this, maintaining the tool becomes an organizational nightmare.

From a compliance perspective, the tool should be able to log and audit all of the actions of which the end-users perform. It is important to trace actions when the tool is being used by a large group of (different) users to keep track of who can access which feature of the tool and who is responsible for which part of the tool. For example: it is important to trace who can upgrade the tool to a newer version.

An enterprise view

Selecting an “enterprise grade” tool should be taken very seriously. It should be very clear why a new tool is needed and which benefits it should bring to the organization. Requirements are very important and those should come from different departments, not just the department that actually implements the tool. Most of the time, this is the technical department. Business departments have different requirements than the technical departments, so it’s important to incorporate them.

To make things more practical for the rest of the article let’s consider selecting a CI/CD tool which developers need to push their application (components) from source code to production. Within the perspective of Agile and DevOps this is a very important tool which impacts the work of almost everyone in the organization. It’s not just the developers, although they are the most important consumers.

If you decide that only the developers of the DevOps teams will use the tool, you are forgetting about other aspects. Think of these:

  • Who will maintain the tool and keep it running? Probably not the developers.
  • What about the reports and statistics which the management requires?
  • How about the (desired) performance now and in the future, can this tool handle the perceived workloads?
  • How well does the tool integrate with other tools being used already in the organization?
  • What will be the licensing model? Think of pay per user, per Virtual Machine or per line of code. The license model should fit into the organization and ideally, it should be predictable for the (near) future.
  • How is support being arranged?
  • How to deal with a growing number of teams (high availability, fall-over, scaling up and down, etc)

Stakeholder management

The requirements mentioned above cover various aspect and are derived from an enterprise point of view. Stakeholder management is crucial here. In terms of this think of the following important aspects:

  • Make a “communication plan” and define which levels of communication are important to which stakeholder (e.g. inform, request information, actively engage).
  • Consult stakeholders early on in the process and often keep coming back to them when executing the goals you have agreed upon with them. Especially inform them when things change unexpectedly.
  • Use their feedback to include it in your project planning and/or implementation plans.
  • Pay special attention to your negative stakeholders. They might disrupt your project, find a way to get them and keep them onboard. The best is to convert them to positive stakeholders which will support you or even become an ambassador for your project.

Some companies use the RACI chart to define and communicate responsibilities of users and/or stakeholders.

Business goals and features

When selecting a tool it’s very important to have your business goals clear. The features of the tool should be able to support the business goals otherwise the link between the business goals and the expected benefits of the tool do not match.

Switch back to the CI/CD tool we use throughout the article. Imagine your business goal is to speed up the delivery of applications to fetch early feedback from customers which use the applications which are processed by the CI/CD tool. Consider the following:

  • If the tool requires several years to implement, you might not meet that goal in the expected time.
  • If developers need extra (external) training to be able to use the tool, you need to take into account the extra costs and the time it will take. Developers who are participating in the training cannot spend their time developing applications. If this is a real concern, maybe it’s better to select a tool which can be learned “on the job”.
  • If the tool is difficult to use, people might use workarounds to achieve their goals. For example: when it is impossible for the CI/CD tool to integrate with the preferred source code management tool, developers might choose another source code management tool. One of the most valuable asset of the company (the source code itself) is scattered and it’s more difficult to keep track of it.

When thinking from the business view, you put the end users (e.g. customers) of your applications up front. You do not only take the perspective of the tech guys which might be too much “working from the inside out”. Think from “outside in” to address the business goals.

Integration

Tools running in enterprise grade environments require integration with a lot of other systems. Think of systems like IAM which stores users and groups which needs to have (proper) access rights (privileges) to tools. Popular implementations are SAML and OAUTH. Or what about the connection to centralized systems for logging and monitoring?

Tips and tricks to select a tool for the enterprise
Source: https://pixabay.com/

The connections to the external systems should be “loosely coupled”. Integration should be done based upon (open) standards like REST APIS or XML based web-services. By using open standards like these it’s easier to integrate the new tool using popular programming languages. There is no big dependence on the vendor of the tool and there is (probably) a lot of documentation on the internet to help the guys actually executing the implementations.

Besides, it is important to integrate on the right level. When the centralized CI server is only capable of integrating with other systems based upon administrator permissions in the tool it needs to connect to, you are creating a severe security risk. Jump on to read more about security in the next paragraph.

Security

Security always plays a major role when selecting a tool. In an enterprise environment, security is even more critical. In general when selecting an enterprise grade tool, think of the following security related requirements:

  • The least privilege principle considering the various roles of the end-users
  • Safe storage of secrets like passwords, tokens, certificates etc.
  • Disk encryption to prevent anyone not having the decryption keys of being able to read the files on the system. In the public cloud, this is even more important.
  • (CIS) Hardening of the underlying infrastructure. Sometimes the tool does not work properly anymore when the CIS hardening is applied. This is because, in most cases, CIS hardening restrict and prevents actions on the underlying infrastructure or other systems. Therefore it’s important to take this requirement into account from the very beginning. Often a vendor need to know the details of the hardening (scripts) to make sure the tool still works when CIS hardening is in place. This is especially important when the vendor helps with the implementation.
  • Support centralized logging and monitoring as well as audit trails of the usage of the tools.
  • Integration with a key management tool like Hashicorp Vault or Cyberarc.

This list can never be fully complete and it differs from company to company, but it acts as a starting point for your other security requirements.

Other non-functionals

A recurring theme in this post is non-functional requirements, and describe how a system should behave. Examples mentioned above are security and integration, but there are many others, like performance, availability (resilience) and manageability (automatability).

Proper selection is mindful of these NFRs, as they determine how the application fits into the landscape, how it’s managed, how it’s delivered, installed and configured, and more.

non-functional requirements

In other words: those stakeholders from before are very likely to not care about the functional requirements of the tool you are selecting, but very likely do care about the non-functional requirements their department is responsible for: purchasing looks at licensing, the security teams looks at security, the Ops team looks at SaaS vs. install,  automatability and support, and managers look at reusability of the tool across more than just your team.

 

Conclusion

Summarizing this article, we can conclude there are a lot of items involved when it comes to proper tool selection. Most importantly: inform and collaborate with the right stakeholders and define your requirements, both functional as well as non-functional. Remember: this is just a start, I hope this inspired you for the next tool you need in your organization.