Why Partnering and Sourcing Need to Managed in Digital Enterprises

The simplest form of sourcing in a digital enterprise is to use open source code. These days, modern IT shops use a high percentage of open source code because it raises productivity significantly. This is important because HTML5, CSS, Java, javascript, Ruby etc. are all fairly low level languages. Used in their naked form, they are like hand tools and limit productivity. Once combined with 3rd party Open source code, a development shop's productivity rises significantly and developers can focus on delivering new business value rather than "reinventing the wheel" and developing capability which already exists.

There is a downside, however, as use of third party open source code can incur other issues. Traditionally, most businesses focused on IPR ownership and the fear that someone else might end up owning the applications that they were investing in. These days the focus has shifted to 3 key issues:

• Technical Debt,
• Security Vulnerabilities,
• Software Entropy.

Technical Debt describes the issues that are typically buried in code and which make it buggy and difficult to support. These may arise from use of legacy code conforming to old standards (or languages), poor programming style and structure, lack of documentation, lack of flexibility to change and programming errors or bugs. To some extent this can be seen as Agile Development's dirty little secret. A philosophy which prioritises working code over documentation as well as speed to market, can lead to poor practice and the inevitable problem of technical debt. Inevitably, quite a bit of the Open Source Software which is available does suffer from Technical Debt. So it is important to manage the way in which Open source Software is acquired to ensure that it is sourced from reputable organisations, some due diligence is used to validate its quality before adoption (as often there are multiple sources of equivalent software) and to ensure that the latest version is being adopted.

Security Vulnerabilities are almost inevitable in software development. There are so many ways that software can be attacked, it is often difficult for developers to conceive or cover all of them when developing applications. Open source is no exception. So again it is important to validate that adopted software is secure and that appropriate versions are deployed, as often it is possible to acquire multiple versions of the same opensource product or component, and one version may fix vulnerabilities recently discovered in an older version. Recently Equifax tripped over this problem dramatically and incurred severe business disruption by using older insecure versions of Open Source code, when fixes were available.

Software Entropy describes the state where multiple versions of the same software product or even multiple products from different open source developers are used in the same application to perform the same task. This causes problems because it not only introduced unnecessary complexity, but it will probably introduce uncertainty into how the code works in different parts of the application. Additionally, if the different versions and products require different component libraries, there will often be an impact on application performance and environmental stability. It seems obvious not to do this, but if all the developers in a project team are free to download and use what they want, it is almost bound to happen.

So a well managed development shop needs someone to be responsible for sourcing Open Software components, validating their quality and security, and tracking where and how they are used within the application (and across the business's) estate of applications. This allows for effective remediation and change when new versions are released and keeps the code as simple, supportable and secure as is practicable. There also should be benefits too, if the relationship with open source software providers is managed to understand what other innovations they support, either directly with other products and new releases, or indirectly through partners and industry alliances who develop complementary capability.

This takes us to wider partnerships. If you are trying to disrupt the market, it is often necessary to partner with other organisations. This may be to gain access to information you don't have or it may be because they do something which you don't but which your customer values. Partnering allows you to bring new value to the table for your customers, but many organisations fail to do this, because they aren't mature in developing partnership approaches. I remember being really astounded when I was told by an offshore services provider that it normally takes 10 years to develop a partnership with its strategic customers. Why would any customer wait that long?

There are some simple pointers to partnership: 

The first is to understand what problem you are trying to solve for your customers. Then it is relatively easy to identify who would make the right sort of partners to develop;

The second is to culturally align a joint team with your chosen partners, if they are interested in addressing the same things as you together. Cultural alignment involves many things but should include mutual goals, a shared policy of openness (within the scope of your alliance), principles by which you will make joint decisions and common values for the team.

The third is to use design thinking within the joint team to gain insight into the customer problem, recognising that multiple viewpoints, a focus on customer value and experience, and the patience to experiment will lead to more successful products and better leverage of your combined capabilities.

Finally, all participant organisations should recognise the need to commit to managing their partnership like a join venture business. This means agreeing strategy, committing resources, reviewing progress and applying just enough governance to manage the partnership for value. 

Sourcing and partnership management are often overlooked, but comprise a significant discipline which contributes to execution. As one CEO once remarked "ideas are ten a penny, but execution makes innovation succeed".