Typically these products are developed in large, and sometimes very complex, industrial projects where the manufacturing and delivery of the product in general is a heavier investment than the software budget. In the automotive domain the purchasing and manufacturing cost of the physical parts for each product is typically an order of magnitude higher than the R&D cost split over the number of products built.
This in turn tends to drive the entire R&D process, and software follows the process logic of the mechanical development and manufacturing setup.
Software differs compared to its mechanical and electronic counterparts; once the software is developed there is no additional cost if one increases the number of products produced.
Likewise, the cost of updating or replacing software in an already built product is orders of magnitude cheaper compared to replacing hardware.
The common business model is to sell the manufactured system as a product, the original equipment manufacturer (OEM) gets paid an agreed amount for each system delivered. From a customer perspective there are some issues with this present business model when it comes to features purely relying on software. An example scenario in the automotive domain could be:
My neighbour bought a new Volvo four months after I did.Another example scenario would be
He got Spotify, but I didn't.
Do I feel ``cheated''?
Google music turns out to be the next hot thing. It takes Volvo 30 months to include this feature according to the present stage gate process. Is the feature still ``fresh'' when delivered?A future scenario could be that Spotify is deployed to customers independently of when the car is built in the factory, i.e. after the customer has received the vehicle.
With more and more vehicles becoming connected it is conceivable to have continuous updates with new software features to customers on a scale and to a cost that is impossible would the updates require hardware modifications. This would build trust in the brand to maintain a useful product and extend the value for the customer after the purchase.
The team developing Google music could deploy it after 3 months of development, making it ``almost competitive'' with smartphones. More and more services are used regardless if one is using the phone or driving in a car, and from a customer perspective it is difficult to understand why services in one context is cannot be delivered in another.
The topic of investigation in this thesis is efficient and sustainable development of software for mass-produced embedded systems (MPES), and the implications a chosen way-of-working and software architecture have on R&D, and indirectly on the business.
2 comments:
In the case study in chapter 5 I designed the study, selected the theoretical framework used (Architecture business cycle), chose the architecture scenarios and made the purposeful sample of interviewees. My co-author contributed with choice of the interpretative research approach and the design of the interview process. The interview questions, the interviews and the transcriptions were performed by 3 students as part of their thesis project, which I supervised together with the co-author. The final analysis in the paper was mainly done by me with input from the co-author based on the material of the students.
click here
In the case study in chapter 5 I designed the study, selected the theoretical framework used (Architecture business cycle), chose the architecture scenarios and made the purposeful sample of interviewees. My co-author contributed with choice of the interpretative research approach and the design of the interview process. The interview questions, the interviews and the transcriptions were performed by 3 students as part of their thesis project, which I supervised together with the co-author. The final analysis in the paper was mainly done by me with input from the co-author based on the material of the students.
click here
Post a Comment