DEV Community: William Antonio Guzmán Bernal

Can AWS help us relive our childhood?

William Antonio Guzmán Bernal — Wed, 01 Oct 2025 08:44:06 +0000

I had the blessing to come from a family where love, support and affection came from my parents and siblings. I was always encouraged to do my best, and this increased my creativity through games. I grew up in Colombia during the 80s, and there was a game called “Estralandia”, which was quite similar in functionality to Lego figures. Dinosaurs, houses, helicopters, buildings... Everything I could think of, I tried to create with its red and white figures. My imagination was really the limit!

That’s why, when I was at an AWS event for the very first time, the following phrase struck me:

“Imagine that AWS is a big box of legos with which you can create things…..”

And it is a quote that I still agree with. AWS is a big box with a LOT of things that allow you to build EVERYTHING.

But perhaps due to stress, rush, or the day-to-day routine, you forget that these toys are not only designed to perform functions in companies, solve corporate problems, or optimize processes in industries. They should also entertain those who use them!

I guess that’s why Jeff Bezos once said:

“Work hard. Have fun. Make history”

So, how do I keep having fun with AWS? How can I continue to marvel at the huge possibilities it allows? When I tried to answer these questions, I recalled my childhood and one of the activities I most enjoyed: creating things with my Estralandia.

Immediately a new question arose: would it be possible that ‘Adult Me’ play together and have fun building stuff in AWW with ‘Inner Child Me’? Even better, how could a person over 40 years old explain to a child under 10 years old, concepts that sometimes seem so complex and unwieldy for an adult?

¡Let’s give it a try!

