Apps in the industrial sector: developing a software architecture geared for profitability

• Whether it’s based on an off-the-shelf package or a custom solution, if you want your app to be profitable, you have to get the software architecture right.

• The user interface plays a big part in determining the success of apps in the industrial sector. As the point of intersection between user and device, it has to be aligned with the needs of the user.

• With the right plan and by striking the right balance between scalability and maintainability, you can use the digitalisation revolution to position yourself for long-term commercial success.

A good software architecture can help keep dependencies and costs under control, enable long-term availability, and offer long-term extensibility for new use cases. As innovation cycles for apps and other software extensions get ever shorter, extensibility is a key factor in determining whether you enjoy a positive ROI. Given this, it’s perhaps unsurprising that a cloud-first approach is often the approach of choice. The cloud offers built-in scalability and early access to new services and features. But what does the road to a cost-effective, requirements-compliant solution look like?

The previous article in this series (“Business first! For apps in the industrial sector, software architecture determines app costs and ROI”), explored some of the drivers affecting app and software architectures in the capital goods sector and discussed various points that need to be clarified to ensure that an industrial app or software project will be commercially successful. I’d now like to explore some specific approaches to developing a profitability-enabling software architecture for apps in the industrial sector.

Software architecture for apps – off-the-shelf solutions enable greater focus

More and more manufacturers are building their app and software offerings around off-the-shelf solutions – assuming, of course, that a suitable solution is available. One reason for this is that, over the last few years, providers of software solutions have been making their products much more flexible. In the past, companies often had to buy a complete package, buy licences for each user, and then integrate it into their IT infrastructure. Today, the same or similar solutions (or even just individual modules) can be accessed by subscribing to a software-as-a-service (SaaS) offering. Integration into the company’s own IT is also less of an issue, as this is frequently carried out by a service provider specialising in the specific software and IT systems used. There are various versions of this, and the right one for your company depends on your resources and the type and scope of the digital services provided. At one end of the scale is integration into your own IT ecosystem. At the other is outsourcing to an infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) provider. The best-known platform providers are industry giants like Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).

What makes these de facto cloud computing standards particularly appealing is their high availability and the fact that these services are being continuously improved by the provider – a clear benefit for software services built on them. Established providers are motivated to continuously expand their service portfolio in order to better serve their customers, including customers in the industrial sector. In addition, providers use software development technologies which are widely used globally or open source their technologies, ensuring that relevant expertise is readily available – an important factor for enhancing their security. They also enjoy astonishing longevity – Amazon’s first web service went online in July 2000, more than 20 years ago.

As a result of these developments, many of the individual components making up software solutions have migrated to the cloud. Right now, this is the most cost-effective way of provisioning, maintaining and extending software components and APIs. And it offers the benefit that it lets you focus your development work on those components that relate directly to your company’s core business.

Software architecture for apps – developing custom software

When implementing apps and digital services for the industrial sector, there will sometimes be compelling business reasons not to use off-the-shelf components. In this case, the company will generally want to develop custom software. What factors might make you want to take this approach? When you’re trying to implement an innovative idea, like a new digital service, it’s often the case that components or services you need are simply not yet available. Which means developing them from scratch. One example might be a variant management tool for your products. Other reasons for wanting to develop custom software include not wanting to become too financially dependent on a third party, a lack of coverage in a particular geography or a mismatch with legal requirements or regulations.

Custom solutions are just as dependent on a high-quality software architecture. Companies need to be clear about the fact that custom means more work and will cost more than an off-the-shelf solution. What the above list of possible reasons for not pursuing an off-the-shelf solution makes clear is that custom solutions have to perform specific roles. Consider, for example, the case of a lack of service availability in particular geographies.

The availability of essential resources such as a stable power supply, fast, secure networking or even the physical safety of facilities are anything other than self-evident. The architecture for your app is therefore going to need to take into account issues such as power cuts, emergency operation, and communication in the event of disruption to services. Then there are challenges such as detecting hardware and software component failure, ease of hardware replacement in the event of theft, special procedures for checking the identity of users, etc.

