Hello everyone, my name is Douglas Dourado and this is my first article on Tech Writers. I will discuss my learnings in my career as a Business Analyst. To be able to elucidate this issue, I first need to go back in time a little. I joined the company Softplan in May 2013 to participate in the Puma Project of our client Court of Justice of the State of São Paulo (TJSP), more specifically for digital Second Instance processes. This project was extremely important for our client because, with it, processes that were time-consuming were optimized day by day for both the employees and all the other people involved during that period. I started my career as a Systems Analyst and, during that time, with the help of several people involved in my professional cycle, I managed to absorb many things until I reached where I am today, working as a Business Analyst. This article will provide some tips from those who have already walked the path and will be interesting for anyone looking to pursue a career in the product area. In all these years, I highlight 3 important skills that I learned and that I consider important pillars for anyone who wants to pursue this career. They are: Resilience, Communication between Teams and Synergy with the customer. Essential skills for a Business Analyst Resilience According to the virtual dictionary, the term Resilience can be briefly defined as: the ability to face and overcome adversity. Throughout your career, some adversities may appear, but resilience helps us to navigate events, learn from them and have more peace of mind and confidence to take the next steps. Therefore, learn to recalculate the route, reorganize and move on. Communication between teams Communication between teams is also very important. This is because, to be at a safe level, we depend on other teams and people. As the late Chacrinha would say: “Those who don’t communicate, get confused”. At times in this role you will need to forward demands, negotiate and conduct meetings with clients and staff. Learn assertive communication techniques, storytelling, try to be clear and objective, adapting your communication to each listener, if your client is formal, adapt. If the environment requires more technical terms, use them or even the opposite: learn to explain complex scenarios with simple words and examples. But remember that the first step to good communication is knowing how to listen and understand the other person's needs. Synergy with the client There are different formats and workflows within the role of Business Analyst, including here at Softplan. In the project I joined, the Business Analyst has direct contact with the client at times, for example, to map requirements and needs. If this is your case, try to follow these tips: I always made sure to absorb as much information as possible from what users had to say in order to analyze the scenario. Focusing on your client, understanding their needs, asking appropriate questions and having a dynamic vision is essential. Don't leave a meeting with doubts, be clear about what you need to deliver to that client, this is essential for quality delivery. Do you want to pursue a career as a Business Analyst? Therefore, for those of you who want to pursue a career in the Business Analyst field, seek to develop resilience, communication and customer focus skills. These skills are essential pillars that I have learned throughout my career and use daily.

