Deve o Arquiteto de Software escrever código?

Este post é bastante interessante. Discute uma questão permanente no desenvolvimento de software: Deve o Arquiteto de Software programar (escrever código)? Leia   AQUI e dê a sua opinião

Arquitetos de Software devem codificar?

Um arquiteto de software deve codificar? Qual a sua opinião sobre o tema? Leia sobre o tema aqui

Posicione a arquitetura no centro de projetos de desenvolvimento de software

Deveria ser óbvio colocar a arquitetura no centro de um projeto de desenvolvimento de software não só do ponto de vista tecnológico, mas também do planejamento gerencial.

Esta ilustração mostra que as partes interessadas fornecem metas de negócios que são destiladas em condutores arquiteturais, que conduzem toda a estrutura da arquitetura.

A arquitetura é iterativamente refinada e pode, por sua vez, refinar os condutores arquiteturais, bem como as metas de negócios.

O DAS (documento de arquitetura de software) se torna o principal artefato mantido ao longo de todo o projeto.

Depois que uma arquitetura de linha de base, chamada também de candidata, é estabelecida, ela serve de base para as provas de conceito (experimentos), planos de projetos, planos de teste, desenho detalhado e alocação das pessoas.

A arquitetura também é usada para criar um roadmap dos releases do produto e servir de base para acompanhamento e supervisão do projeto.

Fonte: Artigo The Architecture Centric Development Method, Anthony J. Lattanze, February 2005

Arquitetos de software e a comunicação com executivos

Saber se comunicar bem com executivos é um skill essencial para profissionais que atuam ou desejam atuar como arquitetos de software. É esperado que o arquiteto saiba lidar com grande volume de informações detalhadas e seja coerente, claro e objetivo ao se comunicar com executivos.

Para arquitetos com formação estritamente técnica, se transformar em um “grande comunicador” é um desafio considerável porque eles tem uma tendência a querer analisar e pensar minuciosamente em todos os detalhes de um problema. Quando ocorre esse “mergulho” nos detalhes os arquitetos não percebem com clareza como o mundo exterior os percebem. Em um time técnico onde todos tem esse mesmo perfil, isso é natural e não é visto como problema, mas executivos entendem esse alto nível de detalhes como uma forma inadequada de se comunicar.

Cito abaixo alguns princípios e estratégias para arquitetos de software facilitarem a comunicação com executivos. Primeiro concentre-se nos princípios, depois nas estratégias e em seguida na abordagem para executivos.

Princípios de comunicação

• Escutar primeiro, falar depois - “Você tem dois ouvidos e uma boca, então ouça mais e fale menos. –Epictetus”;
• Estar presente - Concentre-se, evite distrações quando estiver se comunicando. Planeje-se. Por exemplo, se você for participar de uma reunião e for ficar com a cabeça em outro lugar, em última instância, não vá;
• Ser positivo - Concentre-se nos fatos e procure fornecer alternativas sem julgamentos emotivos. Procure não plantar sementes da incerteza.;
• Se desculpar o quanto antes - Lembre-se que você é um ser humano, ou seja, você pode eventualmente cometer erros. Se você passar informações incorretas ou de maneira inadequada, se desculpe o quanto antes e comunique as devidas correções de informação. Isso vai demonstrar que você se importa e que aquilo é realmente importante.;
• Evitar se concentrar sempre em imperfeições - Em reuniões de avaliação, por exemplo, muitas vezes as imperfeições que cercam o item avaliado começam a aparecer e isso gera um mal-estar. Procure não focar apenas nas críticas. Registre os pontos para referir mais tarde para não impactar o restante da reunião.

Estratégias de comunicação

• Preferir o sim ao não - “Como arquitetos, nós precisamos encontrar maneiras de dizer ‘sim’.”. Se um projeto ou tarefa não é viável explique porque e ofereça alternativas.
• Reservar os nãos para ocasiões especiais - Lembre-se que sempre existem alternativas. Na maioria das vezes, para excluir uma alternativa, você deve fornecer outras alternativas de como algo poderia ser feito (com os custos, riscos e benefícios de cada abordagem). Um Não seco deve ser a última alternativa.;
• Estabelecer confiança no processo de venda - “Como arquiteto, você precisa ser uma pessoa de vendas e como uma pessoa de vendas você precisa ser confiável.”;
• Evitar assumir uma posição defensiva - Muitas vezes, quando ouvimos coisas que não nos colocam em uma posição completamente positiva, procuramos formas de amenizar e colocar um toque mais positivo. Resista ao impulso de responder. Em vez disso, espere, e receba aquilo que está sendo dito. Depois se pergunte: Como posso aprender com o que esta pessoa está dizendo?;
• Receber feedbacks como sugestões de melhoria - Esclareça o feedback, entendendo o contexto, ouvindo e reiterando o que já foi dito como se fosse uma sugestão de melhoria e não como uma crítica apenas;

