The Renaissance of the City State - Digitally of Course

This week is London Tech Week, a series of co-ordinated and themed events aimed at promoting London's place in the Digital World. So the week was kicked off with a talk by Sadiq Khan (Mayor of London) at the Francis Crick Institute (Crick was one of the pioneers in DNA research) where he spoke about London's "leading position in AI"; apparently London has 745 AI focused companies, which is more than twice the number in Paris and Berlin combined. He also spoke about his ambitions for London to become the world's leading smart city, which will obviously be a challenge given the competition from Bangalore, Singapore, China in general and quite a few American cities even before some unexpected contenders such as Moscow are taken into account.

Yesterday TechXLR8 kicked off as one of the major combined exhibition and conference events, combining a huge number of themes: IoT, VR/AR, Cloud, DevOps, a platform for small start ups (known as project Kairos) as well as pretty much smart everything or SmartX. TechXLT8's theme this year is "changemakers" across technology, business and society and the opening talks were quite focused on the national and smart city impacts coming.

So Greg Williams (Editor-in-Chief of Wired) mentioned that 13 of Europe's 47 or so Unicorns (digital companies worth more than $1Bn) are based in Britain. Gavin Patterson (the outgoing CEO of BT) emphasised how BT is preparing to invest in the next new wave of connectivity infrastructure such as FTTP, 5G and quantum key networks with pilots for 5G and quantum key networks having just been announced. This investment is aimed at keeping Britain as the "leading digitally enabled nation" in the world.

Juliet Bauer, Chief Digital Officer for NHS England, discussed the recently published Digital Roadmap for the NHS and how this should drive a revolution in the way in which citizens access and receive treatment from the NHS as well as a shift towards greater prevention of health problems before they become serious.

Paul Copping, Chief Innovation Officer for Greenwich, discussed some of the challenges for cities moving to a Smart City model and the architectural issues around defining what a "City Digital Platform" really looks like and some of the questions around the blurring of lines between local city  authority provided services and private digital service providers, especially with respect to access methods. He also discussed issues of future integration and interoperability between adjacent metropolitan areas and how to marry architecture with public procurement processes. Though what he did not mention was the need to deliver iteratively in small chunks and experiment to continuously fine tune solutions before investing too much or how to abstract changing technical standards within service wrappers to deal with obsolescence across the long time frames needed to implement anything at this scale.

Colin Rhys, VP Virgin Hyperloop for Middle East & Asia, spoke about how Hyperloop could make commuting distances such as London to Edinburgh on a daily basis quite feasible, extending the footprint of cities outwards. His tag line "live in the forest, work in the city" offers the prospect that digital enablement plus fast transport means that the "virtual city" of the future will spread far beyond the natural physical boundaries of a cities geography and extend almost like a virtual state into the rest of the country or continent in which it is located. This has implications far beyond the traditional turf wars between metropolitan and rural councils over "who owns whom" for the purpose of local taxation and implies that all these councils need to collaborate more effectively for collective good. This means that we need to rethink socially our ideas about cities and rural communities and address a whole host of issues around community identity, legal frameworks, representation, pooing of investment and resources, as well as how to deliver the grand scheme that a Smart City is base upon.

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".