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.
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.
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.
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:
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.
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
- Source Code Analysis
- Software Composition Analysis
- Technical Debt
Commenti
Posta un commento