Corporate Open Source

One concept that is under active discussion for the past decade or so but constantly being misunderstood. Open Source is often taken as a label for software downloaded from the internet, packages free of charge, components under a particular license filed under “Creative”. Often enough it’s misused for lower quality software, which reality has proven wrong by 2017, not to mention the issue with intellectual property.

However, there are many much more aspects to the concept, that add substantial value to any software centrist product organisation. And in times of digitalisation and digital transformation, software will move into the value chain of many organisation that don’t anticipate it yet. Whenever a customer offering is complex and / or service based, transparency and documentation are often key to a satisfactory result and efficient processes.

Open source may not be the one single bullet for any organization, but the concept will help becoming more transparent and efficient.

Single Source of Truth

While SharePoint is a powerful tool with many opportunities to improve processes, many organisations use it to maintain a file server. Which has information about any other effort, therefore creating a large spread between the tangible product and the then theoretical documentation. Not to mention the version horror everybody experienced at least once, trying to ask a few people for the latest version.

Reversing this process through Wiki or even Version Control Repositories allows to keep only one version, that is automatically the latest. Software will take care of all versioning, that would go in filenames_v01_final.docx otherwise.

Transparency

Adding together the product with documentation allows quick reference, pointing back and forth between customer facing and engineering. While this may sound terrible technical, the nasty guts of any product can still be ignored by those who don’t need to see it. However, for those requiring insight, they don’t have to go through a process to see it. Or even have to talk to a colleague first and ask. Oh, and the colleague will be on vacation anyway.

Opening the product internals will remove any barrier to productive work and allow employees for quick insight. Obviously, some may argue an open repository may lead to uncontrollable product results, but that’s actually a different point. Write access or merge credentials are not required for anybody without responsibility.

Applicable Metrics

To shape it all up, the management world has plenty of nice metrics that can be applied to measure the whole thing. Not all of them express quality by themselves, but applied consciously these can carry a product far.

Documentation Coverage is something that will serve as a great basis for the point I’m trying to make here. With closed projects, or engineering only code, it’s often difficult to understand whether a product, feature or bug is actually just badly documented or the colleague just doesn’t want to help.

With a metric to measure percentage of a product being documented, at a minimum the amount of available documentation can be measured. And with the product internals being transparent, any reader can – at least theoretically – see whether the documentation correctly corresponds.

Conclusion

While being a strong supporter of open source software in general, I’m not trying to make a point for open sourcing anything outside an organisation. However, transparency will help any organisation improve the offering and processes. And the concept of open source will help achieve this transparency. It has a hurdle to overcome, in particular management will have to overcome their fear of software and technology to adopt this concept, but the step is worth taking on the way to digital transformation.

Change.

Yesterday, a software engineer, also new to the organization, roughly told me the following. The way the organisation plans projects is so different to what he is used to as a software engineer. Planning projects with a horizon of 12 or even 24 months is something he says he just cannot wrap his head around.

While this is very common and necessary in the hardware industry, it is indeed something terribly alienating software people. Software is typically treated as a living product, that takes tiny changes at a time, it is more governed towards a direction to take than having the one exact goal it has to hit by a specific date.

These very fundamental goals both mindsets follow make it difficult for change to happen. While the software engineer above obviously has a point to make, he cannot reach the people he needs to reach, because both sides are just too far apart.

At the same time, I don’t yet have an answer to the problem, but the problem itself became so obvious when this colleague told me he just doesn’t know what to say. The digital world does not yet have a common language, not to mention a common way to think about approaching problems, and unless this hurdle is taken, change will only happen slowly.

Lifelong Learning

IEEE’s Educational Activities Committee (EAC) invited me for their regular meeting, that happens May 13th and 14th in Porto, Portugal. Me being there is to represent Action for Industry Committee (AfI). On first priority, the attendance is to foster inter-committee cooperation. However, one of the items we’d love to promote to industry, but to everybody else, is that education is important. In particular in Industry, where innovation and therefore differentiation from the competition is key to any activity.

To make the point about lifelong learning: upcoming, innovative technology trends, just to mention the Internet of Things, Electromobility or Autonomous-Driving require broad sets of expertise’s, abilities and complex organisations to come to life.

The Internet of Things, while being a vague term, is often associated with an App controlling a device remotely. While this looks easy on the outside, looking into the workings of such a product, it typically requires skills from 2 mobile platforms, Android and iOS, potentially Web. The connectivity part requires knowledge about transport protocols, that need splitting into IP protocols and constraint field busses. The cloud end alone is typically broken down into data transfer, data storage and data processing, while the field offers a broad choice of communication protocols and physical layers, all for different purposes and use cases. Not to mention the engineering, design, production process and supply chain that yields a physical device that a consumer wants to control. Adding in service based products, that give a customer a better understanding of usage patterns, energy savings, potentiation gameification of product use, require data processing and analytics.

This very high level example requires at least 3 major degrees, again, not mentioning the business administration side, that’d increase the count to 4 major degrees, with about 3 minors each, just on the upside estimate.  Highly complex products like this need highly skilled engineers and managers, that do not only need to execute on producing and operating a device, but also keep up on technical ability to stay on top of upcoming technologies, processes and procedures.

