Eu e o Eros Viggiano criamos recentemente um blog dedicado ao assunto arquitetura de software. Diferentemente de outros (excelentes) blogs sobre o tema, o objetivo do nosso canal é fornecer uma visão sócio-técnica sobre arquitetura de software. A abordagem sócio-técnica é uma visão da administração que acredita que processos complexos devem ser compreendidos através da interação de aspectos humanos e aspectos tecnicistas.

Entendemos que uma arquitetura de software não se realiza apenas com ferramentas, técnicas e processos; mas com pessoas motivadas, liderança e times organizados com as ferramentas, técnicas e processos corretos. Entendemos também que a arquitetura de software, que surge como disciplina na engenharia de software no começo dos anos 90, ainda requer de muita investigação e muita discussão para se tornar uma ciência. Esperamos poder contribuir para o fomento desta importante área aqui no Brasil.

Boas Arquiteturas!

DeArchitectura - Uma Visão Sócio Técnica sobre Arquitetura de Software

O mercado de TI no Brasil, apesar da crise que se anuncia, está muito aquecido. Este aquecimento, como qualquer processo econômico, gera problemas de oferta e demanda. Uma alta oferta gera problemas diversos de déficit na demanda. A Gazeta Mercantil, em uma pesquisa de 2006, apontou um déficit de 50 mil profissionais no mercado de TI. Uma outra pesquisa, do portal Convergência Digital da Terra, diz que o Brasil acumulará um déficit de 150 mil profissionais até 2011. A Business Week, renomada revista americana, mostra que a profissão de Engenheiro de Software é a segunda posição do mercado de trabalho dentre as 20 profissões à prova de recessão.

Neste aquecido mercado, começamos a observar um estranho fenômeno, que é da presumida senioridade de profissionais de TI. Em termos mais simples, observamos profissionais que sem nenhuma ou pouquíssima experiência se assumem a seus gerentes e pares como plenos ou mesmos sêniores. Um padrão típico que já observei várias vezes poderia ser resumido da seguinte forma:

• O profissional faz um estágio em uma empresa de TI. No estágio ele “aprende” um framework como por exemplo o Hibernate e “domina” uma ferramenta como por exemplo o Visual Studio.
• Após o aprendizado do estágio, o profissional consegue o emprego e trabalha em seu primeiro projeto. Após um ano e algumas experiências vividas com um mesmo framework em um ou dois projetos, o profissional percebe que domina muito bem a ferramenta. Como ele passa a coordenar novos estágiários, que chegam sem nenhum conhecimento, ele de repente se percebe pleno. Pleno de conhecimento, pleno de domínio e pleno de influência. Para tornar a coisa pior, os seus gerentes, ingenuamente, começam a dizer a todos que ele é pleno. E como uma mentira dita em voz alta ao vento dez vezes se torna verdade, o profissional se torna pleno!
• Um profissional pleno almeja novas posições financeiras. Muitas vezes o profissional não encontra isso na empresa que o empregou. É o momento de ir para outra empresa, onde ele já entra como pleno, devido a sua “experiência” de coordenação de estagiários e novatos e do seu domínio sintático de ferramentas.
• No seu trabalho “pleno”, o profissional vive boas experiências em projetos. Ele lida com pressões de tempo, pressões da sua gerência, coordena pessoas que se dizem plenos e aprende novas ferramentas e novos frameworks. E eis que depois de algum tempo e mais projetos, ele percebe que é a pessoa que possui mais conhecimento no seu time. Neste momento, a síndrome do máximo local o atormenta. Ele é o melhor jogador de futebol da sua rua e então decide que é sênior.
• Este novo profissional sênior busca, novamente, posições maiores e maiores posições financeiras. Muitas vezes ele não encontra isso na empresa que o contratou como pleno. Novamente o seu CV está na rua e em breve ele consegue uma nova posição como sênior. Ele tem três ou quatro anos de experiência de mercado! Nos próximos 32 anos anos da sua vida profissional ele será sênior!

