Recommendations on building the SSoT (alongside with DevOps and Agile approaches) for businesses like Financial Services (FS):
https://www.finextra.com/blogposting/15068/how-and-why-software-development-must-be-included-in-fs-compliance-risk-and-security-processes
https://www.finextra.com/blogposting/15068/how-and-why-software-development-must-be-included-in-fs-compliance-risk-and-security-processes
Quoting:
"The problem is that traditionally, the way software development teams have worked has typically been siloed from the rest of the business. So, the transparency that banks and other financial institutions need is not inherent in software development.
"The problem is that traditionally, the way software development teams have worked has typically been siloed from the rest of the business. So, the transparency that banks and other financial institutions need is not inherent in software development.
Plus, visibility and traceability of digital assets is being made more difficult because of the escalating complexity of applications and systems, multiple operating platforms and end points, plus a wider variety of file types - often larger whether individually or in total volume – and incorporation of emerging technologies.
This makes it difficult to comply with regulatory demands, because the audit trail – for example, when a piece of code was created or changed, by whom, when, where and how – is difficult to unearth, if challenged. This is exacerbated by the fact that many financial products have to be maintained for years, if not decades, because of legacy customers. Plus, should a problem become apparent later, a bank might have to devote extensive time and resource to find the source. Finally, there is the risk that vulnerabilities can creep into the software development process, leading to breaches that are not detected until it is too late.
Clearly, the scale of the potential risk and associated costs is too high to ignore and we are seeing more and more FS firms face this challenge head-on, adopting what has been coined ‘a single source of truth’. Breaking down those traditional software development siloes, the idea of a ‘single source of truth’ is one place for all the digital assets involved in a project or product’s development and on-going lifecycle, from idea, design and development, through to test, deployment, release and maintenance. The ‘single source of truth’ must be extremely collaborative and transparent, with item-level tracking and visibility of what changed, by who, why and when, across every single digital asset and contributor, technology, internally and externally. "
Recommendations on how FS (and other institutions) could build the SSoT in the link provided above.
Recommendations on how FS (and other institutions) could build the SSoT in the link provided above.
