Interfaces to traditional control systems are concrete and detailed, and therefore their operation is complex; one cannot operate such systems without detailed specific understanding, or what is called domain knowledge. There is often little overlap between different areas of domain knowledge.
My car has a complex control system built using the CAN protocol. I have no knowledge of that protocol. I operate the car using a much simpler abstract interface. The one on the right makes it go faster. The one on the left slows the car down. This dial says how fast it is going. That dial says how much fuel is left. By understanding this abstract high level interface, I can operate any car. My mechanic needs to know the control system – I do not.
Because the interface is abstract, it is discoverable. I can sit in my wife’s car, and in a few minutes understand the differences. The dials are slightly different. My car is manual and hers is automatic. Mine has a tachometer and hers does not. The interfaces support some diversity, but the diversity is within a small range so the details to operate each car can be discovered quickly by the driver.
When I am in the car, I become, in effect, the control system for the car. This system interacts the other driver-car systems using a simple abstract interface based on lights. I use abstract signals to indicate slowing and turning, and the other systems react as driven by the needs of their systems. By using a highly abstract interface, no a priori negotiations between drivers is required to coexist on the same systems bus, or “road”.
Before complex control systems are ready for the enterprise, they must hide their complexity and detailed domain knowledge behind an abstract interface. For that interface to be available to computer systems rather than to people, it must be formatted for machines rather than for people.
And that is what I mean by discoverable abstract interfaces.