Este parece ser um sintoma mais presente na geração Y (pessoas que nasceram depois dos anos 70) do que na geração X (seus antecessores), mas isso é pura especulação minha.

O processo evolutivo da senioridade!

Mas o que é um profissional pleno ou um profissional sênior? Sem dúvida é difícil definir isso e eu claramente não tenho competência para isso. O que percebo, entretanto, é que habilidades e competências diversas devem estar presentes. Uma vasta experiência (medida em milhares de horas de projeto), um grande número de projetos entregues com sucesso (medido em dezenas), uma vasta formação acadêmica (medido no número de pós-graduações e cursos de aperfeiçoamentos), um forte quociente emocional e um reconhecimento sólido do mercado são atributos essenciais. Arrisco-me a dizer, entretanto, que talvez o atributo mais importante seja a humildade, afinal de contas, para reconhecer as próprias limitações e aprender continuamente.

Li recentemente um artigo que propõe um tema interessante ao discutir a personalidade de arquitetos de software e gerentes de projeto e a sua relação (normalmente tensa) em projetos de software. (The Tense Relation between Architect and Manager, Gerrit Muller).

Arquitetos e gerentes são peças fundamentais para o sucesso de um projeto e devem interagir fortemente em sinergia, como já apontado por Grady Booch em seu excelente livro Object Solutions, de 1995.

Um aspecto que Gerrit Muller endereça são os comportamentos associados a cada papel. Um resumo destas características é colocado abaixo:

• Arquitetos tem um escopo amplo em projeto e pouca autoridade formal. Gerentes, por sua vez, tem um escopo de atuação mais limitado e possuem muita autoridade formal.
• Arquitetos são independentes, criativos e curiosos. Gerentes são pragmáticos e focados em controles.
• Arquitetos encaram mudanças; vindas dos stakeholders, pressões de tempo e análise de problemas; como fatos da vida. Gerentes encaram mudanças como possíveis fontes de problemas e desvios financeiros.
• Arquitetos são motivados pela busca das melhores soluções. Gerentes são motivados por hierarquias e salários.

O autor coloca, finalmente, que arquitetos e gerentes devem buscar, conjuntamente, as seguintes técnicas para a melhoria do relacionamento e resolução destes problemas:

• Maior delegação de tarefas.
• Liderança ao invés de gerenciamento baseado em tarefas.
• Trabalho em time.
• Respeito mútuo.
• Reconhecimento da diversidade.
• Feedbacks contínuos.
• Estímulo à uma comunicação aberta e franca.

Recentemente, escrevi uma compilação de características de liderança de arquitetos de software, inspirados nos comportamentos de liderança descritos por Stephen Covey. Acredito que estas características podem ajudar a resolver este problema e promover como conseqüência maior sucesso aos projetos.

Creio que o maior valor do interessante artigo do Gerrit Muller é tornar claro que arquitetos e gerentes possuem sistemas de crenças e visões de mundo diferentes. Arquitetos e gerentes não podem cometer o erro de assumir que a outra parte irá pensar e agir como ele. Ao invés, gerentes e arquitetos devem conhecer a natureza da outra parte e desenvolver mecanismos pró-ativos para melhorar a comunicação e alinhamento nos projetos.

A Oracle disponibilizou recentemente um excelente relatório com tendências de adoção do BPM no mundo e também no Brasil.
Resumo aqui para os mais apressados as principais conclusões do relatório:

