Security and Enterprise Agility do not usually go hand in hand. Also, the impact of security and compliance on Agility in today’s technological environment, which requires many companies to take such measures to ensure the integrity of their operations and preserve data confidentiality, should not be underestimated.
Definitely, the constraints that certain security and compliance measures impose suggest that Security and Enterprise Agility can hardly go hand in hand.
But, no matter how many developers there are in your organization, it is possible to do software development in Agile mode. Hundreds of writings praise the merits of this development methodology, so here are some of the most important points:
- Better match between deliverables and needs;
- Minimize the risk of slippage by splitting the project into “sprints” and these into “tasks” of short duration;
- Better communication between the various project stakeholders;
- Emphasis is placed on identifying and categorizing the functionalities that will have the most added value for the organization;
- In the “cost, time, functionality” trilogy, the challenge is to develop as many of the most important features as possible in the time allocated, even if it means removing features, unlike the Waterfall mode, which emphasizes features, all features, even if it means exceeding them over time.
The purpose of this post is not to describe the Agile development method or even to try to convince you to use it because most IT projects are now in Agile mode.
The interest of this post is to discuss the relevance of this development method when in your organization or at your customer’s premises, security and compliance take precedence.
Our concern is rather: what happens to Enterprise Agility with the integration of security and compliance measures? Can Security and Enterprise Agility coexist? How are Agile practices and processes affected?
First, let us describe the impacts that these new priorities are having:
- More stakeholders and levels of stakeholders involved
- More rigorous, more demanding tests
- Longer production start-up times
- Higher production start-up costs
- More complex environment
- A tenfold increase in documentation
Let us clarify these new constraints in the context of Security and Enterprise Agility :
1. More stakeholders and levels of stakeholders involved
– In a more controlled environment, the developer may still have the task of writing test scripts, but it is certain that he will not be responsible for the tests. This responsibility will be given to the Quality Control team and the tests will probably be performed in another environment to which developers do not have access
– Similarly, deployments of the test and production versions will have been performed by another team or by other users
– As for the content of the version, the deployment team or even another team will be responsible for ensuring that the version of the deployed application does not contain any subprograms or APIs that are not approved by the organization’s software environment team. The versions of these subprograms and APIs must be validated
– We don’t want infiltration into our environment. One of the above teams is also responsible for ensuring that robot software has scanned the code to ensure that it is of high quality and hermetic against any hacking attempts such as “SQL injection” or “HTML injection
2. More rigorous, more demanding tests
– In an organization where security and compliance are paramount, depending on the criticality level of the application, testing is the nexus of war. Would you be willing to bank with your financial institution’s application if you had only the shadow of a doubt that it is not honest?
– There is a wide gap between a bank transaction application and an application used by only a few users of the organization and whose impact of a temporary shutdown would be relatively minimal. The quality and quantity of tests will be adapted to the criticality level of the application to be put into production.
3. Longer production schedules and 4. Higher production start-up costs
– It is certain that the two previous points have a major impact on production lead times and costs
– In fact, the impact is so great that even with sprint periods of around 3 weeks, production start-ups will often take place every quarter
– Obviously if we consider the number of stakeholders involved, the number of tests and the number of validations required for a production launch, we understand that the number of man-days required will be significant… and the costs too!
5. More complex environment
– The previous points explain how a production deployment can be complex, how many stakeholders can be involved. It must be understood that a good number of tools will also be required to support all these operations. Please note that our objective is not to advertise some of the products mentioned below, the objective is only to name a product that is often a leader in the field.
- First for the tests, several stakeholders and perhaps several teams will be involved. It therefore takes a communication tool between these stakeholders to list the bugs, describe them, track them, assign them a status, etc. In many organizations, Hewlett Packard’s product, ALM (Application Life Cycle Management), is used. Also, a local firm that specializes in software quality has also developed a great tool that integrates all test operations into a single platform: Askida CT.
- Above, we have indicated that a robot must scan the code to ensure, among other things, that there is no code allowing “SQL / HTML injections”. Depending on the size of the organization, this work will be given externally or otherwise, a product such as Fortify will be used.
- We also want to ensure that the application we want to deploy complies with the organization’s standards and rules. The number of these standards and rules can be staggering; again, it takes a tool to help us in this task, a tool like SD Elements.
6. Much more documentation
– Compliance and documentation go hand in hand. We do not want a “people centric” organization where the organization’s business intelligence is in people’s heads. We want a “process centric” organization where the quality of processes allows to grow, to grow quickly and safely.
– A good process is a documented process with up-to-date documentation
In this post, we understand that in a technological context calling for Security and Enterprise Agility co-existence, the impact on IT developments mainly, for an organization where security and compliance prevail, can be significant. Is it always worth using an Agile development methodology when the organization’s processes are not?
In my opinion yes… but by adapting to the constraints of the organization and understanding that there is a trade-off between Security and Enterprise Agility.
The benefits of Enterprise Agility listed at the beginning of this post (and in our 2 previous posts) remain. To adapt to the constraints of a “Safety & Compliance” oriented organization, I propose to adopt the following directives:
- Maintain relatively short sprint lengths
- Add a test environment that could be called “PILOT TEST”.
- Form a pilot group with whom we work more closely and whose objective is to validate that the deliverables of a sprint correspond to business needs and requirements
- Compile a version at the end of each sprint (or almost) in order to be able to make a demo of the sprint to our pilot group and for them to comment on the deliverables
- Be sure to properly manage the different source code branches because when the business goes into production to release a version, it will be necessary to make corrections and modifications to code that is several weeks old and therefore it will not be necessary to include developments that have started since.
And does the Agile Enterprise become inaccessible in such a security and compliance context? Let’s say that the path to Enterprise Agility will be longer… much longer for these companies!