The blog post on “system of systems” described that many future services are increasingly developed and operated within the framework of complex networks of companies, rather than a single company or a well-established and stable long-term relationship between two companies. This specifically applies to the area of automated driving, as well as comfort functions, for instance. Two aspects different from today are of particular importance for collaborating:
- Future functions and services will – to a considerable extent – be “simply” composed “Lego-style” from existing basic services in a system-of-systems.
- Functions and services must be operated throughout the full lifetime of vehicles.
Collaboration in such “system-of-systems” requires creating the necessary contractual and organizational prerequisites (see blog contributions on the subject of “agility”.) Additionally the organizational units of OEMs or tier 1, who contract to development partners, need to be capable of evaluating the potential development partners for competences different to the ones assessed today. The processes and audits used today may remain methodologically valid, but additional standards will need to be required and evaluated for the organizations in question. The following capabilites are jointly required by partners to give such a collaboration a chance of success:
- Clear understanding of the end-to-end service and the contribution of the development partner to be contracted
The development partner must understand his own task in the network unambiguously. The interfaces available to him both technically and organizationally – during development and during operation – must be defined clearly. It requires e.g. an understanding of which technological dependencies exist functionally, which result from the operation, and which framework conditions must be respected. This is the foundation for a successful contribution to the service.
- Capability to operate services smoothly
Only if all parties involved in the operation of the service share this competence will it be possible to maintain a quality service over an extended time period. Therefore, if the role of the development partner includes operation of the service, then the competence of the partner must demonstrably include quality service operation. This could be analyzed by audits based on relevant standards, such as ISO 20000.
- Ability for continuous update and to respond quickly
The constituent parts of the system-of-systems, upon which all the services are built, are themselves subject to change, sometimes at very short notice or even without notice – surprise! This change may affect the services, possibly even disable particular services. This situation needs to be resolved very quickly. This means that resources must be available to (a) detect such “interference,” and (b) implement adaptations to the services necessitated by the changes. Speedy resolution of such issues requires that these resources must be available throughout the lifetime of the service. This holds for all development and operational partners involved.
- Familiarity with interface partners
Future services are developed in technologically and culturally heterogeneous environments. They may have many dependencies among themselves. Differences in terminology and culture quickly lead to misunderstandings. Think of the different “world views” of those concerned with IT operations, those responsible for functional safety, and those working in open source projects, for instance. For example, the term “change management” is used differently in IT operations compared to software development. Another example is how priorities are set in these different cultures. When dealing with functional safety, this safety has priority over all other considerations. In IT development, it is often time-to-market what gives the edge (possibly leading to “permanent beta.”) This does not mean that one is right or wrong. It means that understanding these differences and the resulting risks is an essential prerequisite for being able to evaluate the capability of a development partner.
Overall, the evaluation of the capability and the selection of “best” suppliers become much more involved. The scope of technologies to be mastered has increased, the extended lifecycle requires new competences, as does the ability to thrive in a fast changing ecosystem that requires “instant” reaction – if not anticipation. This means the scope and the number of evaluations of development partners increase. For service providers, this means a considerable increase in the related costs. And it requires a significant expansion of required competencies. However, without this the satisfaction of the service’s end users cannot be guaranteed. Damaged reputation and direct or indirect warranty costs may be the result.
In a nutshell, this is no less than a fundamental change in the way companies will cooperate. A system-of-systems is no longer something that can be dominated by a single company and divided up hierarchically. The new paradigm brings new risks. These must be countered differently. What is needed are different cooperation models starting with the purchase (selection of partners, other contractual basis), connect to the development (agile cooperation work in the network), stretch into the area of operations (DevOps), and include quality assurance (assessment of partners).