• O mercado BPM vive um crescimento estupendo, com uma perspectiva de crescimento de quase 10 vezes nos próximos anos, apesar da crise do mercado americano. As projeções indicam um crescimento do mercado de 500 milhões de US$ este ano para quase 6 bilhões até 2011.
• As iniciativas BPM na maior parte das organizações estão maturando, sendo usadas ainda primordialmente dentro de uma área ou unidade.
• O mercado de ferramentas está em franco processo de seleção natural. Ao invés de 150 ferramentas representativas (2006), temos agora apenas 25 ferramentas com representatividade (2008).
• Uso do BPM como ferramenta indireta para integrar aplicações (EAI) e para promover uma cultura de alinhamento a processos e escritórios de processos.
• Uso do BPM como um mecanismo de mudança cultural muito além da questão tecnológica, i.e., uma metodologia para remover silos e promover comunicação e alinhamento.
• Incentivo à combinação de BPM e SOA. Empresas que conjugaram as duas iniciativas tiveram resultados bem mais consistentes que empresas que adotaram apenas BPM.
• Aumento explosivo da colaboração entre pessoas com conceitos como CEP (Complex Event Processing) e ferramentas de EDA (Event Driven Architecture) para a montagem de empresas que respondem aos eventos (internos e externos) em tempo real.
• Dentro de TI, é o segmento que apresenta o maior crescimento no uso de ferramentas. Esta é uma clara mensagem para quem trabalha com TI. Se você nao está pensando em BPM e suítes BPM (BPMS), leia o relatório e repense a sua estratégia.

Para os que dispõe de mais tempo, mais interesse ou ambos em BPM, coloco aqui o link para relatório State of the Business Process Management Market 2008.

Uma das características chaves para um arquiteto é a criação de confiança e liderança técnica dentro de times de TI. Um excelente material a respeito sobre o estabelecimento de confiança e liderança, que adapto aqui para TI, foi escrito pelo Stephen M. R. Covey. Este material é simples e fornece conselhos bem pragmáticos sobre o tema. A sua prática, apesar de bastante complexa, pode gerar resultados fantásticos na dinâmica de um projeto.

Comportamentos do Caráter do Arquiteto

1. Ser franco. Ser honesto, dizer a verdade, usar linguagem simples, demonstrar integridade e não manipular pessoas estabelece conexões entre times e também com os envolvidos (clientes, patrocinadores, usuários e gerentes). Um projeto com pessoas desconectadas raramente irá cumprir seus objetivos. Um projeto com desenvolvedores versus usuários raramente resulta em relações ganha-ganha.
2. Demonstrar preocupação sincera. Um arquiteto deve ouvir e respeitar profundamente todo o time técnico. Ouvir requer tempo e disposição. Nào é possível e correto ser “eficiente” com o time de desenvolvimento, especialmente com iniciantes.
3. Criar Transparência. Um arquiteto não deve esconder informações do time. Ao invés, toda informação deve ser divulgada de forma aberta para críticas e melhorias.
4. Fazer dos Erros Acertos. Errar é humano. Reconhecer erros demonstra humildade. Pedir desculpas sinceras com rapidez demonstra grandeza.
5. Demonstrar Lealdade. É fundamental dar créditos às idéias de cada pessoa do seu time. Quando falar sobre qualquer pessoa do projeto (incluindo o cliente!), assuma que ele esteja presente.

   Comportamentos de Competência do Arquiteto

6. Gerar Resultados. Um arquiteto deve produzir resultados consistentes durante todo o projeto. Manter o cronograma no prazo e gerenciar o orçamento técnico do projeto são aspectos chave para demonstrar competência técnica. Se algo fugir do planejado, o arquiteto não deve inventar desculpas pelo ocorrido.
7. Melhorar Continuamente. Aumentar permanentemente os conhecimentos técnicos e habilidades é uma obrigação. O arquiteto deve ser um aprendiz eterno. Para isso, ele deve desenvolvedor sistemas de feedback formais e informais e aprender com este sistema. Parar no tempo e assumir que você se tornou sênior é um erro mortal.
8. Encarar a Realidade. Enfrente a realidade e não as pessoas, i.e., trate as questões difíceis do seu projeto abertamente e não as esconda ou se esconda delas. Um bom arquiteto deve assumir os desafios e buscar soluções coletivas com todo o time para resolvê-las.
9. Esclareça as Expectativas. Abrir e revelar expectativas, discuti-las diariamente com o time e validá-las é chave para exercer liderança técnica. Se necessário, renegocie as expectativas. O arquiteto não deve violar as expectativas e nunca assumir que elas estejam claras ou compartilhadas antes que ele as discuta.
10. Pratique a responsabilidade. Seja responsável pelos resultados, positivos ou negativos. Não apontar os dedos para os outros em situaçòes da responsabilidade de um arquiteto é fundamental. Um arquiteto deve ser claro sobre como comunicar as suas ações no projeto e também as ações do time.

    Comportamentos de Caráter e Competência do Arquiteto