When it comes to the discipline of architecture in software development, we come across several types of architecture. Each one, with its characteristics and specificities. In this article we will address three types of architecture, they are: Software Architecture, Solution Architecture and Corporate Architecture. Despite being different architectures and having specific functions, at some point during development they end up interfacing with each other. Software Architecture This architecture is the closest to the code and the developer. It focuses on the internal organization of a system and addresses the division of the system into components, such as: classes, modules or services. It also defines what the interaction between them will be, being responsible for aspects such as modularity, scalability, security and code reuse. Some of the definitions of this architecture: • Which programming language will be adopted; For example: Java or .NET C#. • Which frameworks and libraries to use in the solution; For example, if you choose the Java programming language, use the Spring Boot Framework to facilitate and speed up the development of web applications and microservices. • How to access the data layer, and how persistence will occur, whether through an Object-Relational Mapping framework or manually. If you choose an ORM, define which tool will be used; For example: Hibernate or EclipseLink. • Which architectural model will be used in the implementation and the appropriate architectural patterns that meet the system requirements. For example: MVC, Layered Architecture, Client-Server, Hexagonal or Service Oriented. • What is the form of communication between the system components; For example: HTTP, REST or Asynchronous Messaging. • How scalability will take place and how the system will scale to handle increases in load and demand; For example: Load Balancing, Horizontal/Vertical Scaling or Data Striping. Which to follow? These topics listed some examples of architectural decisions that can be made during the process of defining a software architecture. There is no right or wrong answer to these definitions. Only the one that best fits to meet a need within a business context. These decisions are very important and must be made with great care and caution, as changing them later will affect the entire structure of the system, causing unwanted costs and delays in the project. Therefore, it is recommended to carry out Proofs of Concepts (POCs) so that the decisions made are as assertive as possible and guarantee a robust, scalable and high-quality system. It is important that the software architect has good technical knowledge and, based on his experiences, makes the best decision so that development is fluid and rhythmic. Furthermore, the architect must be prepared to act in times of crisis. Often, it may be required to identify specific and highly complex problems, such as debugging a library or framework to make an important decision and correct a problem in production, making the operation work normally again. Solution Architecture Solution Architecture is at a higher layer in relation to Software Architecture, and is responsible for transforming the business requirement into engineering components that will work together to solve the problem and meet the business needs. It covers the definition of the systems involved, the integration between them, the communication interfaces and the strategies to ensure that the solution as a whole works effectively and achieves its objectives. This type of architecture is ideal for identifying areas within an organization where there can be cost reduction, improving performance and automating processes to become more efficient, optimized and standardized. The main difference between Software Architecture and Solution Architecture is that the first only deals with engineering-related issues, while the second is responsible for ensuring that a software product solves a specific business problem within a company's strategy. Atividades que estão associadas a esta disciplina: • Compreender e analisar os requisitos do negócio e do sistema para identificar as necessidades e os objetivos da solução; Por exemplo: Entrevistas/workshops, estudos de viabilidade e criação de diagramas de contexto.  • Criar e liderar os processos de integração entre sistemas para atender os requisitos de negócio; Por exemplo: Definição de interfaces, serviços web (API's REST) e Middleware de integração (Kafka).  • Identificar e definir as medidas de segurança necessárias para proteger a solução contra ameaças; Por exemplo: Autenticação, Autorização, Criptografia e proteção de dados sensíveis.   • Colaborar com stakeholders (desenvolvedores, analistas de negócios e gerentes de projeto), para garantir a compreensão e a adoção da arquitetura de soluções; Por exemplo: Comunicação clara das decisões arquiteturais, realização de revisões técnicas e a obtenção de feedback dos envolvidos.  • Identificar os riscos associados à solução e desenvolver estratégia para mitigá-los; Por exemplo: Análise de riscos técnicos, operacionais e segurança.  • Considerar os requisitos de desempenho, como tempo de resposta e capacidade de processamento, e também a capacidade de escalar a aplicação para lidar com picos de aumento de carga; Por exemplo: Uso de caches, escalonamento horizontal, arquitetura de microsserviços ou serviços de mensageria.  Vínculo forte Podemos concluir que a arquitetura de soluções está na divisão entre o técnico e o negócio, e que há um vínculo forte entre essas duas vertentes, considerando a importância de que a solução técnica está sendo definida para resolver um problema de negócio. As habilidades de comunicação na arquitetura de soluções são imprescindíveis, pois há frequentemente um contato direto com a área de negócio, que normalmente tem o conhecimento técnico muito pequeno ou inexistente, com isso, cabe ao papel do arquiteto de soluções ser capaz de explicar e traduzir de forma simples toda a solução técnica que será construída, de uma forma abstrata o suficiente para que todos entendam. Algo importante a se considerar é o conhecimento necessário para representar a arquitetura através de diagramas, como por exemplo o C4, e que ele possa representar de forma clara os componentes do software, a interface com outros sistemas, o fluxo de dados e demais informações que forem pertinentes tanto para a engenharia quanto para o negócio.  Arquitetura Corporativa Define-se arquitetura corporativa como uma série de conhecimentos técnicos e habilidades de gestão que integram a tecnologia aos objetivos do negócio, é uma visão mais ampla que abrange a arquitetura de todo o ambiente de tecnologia da informação da organização. Determina os princípios, políticas e os padrões de governança que orientam a estruturação dos sistemas de software e infraestrutura de uma empresa, se concentrando em como os diferentes sistemas e soluções se encaixam dentro do contexto organizacional, garantindo a consistência, a integração e a eficiência dos recursos de TI.A arquitetura corporativa também considera fatores estratégicos e de negócios, alinhando a tecnologia da informação com os objetivos e necessidades da organização. It may include the definition of business process models, management of the systems portfolio, IT governance and the definition of information security policies. Decisions made within this type of architecture: • Standardization of programming language and frameworks used in solutions within the company, defining which technologies will be able to be used; For example: Using the Java stack with Spring Boot Framework in API solutions. • Standardization of databases; For example: SQLServer and Oracle. • Change control processes for auditing publications in a production environment; For example: Access control and permissions, review and approval of changes. • Define and document an architectural model that the organization will work with; For example: Create a diagram that illustrates the main layers of the architecture, covering the presentation, business and data layers. • Evaluate the implementation of new technologies; For example: Carrying out Proofs of Concept (POC's) and market research. • Implement corporate DevOps solutions; For example: Compilation and packaging automation using Jenkins as a CI/CD mat. Importance of corporate architecture Having a corporate architecture is very important, as it defines standards that the entire company must adopt and follow, and helps to align the organization's strategic objectives with its operational activities, helping to identify redundancies, inefficiencies and optimization opportunities, allowing the simplification, consolidation and rationalization of resources resulting in greater operational efficiency and cost reduction. Corporate architecture assists in managing the life cycle of IT systems, from strategic planning, establishing quality, governance and compliance standards for the development, implementation, operation and maintenance of systems, ensuring effective and sustainable management of IT assets. Conclusion In this article, we covered the three main types of architecture that exist in software development, the details of each type and how they relate to each other. This division is important so that each architecture focuses on a specific area so that the three together can cover the entire software development cycle. As we have seen, software architecture is closer to the code and the developer, solution architecture is more focused on the business that the solution intends to solve and corporate architecture is used to define the technological standards that the organization must adopt for the implemented software solutions. The application of these types of architecture varies according to the size of the organization, the larger, the more separated and specific the types of architecture, and the smaller, the less separation between the types of architecture, and often merging into just one type. It is important to highlight that, for each type of architecture, the architect can play a different role, and each one has their own specific skills for each area, but communication skills, critical sense, proactivity and resilience are common to all types of architecture.

