Better Control and Protection of Software-Based Intellectual Property in the Financial Services Market  -Why IT Matters and How to Achieve IT

By Konrad Litwin, Managing Director International, Perforce Software

With digital data and other content at the heart of how most financial services operate today, these ‘soft’ assets have become an increasingly important and critical part a firm’s intellectual property (IP) assets.  At the same time, visibility and control of those digital assets has become more difficult, thanks to a progressively more complex operating environment.

Today’s financial products not only have more elements, they need to be updated more frequently, yet banks and other financial institutions need to keep legacy products ‘live’ for long periods of time to satisfy not just existing customers, but regulatory authorities too.  The ability to have access to all past versions of code and other digital assets is essential for auditing purposes.

Financial products also have to be made available across multiple delivery methods, including mobile devices and different software operating systems, plus the need to satisfy the increasing cry for smoother, real-time exchange of data between different banks and bourses.

The situation is further exacerbated by the frequently siloed environments in which these largely software-based financial products are created, distributed and maintained.  This is particularly true of software development teams, who – in common with many other industries – traditionally work in isolation, with their own processes and tools, giving the rest of the business little visibility of work-in-progress.

All this matters for one very big reason close to the heart of the world’s financial services industry: risk.  If how these digital assets are being developed and brought to market is not transparent, then who’s to know what problems might have crept in?  With regulators demanding to see the inner workings of every aspect of a bank’s activities, right down to every single piece of code, then that is a pretty big risk to take in terms of security and compliance.

Trace metrics for quality and audibility

So what’s the answer?  First, financial institutions need processes and technology tools that can easily and quickly show what changed, why it changed and who made that change.  That has to be applied across the entire lifecycle of the digital assets associated with a particular financial product and provide that immutable history in both real-time and historic views.

If the full history of software development processes is not easily accessible, then days, if not weeks or months, might be spent by teams trying to unearth and create that information (time that would be better spent on other tasks).  And finally, there is not visibility around who can access what (and whether they did or not), then there is always the spectre of a security breach, caused by a valuable piece of digital IP being inadvertently or deliberately compromised.

Transparent traceability makes it easier to see how two different digital ‘artefacts’ relate to each other or are inter-dependent.  Also, essential software processes such as QA, testing and real-time code reviews are better supported, while it also becomes easier to automate processes and engender improved collaboration between different contributors.

A single source of truth

Mitigation of these risks is why an increasing number of organisations in the financial services market are investing in ‘single source of truth’ strategies and systems. There are different ways of tackling this goal, but a common thread is the desire to create a collaborative and transparent environment that is a single place for all the digital assets associated with a product at every stage of its lifecycle.

Another attribute to which pioneers of this approach aspire is an environment that allows individual teams to carry on working with their existing tools, systems, workflows and processes, yet still have that ‘common ground’ in which to see what each other is doing (who did what, when and how) share and collaborate.

The concept of the ‘single source of truth’ is already well established in software development circles, where version control systems have long been championed by software developers and IT admins for this very purpose.  However, organisations are increasingly realising that they need to extend the ‘single source of truth’ to encompass every aspect of a project, from ideation, design, development, test, deployment, release and maintenance.

In the software world, it may be coined application lifecycle management (ALM) but that is probably too limiting a terminology in this day and age, because the breadth and variety of assets is so wide-ranging.

When successful, this approach can reap some powerful and tangible benefits: better connection across teams to keep a project’s vision on track and out to market more quickly, easier extraction of data to satisfy auditors, easier bug-tracking and fixing, plus reduced security risks.  However, success depends on augmenting the theory with some very practical ‘best practice’ steps.  Here are a few examples.

Version everything – store every digital asset at every step, so that every change is recorded.  Think beyond code and incorporate every asset associated with a project.  Make sure that the version control system supporting this approach can support a wide variety of file types and also creates an immutable source (in other words, changes cannot be made at a later date) to meet regulatory requirements.

