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.
