Author: emlandre

Einar Landre is a practicing software professional with more than 30 years’ experience as a developer, architect, manager, consultant, and author/presenter. Currently working for Equinor as lead analyst within its emerging digital technologies department. He is engaged in technology scouting, open source software development (OSDU) with a special interest for Domain Driven Design, AI and robotics. Before joining Equinor (former Statoil), Mr. Landre has held positions as consultant and department manager with Norwegian Bouvet, Development manager of TeamWide, technical adviser with Skrivervik Data (SUN & CISCO distributor) and finally software developer with Norsk Data where he implemented communication protocols, operating systems and test software for the international space station. Over the last years Mr. Landre has become an active member of the professional community, where he has been author and coauthor of several papers presented at OOPSLA, SPE and Saturn. He has presented at several international conferences in Europe and the US. His professional interests include object oriented programming, enterprise application architecture, multi-agents, autonomous systems design, requirements analysis and specification, use of systems engineering practices, agile methodologies and leadership in high-tech organizations. He is a member of the ACM and the IEEE Computer Society, as well as the SPE (Society Petroleum Engineers). Mr. Landre holds a MSc in Information Technology from the University of Strathclyde, is an IEEE certified software development professional (CSDP) and lives with his family in Stavanger, Norway.

Digitalisation – The value of digital capabilities and assets

emlandreLeave a comment

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

emlandre4 Comments

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

emlandre1 Comment

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

emlandreLeave a comment

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

emlandreLeave a comment

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