The first thing would be to tell him that in AWS we are going to work on a surface, and that this surface (despite the fact that we are going to do it on the floor) can be called ‘cloud’. In order to better explain the picture I’m trying to paint, I am going to use the LeoCAD software (https://www.leocad.org/):

Then I would tell him that we would have to put up a ‘security fence’ so that our creations would not be invaded or attacked from the outside. We could do this with a barrier around what we are building.

At that moment I would say that by having ‘fenced’ our cloud, we have made it private, either for our exclusive use or to give permission to those we want to access it.

From here I can also explain that this functionality is not just for us, but we can also invite other children to play. By putting their figurines in our ‘virtual private cloud’ (as long as we allow it —thus introducing myself to the term ‘VPC’). We could put up a figurine in charge of letting more figurines (people) in, or not.

This figurine would be responsible to confirm whether someone has a ‘username and password’ (this is especially meaningful to me because I used to love the show “Mission Impossible”). Then we can call this “combination of Username and Password” Identity, because they are precisely going to allow us to identify that person.

Whoever wants to enter our VPC must first have a username and password we give them. After this, an ‘entry authentication’ to our VPC would be carried out. Also we can decide what allowances we give them, giving them ‘authorization’ within our VPC and restricting them to others. This way, if someone wanted to enter our cloud the first thing that they would find would be our gatekeeper, our “Identity and Access Manager” (IAM for short):

When our little friend IAM allows the user to enter, we can encounter the following scenarios:

First scenario they can be a little ‘frustrated’, scratching their faces and saying:

“How stingy! Nothing else will fits in there!”

At this point, I would explain that the cloud can grow as much as we want. We could occupy the entire floor of the living room, plus the dining room, plus my parents’ bedroom, my siblings… And so. As much space as we would like to occupy! Or on the contrary, if we do not want to occupy the entire floor of the house, we could play with very few pieces. I would explain that this is one of the many advantages of the cloud, that we are able to ‘scale’ according to our needs.

I would tell them that since we are not the only ones in the world playing with these tiles, there could be discounts on the tile prices for the number of children playing, and that this is called ‘economy of scale’.

In my childhood I did not like mathematics very much. So then I would choose a tile that represents a calculator, so that I can perform basic functions (add, subtract, multiply and divide integers). And to confirm that these operations needed to be done quickly, we could use a rabbit to represent these functions. We can call this rabbit the “Lambda Function”, and it would allow us to use the calculator only when we need it. As long as it’s not running, this calculator isn’t going to consume any battery (or money).

Once again, our IAM gatekeeper would be in charge of allowing a visiting figurine to reach our Lambda function.

As a child I liked to read a lot (before I was 10 years old I had already read “The Bible” for the first time). I could spend whole afternoons reading books, with a lot of information in them, and therefore being able to find something was sometimes a real feat (at that time the Internet was not even a thought!)

With that in mind, I would take the opportunity to explain the concept of being able to store information, to control it, to control who can access it, or how quickly and easily a piece of information can be found. This could be the perfect opportunity to introduce the concept of ‘databases’ and, considering that I really liked dogs, I would use this animal figurine to represent how I could find information, just as a dog would find a bone to play with.

To review everything thus far, let’s start with 2 figurines that would represent the people who want to use our ‘virtual private cloud’. First they’ll encounter the entry rules, and can only go to the parts of the cloud that we have allowed them to.

Something to keep in mind is the importance of knowing who is doing what and where. Having that ‘ability to record’ (groups of logs) what happens in our cloud is vital. For that purpose we could have a ‘little notebook’ on the important points.

These records (or logs) could go to a single central point throughout our cloud, so that our ‘watchman’ could have a broader viewpoint of our entire system. We are going to call this watchman (represented by an owl) “CloudWatch”, and we can ask him for each event that has happened and that has been registered in our cloud.

Finally, I would keep in mind that some of the figurines could potentially have associated cost. Typically, the figurines would only incur a cost for as long as they are used (‘on demand’). All these values should also be centralized in a single point of billing and costs, which we can call “Billing and Cost Management”.

It would be great if, at the end of playing, my ‘Current Self’ asked my ‘Child Self’:

“Did you like the game? What do you think of AWS? Would you like to keep playing with AWS and keep building and learning more?”

I think that last question applies consistently to all of us who are currently developing solutions with Amazon Web Services.

Can some Biblical Principles be applied in the Amazon Leadership Principles?

William Antonio Guzmán Bernal — Tue, 30 Sep 2025 15:38:19 +0000

Next, I present an exclusively personal analysis.

I believe in God as my Lord and my Heavenly Father. I believe in Jesus as my Savior and Teacher. And I believe in the Holy Spirit as my Guide and Counselor. I have seen how the Word of God has manifested itself in a powerful way in different aspects of my life. And as an IT Professional, I have been curious to know if the lessons offered by “The Bible” also have a place in my profession.

I wasn’t surprised to confirm it does.
To begin my analysis, I checked the “Leadership Principles” of Amazon, precisely because Amazon Web Services is the Leader in Cloud Computing, an area that I wanted to analyze.

https://www.amazon.jobs/content/en/our-workplace/leadership-principles

The first of these principles is “Customer Obsession”, which establishes that:

“Leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.”

This reminded me of when Jesus was somehow questioned about the commandments in the law (Matthew 22:35–40):

“One of them, an expert in the law, tested him with this question: Teacher, which is the greatest commandment in the Law? Jesus replied: ‘Love the Lord your God with all your heart and with all your soul and with all your mind.’ This is the first and greatest commandment. And the second is like it: ‘Love your neighbour as yourself.’ All the Law and the Prophets hang on these two commandments.”

I want to emphasize “Love your neighbor as yourself”, since a client is a person or group of people who put their trust in us when they express their concerns or needs for Cloud Computing related projects. The Bible reminds us on several occasions of the value of trust, one of them being in Proverbs 3:29:

“Do not plot harm against your neighbor, who lives trustfully near you.”

For this reason, it is our responsibility to take the concerns or needs of our clients as if they were our own, and give them the priority and importance they deserve.

In this same ‘thinking methodology’ about our clients as if they were ourselves, we find a benefit of cloud computing: “Cost savings”.

“The cloud allows you to trade fixed expenses (such as data centers and physical servers) for variable expenses, and only pay for IT as you consume it. Plus, the variable expenses are much lower than what you would pay to do it yourself because of the economies of scale.”

https://aws.amazon.com/what-is-cloud-computing/

This benefit should be present in any solution to be implemented in the AWS Cloud. Not surprisingly, Amazon Web Services dedicates an entire pillar within its Well-Architected Framework (AWS Well-Architected Framework, https://aws.amazon.com/architecture/well-architected) to Cost Optimization:

https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html

So far in my mind I had an idea similar to this:

In order to protect the interests of our clients and meet their needs, it is important to keep in constant learning and training. Almost every day new services are being created or new features are added to existing services on AWS. Trying to know each and every one of them can be a exhausting task, but one way to be aware (at least) of these news is to consult the official AWS blog page:

https://aws.amazon.com/blogs/

and once in that website, select the topics that attract you the most or represent a greater individual interest. In my case I recommend at least the blogs of:

Architecture:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23architecture

AWS Cloud Financial Management:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23aws-cloud-financial-management

AWS Well-Architected:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23aws-well-architected

Analytics:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23analytics

Big Data:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23big-data

Developer Tools:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23developer-tools

Management & Governance:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23management-tools

Security, Identity, & Compliance:

https://aws.amazon.com/blogs/?&awsf.blog-master-category=category%23security-identity-compliance

Regardless of the strategy or tool used, it is important to apply the “Learn and Be Curious” Leadership principle, which states that:

“Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.”

In this sense, The Bible gives us (once again) several verses where it supports us and invites us to learn and acquire intelligence and wisdom. One of them is found in Proverbs 12:1:

“Whoever loves discipline loves knowledge, whoever hates correction is stupid.”

Fortunately, learning doesn’t necessarily have to be restricted to just one pillar of the AWS Well-Architect framework. It can be applied to all 6 pillars, including the remaining 5:

Operational Excellence:

https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html

Security:

https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

Reliability:

https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html

Performance Efficiency:

https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/welcome.html

Sustainability:

https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html

So now in my mind the ‘scheme’ was modified as follows:

Another leadership principle at Amazon invites us to support the growth of the members of our team. It takes quite an ‘altruistic’ spirit to understand that this may even mean that such growth is present in other areas of the company. I’m referring to the “Hire and Develop the Best” principle, which establishes that:

“Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent, and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.”

I find this principle quite interesting, since it allows a ‘mentorship’ environment that is established almost as company policy. It is about understanding that not everyone have the same learning process, and we all rerequire ‘training’ in order to develop personally and professionally in the company. And if this learning involves from the beginning the design principles in each of the pillars of the AWS Well-Architected Framework, the person will be able to assimilate them more easily and incorporate them into their daily performance.

It is also interesting to see how within the learning that exists between ‘Teacher — Student’ the 2 previous principles can and should be incorporated (“Customer Obsession” and “Learn and Be Curious”).

For this statement we could take as biblical support the verse found in Proverbs 22:6:

“Start children off on the way they should go, and even when they are old they will not turn from it.”

Including this 3rd principle, my ‘mental map’ was modified:

I try in my daily activities to remember that beyond doing them for a person, I am doing them for God, applying what Colossians 3:23 teaches:

“Whatever you do, work at it with all your heart, as working for the Lord, not for human masters,”

It doesn’t mean that perfection is achieved (since only God is perfect), but as Vince Lombardi, American United States Football coach, said:

“Perfection is not attainable, but if we chase perfection, we can catch excellence”

And it is precisely this ‘pursuit of excellence’ that Amazon’s leadership principle “Insist on the Highest Standards” is about:

“Leaders have relentlessly high standards — many people may think these standards are unreasonably high. Leaders are continually raising the bar and drive their teams to deliver high quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.”

Again, this foundation should be instilled in people who are beginning to walk through the Amazon Leadership Principles.

For this first analysis, my resulting schema is as follows:

I hope in future opportunities to continue the analysis of the Amazon Leadership Principles, and their possible correlation with some Biblical Principles.

Data Governance… when there's no Data nor Governance

William Antonio Guzmán Bernal — Mon, 06 Jan 2025 20:37:19 +0000

In 2006, during the Association of National Advertisers Conference, the following phrase was used for the first time: "Data is the new oil (Clive Humby)"


Data is the new oil (Clive Humby)

It was the Mathematician and Data Scientist Clive Humby who 'coined' this phrase to express that both data and oil share key points (Data as The New Oil Is Not Enough: Four Principles For Avoiding Data Fires) among them, high value (which gives companies significant competitive advantages), serves as raw material (which must be processed and analyzed), drives growth (helps the digital revolution), has the gift of ubiquity (being crucial in several industries) and, last but not least, represents risks and considerations (privacy, security, monopolization, among others)..

In an ideal scenario, we could assume that companies are just starting their data projects and we can propose everything from scratch, following the Best Practices available. But what to do when they already have data and there are already projects underway? It could even happen that they do not have visibility over all the data and information they are generating, and therefore, they do not have adequate management to access this data.

They probably require our support in order to get the most out of them, in the most cost-efficient way possible, and with constant optimization. With this objective in mind, a first step would be to identify what type of industry or vertical they belong to. To make this classification, we could remember that each company starts with one or several inputs, which may or may not undergo processes to generate products that will ultimately be purchased by customers or end users. With these elements in common, we could classify companies into the following categories: (Manufacturing Supply Chains Explained | NetSuite): Products / Services, Suppliers and Vendors, Raw Materials, Production, Storage and Warehousing, Distribution / Transportation, Retailers, Maintenance and Repair, or Recycling.

At this point, we should be able to clearly identify which industry or vertical the company we want to support belongs to. The next step is to confirm whether the company has full visibility of its data. In other words, does the company know what data it has, what it needs to monitor, and what it should be leveraging? To address these concerns, we could look for data in reports, dashboards, metrics, Key Performance Indicators (KPIs), notifications/alerts, and corporate objectives.

Our first point of contact could be the stakeholders or BI analysts within the company. Why them? Because they are usually the ones who have access to the already processed data, they are the ones who make the decisions or support those who make them, so that everything is as informed as possible.

In some cases, this data access is done through BI tools (such as Amazon QuickSight) or through SQL queries (using services such as Amazon Athena).


Data Consumption Reference Architecture

But we can't just ask them, as such a conversation wouldn't be the most 'friendly' at the time. As consultants we should avoid conversations like this:

Consultant: What dashboards do we have?
BI Analyst/Stakeholder: Why? What do you need?

Remember that we cannot find the right answers if we ask the wrong questions. Instead of having the above conversation, we could have this conversation:

Consultant: I would like to help improve/optimize our processes. Where can I find information to get started? Especially related to the data we collect/process. Where should I look first?
BI Analyst/Stakeholder:
a) You should ask …
b) You can't, because for that you would have to belong to the team/area of…
c) You need authorization from…
d) You can check our Intranet, check this page….
Consultant: Ok, thank you very much.