Here at the Projuris support team, when we receive a ticket (also known by many as a ticket), we carefully analyze what the customer demand is and what its impact on the operation is. The saying goes: “life imitates art”. Therefore, I can say that our lives have a lot to do with a support ticket. We can even divide it into the same analysis steps to solve a problem. Service, category and urgency. Regarding the analysis of service, we can compare it with life by separating all points of life into areas, whether personal, professional or spiritual. In other words, seek, in a broad way, not only your identification, but also your best way of acting. Right after the service, we arrive at the category, which we can relate to as if it were a question, problem or task. This question is important for us to analyze attitudes to overcome this problem. Problems, which are part of human life, can be confused with doubt. But there is a difference: while doubts refer to lack of knowledge or lack of interpretation about something, problems do not follow the same flow. The problems are notes that should remain that way, but are not. For example: All demands for which we do not have answers, at least at first, are considered problems, and there may be solutions at the moment or in the future. If the problems refer to how to do it, it is not a problem, but rather a doubt. The last item, in my opinion, is the simplest. These are tasks, which are operations on a given point. And when we talk about urgency, we classify it as: blocking, urgent, high, medium and low. Blocking is a category in which the entire operation and all users of the organization are paralyzed. From the perspective of life, the blocking category is something that must be resolved immediately. Urgent is similar to blocking, however, it does not paralyze the entire operation. It can be resolved more calmly. The high, medium and low categories are problems in which we must analyze what the impacts will be on daily life. Urgencies help to understand priority demands. Because, the more serious it is, the greater its impact. Support ticket or life ticket? Now I ask you: who is the expert behind this ticket of life? That's right, it's me, you, us. Therefore, being an expert in your own “demands” (what we can also call self-knowledge) is an essential element in understanding the issues that afflict you. And the more you organize yourself, classify your problems and prioritize them, the better you will solve them, making your life more peaceful. 

