[[Chapter 14]] describes that supervising the development of an [[API]] is a difficult task. First of all, a good API architect has to be like a Cassandra:

* always seeing possible failures
* always knowing what might go wrong in the future
* always proclaiming warnings of danger

Supervision is especially needed when
design is done in a group. The better the architect you are working with, the further into the
future the architect needs to be able to see. However, this creates a problem that makes the
task particularly tricky. People only take '''notice when something goes wrong''':

* when customers become upset by incompatibilities
* when they refuse to migrate to a new version
* when then switch to competitive offerings

However, if everything works as it should, then '''nothing happens''', and it’s difficult to present '''nothing''' as a big success. The situation is comparable to that of security agencies. Until a plane is hijacked and destroyed, nobody likes the work of security agents. People complain about the security checks at airports, which seem complicated and unnecessary.

Without a catastrophe, it all seems to be overkill. However, after the disaster it’s too late to fix anything.

==== Boosting up [[GraalVM]] Security ====

As such, [[I]] always glad for situations like [[FifthGraalAdventures#Designing for Security|the one]] during my fifth year at [[OracleLabs]]. When you can predict the future problems, address them and then a hacking attack proofs you were right, then you deserves to be the architect, I believe!