We start with a friendly approach, we put ourselves in the person's shoes. We know that we are doing something for the good of the company, but we do not want to be seen as a risk or danger to anyone. In some circumstances or companies, when someone asks this type of question it could generate distrust and we need to earn the trust of the work team. In addition, following the last example, the BI analyst or stakeholder could be guiding us (in a natural and fluid way) to one or several sponsors that we require for our work.

In other cases, the answers to this first conversation could lead us directly to the Potential Owner(s) of the Existing Data, which could be IT, Support or Maintenance Personnel. We could ask them what Protocols or Compliance are already implemented in the company, if there is a User Profiling, or even if they have a Cloud Center of Excellence. (AWS Cloud Center of Excellence, The CCoE tenets - AWS Prescriptive Guidance).

At this point it would be important to pause. What would happen if someone asked you NOT to think about a red box?

VERY likely the first thing that will come to mind is precisely the red box. This is because our brain reacts differently to a negative response than you would think. (How Does “Not” Affect What We Understand? Scientists Find Negation Mitigates Our Interpretation of Phrases). By telling someone “NOT to think about a red box,” the brain is actually mitigating that thought, rather than reversing it. In other words, our brain would think about a red box, only smaller. For this reason, it is important to be careful about our communication with other people (“Don’t think about the costs…” vs. “Think about the benefits…”) and even with ourselves (“I am going to learn/start/do…” vs. “I am learning/starting/doing…”).