11. Ouvir primeiro. Ouvir é difícil. Ouvir atentamente é muito difícil. Entretanto, um arquiteto deve aprender a ouvir, entender e gerar diagnósticos. Interromper pessoas no meio de uma explicação técnica é sinal de menosprezo e desprezo. Ao invés, o arquiteto não deve assumir que ele tenha todas as respostas ou questões. Pratique o “ouvir” no seu projeto.
12. Honrar seus acordos. Diga o que você irá fazer. Então faça o que você disse que iria fazer. Mantenha os compromissos a qualquer custo, uma vez que você os tenha feito com o seu time. Se você marcou uma reunião, esteja lá pontualmente. Se disse que irá responder um email, responda-o. O compromisso é sinal de honra. A ausência do compromisso quebra a confiança.
13. Estender a Confiança. Demonstrar a propensão à confiança com as pessoas que você tenha ganho a confiança é fundamental. O arquiteto deve aprender como estender a confiança a outras pessoas baseado na situação, risco e credibilidade.

Sinceramente, é mais fácil escrever ou falar sobre estes comportamentos do que praticá-los nos projetos. Entretanto, observei um exemplo de um arquiteto do meu círculo de amizades que (intuitivamente) praticou estes comportamentos em um projeto no primeiro semestre de 2008. O resultado foi estupendo. Um projeto de grande complexidade técnica e forte pressão de prazo foi entregue abaixo do orçamento, com pouquíssimos defeitos e no prazo.

Estou aprendendo sobre estes comportamentos. É difícil, mas posso dizer honestamente que quando percebo que pratiquei estes comportamentos em uma situação técnica no dia a dia, os resultados são visíveis. A eficácia aumenta a a eficiência também aumenta.

Para quem quiser buscar o artigo no original, deixo aqui a referência para o mesmo.

Pensamento do dia:

“If people know you care, it brings out the best in them.” - Richard Branson, Founder, , the Virgin Group

Redes sociais são excelentes. Unem pessoas, ajudam a criar a confiança entre elas e nos inspiram a evoluir tecnicamente. Neste contexto, divulgo aqui a excelente iniciativa sugerida pelo Adriano Tavares (e que tenho a honra de poder contribuir como criador também) de uma rede social para discussão de temas relacionados à arquitetura de software.

A rede se chama Pangea (o super-continente que ligava todos os continentes muitos e muitos anos atrás) e será um fórum permanente para reunir pessoas que tenham interesse em saber mais e trocar experiências sobre arquiteturas de software.

Como uma rede social, diversas comunidades serão criadas, de acordo com os interesses e afinidades dos membros da rede.

Algumas comunidades já foram criadas, mas esperamos que muitas outras sejam criadas.

Para quem gosta de arquitetura de software e quiser trocar experiências, basta seguir o link abaixo.

http://pangeanet.ning.com/

Exibir minha página em Pangea

Escrevi um artigo há um tempo através sobre conceitos básicos de BPM (Gerenciamento de Processos de Negócio). O BPM envolve um ciclo de vida técnico resumido na figura abaixo e contém um aspecto fundamental chamado de monitoração de processos de negócio (BAM - Business Activity Monitoring, em inglês).

