Em 2007 comecei a ter contato com metodologias ágeis e com SOA, tudo de forma muito tímida ainda, lendo isso, aquilo, mas o suficiente pra constatar 3 coisas:

1 – Eu não precisava “modelar tudo em UML” pra depois programar de novo em algo que compilasse.
2 – Testes automatizados são tão importantes, mas tão importantes, que até pra modelar servem.
3 – SOA segue adiante o caminho iniciado pelo Component-Based Design, dando mais foco no negócio e com uma visão mais corporativa.

Em 2008 comecei a ver alguma coisa de Domain-Driven Design na internet. Mesmo sendo um cara que “curte” modelagem, não dei muita importância. Achava que era apenas um novo nome para uma mistura de CBD com SOA. Só lendo o livro do Evans em 2009, que foi publicado em 2003, é que passei a ver benefícios com DDD, devido à forma como o autor amarrou e organizou uma serie de conceitos e técnicas úteis a modelagem de domínio.

Estamos em 2010.
Perceberam alguma coisa? Não?

Eu sou um cara técnico, curto modelagem de software e não é raro eu estar lendo algo sobre isso. Mesmo assim, só fui conhecer em 2005, algo que já existia desde 2000 e só fui entender em 2007/2009 coisas que começaram em 2003.

Eu curto estudar assuntos técnicos sobre modelagem.
Mas isso não evitou que eu acumulasse débitos técnicos por anos!

Agora imagine o seu gerente e o gerente do seu gerente. Provavelmente eles não sabem o que significam 10% dos termos usados nesse post até agora.

Então, por quê você acha que vai convencê-los a deixar você usar SOA, DDD, TDD, XP, etc, etc…?
Vou piorar as coisas.
Por que você acha que toda uma empresa vai passar a adotar alguma dessas siglas, bancando custos de treinamento, mudanças culturais e perdas de produtividade iniciais?

Eu não tenho 1 ou 2 anos pra convencer meu gerente de que usar X é legal pra empresa. Pior, ele provavelmente não leu os livros que li nem fez os cursos que fiz, então eu precisaria de mais do que 1 ou 2 anos.
Seu gerente, o gerente do seu gerente e daí por diante, são pessoas que leram outros livros, que tem outras preocupações.
Você precisa falar a língua deles.
Você precisa provar que as suas idéias sobre modelagem de software são rentáveis.

Softwares não nascem ou sofrem modificações “do nada”.

Esquema de Exemplo - Telecom

Imagine uma empresa de telecom com alguns setores específicos.
Essa empresa, assim como qualquer outra, de qualquer outro ramo é movida por processos de negócio e tem metas a serem alcançadas.
Tanto os processos quanto as metas podem ser definidos nos mais altos aos mais baixos níveis de detalhe na empresa.
A figura acima destaca um processo bem macro, chamado “pagamento de conta”. Ela também mostra que existem uma serie de sistemas e serviços, construídos para fazer esse processo fluir.
Se for lançada uma meta visando a diminuição do consumo de papel na empresa e o processo de “pagamento de conta” for um dos que precisam se adequar a meta, alterações em sistemas e serviços legados serão necessárias.
Solicitações serão feitas ao pessoal de TI para atender essa demanda.

Mas, por uma triste coincidência, os sistemas envolvidos estão cheios de dependências cíclicas, redundâncias de lógica de negócio, excesso de responsabilidades e interfaces incoerentes com seus propósitos de negócio.
Sendo assim, sua equipe levou um baita tempo extra só pra entender como os sistemas funcionavam, fora o tempo pra promover as alterações em si. O que alias, acabou gerando mais trabalho, porque como os sistemas não estavam cobertos por testes automatizados, muitos bugs só foram percebidos tardiamente e um loop infinito de “corrige-e-estraga” se formou.

Você consegue mensurar quanto de $$ está sendo gasto atendendo essa demanda?
Consegue identificar uma relação entre o que está sendo gasto e o que seria gasto, caso as tais “siglas” que você queria colocar na empresa, tivessem sido usadas na construção desses sistemas?

Você consegue achar outros exemplos na sua empresa, que cheguem a conclusões parecidas?

Sim? Então você consegue provar que investir no que você fala, pode ser uma boa idéia.

Não, eu não estou fugindo do tema desse blog e relatando um desfecho comum para os engarrafamentos de 1 hora no aterro do flamengo ( o tempo normal pra atravessa-lo é de 5 min).

Quando se desenvolve software para uma grande corporação, não é raro se deparar com essa situação ai do diálogo. No papel do policial normalmente está algum membro da EIB (Equipe de Infra-estrutura Básica) e na pele do motorista está algum desenvolvedor com a inevitável missão de submeter um sistema (ou pedaço de um) à aprovação da EIB.