Let's take a look at the product variant management tool mentioned above. To satisfy lots of different customer requirements, lots of different parts need to work together. These include your ERP system, your user portal, production planning and in some cases even external partners such as financial service providers. That means designing, implementing, testing, integrating and bringing into service each software component individually. If you want to ensure requirements are met, budgets are adhered to and that your solution has a positive ROI, the design of the software architecture needs to feed into every one of these stages.

Apps in the industrial sector – user interfaces and adding IoT functionality to your machinery

When developing apps and digital services for the industrial sector, the design and implementation of the user interface is of key importance. This is the meeting point between user and machinery, and it matters. User interfaces should always be designed around the needs of the user. For industrial software, interactive 3D experiences can be an appealing option, as they enable an impressively precise visual representation of machinery, processes or theoretical ideas. Contactless interaction, e.g. voice user interfaces or gesture control, can also be of interest.

The software architecture determines the underlying technologies used, how the solution is integrated into the end device, and how functions are divided between end device and backend. Many of these decisions will have a direct effect on the eventual cost of operating your solution. Depending on your billing model, it may be to your advantage to have smaller data volumes or less transactional memory.

It can often be easier to connect machinery and equipment to your IT systems using an IoT gateway, though this may not be suitable for all components which currently run on the machinery. The software architecture’s job is to demarcate the boundary between on-cloud and on-device functionality in accordance with the requirements specification. It’s self-evident that time-critical processes and safety-related components need to be closely coupled to the machinery; less so dashboards for condition monitoring, configurators, maintenance data, etc.

When performing status quo analysis of machinery software, it’s not always easy to work out which side of this divide a particular process or component should fall. Most such software will not have been built for this kind of separability. As a result, you may need to carry out some refactoring work, or you may even need to complete redesign the machine software.

Build, buy or partner vs. build, buy and partner?

Whether it’s a software solution, platform or component, thanks to ever growing connectivity and ever shorter IT innovation cycles, the question ‘build or buy?’ is increasingly becoming ‘build, buy or partner?’. In addition to development and operating costs, an increasingly important factor in deciding whether to build, buy or partner is dependency on external providers and partners. Today, lots of software systems are hybrid systems, part bought, part developed in-house and part partner solutions. Whilst buy and partner options allow you to get your digital services to market faster, they rarely allow you to implement your business plans in full and in all their diversity.

Apps and profitability – the right balance between extensibility and maintainability

As noted in our previous article, “Business first! For apps in the industrial sector, software architecture determines app costs and ROI,” when designing a software architecture, there’s always a balance to be struck between extensibility and maintainability. Ask yourself where building in extensibility is really going to pay off, where the business model demands it, and where it should be jettisoned to reduce system complexity and boost maintainability. Building in adequate extensibility means you’re investing for the longer term, as it enables your solution to incorporate new features. Good maintainability reduces ongoing costs.

Optimising how costs are spread over the life cycle of your product or service always pays off. For products intended to enjoy a long life span or high scalability, it’s extremely important to think about operating costs as part of the development process. For apps, in addition to actual operating costs, it’s essential to consider ongoing development costs – nowadays users expect apps to be updated regularly.

Successful ongoing app development – plan for change

A commercially successful software architecture is aligned to the commercial needs of the business. High availability and extensibility are a good start in this respect, but you also need to think about technical and external factors. For a software architect and his development team, separability of software – in the sense of functionality, testability, predictability of behaviour, predictability of response times and maintainability – is a constant focus.

In the highly connected world of computing, we are far from being at the point of maximum technological development. New technologies will inevitably come along that enable new opportunities to partner with other companies. Commonly cited examples include DAPPs and Web3. This will require software solutions that aren’t yet commercially available. So make sure you budget for technological change.

The fourth post in our series will look at how to implement a specific project, how to successfully launch a digital service such as an app, and how Zühlke can support you with that.