Passa ai contenuti principali

GDPR, procurement and technical debt: how to control software quality of suppliers.

Buying software and services

Software and IT services are often considered a live cost for big companies whose core business is not focused on software production. Controlling the quality of those factors is a complex task. On the one hand you have to necessarily manage procurement and check whether providers can afford the level of quality you need. On the other hand measuring such a quality is hard and may require not clear tools and criteria.

Public Sector, Finance and Fintech, Banking, Insurance companies require tons of software and IT services. CRM, SAP, ERP, DWH are almost everywhere included as assets the most part of companies rely on. Services for systems and architectures, data and databases, integration, software developments and tools are necessary in order to provide high quality services, internal control, easy evolution, etc.

An important lever to minimise the cost of services is control. This means having the ability to measure and monitor the quality of those services and pay back for the right investment.

A business deal between customers and providers should refer to a statement of work where technical deliverables are also included.
Customers are free to challenge providers with convenient quality constraints to ensure the achievement of required results plus the basis for continuous improvement of received services. 

Enabling big companies to objectively measure the quality of big providers help them reducing costs, improving services and focusing on valuable investments. 

This is important whether requirements come from either business drivers or regulatory compliance at some level.

GDPR (General Data Protection Regulation) is a valid example within this scenario since it is enlivening companies of any market and industry by reviewing security constraints and privacy about user's data. Compliance with GDPR will be achieved through different kind of interventions within IT governance. In this case, requirements for GDPR are very restrictive and companies must adhere by 25th, May 2018.
IT services provided by suppliers must be compliant in turn and it is a customer's duty to control that everything admitted within the company respect European regulations on data protection.
Service Level Agreement

Technical Debt and License Risk



A SLA (Service Level Agreement) is the correct formula to put black on white about which quality of services a customer can expect from suppliers.
This formula let you define rules and constraints for delivered services where IT services may include software development. Thus, this is the right moment to establish quality constraints for received services.

Software developed in-house and provided by suppliers are both potential sources for data breaches and must be controlled and monitored. If the formers need for continuous improvement to keep high  quality on internal services, the latters can be improved through objective gauges related to software quality in addition to other usual indicators.

The technical debt can be a measure of the software quality a company should rely on to evaluate suppliers of IT services. Somehow, it is related to the amount of rework is necessary to do things right. The technical debt has not a unique definition but a company can adopt specific recommended gauges to define it. Once that the criteria is well understood and internally accepted, this can be applied to all received software development and integration services.
Here there are some solutions that can be of help:

  • Source Code Analysis: it is the automated testing of an application source code targeted to reveal possible faults, weaknesses and flaws before with the purpose of finding faults and fixing them before this application is delivered.
  • Software Composition Analysis: it is the automated discovery of open source security risk and vulnerabilities of third-parties components. 
Both of them often relies also on vulnerability analysis provided by NIST-NVD.

Tools related to those areas usually provide a technical debt computation that can be easily introduced as a metric for software quality evaluation and it may be used to define SLAs.

License threats are another important factor to take into account when monitoring software developments and integrations by your company's suppliers. In fact, the whole portfolio of adopted software is regulated by licenses. Third-parties software may contain open-source and commercial licenses that your company is not directly aware of. This can be translated in high risk inadvertently introduced within your company.  Most of times, even your suppliers are not aware of all licenses they are including within their software and there is not control of the burden you should care about.
There are professional tools able to detect, categorise and manage licenses in order to reduce risks due to licenses threats, they are usually referred to as License Analysis tools.

External links






Commenti

Post popolari in questo blog

Enterprise DevOps for Database Lifecycle Management

Database and Developments Databases represent the biggest burden for enterprise realities addressing SDLC optimisation. Database Build and Release Automation are often considered as an unsolved issue and they are confined as occasional local experiments, making difficult  a broader adoption of DevOps methodologies . Trying to conceptually shrink a process for SDLC: business requirements are collected, translated into proper technical requirements, arranged by releases and split in tasks. Each release will contain changes for different application components  and database objects . Sample Design / Develop Process Data modeling Data models are key for a software architecture and they go side by side with the data access layer . They affect the way data are organised and retrieved, thus it is necessary a careful analysis and design of data models that are often carried out through specialised tools. Those tools provide database structures for instance and may represen

Vulnerabilities explained: how NIST globally detects and manages flaws

What is a vulnerability? A vulnerability is a weakness of a computer system that allows potential attackers to reduce information assurance. A vulnerability can occur at any "place" of a computer system, for instance it can be a flaw at network level during protocol messages exchange, it can be an application bug unveiling private information, it may reach the sphere of copywriting and much more. Nowadays computer systems drive most of the human activities from agricolture to health through aerospace, automotive, Internet of Things, mainframes, micro-services and any modern keyword buzzing over the Internet. Security is an important aspect of any modern computer system since it represents the endless battle against attackers. There not exists systems 100% safe and secure. The level of security a computer system can afford depends on many factors, to mention a few: Money : the "bigger" is your investment the more your system will be secure. Poor product