Uma EIB normalmente é composta por um conjunto de pessoas, onde cada uma tem uma aptidão específica, como administração de banco de dados, ou arquitetura SOA por exemplo. Muitas vezes uma EIB é até composta por um conjunto de equipes menores, cada qual com sua especialidade. Mas enfim, a função dessa galera de infra é dar apoio as equipes de desenvolvimento de software, criando diretrizes e convenções corporativas, as quais devem ser seguidas pelas equipes de desenvolvimento.

Existem duas formas de se trabalhar essa questão “EIB vs equipes de desenvolvimento”:

1 – Colocando uma contra a outra nessa estratégia de BLITZ CORPORATIVA, onde o pessoal de EIB apenas gera um mar de documentos-diretrizes, envia esse “manual de trânsito” para as equipes de desenvolvimento e marca uma data (normalmente ao final de alguma entrega importante) para revistar (ops!) digo….analisar, o trabalho da galera de desenvolvimento.

2 – Promovendo a comunicação e a humildade (valores da modelagem ágil) entre ambas as partes. Isso se faz inserindo as pessoas de EIB em determinados projetos de desenvolvimento por algum período de tempo, fazendo com que elas compartilhem sua maturidade profissional nas áreas em que se especializaram. Assim, as diretrizes corporativas passam a ser amadurecidas, repassadas e colocadas em prática em um cenário real. De quebra, ainda se cria um ambiente amigável e colaborativo entre as partes. Isso funciona! Dia desses estava conversando sobre isso com o Gustavo Serafim e ele diz estar tendo bons resultados com essa abordagem.

Ah! não posso deixar de dizer isso. Um grande risco de insucesso que se corre usando essa segunda abordagem, é colocando pessoas com pouca ou nenhuma habilidade de comunicação na EIB. Para isso funcionar é preciso ter profissionais bons tecnicamente mas que sejam sociáveis também. Já imaginou a pessoa ser apresentada como nova especialista XPTO pra apoiar o projeto durante algumas semanas, daí após essas semanas sem falar um “ah” ela manda um “manual de trânsito” por e-mail e some?

Ok. Vamos produzir SADs em nossos projetos então!
Mas….
Porque tendemos a achar que esse documento também é muito bom para comunicar (informar, ensinar) a própria equipe envolvida atualmente no projeto sobre a arquitetura do mesmo? Pergunto isso justamente pelas experiências que tive nos projetos em que o usei. Nesses projetos, o principal movitador de criação do SAD era a ideia de disseminar o conhecimento referente a arquitetura do sistema para os membros da equipe de desenvolvimento, que na maioria das vezes, estavam unidos em um mesmo local.

….
Pra falar a verdade, na maioria das vezes a “equipe de desenvovimento” trabalhava remotamente (estratégia “fábrica de código”), então problemas como falha de comunicação, modelagem excessiva e eventualmente atrasos faziam com que a “fábrica” fosse transferida para o mesmo local físico onde ficavam os outros membros da equipe, ou então, os “analistas”, “arquitetos” e demais “especialistas “ acabavam por produzir software de verdade.
….

Nosso relacionamento com o SAD acaba sendo mais ou menos assim:

A equipe de modelagem e o arquiteto se reuniam no inicio do projeto e discutiam a arquitetura base do sistema rabiscando modelos em quadros. A partir dai o arquiteto se responsabilizava pela criação do SAD, como base no que foi discutido na reunião e por mantê-lo atualizado durante o desenvolvimento do sistema.
Sempre que alguma nova questão arquitetural surgia, ou era alterada, essa informação era passada por e-mail ou através de reuniões rápidas com a equipe, utilizando uma sala com um quadro pra rabiscar ou mesmo uma baia de algum dos desenvolvedores com algumas folhas de papel. Depois disso, o arquiteto arrumava algum tempo pra atualizar o SAD com textos e diagramas UML mais formais.

Agora me diga. Quem mais alem do arquiteto, teve realmente necessidade de manter um contato continuo com o SAD durante o tempo de desenvolvimento do sistema? Ninguém.
Então, pra que criar esse documento no inicio do projeto e continuar dando manutenção nele enquanto o sistema ainda está sendo feito, se ele não é a forma mais direta, mais viável, de se comunicar questões arquiteturais pra sua própria equipe?
Seu cliente é que pode precisar dele, no final do projeto, como um guia arquitetural para novos desenvolvedores que possam vir a dar manutenção no sistema. Alias, seu cliente é que deve decidir se esse documento deve ou não ser produzido, afinal, quem está pagando é ele.
Então, se seu cliente decidir que é valido ter um SAD (e eu creio que seja) atrase a sua criação o máximo que puder, você não vai precisar dele pra dizer algo as pessoas que trabalham com você. Seja ágil e documente somente o necessário e quando necessário.