If you work with software projects and have ever had the need to treat individual objects and collections of objects in a uniform way, the Composite design pattern will help you. Find out below how the Composite pattern helps you create more intuitive user interfaces and process object trees efficiently. In this article, we invite you to explore the benefits of this pattern, which simplifies hierarchical structures and offers greater flexibility in manipulating elements. Check below what Composite is, what are its advantages and disadvantages and see a practical example of its implementation. What is Composite? Composite is a structural design pattern that allows individual objects and compositions of objects to be treated uniformly, forming a hierarchical structure. It is the fourth standard in this category presented by the "Gang of Four" (GoF). As the authors themselves put it, the official intent of this pattern is "to compose objects into tree structures to represent parts-whole hierarchies". With Composite, an individual object and a group of objects are treated the same way, as they both implement a common interface. How does the Composite design pattern work? Within the Composite pattern, we find an abstract class known as "Component", which establishes a shared interface for individual objects and groups of objects. Individual objects are represented by a concrete class that implements the Component, while groups of objects are represented by a composite class that also implements the Component. Hierarchical structure is created through composition, in which a group of objects can include other individual objects or groups of objects. This structure allows the realization of recursive interactions, and thus makes it possible to apply operations to all objects in the hierarchy. The Composite pattern is ideal for when there is a need to treat individual objects and collections of objects homogeneously, simplifying the code and providing greater flexibility. Its use is common in user interfaces, processing trees, and other hierarchical structures. How is Composite implemented? To better understand the implementation of Composite, let's analyze the following example: In a supermarket, you have two ways to buy a soft drink: You can buy the unit Or buy a pack with 12 units Here, we have a Composite: the notion of that the bale (structure) behaves like a product, and that it can set its price by delegating its value, thus adding the costs of the daughter units and using it as its own. Of course, the above scenario only makes sense if the bale does not have a fixed value, but rather its value is summed up in the total number of units inside it. Let's look at a code for the described scenario (in this case, using Java to exemplify): In the example above, we defined a Product interface, which will be implemented by both the “refrigerant” unit and the bale. The common method that will be implemented by them, in our case, is getValor(). The soda, in turn, has the value and a name. The implementation of getValor(), as it is a single unit, only returns its own value. Above we have the refrigerant load, acting as a Composite, its “value” is delegated to the units inside it. That is, if there are 5 units of soda, each with a value of “5”, the bale value will be 25. The interesting thing about this design pattern is that the complexity of this type of structure doesn't end there. As the SodaBurden class has a list within it of the Product type, it is capable of supporting even other burdens within itself. Example of the Structure of a Composite Although the “bale of soda” is not the best example in this case, we can imagine a box inside another box, and each of them with products of different values ​​inside them, the inner boxes totaling the value of the internal products, and the external box would total the value of the internal boxes, looking very similar to the structure below: Example of what the structure of a composite might look like. Source: “Design Patterns: Reusable Object-Oriented Software Solutions” Normally, the Composite design pattern is used, for example, to run a battery of validations on top of an object. While the Decorator serves to extend functionality within an existing class, without changing the original class and preserving the SOLID principles. The way of implementing it can vary a lot depending on how you use it, but the important thing is to know the pattern and know when to fit it into your system. Do not strictly follow the diagrams proposed by GoF, or the examples cited, adapt them according to your needs and situations. When to use the Composite design pattern? The Composite design pattern is applied in situations where there is a hierarchical structure of objects and when you want to treat individual objects and groups of objects uniformly, simplifying code and providing greater flexibility. Here are some example situations of using the Composite pattern: Hierarchical Structures: The Composite pattern is ideal for dealing with hierarchical structures, such as trees or graphs, where the nodes can be individual objects or groups of objects. User Interface Modeling: It is common to use the Composite pattern in the construction of user interfaces, especially when there are elements that can contain other elements, such as menus, buttons and panels. Document Processing: Composite can be useful for treating elements like documents with sections, paragraphs, lists, etc. uniformly. Graphics Manipulation: If you need to deal with graphical elements such as shapes, lines and groups of shapes, Composite allows you to treat them in a uniform way and makes it easy to apply operations to all elements. Implementing Data Structures: It is also possible to apply Composite to implement data structures such as arrays, lists and matrices, where individual elements and groups of elements are treated similarly. What are the pros and cons of using Composite? Check out the main pros and cons of Composite: ProsConsSimplifies the hierarchical structure Can impact efficiency in very large structures Provides flexibility in handling objects and recursive operations May require greater design effort and initial implementation Promotes code reuse Requires a well-defined common interface However, it is important remember that the pros and cons of Composite may vary depending on the context and specific requirements of the project. Therefore, it is essential to carefully consider these aspects before deciding to use the Composite design pattern. And did you already know how to implement Composite?