Lastly, any requirement to understand peering functions and technology makes the final argument for lifelong learning, because not only does the world change so fast, there is always fields interfering with an engineers major in an evolving market. This way, lifelong learning is not only something desirable to one self’s development, but a fundamental requirement to stay ahead of the market.

IEEE’s main pillars are academic publications, conferences and standards, all carried by an overwhelming number of volunteers. These are all, with no doubt, convinced that sharing knowledge increases knowledge. The really differentiating fact for IEEE is these are not from a single domain of research, but these ~420.000 members are organised in 39 technical societies, spanning all different kinds of technology and research.

Through this large spectrum of interest and the volunteering nature of the organisation, it enables lifelong learning through the exchange of ideas and knowledge alone, with Committees like the EAC fostering the activity, and Action for Industry keeping the relationship with engineers in industry.

On Digitalised Product Management

Now the family left me here for the afternoon, I have some time to exercise blogging and put down a few thoughts on my recent job. To write in a cosy environment, a lit the fireplace at the house we are staying in. The result is as favourable as you may imagine. Only the missing bear fur could add to the feeling. The role in marketing, “Product Management”, hasn’t been that cosy recently, for a few reasons, that are more related to corporate behaviour than to individual contribution.

While I will need to avoid mentioning the actual product I am still working on, and it’s probably difficult even not to have any references, the below still tries to explain the tensions that exist in the world of traditional industry, moving towards a digitalised service business, in which tangible products get marginalised.

The primary reason for me, an computer engineer, having spent all his life in service business and so to say “in the cloud“, to come to a marketing oriented role is to design and develop – as in business, not as in a computer programming – a connected product.  The Internet of Things, if you want to. Whereas many companies have Things already. But they want to offer smarter things, that’s why everything gets connected. Now connectivity has to offer many benefits over traditional products, but they’re not the primary value proposition the customer pays for. The customer still pays for the product. And in the market, any customer will ask for the smartest product available. Just like I wanted to light a fire. One that was good and warm, and keep my cosy. And to do so, I had to collect some pinecones, that would easily catch fire. It was bothersome, but necessary. 

The things industry is not very familiar with service offerings. It’s actually something fundamentally different from the internet or services industry. To put it boldly, what a customer expects from a product: something solid. And what a customer expects from a service: something that is available anytime. (Like, literally, in the middle of the night!). While Things are sold physically and can be produced on stock, a service cannot be hold until the customer asks for it. Value through a service is created by making something more convenient. I’d have paid somebody to cut and carry the wood required to light a fire. But I had to do it myself, and that was  not only tiring but also heavy work. While, as a customer, the thing I’d buy is the wood, I would spend a premium for somebody to do the work. To add the service. Probably not much, but hey. The same happens for businesses.  While still everybody produces products, the more convenient products are in the customers favour, only at a small margin, though. Just to make an example, just recently Oracle, a business to a majority based on the sales of products, databases, announced to acquire Accenture, a consultancy service, to add services to it’s portfolio. Others have doubts this merger makes sense, exactly for the above reason. Margin driven things companies will have a difficult time appreciating low margin service as part of their portfolio.

Just like me. I wanted to sit in front of a warm fire when spending my time without the family. It’s very clear I’d need pinecones and wood to get that, and I’d pay for it. However, if some other guy selling wood sells cut wood and carries it to my house for a fee, I’d probably appreciate that more convenient offer. But that decision has to be made very conscious, and people responsible for the service in that organisation can’t be measured on financial goals as their product colleagues, but customer satisfaction.

 

 

 

The code I’m still ashamed of

The following came through my timelines a few days back. A guy feels guilty for what he did – as a programmer – when he was young. Basically he built a promotional website for a questionable medicaments. Apparently the drug has side effects of depression and suicidal thoughts. Only after his sister was prescribed the same medicaments, his conscience made him quit what he was doing.

If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little…

Source: The code I’m still ashamed of

Also, the author writes the following:

As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices.

It’s a pretty sure bet everybody long enough in the Internet Business has had moments like this before. For myself, there were a few moments, where I saw an ethical border that I didn’t want to cross. As a student, this was porn. As a professional, it was weapons manufacturers.

Interestingly enough, I even quit two companies for their ambition in IT security. The first pushed datacenter-grade firewalls to small businesses that basically only needed a DSL modem. Through a sales method borrowed from insurance brokers.

The other one at least had a solid technology, but developed a solid sales pitch relying on the same FUD, that crosses that ethical border.

Just like with medication, people shouldn’t buy security out of fear, or any other product for that matter. And any technical person should strive for educating customers and not helping sales people create that fear.

Audi, BMW and Daimler buy here.com

William Boston of the Wall Street Journal comments on the acquisition of here.com, formerly Nokia, by German car manufacturers Audi, BMW and Daimler.

German auto makers Audi, BMW and Daimler have agreed in principle to purchase Nokia’s digital mapping service, called Nokia Here, for about $2.7 billion, according to a person familiar with the situation.

via: Audi, BMW and Daimler Near Deal to Buy Nokia Mapping Service

Also:

Both sides of this — why Nokia needs to sell Here Maps, and why the car makers want to buy it — were explained by Horace Dediu last month.

via: Daring Fireball.