We can start to guess that we are going to have quite a few interactions with the client's team. So, let's get ready for meetings!

Some points to consider when having meetings:

Listen to understand, not to respond. Also, listen with your eyes (establish and maintain respectful eye contact).
Take notes (this can be on sheets of paper), but do not take dictation, i.e. do not type on a keyboard, as this can sometimes cause distractions and give the client the feeling that they are not being listened to properly. In this regard, it is best to ask for permission to record the meeting.
Get as much context as possible before starting the meeting (who the client is, what they are about, what their products or services are, their potential competitors…)
During the course of the meeting, identify whether the meeting attendees have an administrative, commercial/sales, or technical/development profile (or even a combination of these).
For each of the attendees, also identify knowledge of the project, business, needs or requirements; clarity of objectives; technical level
BANT (Budget, Authority, Needs, Timing)

where we can have:

Who = Ejecutivos C-Level; Product Owners; Project Managers; Business Analysts; External Dependencies; Sales Representatives; Developers; Designers; Architects
Why = Company-level goals (H1, H2, Q1…); Optimization, Automation, or Improvements; Success Criteria; Metrics or KPIs; SLAs

If we have the “Who” and the “Why”, organically we will obtain the “What” for each one of the participants. The “How” will come later.

One mistake to avoid when trying to identify data (and its corresponding governance) is to postpone contact with the purely technical team. This could create a ‘resistance or refusal’ to collaborate in our purpose of analyzing data that may require more detailed control. For this reason, it is important to involve the IT team in charge of observability, maintenance, access and security of the platform we are analyzing. Some of the services that the IT team may be using in their tasks in AWS may be IAM, CloudWatch, EventBridge and SNS.


Reference Architecture IT Team

If we want to find out what data may be being overlooked, we should answer these questions: Are there standard metrics in that industry? KPIs? And for this point we can rely on institutions, organizations, best practices of each industry, among others. Some examples could be, depending on the industry:

Financial (15 Essential Financial Metrics for Advisors, Consultants, and Investors)
Healthcare (30 Healthcare KPIs & Metrics To Start Tracking Today)
Software (7 SaaS Metrics Every SaaS Company Should Care About)
Security (18 Data Security Metrics & KPIs You Need To Track)

The goal is to find out which metrics are not being considered by the client.

Before you start ‘touching the data’, it is worth asking yourself the following questions related to Security (a topic that should be included from the ‘initial moment’). Investigate whether there are security protocols and, if they do not exist, propose one based on:

