Abstraction

If I were asked about the concept of abstraction, I would say that "abstraction is the reference for the existence of the division of responsibilities". The few words of this definition encapsulate a mountain of ideas that can have different interpretations when looked at by different angles, especially when viewed from within the concept of organization, and this is where we are going to explore.

Organization is a system made up of people coordinated in order to achieve a common objective, for this it is necessary that each individual has clarity of his role, therefore in an organization there is an internal customer-supplier relationship, and one of the things that is essential in this relationship is abstraction, abstraction when well implemented allows the customer (internal) to have a sufficiently ergonomic interface in such a way that they only have visibility of what is expected of the product and not the technical aspects behind it.

It is important to emphasize that it is not prohibited for customers to have technical visibility, it is just not supposed, since the people who occupy the position of customer in the customer-supplier relationship in the first tier are suppliers in the customer-supplier relationship in the second tier and so on, until the product reaches the final consumer (which is probably external to the organization). Therefore, instead of focusing on the supplier's technical issues, the customer should focus on technical aspects present in its own layer. it is clear that there is room for criticism about what is supplied, but these criticisms must be presented ideologically and not technically, since to present a review looking at technical aspects, it would be necessary to have details about the contents of the black box and for that to happen it would be necessary for the client to leave the scope of its responsibilities. In other words, I mean that when you are unhappy with the latency of an EC2, instead of trying to figure out the AWS implementation in order to find out the reason for the slowness, you are supposed to show AWS what you expect from the product in terms of latency, since your job is not to debug the AWS implementation, but to put applications running on top of EC2.

Depending on the software engineering segments, abstraction can bring with it standardization, this characteristic is the result of sharing the same interface with many customers, the standardization associated with the fact that the customer has the perception of a product as a black box, allows with countless changes being made behind the scenes without customers noticing.

Operating systems are the abstraction of a computer's hardware resources, programming languages are the abstraction of machine language, frameworks and libraries are abstractions of a set of instructions and algorithms, remote control is the abstraction of electrical circuits... all the abstractions mentioned have something in common, they provide security to their users. Yea! Security, this is one of the biggest advantages of abstraction, since when abstracting an interface is created, and it is through this interface that the customer communicates with the product, so the dimension of the interface defines the scope of the customer's actions within the product and it is in this limitation that security resides, since it allows the customer to be protected from details that he does not need to know.

As you know Inside any black box there is a set of complex actions that are executed in such a way as to achieve the product result, if these details are exposed in the interface, greater manipulation space is opened and consequently greater is the complexity, so customers would have more intellectual responsibilities to handle the box and in probabilistic terms greater would be the possibility of the customer passing wrong or contradictory configurations and everything ending up in tragedy. There is more chance of making catastrophic errors when the user is given the freedom to write 50 configurations compared to writing 5.

By creating an interface that does not isolate the implementation details, we are opening the door to the need for the client to be aware of what is happening inside the black box in such a way that it handles it successfully, that is, the successful handling of the black box is conditional on the client being aware of what is going on inside it, and that, gentlemen, depending on the situation, can be a problem.

Customers' tendency to obtain technical details related to the product usually expresses a deficiency in the quality of the interface, usually this happens when the interface does not expose the purpose of the product, but rather technical issues related to its implementation. 

Generally, when the interface is strongly linked to technical issues used in the construction of the product and not to the objective of the product, the change or migration to another technology results in a change in the interface. Therefore, it is necessary to ensure that there is a distance between the implementation and the interface.