Business first! For apps in the industrial sector, software architecture determines app costs and ROI

• To keep costs for digital offerings down and ensure profitability, it is essential that the software architecture is optimally tailored to the intended use cases.

• When choosing a software architecture, it is important to look at things from a strategic, commercial perspective.

• Sales teams are a key ingredient. Their structure and training need to be tailored to successfully selling your new services.

In the industrial sector, new digital applications such as apps and software extensions are becoming ever more critical for product success. Over the last few years, I’m sorry to say that on a number of occasions I have watched promising major projects fail to achieve a positive ROI because implementation has proven just too expensive. One Zühlke study found that only 5 percent of IoT projects turn a profit. The future of The future of industrial businesses depends on being able to successfully implement digitalisation projects. This blog looks at what questions you need to be asking yourself to ensure project success.

The first blog post in our series (“Apps deliver innovative product USPs and novel digital revenue models for the industrial sector”) looked at the huge potential that apps and digital revenue models offer for the industrial sector. This post looks at choosing and developing a software architecture and looks at the commercial questions that need to be clarified to successfully and profitably implement an industrial app or software project.

Architecture drivers for app and software projects in the capital goods sector

Most of the major drivers when choosing and developing a new software architecture are commercial in nature. Before starting to develop a software architecture for a new digital offering (taking into account the existing architecture and other company-specific technical restrictions), it is essential to ensure that the business case is clear.

To minimise development and operating costs and ensure apps are a commercial success, the software architecture needs to be optimally tailored to the intended use cases. An architecture which is not appropriate for the application or an application which is a bad fit for the architecture can unnecessarily drive up implementation, post-release development and operating costs. Such avoidable software costs can undermine the entire business case. A study by Zühlke (Data-driven companies – charting a course to strategic data use) found that this mismatch between technology and application was a major reason why digitalisation projects in industrial companies fail. Conversely, in the brave new digital world, the right software architecture is the foundation on which long-term commercial success is built.  

Functions and apps for standalone machines or groups of machinery

One of the first core questions you need to ask when designing the architecture for a new piece of software is: Are you delivering additional functionality to a single machine or are you aiming to enhance machine functionality by networking together multiple machines? In the first case, the focus is solely on the individual machine or on areas where networking with other machines is not relevant. Developing and operating software architectures for products aimed at helping multiple machines work together more effectively tends to be more complex and expensive.

App compatibility – new machines only or upgrading older machines?

Another question companies need to ask themselves is: Will they need to extend existing machine interfaces, and if so how they will go about this? How you’re going to deal with multiple generations of existing machinery requires careful consideration. Choosing to support older machine versions may push up your costs so much that you wipe out the business case for your planned suite of apps. It’s possible, for example, that making the app compatible with older machine versions both reduces its utility and at the same time doubles your costs.

Building compatibility with older machines is time-consuming and expensive. From a commercial perspective, there’s a strong case for only supporting the most recent machine versions. It’s also very important that the interface is specified to maximise its lifespan. Implementing changes at a later date can be expensive, so this point needs careful consideration.

Machine interfaces for apps and extensions – communications standards like OPC UA vs. industry standards

Do you use custom interfaces? If you do, you need to ask yourself whether you want to keep on using them or whether you want to take the opportunity to switch to industry standards. If you want to be able to access machinery from a range of manufacturers, you need to either support all custom manufacturer interfaces, or use standards such as OPC UA. In practice, you often need to do both – you need to support popular existing interfaces, the latest sector-specific standards and industrial standards such as OPC UA. Before taking a final decision, you should task some experienced software architects with estimating the likely cost of developing and operating these interfaces.

Apps on mobile platforms like Android and iOS

In principle, it is perfectly possible to use standards like Android for your user interface, or even, where appropriate, mobile devices such as iPads or other tablets. The advantage of using standards is that you may be able to use their built-in deployment functions to distribute your software. This can reduce development time, but it does make you highly dependent on the provider. It’s important to examine the commercial implications of this dependency and not just to go with whatever your software team recommends. A variety of perspectives reduces the risk of overly subjective decision-making. It can minimise the risk that decisions are made solely on the basis of personal preferences for specific technologies.

IoT platforms – cost vs. acceptance

On behalf of a German company in need of an IoT platform, Zühlke analysed IoT platforms from three major providers – AWS, Microsoft and Google – to determine which was the best fit for the company. We started by working out how much operating the cloud backend for the planned application was likely to cost, as this has a big effect on the business case. From a cost perspective, it turned out that the difference between the three providers was minimal. So we looked at a further key factor – we looked at how using each provider was likely to affect acceptance among the client’s international customers in the specific sector in which it operated. In addition to their pure cloud businesses, some of the three major providers are active in other fields of business. As a result of the different strategies pursued in different sectors, levels of acceptance can vary. Our client ultimately selected the provider expected to enjoy the widest customer acceptance.

Third-party apps – adding value or adding risk?