What data is handled in the organization?
Why does this data exist?
Who owns the data? Who should own it?
Who needs access to what data?
Who should authorize that access?
How long should this access be granted?
How should this access be authorized (email, ticket...)?
Where should the data be stored?
Are there compliance laws or regulations applied to that data (local, national or global)?
What are the actions to be taken in the event of a data leak or breach?
Are there data backup or retention policies?

This is an excellent time to create a flow chart of the lifecycle of that data explaining the protocol created, and organize meetings to inform the appropriate people. Again, involving people in data governance management gives them the proper treatment of respect and consideration in the decisions to be made.

Once this ‘draft data security protocol’ has been drawn up, the analysis of the data flow (from right to left) can continue.


Reference Architecture Security

It is always good to remember that, like any architecture to be deployed in AWS, it should be guided by the Key Concepts, Design Principles and Architecture Best Practices contained in the AWS Well-Architected Framework, which includes the following pillars:

Operational excellence
Security
Reliability
Performance efficiency
Cost optimization
Sustainability

At this point we can introduce the concept of Governance (Management and Governance on AWS) como “the ability to implement executive board policies that your AWS cloud environment must comply with” (Guidance for Governance on AWS). The power of AWS is that this concept is not 'bound' or 'restricted' to a particular point or area, but can be applied “across the AWS ecosystem, including accounts, infrastructure, and environments owned and operated in the AWS Cloud” (Cloud Governance).


Reference Architecture Governance

Now it’s time to give the ‘official welcome’ to the Technical and Development Area!

Let's remember that we must preserve the essence of teamwork:

stakeholders,
IT team,
security,
governance
and now, development

By understanding who each of these areas is, and why they should be involved in data governance, we can understand what each area really does and then analyze the best way to actively involve them in generating Data Governance.

Ask in each area how they are now. (“As Is”), if there are differences with respect to the goals that should have already been met at that time (“To Be”), and how they think they should be (“Should Be”).

This analysis will probably lead to definitions of technology stacks, dependencies (both internal and external), possible automations, documentation protocols and testing. Remember that “Documentation is a love letter that you write to your future selves.”.

Also keep in mind this simple 'formula':

Monitoring + Alerts + Responses = Sleep Well

This goes hand in hand with confirming whether there are disaster recovery plans.

Also confirming whether there are corporate standards for coding, Best Practices to follow, patterns; whether internal talks are held to share knowledge (chapters).

If at any point we find that something is missing to implement or create, if possible propose it. To summarize in one sentence:

Be discreetly disruptive!

Continuing with our analysis from ‘right to left’, we could now ask ourselves this question: where are we going to get (or are we already getting) our data from?

For this, there is a set of representative AWS services to take data from different sources, which could be ‘cataloged’ in a data ingestion layer.


Reference Architecture - Data Ingestion

Let's look at which of these services (or similar ones) are currently in use, which data sources they are connected to, and which data is NOT being brought to consumption by stakeholders or IT. We may be looking at useful, unused data.

When we find this 'orphaned' data (it is being ingested but does not have a 'parent' in the consumption area), we can find ourselves in the last layer we are going to review: the data processing area.


Reference Architecture - Data Processing

If we wanted to summarize the mental process for generating data governance in companies that do not currently have it, involving data that may have gone unnoticed until now, we could say that we need to identify:

data
stakeholders
BI components

already existing, to then propose:

missing BI components
required protocols
automation / optimization

In the course of this analysis, the most important thing is to always remember that we are dealing with a human factor, susceptible to errors, feelings, personal and group objectives. With the best possible intention and will, always have empathy for each and every person who gives us their time, experience and advice to achieve building an effective and useful Data Governance for the company.

Gobierno de Datos… cuando no hay Gobierno ni Datos

William Antonio Guzmán Bernal — Mon, 06 Jan 2025 16:28:12 +0000

En el año 2006 durante la Conferencia de la Asociación Nacional de Anunciantes se utilizó por primera vez la frase: "Los Datos son el nuevo Petróleo (Clive Humby)"


Los Datos son el nuevo Petróleo (Clive Humby)

Fue el Matemático y Científico de Datos Clive Humby quien ‘acuñó’ esta frase para expresar que tanto los datos como el petróleo comparten puntos clave (Data as The New Oil Is Not Enough: Four Principles For Avoiding Data Fires) entre ellos un alto valor (que le otorga a las empresas ventajas competitivas significativas), sirven de materia prima (la cual debe ser procesada y analizada), impulsa el crecimiento (ayuda a la revolución digital), tiene el don de la ubicuidad (al ser crucial en varias industrias) y, finalmente pero no menos importante, representa riesgos y consideraciones (privacidad, seguridad, monopolización, entre otros).