Mas o que é o BAM? Em termos simples, O BAM permite o armazenamento, análise e exibição de informações estatísticas sobre a execução de processos de negócio.

Para entendermos o BAM, devemos lembrar que a metodologia BPM requer que todo processo de negócio seja mensurável, i.e., tenha a capacidade de ser medido através de métricas. Por exemplo, um processo de negócio de pré-venda poderia ser observado através do percentual de vendas fechadas, volume financeiro gerado ou do tempo médio em dias para finalização do processo. Um processo de negócio de fabricação de um produto em uma fábrica poderia ser medido através do percentual de produtos rejeitados pela área de qualidade (% de defeitos) ou também pelo tempo médio em semanas para a sua fabricação.

Dado esta premissa, que vem dos modelos mentais de metodologias que influenciaram o BPM, como o DMAIC Six Sigma, podemos explicar o mecanismo BAM. O BAM é um método que monitora todas as atividades de negócio, i.e., todos os processos de negócio que estejam em execução, e extrai medidas destes processos de negócio em observação.

Não devemos confundir, entretanto, o BAM com ferramentas. O BAM pode ser realizado por um analista de produção que observa toda a cadeia de pessoas, máquinas e sistemas enlaçadas por um processo de negócio e então mede através de processos estatísticos o desempenho deste processo. As medidas extraídas do processo são então comparadas com possíveis métricas pré-acordadas entre o time de análise, gerência e time de produção e eventuais desvios são analisados e tratados. O BAM permite, portanto, que acordos de qualidade entre o time de gerência e análise (SLAs) sejam monitorados e que um processo de gerência de nível de serviço (SLM) seja implementado sobre um determinado processo de negócio.

Ferramentas BAM

O BAM têm obtido popularidade devido a ferramentas BAM. Ferramentas BAM são softwares que monitoram continuamente “tempo real” ou em ciclos de eventos de monitoração como o desempenho de um processo se comporta frente às métricas definidas de um processo. Boas ferramentas de BAM devem oferecer as seguintes funcionalidades (em uma listagem não exaustiva):

• Facilidades para a definição de métricas de processos e um conjunto comum de métricas típicas já implementadas (ex: Custo, Tempo de resposta, Uso de Recursos Humanos, Uso de Equipamentos, Uso de Sistemas Computacionais).
• Facilidades para a coleta de medidas através de fontes de dados diversas (ex: arquivos, bases de dados e sistemas transacionais)
• Facilidades para a consolidação das medidas e transformação destas em métricas do processo. Estes dois últimos aspectos guardam relacionamento
  com ferramentas de ETL (Extração, Carga e Transformaçào), embora em um contexto diferente.

• Facilidades para geração de métricas em “tempo real”, i.e., observação do desempenho atual de um processo.
• Facilidades para a definição e monitoraçào de eventos de negócio. Um evento de negócio é um sinalizador de negócio usado para aumentar a velocidade e adaptação a mudanças de mercado e da saúde de uma organização ou área. Exemplos de eventos de negócio poderiam incluir uma queda acentuada de uma bolsa de valores, um novo contrato fechado ou um aumento súbito no volume de pedidos de produtos.
• Facilidades para a publicação de indicadores em portais e “dashboards”.
• Integrações com soluçÕes SOA e ferramentas como servidores de orquestração, servidores de eventos arquiteturais (EDA) e portais.
• Facilidades para a definição de SLA/SLM e geração de alarmes para a monitoração de desvios.

O BAM, obviamente, não deveria ser o ponto de entrada para uma organização que esteja começando uma iniciativa BPM, mas pode sem dúvida ser alcançada ao longo de uma implementação.

Para os interessados, coloco abaixo uma lista de referências sobre BAM:

• Jump-start business activity monitoring
• Série de 11 artigos sobre BAM com o IBM WebSphere Business Monitor. Independente da ferramenta, os artigos trazem informações valiosas sobre BAM.
• Blogs sobre BAM da TIBCO