Comunicando com executivos

• Evitar surpreender executivos - Os executivos não gostam de surpresas, especialmente o tipo que eles precisam agir em um período muito curto de tempo, quando o número de opções restantes é pequeno e o resultado provável é que eles precisam comunicar uma mensagem ruim para o resto da organização.
• Preferir ser claro ao invés de completo - Como uma regra geral, a quantidade de informação pormenorizada necessária é inversamente proporcional ao nível da pessoa na organização. Em outras palavras, os desenvolvedores querem e precisam de uma quantidade enorme de informação para construir algo, enquanto um executivo terá apenas informações de alto nível (resumo) sobre um projeto durante uma reunião de status regular. Essa informação deve ser clara e concisa. Você precisa dar aos executivos a informação certa e fornecer o contexto apropriado, que consiste em obter mais informações de negócios e menos informação técnica.;
• Executivos se concentram na confiança, lealdade e consistência - Quando você está interagindo com executivos (especialmente os que têm a supervisão das áreas que trabalham), você precisa se concentrar em estabelecer e construir a confiança e lealdade. Para estabelecer isso, a informação tem de ser coerente: Você não pode contar uma história um dia e uma história totalmente diferente no dia seguinte. Concentre-se nos fatos de maneira sucinta e direta, reconhecendo que eles são pessoas ocupadas.

Apesar de serem direcionadas para arquitetos, acredito que essas dicas podem ser aplicadas por qualquer profissional técnico que queira se aprimorar nesse sentido.

Fonte: Livro 12 soft skills para arquitetos de software

O Quadrante do Débito Técnico

Débito técnico é um neologismo, cunhado por Martin Fowler, que se refere ao acúmulo de defeitos, baixa legibilidade de código, dados des-normalizados, arquitetura ineficiente, desenho pobre e coisas como essas. É como um “cheque especial técnico” onde o débito vai se acumulando e depois é cobrado da solução final com juros e correção monetária. Abaixo o quadrante nada “mágico” do Débito Técnico.

Geralmente os times técnicos focam muito no débito técnico relativo ao código, mas ele pode ocorrer em todos níveis da arquitetura, incluindo mas não se limitando a, interface com usuário, lógica de domínio, comunicação e aos dados.

Esse gráfico não é o original cunhado por Martin Fowler. Ele teve o quadrante Inconsistente/Imprudenteestendido por Scott Ambler para endereçar questões além do código.

Existem algumas razões Prudentes para  entrar no “cheque especial” do débito técnico como a redução do tempo de liberação da solução (time-to-market)  ou uma oportunidade de aprendizado, devido à pressão do negócio.

Outras razões são Imprudentes como não investir  em arquitetura e desenho de forma Intencional, ou mesmo de forma Inconciente, resultado de não ter o conhecimento suficiente para entregar a solução.

Entre diversas abordagens para fugir do débito técnico está a adoção de métodos de desenvolvimento centrados em arquitetura, aliados ao desenvolvimento de provas de conceito e refatorações. Essa é uma abordagem que tem se mostrado sustentável, para gerenciar melhor as decisões técnicas visando manter o débito técnico sob controle.

E você? As soluções usadas em sua empresa acumulam débito técnico?. Pense nisto. Uma hora você terá que pagar a conta. 

Uma das grandes dificuldades no processo de criação de arquiteturas é capturar os requisitos que realmente importam para a arquitetura (Requisitos Arquiteturais).

Uma técnica para auxílio neste processo é fornecida por uma ferramenta da psicologia e também usada em alguns círculos de requisitos, chamada de Janela de Johari.

Adapto este conceito para o contexto de arquitetura de software, exibido na figura abaixo.

A figura mostra nem todo requisito é conhecido pelo nosso time e pelos nossos usuários e este desconhecimento (nosso, dos usuários ou de ambos) é fonte de muitos problemas.

Vamos contextualizar o conceito em um exemplo didático de um sistema de Internet Banking. É natural (para qualquer arquiteto e para os usuários chave de um Banco de Crédito) que aspectos de segurança devem afetar a arquitetura executável do produto sendo criado. Portanto, aspectos de autenticação, autorização e transporte seguro estariam no quadrante Q1, que é o dos requisitos arquiteturais óbvios. Até agora não temos nenhum problema.