En un escenario ideal podríamos suponer que las empresas están comenzando sus proyectos de datos y se puede proponer todo desde cero, siguiendo las mejores prácticas disponibles. Pero, ¿qué hacer cuando ya tienen datos y ya existen proyectos en curso? Incluso podría suceder que no tengan visibilidad sobre todos los datos e información que estén generando, y por ende, tampoco tengan una administración adecuada para acceder a estos datos.

Probablemente requieran de nuestro apoyo para poder obtener el mayor provecho de ellos, de la manera más eficiente posible en costos, y con una optimización constante. Con este objetivo en mente, un primer paso sería identificar a qué tipo de industria o vertical pertenece. Para hacer esta clasificación podríamos recordar que cada empresa comienza con uno o varios insumos, los cuales pueden o no someterse a procesos para generar productos que finalmente serán adquiridos por los clientes o usuarios finales. Con estos elementos en común, podríamos clasificar las empresas en las siguientes categorías (Manufacturing Supply Chains Explained | NetSuite): Productos/servicios, Proveedores y vendedores, Materias primas, Producción, Almacenamiento y depósito, Distribución / Transporte, Minoristas, Mantenimiento y reparación, o Reciclaje.

En este punto deberíamos poder identificar con claridad a qué industria o vertical pertenece la empresa que deseamos apoyar. El siguiente paso es confirmar si dicha empresa tiene visibilidad completa de sus datos. En otras palabras, ¿la empresa sabe qué datos tiene, cuáles le falta supervisar, y cuáles debería estar aprovechando? Para resolver estas inquietudes podríamos buscar datos en informes, dashboards, métricas, Indicadores Clave de Rendimiento (KPI), notificaciones/alertas, y objetivos corporativos.

Nuestro primer punto de contacto podrían ser los stakeholders o analistas BI dentro de la empresa. ¿Por qué ellos? Porque por lo general son ellos quienes tienen acceso a los datos ya procesados, son los que toman las decisiones o apoyan a quienes las toman, para que todo sea de la manera más informada posible.

En algunos casos este acceso a los datos se realiza a través de herramientas BI (como por ejemplo, Amazon QuickSight) o por consultas SQL (utilizando servicios como Amazon Athena).


Arquitectura Referencial de Consumo de Datos

Pero no podemos llegar simplemente a preguntarles, ya que dicha conversación no sería la más ‘amigable’ en un momento. Como consultores deberíamos evitar conversaciones como esta:

Consultor: ¿Qué dashboards tenemos?
Analista BI/Stakeholder: ¿Por qué? ¿Qué necesita?

Recordemos que no podemos encontrar las respuestas correctas si hacemos las preguntas equivocadas. En vez de tener la anterior conversación, podríamos seguir esta charla:

Consultor: Me gustaría ayudar a mejorar/optimizar nuestros procesos. ¿Dónde puedo encontrar información para comenzar? Especialmente la relacionada con los datos que recopilamos/procesamos. ¿Dónde debería revisar primero?
Analista BI/Stakeholder:
a) Usted debería preguntarle a …..
b) No puede, porque para eso usted debería pertenecer al equipo/área de…
c) Necesita autorización de…
d) Puede revisar en nuestra Intranet, revise en esta página….
Consultor: Listo, muchas gracias.

Comenzamos con un enfoque amigable, ‘nos ponemos en los zapatos’ de la persona, sabemos que estamos haciendo algo en bien de la empresa, pero no queremos que nos vean como un riesgo o peligro para nadie. En algunas circunstancias o empresas, cuando alguien hace este tipo de preguntas podría generar desconfianza y precisamente necesitamos ganarnos sinceramente la confiabilidad del equipo de trabajo. Además, siguiendo el último ejemplo el analista BI o stakeholder nos podría estar guiando (de manera natural y fluida) a uno o varios sponsors que requerimos para nuestras labores.

En otros casos, las respuestas a esta primera conversación podrían llevarnos directamente a los Propietario(s) Potencial(es) de los Datos ya Existentes, pudiendo ser el Personal de TI, Soporte o Mantenimiento. A ellos podríamos preguntarles cuáles Protocolos o Compliance ya se tienen implementados en la empresa, si existe un Perfilamiento de Usuarios, o incluso si tienen un Centro de Excelencia en la Nube (AWS Cloud Center of Excellence, Los principios del CoE - AWS Guía prescriptiva).

En este momento sería importante hacer una pausa. ¿Qué pasaría si alguien les pide que NO piensen en un cuadro rojo?