Third-party software providers can also add value for your customers, in turn increasing the value of your products. It’s possible for a whole digital ecosystem to grow up around your machinery. You need to determine at an early stage whether you want to charge third-party providers a percentage of sales or charge a fixed fee. Both will bring in additional revenue, but the wrong choice can dampen third-party provider interest in your ecosystem, with obvious disadvantages.

Being able to add useful third-party software to your machinery increases the value of your product. But remember that poor or unsuitable third-party software solutions will reflect badly on your own products and brand. As well as damaging your image, they can also result an increase in complaints, coupled with time-consuming investigations to determine whether the problem is due to your product or the third-party software.  

Competitor apps – additional revenue opportunity or threat?

Things start to get particularly delicate when it’s your competitors who are shipping third-party software. You therefore need to decide whether you will allow your competitors to sell higher-level control software or whether their role should be limited to connecting their machines. When thinking about how you want to position your company in the new digital world, look at your market power compared to your competitors. If you’re not starting out as market leader, remember that attempts to use new digital offerings to squeeze out the incumbent rarely succeed.

On the contrary, any such attempt will often instead have the result that it is your new digital solution that ends up failing to gain traction. If, on the other hand, you are a more dominant presence in the market, it is much easier to set new standards for digital offerings and to decide what roles other companies can play.

To exploit the benefits of third-party apps while minimising the risks, it’s worth looking at how Apple runs its software ecosystem. Third-party providers are obliged to use the App Store to sell their apps. This means that Apple is able to test key functions before release and check the software for security vulnerabilities. The software is sold via the App Store and Apple retains 30% of the sales price. To get a successful digital ecosystem like this off the ground, the machinery manufacturer needs to make sure that selling apps on their proprietary platform is worthwhile – sufficiently worthwhile to attract a good crowd of third party providers to the platform. If your platform is highly machine-specific, this approach is likely to be less promising.

There are therefore a number of questions that need answering before you make a final decision on whether to enable external access to your machines:

• Will third-parties apps be permitted and within what parameters?
• Will there be restrictions on which third parties are permitted to supply apps?
• Will competitors be excluded?
• Will you perform quality control on external apps in-house?
• Will apps be made available via an in-house app store only, with you taking a cut?

App updates and safety strategy – a clear separation between critical and non-critical functions

One way apps and software extensions can add value is to add new functions to equipment and machinery to enable it to adapt to changing circumstances and thus prolong its service life. Upgrades play a key role in ensuring that machines stay relevant and flexible. A few questions need to be asked, however, ranging from, “How will software and optional software extensions be delivered?” to “Will apps on the machine be updated manually or automatically?” to “How time-critical are apps?”

Safety strategy is another key consideration when designing an architecture for apps and other digital services. Some applications can’t be updated, as they are certified for a particular software state. This is especially true for safety-critical applications. If a company wants to enable app-based services for these applications, this can be achieved by clearly separating critical and non-critical functions. In a car, for example, the airbag control systems are clearly separated from the infotainment systems. Separated functions only interconnect at a small number of well-controlled points. If there’s a clearly defined strategy in place from the outset, this can be implemented within the software architecture.

Selling apps and software – an underappreciated stumbling block

One area that people don’t necessarily think about in relation to implementing digitalisation projects is sales. That’s one reason why sales is often one of the biggest stumbling blocks when it comes to successfully monetising software in industrial businesses. Capital goods such as equipment and machinery are usually sold by a field sales team who advise potential customers in person.

They tend to be experienced teams with a profound understanding of the machinery and the industry, but often little experience in selling software. For digital products too, the costs associated with using an internal sales force, or for export sales often an external distributor, reduces margins.

A Zühlke study (Radical innovation: Why companies fail and how they can succeed) found that more than 90 percent of companies surveyed are of the opinion that their existing sales force will not be able to sell their new digital product or service. In the car sector, after-sales digital services are generally sold to the customer directly without any dealer involvement. This increases car company margins, but requires appropriate IT infrastructure. For capital goods, sellers additionally need clarity about who will be authorised to make after-sales purchasing decisions. Should all users be able to enable machinery functions or does there need to be a system of user privileges? And how will these purchases be billed? All of these points need to be clarified, as they will have a big effect on the software architecture.  

Your business strategy shapes your software architecture, not the other way round

In answering the above questions, your choice of software architecture should not be based solely on technical considerations. It should be your business strategy that determines the specifications for developing a cost-effective software architecture. So get all internal stakeholders involved at an early stage – including your IT department. After all, it’s the IT department that has to decide whether it will operate the infrastructure or whether this will be outsourced to an external provider.

Depending on how your company is structured, a final decision might be made by the product management team for digital products, for example. Which department makes this decision is, however, less important than the expertise of the decision-makers. Because this decision requires both commercial expertise and an understanding of technical aspects of software architectures, in our projects we employ mixed teams made up of Zühlke digital consultants and software architects. They advise our clients and work with them to develop the right software architecture for the use case.

In the next post “Developing a software architecture geared for profitability”, we will be taking an in-depth look at how we go about such projects, and showing you how we can support you in using your business requirements to develop your architecture, the methods we use in doing so, and how this enables us to arrive at an early estimate of development and operating costs.