Vamos considerar agora alguns requisitos de qualidade interna como a manutenibilidade ou a testabilidade, que são normalmente conhecidos pelo nosso time. Normalmente aspectos de qualidade interna não são percebidos diretamente pelos usuários chave, o que os coloca no quadrante Q4. Portanto, arquitetos devem tomar cautela extrema com estes requisitos pois eles não são normalmente percebidos pelos usuários e portanto não valorizados. A consequência é que eles podem causar aos usuários a sensação de baixa produtividade na execução de código pelo time de desenvolvimento. Ainda pior, eles podem encarecer o seu projeto sem percepção de valor correspondente para os seus usuários.

Vamos agora considerar alguma norma obscura do Banco Central que lide com algum aspecto regulatório. Se a maturidade dos usuários envolvidos no projeto e da equipe de arquitetura for baixa, este requisito regulatório, que pode afetar a arquitetura, estaria colocado no quadrante Q3. A lição aqui é óbvia. Os usuários normalmente não conhecem todos os requisitos e portanto devemos buscar requisitos que podem afetar a arquitetura em outras fontes de informação.

Finalmente, vamos lidar os requisitos mais perigosos, que são elementos óbvios para os usuários mas não óbvios para o time. Por exemplo, o usuário pode assumir que a portabilidade entre navegadores para dispositivos móveis é dada. O time, por sua vez, pode nem ter considerado esta possibilidade. Tipicamente estes requisitos do quadrante Q2 são fontes de desgaste durante o projeto e envolvem retrabalho para o time pois afinal eles são "óbvios" para os usuários.

Em cenários ideais gostaríamos de mover todos os requisitos para o quadrante 01, mas o fato é que sempre haverá requisitos nos quadrantes Q2, Q# e Q4. Naturalmente a aplicação de métodos arquiteturais de coleta de requisitos reduzirá a probabilidade que isto aconteça. Algumas dicas rápidas para isso incluem:

• Realizar reuniões e oficinas de trabalho podem ajudar a mover requisitos do quadrante Q2 para o quadrante Q1. Técnicas de leitura ambiental também são úteis neste contexto.
• Buscar outras fontes de informação além do ambiente e informações fornecidos pelos seus próprios usuários podem mover alguns requisitos do quadrante Q3 para o quadrante Q1.
• Educar usuários sobre os requisitos que eles não conhecem pode ajudar a levar requisitos do quadrante Q4 para Q1. Em outras situações, talvez devamos remover alguns requisitos do quadrante Q4 do escopo do nosso projeto.

Tendências de Arquitetura para 2012-2014

O Forrester Group lançou agora em Outubro seu relatório de tendências de tecnologias de negócio para arquitetura corporativa os próximos três anos (2012-2014). Faço um brevíssimo resumo do mesmo abaixo, focado em quatro das tendências apresentadas.

BPMO  Forrester prevê uma expansão do BPM e uma fusão com eventos complexos e gestão de regras de negócio. Um conceito que surge neste contexto de unificação é o de BLMS (Business Logic Management Systems), que une em um mesmo ambiente processos, regras e eventos. Em termos tecnológicos, as soluções de BPMS, CEP e BRMS precisarão ser harmonizadas a partir de tecnologias e fornecedores distintos para gerar este valor de negócio.

BIO BI se torna pervasivo nas organizações e se expande para analisar quantidades absurdas de informações (Big Data). Em termos arquiteturais, as arquiteturas de EDW e projetos que incorporem mercados de dados departamentais (DM) e ETLs ganham cada vez mais espaço na agenda dos arquitetos de dados.

Governança e Gestão de Dados

O MDM (Gestão de Dados Mestres) ganha espaço e começa a se integrar com iniciativas BPMS (gestão de dados de processo). As iniciativas de governança de dados ganham espaço. Em termos arquiteturais, as arquiteturas de dados mestres e questões de replicação e federação de dados se tornam cada vez mais presentes na agenda dos arquitetos. Talvez seja o momento para que os arquitetos de dados ganhem o espaço que os arquitetos de software na década 2000-10.

Computação nas Nuvens e o XAAS

A computação nas nuvens ganha ainda mais espaço e gera cada vez mais pressão econômica sobre a TI (e os gestores). Em termos arquiteturais, a análise sobre as vantagens e desvantagens da virtualização bem como sobre (qualquer coisa) como um serviço devem ser corretamente analisadas pelos arquitetos de infraestrutura.

Originalmente publicado em marcomendes.com/blog

Publicado em 1 de novembro de 2011 por Marco Mendes