MUY probablemente lo primero que llegará a la mente es, precisamente, el cuadro rojo. Esto debido a que nuestro cerebro ante una negativa reacciona de manera diferente a lo que se pensaría (How Does “Not” Affect What We Understand? Scientists Find Negation Mitigates Our Interpretation of Phrases). Al decirle a alguien “que NO piense en un cuadro rojo”, el cerebro lo que hace es mitigar ese pensamiento, más que invertirlo. Dicho de otra forma, nuestro cerebro pensaría en un cuadro rojo, solo que más pequeño. Por esta razón es importante cuidar nuestra comunicación con otras personas (“No piense en los costos…” vs “Piense en las ventajas…”) e incluso con nosotros mismos (“Voy a aprender / comenzar / hacer…” vs “Estoy aprendiendo / comenzando / haciendo…”).

Podríamos comenzar a deducir que vamos a tener bastantes interacciones con el equipo de trabajo del cliente. Es decir, ¡preparémonos para reuniones!

Algunos puntos a considerar al momento de tener reuniones:

Escuchar para entender, no para contestar. Además de ‘escuchar con los ojos’ (establecer y mantener un respetuoso contacto visual).
Tomar notas (puede ser en hojas de papel), pero no tomar ‘dictados’, es decir, no escribir en teclado ya que esto en algunos momentos puede generar distracciones y dar la sensación al cliente de que no se le está escuchando apropiadamente. En este sentido es mejor pedir autorización para grabar la reunión.
Obtener tanto contexto como sea posible antes de comenzar la reunión (quién es el cliente, de qué trata, cuáles son sus productos o servicios, sus posibles competidores…)
En el transcurso de la reunión identificar si los asistentes de la reunión son de perfil administrativo, comercial/ventas, o técnico/desarrollo (o incluso, una combinación entre ellos).
Para cada uno de los asistentes identificar también conocimiento del proyecto, negocio, necesidades o requerimientos; claridad en objetivos; nivel técnico
BANT (Budget, Authority, Needs, Timing)

en donde podemos tener:

Quién = Ejecutivos C-Level; Product Owners; Project Managers; Business Analysts; Dependencias Externas; Representantes de Ventas; Desarrolladores; Diseñadores; Arquitectos
Por qué = Metas a nivel de compañía (H1, H2, Q1…); Optimización, Automatización, o Mejoras; Criterios de Éxito; Métricas o KPIs; SLAs

Si tenemos el “Quién” y el “Por qué”, de forma orgánica obtendremos el “Qué” para cada uno de los participantes. El “Cómo” vendrá más adelante.

Un error que se debe evitar al intentar identificar los datos (y su correspondiente gobierno) es postergar el contacto con el equipo netamente técnico. Esto podría crear una ‘resistencia o rechazo’ a colaborar en nuestro propósito de analizar los datos que pueden requerir un control más detallado. Por esto es importante involucrar al equipo de TI encargado de la observabilidad, mantenimiento, acceso y seguridad de la plataforma que estamos analizando. Algunos de los servicios que el equipo TI puede estar usando en sus tareas en AWS pueden ser IAM, CloudWatch, EventBridge y SNS.


Arquitectura Referencial Equipo TI

Si queremos descubrir qué datos pueden estar pasándose por alto, deberíamos dar respuesta a estas preguntas: ¿Existen métricas estándares en esa industria? ¿KPIs? Y para este punto podemos apoyarnos en instituciones, organizaciones, mejores prácticas de cada industria, entre otros. Algunos ejemplos pueden ser, según la industria:

Financiera (15 Essential Financial Metrics for Advisors, Consultants, and Investors)
Ciencias de la Salud (30 Healthcare KPIs & Metrics To Start Tracking Today)
Software (7 SaaS Metrics Every SaaS Company Should Care About)
Seguridad (18 Data Security Metrics & KPIs You Need To Track)

La meta es encontrar cuáles métricas no están siendo consideradas por el cliente.

Antes de comenzar a ‘tocar los datos’, vale la pena plantearse las siguientes preguntas relacionadas con la Seguridad (un tema que debería incluirse desde el ‘momento inicial’). Investigar si existen protocolos de seguridad y, en caso de que no existan, proponer uno en función de:

¿Qué datos se manipulan en la organización?
¿Por qué existen estos datos?
¿Quién es el propietario de los datos? ¿Quién debería ser su propietario?
¿Quién necesita acceder a qué datos?
¿Quién debería autorizar ese acceso?
¿Por cuánto tiempo se debe conceder este acceso?
¿Cómo se debe autorizar este acceso (correo electrónico, ticket...)?
¿Dónde se deben almacenar los datos?
¿Existen leyes de cumplimiento o regulaciones aplicadas a esos datos (locales, nacionales o mundiales)?
¿Cuáles son las acciones a tomar en caso de fuga o violación de datos?
¿Existen políticas de copia de seguridad o retención de datos?