Balance control over flexibility – the best tools are those that allow users to carry on working with their own workflows, processes and favourite tools, rather than imposing new ways of working or technologies.  It’s human nature that people will always find a workaround if they don’t like a piece of software.  For instance, Git is in widespread use by software development teams worldwide, so look for tools that will allow them to carry on using Git, but in a framework that gives management the visibility needed over code changes.

Similarly, make sure that the ‘single source of truth’ ‘plays nice’ with other systems already in place and can scale to support large projects or growing numbers of users, regardless of their location or operating environment.

Keep it simple – don’t inhibit the non-technical users who need access to this single source of truth.  Make sure that the version control system is intuitive enough for them to use.  These individuals might include product or marketing managers, creative teams, even senior management and external third parties, such as auditors and regulators.

Control access – security involves a multi-layered strategy of attack, but within the context of the ‘single source of truth’, do think about what access people are given.  In so many instances, access is carte blanche, with users having unnecessary levels of access.  This is not fair on them or the organisation.  Instead, implement ‘fine grained’ access control, whereby users are given access to what they need, but no more.

Protect digitally-based intellectual property (IP) across IP address, user and group, with enforceability at code repository, branch, directory or individual file level, locally or across authorised locations.   This will also contribute to compliance and regulatory processes.

Educate – this may sound obvious, but users do need to understand why this level of visibility and control is so important and top-level management endorsement is important.  In addition, any financial services organisation implementing Agile, Continuous Delivery or DevOps in their software or digital projects will appreciate the benefits that the ‘single source of truth’ brings, in terms of underpinning the transparency and collaboration on which these methodologies depend.

There is no overnight silver bullet to achieving all this and the reality is that most organizations are going to have to put in a lot of work into making the ‘single source of truth’ a success. However, choosing the right support tools and approaches will go a long way towards achieving that goal and in today’s increasingly competitive, time-pressured and regulated financial services market, with such a high dependency on digital assets, this level of traceability and management over the entire product lifecycle is fundamental.

By Konrad Litwin, Managing Director International, Perforce Software

With digital data and other content at the heart of how most financial services operate today, these ‘soft’ assets have become an increasingly important and critical part a firm’s intellectual property (IP) assets.  At the same time, visibility and control of those digital assets has become more difficult, thanks to a progressively more complex operating environment.

Today’s financial products not only have more elements, they need to be updated more frequently, yet banks and other financial institutions need to keep legacy products ‘live’ for long periods of time to satisfy not just existing customers, but regulatory authorities too.  The ability to have access to all past versions of code and other digital assets is essential for auditing purposes.

Financial products also have to be made available across multiple delivery methods, including mobile devices and different software operating systems, plus the need to satisfy the increasing cry for smoother, real-time exchange of data between different banks and bourses.

The situation is further exacerbated by the frequently siloed environments in which these largely software-based financial products are created, distributed and maintained.  This is particularly true of software development teams, who – in common with many other industries – traditionally work in isolation, with their own processes and tools, giving the rest of the business little visibility of work-in-progress.

All this matters for one very big reason close to the heart of the world’s financial services industry: risk.  If how these digital assets are being developed and brought to market is not transparent, then who’s to know what problems might have crept in?  With regulators demanding to see the inner workings of every aspect of a bank’s activities, right down to every single piece of code, then that is a pretty big risk to take in terms of security and compliance.

Trace metrics for quality and audibility

So what’s the answer?  First, financial institutions need processes and technology tools that can easily and quickly show what changed, why it changed and who made that change.  That has to be applied across the entire lifecycle of the digital assets associated with a particular financial product and provide that immutable history in both real-time and historic views.

If the full history of software development processes is not easily accessible, then days, if not weeks or months, might be spent by teams trying to unearth and create that information (time that would be better spent on other tasks).  And finally, there is not visibility around who can access what (and whether they did or not), then there is always the spectre of a security breach, caused by a valuable piece of digital IP being inadvertently or deliberately compromised.