With the exponential increase in the use of electronic devices and gadgets in our routine, the importance of Human-Computer Interaction, also known as HCI, has increasingly increased in the transformation of society, directly impacting everyone's daily lives. Especially for software developers and interface design professionals, it is essential to understand the principles of HCI to create successful products that meet the expectations of users. If you want to know more about it, find out what the IHC is below. We will also address the main pillars of study in this area to better understand this concept. What is IHC? Digital transformation occurs more fluidly with the good use of good interfaces, which must be carefully designed to allow effective communication between people and machines. The focus is to provide a pleasant and satisfying experience for the user, in which they can carry out their task and resolve their “pain” efficiently and without frustration. That's where IHC comes in. Human-Computer Interaction (HCI) is a multidisciplinary area of ​​technology dedicated to the study and improvement of the interaction between human beings and computational systems. Its goal is to create user interfaces that are intuitive, efficient, and enjoyable to use. HCI covers several aspects of interface design, such as usability, accessibility, user experience and ergonomics. Therefore, the area uses methods and techniques from different origins, such as psychology, software engineering, computer science and design. What are the 3 focuses of HCI study? The three main study focuses of HCI (Human-Computer Interaction) are: 1. The user (and their task): HCI focuses primarily on understanding the needs, abilities and limitations of users, aiming to design systems and interfaces that are intuitive and optimized for the intended actions. To achieve this, the area uses research techniques, such as quantitative and qualitative interviews, mental model observation, user journey mapping and usability testing. 2. The system: Another focus of the area is the system itself, that is, understanding how computing systems work and how to design them in an optimized and safe way taking into account various factors, such as hardware and software limitations, for example. In order to increase this knowledge, it is necessary to deepen the areas of software architecture, interaction technologies, usability and interface design. 3. The context of use: Finally, another focus of study in the area is the context of use of the systems. For example, the user's environmental conditions, time constraints, abilities or possible physical limitations, as well as their desires, needs and culture — digital or otherwise. All of these elements shape the response to the needs of those using the system. Thus, it is possible to ensure that the system is designed taking into account the user's expectations of action and reaction in a wide range of situations. Feedback is life As an example, the feedback that the user needs to receive from the computer system must be explicitly planned and programmed. This is essential to ensure that the user clearly understands what is happening internally on the computer and can interact with it in a more assertive way. Imagine the following situation: you activate an elevator and receive no response from the system, no button lit, no floor counter, no arrow up or down, and from that point on your interaction with the system becomes be based on faith – that the elevator will arrive at some point… Jakob Nielsen, the Yoda of usability, is not satisfied with pretty designs; it invites us to think about the user first. Efficiency of use and user satisfaction are like its design mantra. It's more than creating something beautiful; is to create something that works masterfully and makes the user “smile” while using it. And this is where Nielsen's heuristics come in, the master of functional pragmatism wizards. These principles are not just guidelines embraced by designers; They are like the 10 commandments of interface design. "Make system status visible!" he proclaims. "Maintain a correspondence with things in the real world and control the user!" These rules are like compasses that guide designers through the seas of user experience. So, stop using them and sail aimlessly to your own devices. We can list 10 main heuristics and one of them, mentioned above, is precisely the first of all: Visibility of the system status. To complete the combo, we have 9 more heuristics — which will be gradually addressed in the next posts: Correspondence between the system and the real world User control and freedom Consistency and standards Error prevention Recognition instead of memorization Flexibility and efficiency of use Aesthetics and minimalist design Error recognition, diagnosis and recovery Help and documentation Origin of HCI and Timeline Previously, at the dawn of interface times we can safely point to Lisa as the "baked oven" of interfaces. Launched in 1983, by Apple, the first commercial computer that had a Graphical User Interface (UI). This technology allowed computers to be used by people without any special training, making them accessible to everyone. However, Apple was already working on a more accessible and lower-cost version. A year later, the company launched the Macintosh, the first computer with a truly accessible graphical interface. It came with a monitor, keyboard and mouse with a button, and had a greater organization than previous computers. Options were ordered in menus and there were icons that could be clicked to operate a program. The focus here is to understand that the greatest legacy of this disruptive movement was the Desktop folders metaphor, used commercially for the first time by Apple in Lisa OS, which also leveraged the use of Graphical User Interfaces (Graphical User Interface, or GUI) by other companies. This desktop metaphor represented an office table with several papers on top, symbolizing computer files, as well as other representations of the real world, such as the trash can, calendar, clock, files, spreadsheets, notepad. , calculator, etc. At that time, the first users and enthusiasts of computers were people who worked in offices, with typing, calculating machines, file folders, etc. Therefore, it was realized that by simulating the physical office environment in a computer interface, users would more easily understand the storage of information on the Desktop. That was the mental model. After this tour of the past, let us now look at the present. We cannot ignore the buzz around artificial intelligence (AI). Now, things are getting real, with speech commands about to enter the picture. We're not just clicking and dragging; we are talking to our machines. It's like having a personal assistant that not only understands what you say, but can also help or perform what task you really need to do, in the best Tony Stark's JARVIS style. However, with great power comes great responsibility. As AI becomes ubiquitous, we begin to question the privacy, security, and even trustworthiness of these interactions. It's as if we're flirting with a new era of digital conversations, but we don't really know all the rules of the game. It is also worth noting that even with a little help from his talking personal assistant, the boy Tony still makes extensive use of graphical interfaces. Conclusion In short, we call Human-Computer Interaction the study, design and implementation of software for direct use with users. Such systems feature User Interfaces (UI). It is through them that a person will interact with a computer. Thus, it was through interfaces that the computer became what we know. Would you like to know more about Human-Computer Interaction?

