How to Avoid Roadblocks?
Karl Bråtegren, Senior Manager at Modular Management in Stockholm, shares some thoughts on software modularity and how to avoid roadblocks.
KARL ON ONE OF HIS FAVORITE TOPICS
What is Software Modularity?
Software modularity is the decomposition of a program into smaller programs with standardized interfaces.
Microservices is a hot trend right now, and it’s essentially about small modules that are built into a whole software system. Spotify and Netflix talk about how they work with microservice architectures, and before this there was a similar trend called Service-Oriented Architecture (SOA) that targeted bigger modules.
Software modularity pretty much shares the same definitions as hardware modularity, with strategically- and functionally-clean modules that are driven by customer needs and share standardized interfaces. You basically allocate different functions to software modules and then implement them in source code.
A common way of referring to interfaces between software modules is Application Program Interfaces (APIs). For example, Google and PALMA expose APIs to the external world, and when you create software modules it’s like creating APIs within the product.
Why is This a Hot Topic?
The main driver is that software is rapidly becoming a bigger part of many products.
Software is delivering on the most important customer values and companies need to be much faster in development to stay ahead of competition. With modularity you can secure product leadership with separate modules that can be developed quickly without being locked into a complex web of other software functions. Basically, you can avoid roadblocks.
A second driver is ‘hardware portability’, a topic that many clients are looking at right now.
Hardware portability means that you want to be able to move the software solution from one hardware to another, enabling you to easily change hardware supplier. Electronics like PCBs, for example, can reach end-of-life quickly and you need to replace them. You also want to take advantage of better and cheaper hardware when it becomes available. If you have inflexible, over-dimensioned software that doesn’t scale well with the hardware, it makes it very hard to move the solution to a lower performance piece of hardware. With the right modules in place, you can isolate hardware impact to specific modules and enable hardware scalability and portability.
A third driver is that you can’t do everything on your own.
You want to make use of open source and leverage third-party specialist expertise. It’s much easier to plug in third-party software, for example navigation and vision processing, into a modular architecture than a monolithic one. You would in this case aim to create modules with the aim to source them from a strategic partner.
What’s Your Personal Experience of This?
We’ve recent client experience, but an older example is when I worked as Product Manager at Siemens Mobile Networks. This was back in the old days of Wireless Application Protocol (WAP), General Packet Radio Services (GPRS) in mobiles and slow networks.
At Siemens we didn’t have a WAP proxy to sell to operators and wanted to launch our own product. What we did was to partner with an American company that had a proxy server with compression technology, and they then made their APIs available to us. Using these APIs we could develop services aimed at the cell phone service providers and make a viable and attractive solution. We also discovered that we needed a WAP protocol stack, so we found a Finnish company with a commercially available WAP-stack that we could plug into.
This is a practical application of our strategic sourcing driver from the Module Indication Matrix (MIM), but at Siemens we didn’t think much about it back then. We just bumped into challenges that had to be solved and found a way to solve them with strategic partners.
What are the Opportunities for Companies?
There are many reasons to invest in software modularity, but it’s basically about being fast and flexible. By developing new features faster, and more frequently, you can provide new software and hardware products that better meet customer needs.
You can also work with the continuous release of new features, while maintaining quality and not putting product reliability at risk. In an integrated or monolithic architecture, there’s a risk that when you introduce a new feature update the whole product goes down. If it’s a robot, for example, this means the whole line stops. Even if the update feature is quite small, like a nice new Graphical User Interface (GU), customers will be scared – or won’t even dare – to update if it’s in a big monolithic package. This has been a real issue and in some cases it still is.
Without a flexible, modular software you have a slower development pace, more bugs, more testing issues and more time to release. You’re also forced to live with old and expensive hardware and run end-of-life hardware projects, often in panic mode.
MONOLITHIC AND MODULAR DEVELOPMENT HIGHWAYS
What is Modular Management Able to Offer?
We’re able to offer a unique approach in Modular Function Deployment® (MFD) which solves many of the challenges mentioned earlier.
I haven’t seen any other structured approach that explains how you should think if you want to move to microservices or a more modular software architecture. There are rules of thumb in the software world, like separation of concerns, but there is no real method like the one we have.
MFD is unique because it takes customer values into account. This is extra important for software, because for a lot of modules you don’t need parallel variants of the source code, you just need to increase speed in delivering on certain customer values. In other words, you need to rapidly bring out new versions of these modules.
With MFD you can also consider company strategy up front, for example hardware portability, strategic sourcing, carry over and technical specification. One scenario is that when you offer integration capabilities to the external world you may need different protocol stacks. An example of this is to offer many different industrial Fieldbuses (ProfiNet, EtheNnet/IP, DeviceNet…). They will typically come with their own variants of the code. This is an example of when we would apply technical specification as a strategic driver. In the end, this could be enough reason to create a module for the Fieldbuses.
Many of our clients typically have good technical software architects. Architecture is a skill that’s important when you work with software because it’s so abstract. You don’t have brackets and pumps to touch and feel, so software architects are typically comfortable in talking in functions and working with architecture diagrams. But they often overlook customer values and strategies, or at least don’t have a systematic method to approach these critical drivers and how to reflect them in the architecture.
THE CUSTOMER-CENTRIC METHOD FOR PRODUCT ARCHITECTURE CREATION: MODULAR FUNCTIONAL DEPLOYMENT (MFD)
Any Final Thoughts?
I’ve heard software architects say that it’s more difficult to describe exactly what you mean when it comes to software, just because it’s so abstract. You also have a very high degree of freedom in implementation since you’re not bound by physics.
This level of freedom makes it easier to circumvent the architecture during implementation, so it’s always important to go back to why you defined a module and make sure it’s implemented accordingly. That’s where we come in.
For more information, contact me via the button below. Feel free to download our template to document your strategic software module here:
As software architecture can easily be circumvented by the coders, it is important to repeatedly go back and look at the reasons why certain functions were grouped into modules.
We have done software modularity before, but this time we factored in customer values and strategy. I believe this makes our new architecture much stronger.