Este es un excelente momento para crear un diagrama de flujo del ciclo de vida de esos datos explicando el protocolo creado, y organizar reuniones para informar a las personas adecuadas. De nuevo, el involucrar a las personas en la gestión del gobierno de datos les da el tratamiento adecuado de respeto y consideración en las decisiones a tomar.

Una vez elaborado este ‘borrador de protocolo de seguridad en datos’, se puede continuar el análisis del flujo de los datos (de derecha a izquierda).


Arquitectura Referencial Seguridad

Siempre es bueno recordar que, como toda arquitectura a ser desplegada en AWS, debería ser guiada por los Conceptos Clave, Principios de Diseño y Mejores Prácticas de Arquitectura contenidos en el Marco de AWS Well-Architected, el cual incluye los siguientes pilares:

Excelencia operativa
Seguridad
Fiabilidad
Eficiencia del rendimiento
Optimización de costos
Sostenibilidad

En este punto podemos introducir el concepto de Gobernanza (Management and Governance on AWS) como “la capacidad de implementar políticas de la junta ejecutiva que su entorno de nube de AWS debe cumplir” (Guidance for Governance on AWS). El poder que tiene AWS es que este concepto no queda ‘sujeto’ o ‘restringido’ a un punto o área en particular, sino que se puede aplicar “en todo el ecosistema de AWS, incluyendo cuentas, infraestructura y entornos que se posean y operen en la nube de AWS” (Cloud Governance).


Arquitectura Referencial Gobernanza

¡Ahora es momento de darle la ‘bienvenida oficial’ al Área Técnica y Desarrollo!

Recordemos que debemos conservar la esencia del trabajo en equipo:

stakeholders,
equipo TI,
seguridad,
gobierno
y ahora, desarrollo

Si entendemos quién es cada una de estas áreas, y por qué debería involucrarse en el gobierno de datos, podremos entender qué realmente le compete a cada área y, posteriormente, analizar la mejor forma de involucrarlos activamente en la generación del Gobierno de Datos.

Preguntar en cada área cómo se encuentran ahora (“As Is”), si existen diferencias con respecto a las metas que deberían tener ya cumplidas en ese instante (“To Be”), y cómo consideran que deberían estar (“Should Be”).

Probablemente en este análisis surjan las definiciones de stacks de tecnología, dependencias (tanto internas como externas), posibles automatizaciones, protocolos de documentación y pruebas. Recordar que “la Documentación es una carta de amor que ustedes escriben a sus futuros ustedes”.

Además tener presente esta sencilla ‘fórmula’:

Monitoreo + Alertas + Respuestas = Dormir bien

Esto va de la mano de confirmar si existen planes de recuperación ante desastres.

También confirmar si existen estándares corporativos para codificación, Mejores Prácticas a seguir, patrones; si se realizan charlas internas para compartir conocimientos (chapters).

Si en algún punto nos encontramos con que falta algo por implementar o crear, en lo posible proponerlo. Para resumir en una frase:

¡Sean disimuladamente disruptivos!

Siguiendo con nuestro análisis ‘de derecha a izquierda’, ahora bien podríamos plantearnos esta pregunta: ¿de dónde vamos a obtener (o ya estamos obteniendo) nuestros datos?

Para esto existe un conjunto de servicios de AWS representativos para tomar datos desde diferentes orígenes, los cuales podrían ‘catalogarse’ en una capa de ingesta de datos.


Arquitectura Referencial - Ingesta de Datos

Busquemos cuáles de estos servicios (o similares) se encuentran actualmente en uso, cuáles son los orígenes de datos a los que están conectados, y cuáles datos NO se están llevando hasta el consumo de los stakeholders o el equipo TI. Quizás estemos presenciando datos útiles no utilizados.

Cuando encontremos estos datos ‘huérfanos’ (se están ingestando pero no tienen un ‘padre o madre’ en el área de consumo), nos podremos encontrar con la última capa que vamos a revisar: el área de procesamiento de datos.


Arquitectura Referencial - Procesamiento de Datos

Si quisiéramos resumir el proceso mental para generar un gobierno de datos en empresas donde no lo tengan actualmente, involucrando datos que quizás hayan pasado desapercibidos hasta el momento, podríamos decir que necesitamos identificar:

datos
stakeholders
componentes BI

ya existentes, para posteriormente proponer:

componentes BI faltantes
protocolos requeridos
automatización / optimización

En el transcurso de este análisis lo más importante es recordar siempre que se está tratando con un factor humano, susceptible a errores, sentimientos, objetivos propios y grupales. Con la mejor intención y voluntad posibles, siempre tener una empatía por todas y cada una de las personas que nos proporcionen su tiempo, experiencia y consejos para lograr construir un Gobierno de Datos eficaz y útil para la empresa.