Transparent traceability makes it easier to see how two different digital ‘artefacts’ relate to each other or are inter-dependent.  Also, essential software processes such as QA, testing and real-time code reviews are better supported, while it also becomes easier to automate processes and engender improved collaboration between different contributors.

A single source of truth

Mitigation of these risks is why an increasing number of organisations in the financial services market are investing in ‘single source of truth’ strategies and systems. There are different ways of tackling this goal, but a common thread is the desire to create a collaborative and transparent environment that is a single place for all the digital assets associated with a product at every stage of its lifecycle.

Another attribute to which pioneers of this approach aspire is an environment that allows individual teams to carry on working with their existing tools, systems, workflows and processes, yet still have that ‘common ground’ in which to see what each other is doing (who did what, when and how) share and collaborate.

The concept of the ‘single source of truth’ is already well established in software development circles, where version control systems have long been championed by software developers and IT admins for this very purpose.  However, organisations are increasingly realising that they need to extend the ‘single source of truth’ to encompass every aspect of a project, from ideation, design, development, test, deployment, release and maintenance.

In the software world, it may be coined application lifecycle management (ALM) but that is probably too limiting a terminology in this day and age, because the breadth and variety of assets is so wide-ranging.

When successful, this approach can reap some powerful and tangible benefits: better connection across teams to keep a project’s vision on track and out to market more quickly, easier extraction of data to satisfy auditors, easier bug-tracking and fixing, plus reduced security risks.  However, success depends on augmenting the theory with some very practical ‘best practice’ steps.  Here are a few examples.

Version everything – store every digital asset at every step, so that every change is recorded.  Think beyond code and incorporate every asset associated with a project.  Make sure that the version control system supporting this approach can support a wide variety of file types and also creates an immutable source (in other words, changes cannot be made at a later date) to meet regulatory requirements.

Balance control over flexibility – the best tools are those that allow users to carry on working with their own workflows, processes and favourite tools, rather than imposing new ways of working or technologies.  It’s human nature that people will always find a workaround if they don’t like a piece of software.  For instance, Git is in widespread use by software development teams worldwide, so look for tools that will allow them to carry on using Git, but in a framework that gives management the visibility needed over code changes.

Similarly, make sure that the ‘single source of truth’ ‘plays nice’ with other systems already in place and can scale to support large projects or growing numbers of users, regardless of their location or operating environment.

Keep it simple – don’t inhibit the non-technical users who need access to this single source of truth.  Make sure that the version control system is intuitive enough for them to use.  These individuals might include product or marketing managers, creative teams, even senior management and external third parties, such as auditors and regulators.

Control access – security involves a multi-layered strategy of attack, but within the context of the ‘single source of truth’, do think about what access people are given.  In so many instances, access is carte blanche, with users having unnecessary levels of access.  This is not fair on them or the organisation.  Instead, implement ‘fine grained’ access control, whereby users are given access to what they need, but no more.

Protect digitally-based intellectual property (IP) across IP address, user and group, with enforceability at code repository, branch, directory or individual file level, locally or across authorised locations.   This will also contribute to compliance and regulatory processes.

Educate – this may sound obvious, but users do need to understand why this level of visibility and control is so important and top-level management endorsement is important.  In addition, any financial services organisation implementing Agile, Continuous Delivery or DevOps in their software or digital projects will appreciate the benefits that the ‘single source of truth’ brings, in terms of underpinning the transparency and collaboration on which these methodologies depend.

There is no overnight silver bullet to achieving all this and the reality is that most organizations are going to have to put in a lot of work into making the ‘single source of truth’ a success. However, choosing the right support tools and approaches will go a long way towards achieving that goal and in today’s increasingly competitive, time-pressured and regulated financial services market, with such a high dependency on digital assets, this level of traceability and management over the entire product lifecycle is fundamental.