You’re a System Architecture professional who needs to solve a problem. What’s the first step?

As a system architecture professional, you know how important it is to design and implement reliable, scalable, and secure systems that meet the needs of your clients and users. But what do you do when you encounter a problem that threatens to derail your project, compromise your system, or affect your reputation? How do you approach it in a systematic and effective way?

In this article, we'll explore the first step of problem solving for system architecture professionals: defining the problem. We'll cover why this step is crucial, how to do it properly, and what tools and techniques you can use to help you.

1 Why define the problem

Defining the problem is the first step of problem solving because it helps you to understand the nature, scope, and impact of the issue you're facing. Without a clear and accurate definition, you might waste time and resources on irrelevant or ineffective solutions, or miss the root cause or the underlying factors of the problem. Defining the problem also helps you to communicate it to others, such as your team, your stakeholders, or your customers, and to align on the expected outcomes and success criteria.

Add your perspective

Marcio Moreira

IT & Business Specialist Executive
Report contribution
Para mim, entender qual o problema/necessidade de negócio precisamos resolver é primeira ação mais importante em arquitetura. Se errarmos esse tiro, não tem engenharia de software que acerte o alvo. Geralmente utilizo alguns passos do método de Kepner e Tregoe (descrito no ITIL, PMBOK, etc.). Esse método é suficientemente bom para isolar o problema. Além disto precisamos de domínio do negócio do cliente; do produto, processo e funcionalidades existentes. A solução do problema novo não deve derrubar o que já existe funcionando.

Translated

Like
Diogo Alves Miranda Barbosa

DEVOPS ENGINEER | SRE | AZURE | AWS | GCP | OCI | INFRA | TERRAFORM | ANSIBLE | DOCKER | KUBERNETES | GIT | JENKINS | ITIL | PYTHON |
Report contribution
Extramamente necessário, entender de fato o que sera resolvido com uma solução sistemica, pois sera dessa etapa que será definido, talvez um caminho apoiado com ferramentas, ou definir um fluxo processual para definir diretrizes, regras e requisitos para a solução sistemica ser bem construida.

Translated

Like

2 How to define the problem

To define the problem, you need to gather and analyze relevant information, such as data, feedback, logs, metrics, or documentation. You should also ask the right questions to gain a better understanding of the issue. These questions could include what the problem is and how it affects the system or users, when and where it occurs, who is involved or affected by it, why it happens and what are the possible causes or factors, how to measure it and its impact, and what are the constraints or assumptions that limit your options or influence your decisions. By answering these questions, you can create a problem statement that summarizes the problem in a concise and specific way. This should include the current situation or state of the system or users, the desired situation or state of the system or users, the gap or difference between them, as well as the impact or consequences of not solving the problem. For example, a problem statement for a system architecture problem could be: The current situation is that the system experiences frequent downtime and performance issues due to high traffic and load; whereas in the desired situation, it should be able to handle high traffic and load without compromising availability and performance. The gap is that the system is not scalable and resilient enough to cope with this demand; thus leading to lost revenue, reputation, and customer satisfaction.

Add your perspective

Marcio Moreira

IT & Business Specialist Executive
Report contribution
Essa compreensão é fundamental. Entretanto, mais profundo do que isto é entender as relações de causa e efeito entre os problemas. De uma forma geral, detectamos as consequências. O que precisamos resolver é a causa raiz, pois ela alavanca todo o sistema relacionado ao problema. Achando a causa raiz geralmente damos um tiro pequeno e certeiro na solução. No geral, essa causa é menor do que imaginamos. Por outro lado, geralmente é uma das mais densas de serem resolvidas.

Translated

Like
Diogo Alves Miranda Barbosa

DEVOPS ENGINEER | SRE | AZURE | AWS | GCP | OCI | INFRA | TERRAFORM | ANSIBLE | DOCKER | KUBERNETES | GIT | JENKINS | ITIL | PYTHON |
Report contribution
Na maioria das vezes, é entender de fato o impacto gerado, e que nivel esse impacto tem resultados negativos em algum projeto, empresa, processo ou pessoa, pois entender que existe o problema e chave para começar a pensar quais soluções, caberiam ou seria necessario adotar algo personalizado para o caso, e dai sim começar a pensar em plano de ações.

Translated

Like

3 Tools and techniques for defining the problem

There are many tools and techniques that can help you to define the problem more effectively and efficiently, such as root cause analysis, stakeholder analysis, and problem framing. Root cause analysis is a method that helps you to identify and eliminate the underlying causes of the problem, rather than the symptoms or the effects. You can use tools such as the 5 Whys, the Fishbone Diagram, or the Fault Tree Analysis to perform root cause analysis. Stakeholder analysis is a method that helps you to identify and understand the needs, expectations, and perspectives of people involved or affected by the problem. You can use tools such as the Power/Interest Matrix, the Stakeholder Map, or the Empathy Map to perform stakeholder analysis. Problem framing is a method that helps you to restate or reframe the problem in different ways to generate new insights, ideas, or solutions. You can use tools such as the SCAMPER technique, the Six Thinking Hats, or the How Might We questions to perform problem framing. By using these tools and techniques, you can define the problem more clearly and comprehensively while also being able to be creative in your approach. This sets up for success in subsequent steps of problem solving such as generating and evaluating solutions, implementing and testing solutions, and monitoring and reviewing results.

Add your perspective

Marcio Moreira

IT & Business Specialist Executive
Report contribution
Como mencionei no item 1, gosto muito do método de Kepner e Tregoe. Ishikawa, 5W2H, Análise de Partes Interessadas, etc. todos são úteis. Novamente coloco que conhecer as relações de causa e efeito do sistema como um todo é fundamental para isolar a causa raiz.

Translated

Like

4 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?

Add your perspective

Marcio Moreira

IT & Business Specialist Executive
Report contribution
Um ponto fundamental é testar sua hipótese. Não acredite que vendo-a pela primeira vez ela esteja correta. Valide-a com "n" casos no passado e pelo menos uns 3 casos atuais. Lembre-se errar na definição do problema é igual a jogar tempo e dinheiro fora!

Translated

Like

You’re a System Architecture professional who needs to solve a problem. What’s the first step?

1

2

3

4

1 Why define the problem

2 How to define the problem

3 Tools and techniques for defining the problem

4 Here’s what else to consider

System Architecture

Rate this article

Thanks for your feedback

More articles on System Architecture

More relevant reading

You’re a System Architecture professional who needs to solve a problem. What’s the first step?

1

2

3

4

1 Why define the problem

2 How to define the problem

3 Tools and techniques for defining the problem

4 Here’s what else to consider

System Architecture

Rate this article

Thanks for your feedback

Explore Other Skills