Digitalisation – Building the needed capabilities

Some 20 years ago was I called to help two researchers, a physicist and a medical doctor with a poorly written C++ computer program at their hands. As the three of us sat and peered on the code the medic said: «You know, what happens now is rare phenomena here in Norway. Here we are, three professions working on a common problem as a team of equals».

That day I learnt a few things about tumours and magnetic tomography, they a few things on how to write faster and better C++ programs, but all of us learnt that solving a difficult problem benefits from a multi disciplined team.

Yesterday I wrote that digitalisation requires organisations to adopt Internet thinking and begin developing their digital capabilities and asset. The first capability they need to leverage is multi disciplined teams. In a true multi disciplined team all participants acknowledge the other disciplines and respect their uniqueness. It´s not about a customer / vendor or master / servant relationships,  its about peers working to solve a common problem.

Creating multi disciplined teams is hard, because most businesses are built around what is perceived as the most valuable discipline. Within healthcare and hospitals the medical doctor is at the top of the food chain. In oil companies geologists and geophysicists are the ones that rules the exploration department. Drillers and drilling engineers the drilling department and so on. In these type of cultures the final decision power is allocated to the what is perceived as the «leading» discipline. To succeed with digitalisation this kind of culture must come to and end.

Why must it come to and end, you now might ask? The answer to that is that digitalisation implies that the function or role of disciplines are changed. Digitalisation forces disciplines to create tools or services that make their skills and insights available in new ways. The geophysicist is not interpreting seismic images any more, their skills are needed to create software that interpret images. The same happens with any other discipline, it be medical doctor or a civil engineer.

With the multi disciplined team in place, whats next? Sustainable funding, as teams and digital assets eat money for breakfast. Compared with physical assets, that have a lifespan measured in years, a digital asset (in terms of software) need continuous investments to stay healthy and competitive. You are very much in a climate where «Who dares win» to quote David Sterling, the founder of the British SAS forces.

The practical consequence of this is less upfront work on formal business cases, but an adaptive learning approach where we want to fail early to make sure that good ideas are separated from the bad ones before the cost of failure skyrockets.

The third ingredient needed is adequate digital (software engineering) competence. You need software developers and software engineers. Here most companies faces another challenge, the good ones are rare. The one you need are the ones who can envision new capabilities and put in place the process, tools and team to make it fly.

Finally, what does Internet thinking mean? It boils down to a culture of sharing. Open source software. Create a community to solve the problem. This is how you scale the multi disciplinary team globally. The Internet is built on the simple belief that sharing is the fastest and most efficient way to create business. In this respect open source software does not mean free software, it mean that monetisation is done by other means than sale of licenses.

So summarised digitalisation depends on three things, multi disciplined teams, adequate funding, software engineering skills all wrapped into a sharing culture in line with the spirit of the Internet.

Good luck with your digitalisation journey.

Digitalisation – The value of digital capabilities and assets

During the last year have I been involved in many discussions on digitalisation, particularly on its possible effects on the oil and gas industry. There is no doubt that digitalisation will impact all industry, the hard part is guess how.

Most of the discussions have been on how digital technology will impact industrial value chains and the production and consumption of goods, including oil & gas. Basically, how to do the things we already to more effectively. What has been less visible is how digital capabilities can be used to create new revenue streams. How can we use digitalisation to redefine industrial borders.

My favourite example of what this might mean is Amazon. They started out as an online retail book store. To build the store they needed a data centre, which they built and learnt to operate. Then they discovered that others also might need a data centre, and they developed AWS (Amazon Web Services). Today AWS represents a business in its own right targeting a different market than the original retail book store. This is the effects of digitalisation.

What can we learn from Amazon? The main lesson is to understand that digital skills can have value outside your primary line of business and that the introduction of digital capabilities blurs the boundary between supplier and consumer. Digital capabilities will change the power balance within industrial value chains and avoiding becoming the easiest replaceable middle man become a race in its own right.

The second thing to grasp is that within digital being a first mover has value in itself. For a competitor to catch up with Amazon on cloud services today is not easy. The third thing is that digital capabilities require continuous development with high frequent deliveries. This is very different from the business models used within long term CAPEX based industries.

A totally different effect of digitalisation is that actionable data has a value in its own right and that data enables new business models within existing industries. A good example is seen within the aircraft engine industry where actors as Rolls Royce and General Electric do not sell engines anymore, but they lease engines to the airliners on outcome based contracts.

What has made this possible is the real time monitoring of the engines, combined with condition based maintenance and the ability to optimise spare engines across airliners. A Boing 737 is a Boing 737 independent of airline.

The same model is applicable for other industries as well. Move sales from physical products and time and material services to outcome based services that includes leasing of physical machinery. The effect is reduced upfront capital expenditure and payment as fraction of produced value from the asset.

To take advantage from these opportunities requires that industrial enterprises adopt´s Internet thinking, and starts to develop and exploit their digital capabilities and assets.

Why software matters – from hardware to software

Why software matters – from hardware to software

In the first post I argued that software matters because it is the tool organisations have to encode information and knowledge so it can be effectively used, and that the firms being good at it will gain competitive advantage.

But computers have been around for decades, so what is it that have changed? The simple answer to that question is cost and performance. Thirty years ago, buying a computer was a serious business decision. The effect: computers was used only for the most valuable tasks at hand.

Today, computers are almost for free. Most of us have more computer power in our pockets than the one that was used to control the Apollo missions to the Moon. With the cloud offerings from companies such as Amazon, Microsoft and their likes, data centres have become commodities. Large organisations who have been running their data centres for years strive to understand this, while new companies exploiting it is started every day.