In recent years, we have noticed an increase in the complexity of software systems, the emergence of SaaS and hybrid apps. This consequently increases the risk of bugs, in addition to greater exposure of systems to intrusion and data leakage. In this new context, observability can help identify problems more quickly, optimizing the work of the development team and improving the quality of systems. If you still don't know this concept, check below for more information about one of the main trends in software engineering and find out what observability is, its pillars, advantages and how to implement it! What is observability in IT? Observability in IT is the application of a system of constant monitoring, tracking, analysis and diagnosis of a system, making use of some software tools. Observability allows you to investigate and understand in more depth how a system behaves, especially in cloud architectures. From the observability tools, it is possible to collect and analyze a large spectrum of data, detect problems, understand the causes of identified problems and draw up an action plan to improve the functioning of the systems. In this way, observability helps resolve problems before they affect the company's KPIs. Furthermore, they transform an incomprehensible problem into something more detectable, visible and traceable. This concept is widely applied by DevOps, infrastructure and development teams, as it is already widespread in Software Engineering that it benefits the software and facilitates problem solving. The ideal is to adopt the implementation of software observability especially when the focus of your business is the customer experience or to optimize the work of the developers on your team. Take the opportunity to also check out our article that talks a little more about domain-oriented observability, a methodology for implementing observability. What are the advantages of implementing Observability in IT? Some advantages of implementing observability are: Availability, as it facilitates the identification and correction of errors, minimizing downtime and impact on end users; Reliability, because, when used preventively, observability is capable of mitigating scalability or performance problems of an application in advance; Traceability of the use of functionalities, in order to obtain inputs for strategic decisions that can be taken within the scope of the business; Productivity, as observability allows you to monitor changes in real time, increasing your team's productive capacity when meeting daily demands, helping DevOps, infrastructure, or other teams; Lower cost, since observability prevents security problems, the company spends less on unexpected maintenance; Predictability, because when the team's culture is focused on tracking and monitoring systems in real time, the company can more easily predict some of the future problems. Among these advantages, traceability is the one that most impacts the business, as it defines the success of your application. The so-called “high-level metrics”, because they are intrinsically linked to the business, are the ones that deliver the most value. Through the traceability of the use of a system's functionalities, we are able to understand whether it is performing according to the objectives of a product. What are the 3 pillars of observability in IT? Effective implementation of software observability is only possible through the use of telemetry data, which are the pillars that bring together all the information about the investigated system. In the concept of observability, we have 3 pillars: event logs, metrics and tracking. See below an explanation of the 3 pillars of observability in IT: Event logs: It is an immutable record that presents the time and date of events. It is possible to capture it through text, binary or structured. Metrics: Metrics are values ​​defined according to the objective. They are used to investigate the behavior of an event over a specific time interval and provide data such as date, name, time and KPIs. Tracking: It is the pillar that details all operations, from the beginning to the end. This happens with the monitoring of the entire journey to understand whether the system is normal or at risk. What is the difference between monitoring and observability? The observability strategy is not exactly different from monitoring, as monitoring handles problems more reactively and is not capable of dealing with highly complex problems. This is because since the incorporation of microservices architecture for web apps, there has been greater scalability in the creation of system components being implemented individually on platforms. In this scenario where new unknown problems may arise, monitoring alone cannot be as efficient. On the other hand, observability is a large set of monitoring focused on the architecture of microservices in the application layer and containers in the infrastructure area. In addition, it correlates the telemetry data collected with the aim of creating more effective solutions. Thus, constant observation can provide data that helps monitoring, facilitating the identification of problems and their causes. In other words, monitoring ensures that an application becomes observable, therefore, observability is an evolution of the monitoring concept. Through observability, it is possible to have a better monitoring of the system, being almost synonymous in this sense. How to implement observability? To implement observability properly, you first need to define your goals. That is, identify key performance indicators (KPIs), their objectives and list the monitorable critical points. Then instrument your code with metrics and logging. Some tools can help you with this task, such as Prometheus for metrics and Fluentd for records. You can also use monitoring tools to analyze the data generated in the application. For example, Grafana for viewing metrics and Kibana for analyzing logs. In addition to these points, it is important to have alerts that notify the team whenever a critical event occurs. To understand how requests are behaving within the system, you can use transaction tracing to trace the flow of requests through the different components. By following these steps and maintaining an ongoing process, update your goals and adjust your implementation as needs change. Still have any questions about observability?