What is the difference between software and software solutions?

by Daniel Lübke
A software solution is the whole solution to a customer's problem, which comprises software but recognizes that software is only part of the solution and not the solution itself.
-- Daniel Lübke

In software development projects we often think about the software. It is centered in our mind as the only important thing we need to care about. We try to make it more efficient, to make the code cleaner, we think about maintainability about performance and about availability. If we are an advanced software engineer, we also think about the usability and the end user. However, the customer will sooner or later realize that not the software is important but that it is the solution to his or her problems. This is what I call a software solution. The software solution obviously comprises the software itself, but it also contains other environmental properties like business processes and success with the customer’s customers.

We need solutions

Therefore, it is not sufficient to “only” develop good software. It is also necessary to take the environment of the software into account and to design and change the environment as necessary for addressing the customer problem.

I encountered one example of such a mismatch in the last week when I was interested in a house that was offered for sale. I contacted the real estate agent via a housing portal site and entered all my personal data. A day later I received an email that I must confirm my interest and the processing of my data (GDPR regulations). This form also requested me to enter all my personal data again. I accepted and entered my data the second time and was notified that the real estate agent will contact me via phone. Indeed, I received a phone call. To my surprise it was not real estate agent but the call center which again requested me to revalidate the data which I had entered before. So, the call center agent told me which data I had entered and ask me for each item whether it was correct or not. Again, I received an email, but the real estate agent will contact me. Nothing happened so I called the real estate agent. Although my journey began on the first day of the announcement that this particular house was on sale, I was told that this house was already sold. This whole encounter lasted for about a week(!) without any productive interaction and led to no success. In the end I was frustrated and will not pursue any selling offer by this real estate agent, and I will never sell anything with this agency as well.

Noticeably, the whole process was fully digitized. All employees knew my data that I had entered before and when I had entered it. This means that there was a working software and perhaps it was even a well architected software and it was perhaps even as specified but it was no software solution. The solution would include the software and multiple changes to the underlying business processes.

Software vs. Solutions

Very often - like in this case - the changes to the business processes are simplifications which will also make the software simpler: either in terms of offered use cases or in the complexity of business rules. In this case multiple user interfaces for example from the call center could have been eliminated and thereby led too a much better result from the customer’s perspective. By changing our focus from the software to the software solution we need to make more effort to understand and improve the business side of things. In upcoming blog posts I will show how this can be integrated into software engineering processes and tools. For example, quality trees can be used to also track quality characteristics off the end customer. While this change in the mind set will require some effort and will require to game knowledge and experience in business process design, it will ultimately lead to more successful projects and to more satisfied customers and customers of the customers.

Let’s make our world a bit better, our customers a bit happier and recognize that the software is only part of the solution, but it is not magically “good” if it is done in software! Care about the context in which the software is used and optimize this setting as well!

<<< Previous Blog Post
Why and How to Profit from Software Engineering Research?
Next Blog Post >>>
Un-reason-able Software Engineering

To stay up to date, we invite you to subscribe to our newsletter and receive notifications whenever a new blog post has been published! You can of course unsubscribe from these notifications anytime.