With data centres as commodities, competition, innovation and investment has moved from hardware to software. Competitive advantage is gained by being better than your competition in collecting data and to develop the software that transform your data into information and knowledge, and by doing so become learning organisations.

At the time of writing this is most visible for the Internet based businesses such as Facebook, Netflix and their likes. More traditional companies and industries will face the same race and now is the time where the actors positions themselves for the race.

So, what should firms do? Move your human resources away from tweaking computer hardware to writing high impact software.

Why software matters

Why software matters

I have for some time tried to answer questions like «why is software important for an oil and gas company and why must we take software seriosly?»

The short answer is that software is the mean organisations have to encode their information and knowledge, and to encode it in such way that it can be used, and that the organisations that are good doing this will be more competitive than those who are less good.

If this did not convince you, please read on.

For about 5000 years ago the Sumerians invented cuneiform writing and with the writing a new profession emerged, the scribe. The job of the scribe was to capture facts, insights and the knowledge of the time and write it down so it could be consumed and used by fellow humans.

During the millenniums writing technology changed. Clay tablets was replaced by papyrus and parchment and new encodings (read languages) emerged, but the task of the scribe remained more or less the same until the general level of literacy obsoleted the role in the western part of the world.

With the electronic computer came a change. There was suddenly a need for a new class of scribes. We did not call them scribes but programmers, but in many ways their task was the same. To capture facts, insights and knowledge and encode it into computer programs so it could be used.

The main difference between the Sumerian scribe and the modern scribe i.e. software engineer or programmer is that the primary user of the writings has changed. The modern scribe writes for computers.

The analogy with the scribe positions the programmers, but why should organisations bother about storing knowledge in computer programs, and why is this more important now than it was for say 10 years ago?

The simple answer to the last question is that now computers are everywhere and they are cheap. The effect is that organisational efficiency and accuracy depends on the speed the organisation is able to encode its knowledge.

The fuel of companies such as Facebook and Netflix is the speed they are able to encode their insights in user preferences into new offerings. These companies are at the extreme end, but the same competition has now come to more traditional industries.

Microservices and the role of Domain-Driven Design

In our #SATURN15 talk From Monolith to Microservices we addressed the challenge of data centric development, particularly when behaviour rich domain models are needed.

One of our main point in the talk was that too many developers continued with their script like programming style when they moved to Object-Oriented programming languages. Objects was treated as records and they seamed to have forgotten or never learned that object-oriented programming is all about capture of domain  behaviour and knowledge.

After reading the introductory chapter of @VaughnVernon book Implementing Domain-Driven Design this weekend another aspect became evident. The negative influence of properties and property sheets, originally introduced by Microsofts Visual Basic in 1991 and later copied by the JavaBean specification. These innovations dumbed objects down to records and even worse, trained developers to think this was the right way to design software using objects.

For Microservices to survive it is time to take object-oriented modelling back. Developers must learn that objects and object oriented programming supported by domain-driven design provides the tooling and techniques required to build behaviour rich software.  Software that not only capture data, but also domain behaviour and knowledge and make it executable.

The claim is that Microservices without sufficient capture of rich domain behaviour and knowledge will not add sufficient business value. They will just end up as distributed balls of mud.

Architecting Systems of Action

Architecting Systems of Action

Typed up this post to provide background reading for my coming talk on Systems of Action at the Saturn 2015 conference.
For years, if not decades, one of my professional passions has been to answer the question: How to create software systems that actively support operational decision making in time critical domains. At Statoil we decided to call these kind of software systems «systems of action».

The terms «systems of action» originated from a need to differentiate this type of software from record keeping software, also known as «systems of record». In an upstream oil and gas company there are wide range of record keeping systems, spanning from SCADA historians through drilling operations reporting to financial accounting.

Systems of action
Systems of action are by any norm an emerging group of systems that consists of three building blocks. Firstly they can sense or observe a phenomena, process or machine, secondly they can process their observations in search for anomalies, undesired state changes or other underlying deviations that must be dealt with, and finally, they recommend / execute actions to bring the observed phenomena, process or machine back to its desired operational state. In addition they observe the effects of their actions and are able to re-plan and adapt their actions based on observed effects.

Systems of action will operate with some level of autonomy; they will interact with human operators in trust based collaborations and they can be tasked with missions. Trading robots, tasked to observe market and to buy and sell shares to maximize profit is a good example of a “system of action” implementation.

Other examples include unmanned vehicles and robots such as NASA’s Mars Rover Curiosity and DARPA’s DART (Dynamic Analysis and Re-planning Tool) used for military logistics (supply chain optimisation). Systems of action are built with dynamic models, physical and/or statistical, models with their scientific basis in cybernetics and artificial intelligence research.

To be trustworthy their decision making mechanisms need to be transparent (humans must understand why a specific action is recommended / executed, included its intended effect, cost and risk). They can be fully autonomous, meaning they can be tasked to solve a particular task, but most likely they will be used to reduce the workload on human operators tasked with the control of dynamic high risk tasks.

In the conference talk, we have used drilling as case. The reason for using drilling is two fold. One, it is a domain where such capabilities have meaning and will be very useful. Two, it is a domain that is easy to explain to lay people.

The stack model
One of the challenges we faced talking about the value of system of actions was to have good means to conway their value so subject matter experts understood their potential.

It was in this context the stack model was created. We discovered a need to create a graphical picture illustrating what systems of action offers and how the need to be built with respect to capabilities.

The stack model was the result of this work. So for those attending Saturn 2015, come and learn more about systems of action and their architecting challenges.

stack model