Foto de Kk+.

A classificação e organização dos ativos de software sugeridas no capítulo anterior indicam claramente a necessidade de um repositório. Um misto de ‘cofre’ e estoque que deve armazenar e facilitar a recuperação de todo o patrimônio catalogado. O padrão RAS apresenta uma especificação relativamente simples para a implementação de um repositório, que visa exclusivamente o armazenamento e a recuperação de ativos . O diagrama abaixo apresenta uma visão geral do serviço do repositório RAS:

Basicamente são definidos apenas dois serviços: a busca através de palavras-chave ou pelo caminho lógico do arquivo. Já existem algumas ferramentas* que atendem essa necessidade, todas oferecendo mais funcionalidades do que aquelas previstas na especificação RAS. A lista abaixo apresenta as funções que deveriam existir em todo repositório de ativos de software :

• Identificação e Descrição dos Ativos: todos os ativos devem ser apresentados de maneira homogênea, utilizando uma mesma interface.
• Cadastramento de Ativos: o repositório deve facilitar a inserção de novos itens.
• Navegação no Catálogo de Ativos: os usuários devem ter condições de navegar por todo o repositório, refinando as listas por Tipo de Ativo, Contexto, Histórico de Uso e todos os demais atributos que caracterizam um ativo.
• Busca Textual: os usuários devem ter condições de procurar por ativos a partir de trechos ou palavras que constem de seu nome, descrição ou demais atributos.
• Recuperação: a recuperação de um determinado ativo deve ser fácil e direta.
• Informação Completa: é crucial que a interface mostre todos os dados sobre o ativo. Suas dependências, por exemplo, devem ser nítidas para os usuários.
• Histórico: todo o histórico de uso do ativo (informações que não constam na especificação RAS original, conforme alertado no capítulo anterior) também deve ser de fácil acesso.
• Contabilidade: todos os números relativos ao uso do ativo (número de acessos, reuso efetivo etc) bem como os números gerais do próprio repositório (total de ativos, número de buscas bem e mal sucedidas etc) devem ser fornecidos.
• Controle de Acesso: todas as funcionalidades do repositório devem estar disponíveis para perfis específicos. Enquanto o Gestor da Biblioteca (mais sobre ele abaixo) tem controle total do repositório, os desenvolvedores não deveriam ter condições de alterar diretamente informações sobre os ativos, por exemplo.
• Gerenciamento de Versões: ativos podem ter várias versões diferentes. É fundamental que o repositório faça o controle de versões.
• Controle de Mudanças: assim como é importante que o repositório forneça suporte automático para a requisição, discussão, aceitação e implementação de mudanças nos ativos.
• Notificação de Mudanças: por fim, o repositório deveria ‘avisar’ todos os usuários quando uma mudança em determinado ativo for solicitada ou implementada.

É desejável que o repositório ofereça dois tipos distintos de interfaces com os usuários finais:

1. Totalmente integrada ao ambiente de desenvolvimento (IDE), facilitando a convivência dos desenvolvedores (analistas, programadores e testadores) com os ativos que podem ou devem ser utilizados naquele projeto;
2. Interface acessível via browser, para todas as tarefas de gerenciamento do repositório: manutenção do cadastro de ativos, relatórios e estatísticas etc.

A implantação de processos que levem ao reuso sistemático de ativos de software requer a existência de um repositório gerenciado. Abaixo são apresentados o perfil e as responsabilidades do profissional que deve gerenciar o repositório de ativos de software.

O Gestor da Biblioteca de Ativos (GBA)

Como foi colocado anteriormente nesta série, se o conteúdo do repositório for confuso e mal estruturado (mal padronizado), corre-se o risco de não aproveitar todas as oportunidades abertas pelo investimento. A organização deve delegar para um profissional ou um pequeno grupo a responsabilidade pelo gerenciamento do repositório de ativos.

Em alguns trabalhos são sugeridos dois perfis distintos: o Gestor de Ativos (Asset Manager) e o Bibliotecário (Asset Librarian). Quando o foco da iniciativa é a implantação do reuso sistemático , são sugeridos o Gestor de Reuso (Reuse Manager) e o Gestor da Biblioteca de Ativos (Asset Library Manager). Neste ponto será apresentado apenas o GBA. Os próximos capítulos desta série apresentarão os processos de reuso e o gerenciamento do ciclo de vida dos ativos, bem como os demais perfis demandados por eles.

O GBA “gerencia o repositório e sua configuração, e garante que os ativos estejam sempre disponíveis para os desenvolvedores” . Por ser um perfil pouco comum nas organizações de TI, cabe elencar algumas de suas principais características:

• É um programador e/ou analista de sistemas;
• Tem bons conhecimentos da principal arquitetura tecnológica em uso e, consequentemente, dos Ativos Horizontais que compõem o repositório;
• Domina o uso do repositório e de todas as ferramentas (IDE’s e afins) que o acessam;
• Domina e respeita o “Guia de Criação, Manutenção e Uso de Ativos”**;
• Mantém bom relacionamento com todos os desenvolvedores e coordenadores de projetos da organização;
• É organizado e disciplinado.

O gerenciamento do repositório não significa sua posse. O GBA apenas garante a disponibilidade e ‘limpeza’ do repositório. Mas não é ele quem determina o que pode e o que não pode ser realizado ali. As decisões pela inserção e deleção de ativos, por exemplo, fazem mais sentido quando são da alçada do grupo que cuida da Arquitetura Corporativa (AC). Cada equipe de projeto ou profissional pode sugerir adições ao repositório. Mas a palavra final deveria ser de um comitê central (AC).

O GBA também não tem poderes sobre um ativo. Cada ativo cadastrado possui um autor e um dono. Alterações, sugestões de melhorias ou problemas com um determinado ativo são tratadas diretamente com o seu proprietário (ou com um grupo de suporte, como será apresentado nos próximos capítulos). O GBA pode, no máximo, intermediar o processo. Sendo assim, quais seriam então as principais responsabilidades do GBA? Elas estão sumarizadas abaixo:

• Gerenciamento do Repositório: garantindo sua disponibilidade e performance. Sendo assim, relaciona-se (nas exceções e dúvidas) com todas as equipes de desenvolvimento;
• Publicação do Catálogo de Ativos: atualiza e publica o catálogo com todos os ativos constantes do repositório. Espera-se que uma boa ferramenta realize tal serviço, mas sua manipulação é uma responsabilidade do GBA;
• Manutenção do Catálogo: a inserção, atualização e exclusão de ativos é realizada pelo GBA. É uma forma de garantir que todas as diretrizes fixadas no “Guia”** serão respeitadas.

Referências:

1. RAS – Reusable Asset Specification – Versão 2.2
   Object Management Group (OMG) (05/Nov/2005).
2. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
3. Asset Lifecycle Management for Service-Oriented Architectures
   Grant Larsen e Jack Wilber.
   IBM/Rational (2005).
   

Observações:

* – Ferramentas: A Flashline, recentemente adquirida pela Bea, há tempos oferece um repositório desenhado especificamente para o reuso sistemático de ativos de software. Sourceforge (VA Software) e IBM também possuem produtos que podem ser adaptados para atender os requisitos apresentados neste artigo.

** – Guia de Criação, Manutenção e Uso de Ativos: um documento que seria elaborado pela equipe de Arquitetura Corporativa ou similar. Nos próximos capítulos desta série ele será apresentado em maiores detalhes.

No artigo anterior foi apresentada a “etiqueta” RAS (Reusable Asset Specification) , na sequência de uma definição sobre ativos de software e suas principais características. Neste post o padrão RAS será apresentado em maiores detalhes. O modelo abaixo apresenta uma visão geral dos elementos do Core RAS:

Clique para ampliar.

Existem 4 grandes grupos de informações sobre os ativos: Classificação, Solução, Uso e Ativos Relacionados. Abaixo serão apresentados os elementos de cada um dos grupos. Cabe lembrar que o Perfil e os Perfis Relacionados são extensões específicas de um ativo. Serão apresentados aqui apenas os elementos do Core RAS, ou seja, aqueles obrigatórios segundo o padrão.

Classificação

Trecho do padrão que trata da definição, identificação e contextualização de um ativo de software. Ele possui uma série de Descritores que apresentam suas características e qualidades. Enquanto o padrão RAS sugere o uso de uma descrição livre, alguns autores indicam o uso de uma classificação baseada em conjuntos de atributo+valor, como por exemplo: “tipo do ativo: Código”, “linguagem: Java” . Uma correta e ampla classificação facilita a busca por ativos em um repositório.

Assim como a apresentação de um ou mais Contextos. Na última versão publicada do padrão são apresentados alguns exemplos de categorias para contextos, como core, negócios, desenvolvimento, documentação etc. Interessante é que todos os exemplos referem-se a Artefatos e em sua maioria estão relacionados com produtos gerados em determinado momento do ciclo de vida de um ativo. São mais relevantes para a classificação de um ativo as informações acerca do ambiente (ambientes de desenvolvimento, testes e produção) e, em caso de ativos verticais, a descrição do(s) problema(s) de negócio que o ativo endereça.

Outra qualificação aparentemente ausente no padrão RAS* é uma indicação direta do Tipo do Ativo. Essa informação relaciona-se diretamente com o tipo de uso que pode ser feito daquele ativo. A lista abaixo apresenta exemplos de tipos de ativos, mostrando seu Tipo seguido do Tipo de Uso :

• Executável: Chamada direta.
• Biblioteca: Integração.
• Padrão (Pattern): Imitação.
• Frameworks: Customização.
• Pacotes de Software: Integração.
• Requisitos: Comparação.

*Obs.: Porém nada impede que esse tipo de classificação seja realizada através dos elementos Descritor e Grupo de Descritores.

Por fim há um grande elemento chamado Descrição que compila todas as informações sobre a classificação de um ativo, além de outras capturadas em outros grupos. Segundo o padrão, trata-se de um simples container para uma descrição apresentada em linguagem natural.

Solução

A solução oferecida por um ativo é representada por um ou mais Artefatos. Um artefato, segundo a especificação RAS, “é um produto que pode ser criado, armazenado e manipulado por produtores / consumidores de ativos e por ferramentas. Ele pode ser um arquivo armazenado no pacote do ativo ou uma entidade lógica que possui pelo menos um artefato que existe na forma de um arquivo” .

Na prática, a solução sempre será representada por um conjunto de artefatos com diferentes tipos de relacionamentos entre si. As relações de dependência são formalizadas em um elemento específico (Dependências / artifact-dependency)*. O tipo de dependência (em tempo de compilação ou em runtime, por exemplo) também pode ser especificado.

O padrão RAS fixa dois níveis de Tipos de Artefatos: Primários e Secundários. O primeiro vincula o artefato diretamente a um programa, usando a extensão do arquivo (.jar, .ppt, .htm, .js etc). Os tipos secundários são utilizados apenas para descrição. Como exemplos a especificação cita: Casos de Uso, Modelos etc.

Faz mais sentido que sejam colocadas aqui, no Contexto do Artefato (contexto-artefato / artifact-context), informações sobre o momento no ciclo de vida do ativo aquele artefato foi gerado. Outras informações, como ferramentas utilizadas, detalhes do ambiente (que se diferenciem daqueles fixados para o Ativo como um todo – na seção Classificação), também devem ser cadastradas neste elemento.

Finalmente, na seção Solução, há o Ponto de Variabilidade. Trata-se da indicação do(s) local(is) onde o artefato pode ser alterado. É indicado que se forneça um contexto, bem como uma referência que detalhe os tipos de alterações que podem ou devem ser feitas.

Uso

Nesta seção são fornecidas informações sobre a(s) forma(s) de uso e manipulação dos ativos. Condensa-se aqui, particularmente no elemento Atividade, todas as ações que podem ou devem ser executadas para o efetivo uso de um ativo e de seus artefatos. Uma atividade por ser vinculada a um artefato específico (atividade-artefato / artifact-activity) ou a todo o ativo (atividade-ativo / asset-activity). A atividade pode se referir a um contexto (ref-contexto / context-ref) específico, e pode ou deve indicar o ponto de variabilidade (variability-point-binding) ao qual se aplica.

É interessante como a descrição oficial da especificação RAS faz referências ao uso de ferramentas, particularmente nesta seção. Parece ser reflexo direto do perfil dos principais patrocinadores do padrão. No entanto, graças à extensibilidade da especificação, é relativamente simples ‘corrigir’ o padrão ou, colocando de outra forma, adequá-lo para as necessidades específicas de uma organização.

Nesta seção Uso, por exemplo, faz falta um Histórico de Uso do Ativo. Conhecer a história de um ativo é fundamental para uma eficaz avaliação do seu potencial e do retorno gerado por ele. O Histórico deveria indicar o “Contexto de Uso e os resultados obtidos (sucesso ou fracasso, facilidade de uso, melhorias necessárias, problemas encontrados no entendimento do ativo, testes, integração e adaptação do ativo, esforço requerido nessas tarefas, …)” .

Ativos Relacionados

A última seção do Core RAS cuida de vincular o ativo com todos os outros ativos que se relacionam direta ou indiretamente com ele. Um ativo de software, como colocado na especificação, “raramente existirá em isolamento”. Apesar do padrão indicar que o tipo de relacionamento entre ativos é totalmente aberto, ele indica que para quatro tipos de relacionamentos existem Valores Reservados. São eles :

• Aggregation: indica que o ativo ‘contém’ o ativo relacionado;
• Similar: o ativo possui características similares às daquele relacionado;
• Dependency: indica que o ativo referencia ou depende dos serviços ou artefatos do ativo relacionado;
• Parent: o ativo ‘é contido’ ou pertence ao ativo relacionado.

Cabe neste ponto alertar para a possibilidade de um risco: gerar um repositório de ativos bastante confuso. Um artefato pode ser tratado como um ativo em determinado contexto, mas pode ser um componente de outro ativo maior em outro momento. Vale lembrar que até um requisito pode ser tratado como um ativo propriamente dito. Tem-se assim a noção do tamanho que um repositório de ativos pode atingir. Parece indicado que a organização defina – particularmente nos momentos iniciais da implantação de processos de gestão e reuso de ativos de software – características mínimas e porte mínimo para que um determinado artefato ou conjunto de artefatos sejam tratados como ativos.

Referências:

1. RAS – Reusable Asset Specification – Versão 2.2
   Object Management Group (OMG) (05/Nov/2005).
2. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).

Observação importante: Para uma visão completa da especificação RAS, recomendo a sua leitura integral. A versão 2.2, publicada em novembro/2005, é um arquivo PDF com 121 páginas.

Não obtive NENHUM retorno na pequena pesquisa que fiz sobre a utilização do padrão RAS aqui no Brasil. Sei que as últimas versões das ferramentas IBM/Rational, por exemplo, usam RAS. Sei também que tais ferramentas possuem uma considerável base instalada por aqui. Mesmo assim, desconfio, RAS é uma feature ignorada. Aliás, como parece ser tudo que se relacione a “reuso de ativos de software”.

Aliás, tentei um contato com o RiSE (Reuse in Software Engineering Group), que, apesar do nome, é uma iniciativa tupiniquim vinculada ao CESAR e à UFPE. Resposta rápida: “desculpe a demora. os papers do RiSE voce pode pegar nos sites de ieee, acm, etc.”. Admiro o trabalho dos caras, mas queria entender porque é tudo tão fechado e difícil. Aliás, nem responderam meu último email, enviado em 21/dez. Parece ser mais fácil conversar com Scott Berkun, Martin Fowler e Grady Booch do que com algumas figuras daqui. Estranho, não? Mas deixa pra lá…

Seguinte: não queria “afundar” tanto assim, mas acho que na próxima parte desta série vou falar sobre os repositórios. Tentarei encaixar no mesmo artigo o job description do GBA, o nosso Gestor da Biblioteca de Ativos.

A crescente aceitação da proposta de Arquiteturas Orientadas a Serviços (SOA) fez com que voltasse para agendas e debates um velho tabu da área de TI: o Reuso de Ativos de Software. Uma pesquisa recente, tratando especificamente de SOA, mostra que a maioria das empresas espera reutilizar apenas 30% dos serviços criados. Apesar de 84% delas dizerem que a possibilidade de reutilização de ativos é uma das maiores promessas de uma SOA; uma das maiores justificativas para sua adoção. Vamos aproveitar o debate para tratar o tema de uma maneira mais aprofundada. Este post inaugura uma série sobre o assunto. Gestão de Ativos; Reuso Sistemático; Adequação de processos; RAS (Reusable Asset Specification); GBA (Gestor da Biblioteca de Ativos); dentre outros, serão tratados de maneira específica nos próximos artigos*.

O assunto é tão antigo e batido, com sucessivas ressurreições e decepções, que fará com que muitos profissionais da área simplesmente ignorem a discussão e a nova fase de oportunidades aberta pelo conceito SOA. Data de 1968 a primeira tentativa para tornar o reuso sistemático uma prática , uma disciplina obrigatória em Engenharia de Software. Muito tempo depois, de maneira menos impositiva, foi a vez da Orientação a Objetos e da Componentização proporem e facilitarem o reuso de ativos de software. A princípio, os resultados sempre foram desprezíveis. Quando havia algum resultado.

A reutilização de experiências e conhecimentos externos – normalmente apresentados como aplicações, frameworks, componentes, design patterns ou até mesmo código fonte – é prática corriqueira na maioria das organizações que desenvolvem sistemas atualmente. O grande problema, o tabu em torno do reuso de software, é o não aproveitamento dos ativos criados internamente. Qualquer tipo de ativo.

O reuso do capital intelectual – do conhecimento e da capacidade de aprendizado e inovação – é um desafio para todas as áreas de praticamente todo tipo de empresa. Não se trata de uma carência específica da área de TI, apesar de sua natural orientação a projetos e sua intimidade com tecnologias indicarem que seria teoricamente mais simples a adoção de métodos e ferramentas para uma excelente gestão de conhecimentos. Trata-se de uma área que tem muito a evoluir. Erros e falhas recorrentes indicam que o conhecimento não está fluindo de forma adequada. “Os que não conseguem lembrar-se do passado estão condenados a repeti-lo“, dizia George Santayana.

No entanto, de todos os ativos que formam o grande inventário da área de TI, aquele que parece mais esquecido ou, colocando de outra forma, relegado a um segundo plano, são os ativos de software. Seus co-irmãos palpáveis, notadamente o hardware e todas as instalações físicas, herdaram métodos e ferramental de controle de todos os outros ativos tangíveis de uma organização. Eles aparecem no controle patrimonial (nos sistemas de Ativo Fixo e Contabilidade) da empresa. Cadeiras, servidores e caminhões merecem uma “etiqueta” de patrimônio. Você usa, e reusa, aquilo que você sabe que possui. Quando conhece sua localização, utilidade, modos de uso, restrições, idade etc.

Autores como Robert Kaplan e David Norton, criadores do Balanced Scorecard, classificam os ativos de software como intangíveis . Talvez sejam exatamente a percebida intangibilidade e a infinita maleabilidade do software que façam com que ele seja um ativo muito mal tratado e pouco controlado. Outro motivo, sugerido por Paul Strassmann , seria a falsa idéia de que o ciclo de vida do software obedece aquele ditado pelo hardware (com uma total depreciação em um prazo de 4 anos). É sabido que algumas empresas, particularmente no ramo financeiro, possuem código com mais de duas décadas de vida.

“Sem o legado, cada geração começaria na idade da pedra.”
– Paul Strassmann

Visando à valorização dos ativos de software, Strassmann sugere que as organizações :

• Adotem ferramentas que forcem a construção de software a partir de um repositório de peças padrão reutilizáveis;
• Façam da acumulação e preservação dos ativos de software úteis um de seus principais objetivos;
• Ofereçam incentivos para que o staff de sistemas inclua a acumulação de ativos de software como um de seus objetivos-chave; e
• Aumentem a longevidade dos ativos de informação ao invés de aceitar a suposição de que eles não valerão nada após o período de breakeven.

Viabilidade

A era industrial se consolidou através do reuso de peças padrão. A economia de escala é indissociável do reuso. As linhas de montagem ganharam a forma que conhecemos hoje após a adoção de conceitos de reuso. O mercado de TI lançou suas “fábricas de software” mas parece ter se concentrado exclusivamente na parte (des)humana da metáfora.

Apesar do reuso sistemático ser considerado um claro indicador de maturidade , não há em propostas como o CMMI ou MPS.br uma área ou processo específico para incentivá-lo e controlá-lo. No RUP, amplamente divulgado e relativamente aceito, o reuso de ativos é citado como “facilitado” pelo processo . No entanto, não há uma única disciplina que tente fazer do reuso uma prática sistemática, intencional.

“Os ativos intelectuais, ao contrário dos ativos físicos, aumentam de valor com o uso.”
– James Brian Quinn

O mesmo se aplica para ativos de software (que são um tipo de ativo intelectual): quanto maior seu uso (e reuso), maior seu valor. Por isso causa estranheza, particularmente naqueles “não-letrados” na área, nossa incapacidade ou resistência em fazer do reuso uma prática central, obrigatória. Assim como parece estranha e extremamente pessimista a meta aferida na pesquisa citada no início deste artigo: a reutilização de 30% dos serviços em uma SOA. Casos documentados , anteriores à onda SOA, reportam ganhos de até 72% em organizações que adotaram o reuso de ativos de software como uma prática sistemática. Se sua viabilidade é provada em empresas que não têm no desenvolvimento de software uma atividade fim, o que dizer então daquelas que vivem de produzir e comercializar software?

===

* Como em alguns casos anteriores, este artigo é parte de um estudo/trabalho em desenvolvimento. Ao término da série será publicada uma compilação, em formato PDF, com as devidas revisões e considerando eventuais críticas e/ou sugestões recebidas. Sinta-se à vontade para participar.

===

Referências:

1. Outside the Box (blog de Todd Biske): Use or Reuse?
2. Software Reuse: Principles, Patterns, Prospects
   Mária Smolárová e Pavol Návrat
   Slovak University of Technology
3. Mapas Estratégicos
   Robert S. Kaplan e David P. Norton
   Editora Campus / Elsevier (2004).
4. The Squandered Computer
   Paul A. Strassmann
   The Information Economics Press (1997).
5. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
6. Hoje (11/Dez/2006) fiz uma consulta ao grupo de discussão CMM-Br. Tudo indica que o MPS.br receberá um processo específico para tratar de Reuso a partir de Abril/2007.
   Agradeço os colegas Rafael Prikladnicki e Marcio Pecegueiro do Amaral pelas informações.
7. The Rational Unified Process – An Introduction (Second Edition)
   Philippe Kruchten
   Addison-Wesley (2000).

A experiência prática de Fred Brooks, como citado anteriormente, foi com projetos mastodônticos: 1000 pessoas envolvidas ou mais. Mas ele lembra que desde aquela época os ‘gerentes de programação’ preferiam “pequenos e ‘agudos’ times formados por pessoas de ‘primeira classe'”. Brooks cita um estudo (de Sackman, Erikson e Grant) que mostra que um programador de ‘primeira classe’, que recebia US$20.000/ano, podia ser até 10 vezes mais produtivo que um programador de US$10.000/ano. Mas um pequeno grupo de ‘estrelas’ seria capaz de desenvolver um OS/360? Talvez em 10 ou 25 anos, segundo cálculos do autor. Por outro lado Brooks lembra que times grandes, orientados para a execução de um trabalho na base da ‘força bruta’, são “lentos, caros, ineficientes, e produzem sistemas que não possuem ‘integridade arquitetônica’. OS/360, Exec 8, Scope 6600, Multics, TSS, SAGE, etc. A lista é longa”. E “o dilema é cruel”, escreve Brooks. Haveria solução?

A sugestão de Brooks, baseada em uma proposta de Harlan Mills , dá título para o terceiro capítulo do seu livro, “O Time Cirúrgico”. Segundo ele, o time ideal é formado por:

• Programador Chefe (Cirurgião)
• Co-Piloto
• Administrador
• Editor
• Secretárias (duas)
• Bibliotecário
• Almoxarife
• Testador
• Advogado (da Linguagem)

Reparem bem. Nós temos praticamente 9 pessoas trabalhando para o programador! Dando-lhe “todo suporte que fará aumentar sua eficácia e produtividade”. Lembram-se que o Brooks também sugeria que alocássemos apenas 1/6 de nosso cronograma para tarefas de codificação? Outro mundo, não é mesmo? Pode e deve ser factível em um time cirúrgico de verdade mas aplica-se a equipes montadas para o desenvolvimento de sistemas?

O ‘cirurgião’ seria responsável pela execução de todas as tarefas principais daquela parte do projeto: sua especificação, design, codificação, testes e documentação. Não difere muito de alguns job descriptions e anúncios de vagas que ainda vemos por aí. Seria um “analista-programador” que, segundo Brooks, deveria ter 10 anos de experiência.

O mundo da programação mudou muito desde os tempos do COBOL e da PL/I. A complexidade e abrangência de nossas linguagens e arquiteturas de aplicações aumentaram ‘para os lados e para baixo’. E é cada vez mais comum que cada uma das tarefas listadas acima seja atribuída a um especialista. Uma divisão que é nítida em ‘fábricas de software’, por exemplo. Em caminho oposto, alguns advogados de métodos ágeis enaltecem a importância de um time formado por ‘generalistas’.

A analogia com equipes médicas reaparece em um artigo de Peter Drucker publicado pela Harvard Business Review em 1988, “O Advento da Nova Organização” . Segundo Drucker, “informação é dado investido de relevância e propósito. Por conseguinte, a conversão de dados em informação requer conhecimento. E conhecimento, por definição, é especializado. (Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender).”

Apesar de ser simpático aos chamados métodos ágeis, não acredito na possibilidade ou eficácia de um time composto por ‘generalistas’. Prefiro apostar em uma formação que valorize o perfil e a experiência de cada um de seus membros. No diagrama abaixo apresento um exemplo de um time desenhado para desenvolver uma aplicação web (ou ‘cliente/servidor n camadas’, como queiram):

O arquiteto é o novo ‘cirurgião’. É o dono e principal responsável por aquele projeto ou módulo. Mas só coloca ‘a mão na massa’, codificando, para transferir conhecimentos. Ocupa-se com a concepção e manutenção da integridade arquitetônica da solução. Ele é diretamente apoiado por cinco especialistas:

• Analista de Negócios (biz): cuida da coleta e organização dos requisitos, e apóia seu desenvolvimento, fazendo a ponte entre os usuários e a equipe de desenvolvimento;
• Desenvolvedor de Interfaces (front): é especialista em usabilidade e ‘manda bem’ em conceitos de arquitetura de informações. Hoje deve ‘brincar’ com AJAX (Javascript), Flash, HTML, CSS, ASP, JSP, JSF e afins.
• Desenvolvedor de Serviços (srv): domina orientação a objetos, componentização e, mais recentemente, serviços. É um programador clássico que, como tal, não leva o menor jeito com as ‘frescuras da camada de apresentação’.
• Arquiteto de Informações (data): uma versão remoçada dos DBA’s (administradores de bancos de dados). Domina o desenho e desenvolvimento de bases tradicionais, transacionais, mas também sabe quando lançar mão de sistemas gerenciadores de conteúdo e bases analíticas.
• Nosso antigo inimigo (infraestrutura): são os responsáveis por nossos servidores, redes, firewalls e outros brinquedinhos. Tê-los como parte da equipe de projeto desde os primeiros dias é uma prática que, com certeza, minimiza aquele ‘jogo de empurra’ que costuma acontecer um pouco antes ou um pouco depois do delivery da solução.

Mas… e o coordenador? No próximo sub-capítulo falo especificamente sobre ele e sua convivência com o arquiteto.

Agora, seguindo com o time cirúrgico proposto por Fred Brooks. O co-piloto que ele sugere é o ‘alter ego’ do cirurgião, capaz de executar qualquer tarefa atribuída à este. A única diferença é que o co-piloto seria menos experiente. Mas, ainda assim, funcionaria como um backup do cirurgião, inclusive representando-o em reuniões com outras equipes. Porém sua principal função é avaliar e discutir as idéias do programador-chefe. Lembra uma das práticas sugeridas pelo método conhecido como eXtreme Programming (XisPê – para os íntimos), a Pair Programming. A prática é polêmica e eu não disponho de dados que confirmem ou não as promessas de produtividade. Quero crer que a qualidade do código gerado realmente seja superior. Mas tenho algumas considerações que, por questão de tempo e espaço, tratarei em outra oportunidade.

O ‘Administrador’ sugerido por Brooks é um tipo de Coordenador do Projeto. Apesar do cirurgião ter a palavra final em todas as questões, é o administrador que cuida do dia-a-dia da gestão financeira, de pessoal, suprimentos etc. Mais sobre o assunto no sub-capítulo seguinte.

O ‘Editor’ é o responsável pela documentação. O cirurgião, segundo a proposta de Brooks, gera os documentos principais, tanto técnicos quanto aqueles para os usuários finais. Mas seria o editor o responsável pela compilação final, anexação de referências, bibliografia etc. É um luxo. Porém, ainda hoje brigamos para obter bons documentos de bons programadores, inutilmente.

O ‘Bibliotecário’ – ‘escriturário’, ou program clerk, como sugerido por Brooks, não faz muito sentido nos dias de hoje. Mas parecia ser crucial nos tempos dos cartões perfurados e das intermináveis listas impressas em formulários contínuos. No entanto eu acredito que toda organização que esteja buscando o reuso de seus ativos de software, ou implantando uma SOA (Arquitetura Orientada a Serviços), demandará a presença de um bibliotecário, um especialista que em outro artigo eu chamei de GBA (Gestor da Biblioteca de Ativos).

Se prestarmos atenção na complexidade dos atuais ambientes integrados de desenvolvimento (IDE’s – Integrated Development Environment), com seus frameworks, testes automáticos, integração com ferramentas de modelagem etc, veremos que pode fazer sentido o papel do ‘Almoxarife’, ou toolsmith, na nomenclatura original utilizada por Brooks. Um profissional especializado nas ferramentas e na sua adequação para cada tipo de projeto e função. Em equipes grandes ou em ‘fábricas’, parece ser uma função de grande utilidade.

O ‘Testador’ é o nosso “Engenheiro de Testes”, uma função que aos poucos vai se tornando mais comum. Pena que muitos ainda o confundam com um ‘programador que não deu certo’. Teste é coisa séria, tanto que Brooks, como mostramos na 1ª parte desta série, dedicaria 50% do esforço de um projeto exclusivamente para ele.

Por fim Brooks sugere a alocação de um ‘Advogado da Linguagem’. Creio que nossos espertíssimos e modernos IDE’s, nossos ‘testadores’ e, lógico, o arquiteto, eliminam a necessidade de um ‘language lawyer’. Advogado não, né?

continua…

===

1. Mills, H., “Chief Programmer teams, principles, and procedures”, IBM Federal Systems Division Report FSC 71-5108, Gaithersburg, Md., 1971.
2. Artigo republicado em “Gestão do Conhecimento” (Harvard Business Review on Knowledge Management), Editora Campus, 2001.

Um programa SOA deve ser dirigido por um Comitê Gestor, desenhado e populado especificamente para a iniciativa. Dentre as responsabilidades deste Comitê destacam-se :

• Estabelecimento e revisão das estruturas, processos e padrões utilizados tanto no âmbito do programa quanto no nível dos projetos;
• Acompanhamento da execução de todos os projetos SOA;
• Garantia do apoio e participação das áreas de negócio durante todo o programa;
• Manutenção do plano estratégico e do foco da iniciativa; e
• Execução de atividades de evangelização, como treinamento, coaching e divulgação dos benefícios e restrições do programa para toda a organização.

O Comitê Gestor de um programa SOA possui algumas funções bastante particulares. A figura 3 abaixo apresenta um modelo padrão desta estrutura, destacando seus principais atores:

O Gestor do Programa responde por ele perante toda a organização. Dada sua importância estratégica não será estranho se algumas empresas optarem por alocar o próprio CIO ou Diretor da área de TI nesta função. Ele é apoiado diretamente por um Engenheiro do Processo, que pode ser um representante do Escritório de Projetos (PMO – Project Management Office), caso exista. A uniformidade e respeito aos processos de desenvolvimento e manutenção são fatores críticos de sucesso. O Engenheiro do Processo deve garantir que tanto o programa quanto os projetos SOA estejam sendo executados dentro dos padrões estipulados pela corporação. Também é sua responsabilidade a indicação dos Coordenadores de Projetos, seu acompanhamento e apoio.

No entanto, o “braço direito” do gestor do programa é o Arquiteto SOA. Ele é o principal responsável técnico pela elaboração e implementação da arquitetura orientada a serviços. Devido a abrangência, complexidade e criticidade de tal iniciativa, o Arquiteto SOA compartilha suas responsabilidades com outros 5 arquitetos, cada um especialista em uma parte do programa.

O Arquiteto de Negócio é o principal representante do programa perante as áreas de negócio. Visto de outra maneira, ele também representa as comunidades usuárias no Comitê Gestor. Ele deve coletar, avaliar, apresentar e defender os requerimentos de negócio. Portanto ele faz uso, em alto nível, das disciplinas Modelagem de Negócios e Engenharia de Requisitos. Se estivessem representadas na figura 3 acima, as áreas de negócio estariam no lado esquerdo do desenho. Entende-se então que os membros do comitê gestor que se relacionam de maneira direta com a comunidade usuária, além do Arquiteto de Negócio, são o Gestor do Programa, o Engenheiro do Processo e o Arquiteto SOA. Mas sua representação é uma atribuição exclusiva do Arquiteto de Negócio.

O Gestor da Biblioteca de Ativos (GBA) é um personagem raríssimo nos ambientes e projetos de TI. Mas sua existência é fundamental para o sucesso de um empreendimento SOA. Além do gerenciamento do Repositório, apresentado anteriormente, o GBA também é responsável pelos principais processos de reutilização de ativos , ou seja: publicação e manutenção dos Contratos; introdução e coordenação do reuso de ativos; evolução do processo de reutilização etc. Com o tempo e conseqüente aumento no número de serviços disponíveis cresce também a importância do GBA.

O Arquiteto dos Frontends das Aplicações tem sua alocação no comitê justificada pelo fato destas interfaces serem o único ponto de interação dos usuários com a SOA. São críticas as atividades de padronização das interfaces e garantia de usabilidade, que são atribuições exclusivas deste arquiteto.

O Arquiteto de Serviços, por sua vez, concentra-se na padronização, acompanhamento do desenvolvimento e avaliação dos Serviços. Nos momentos iniciais do projeto são de sua responsabilidade a elaboração de padrões para os quatro tipos de Serviços existentes em uma SOA, ou seja: Básicos, Intermediários, Processos e Públicos.

Por fim, temos o Gestor da Infra-estrutura Tecnológica, o membro do comitê responsável por garantir que os recursos computacionais disponíveis sejam adequados para atender a demanda que SOA e seus serviços gerarão. Além do sizing e estudo de capacidade de carga dos servidores, redes e softwares de infra-estrutura, este Gestor também acompanha os serviços em ambiente de produção visando garantir os níveis de serviço esperados.

Percebe-se que o Comitê Gestor é praticamente uma representação do corpo gerencial de uma organização de TI. Em muitos casos talvez seja uma estrutura ainda mais sofisticada e completa. Acontece que em um “mundo ideal”, quando SOA encontra-se em estágio avançado de maturidade e todos os processos de negócio são representados por Serviços, o comitê gestor do programa SOA torna-se praticamente a equipe de gestão de toda a organização de TI. Apesar de ser um conceito relativamente novo, alguns casos de sucesso comprovam que tal “metamorfose” é uma conseqüência bastante plausível de uma implementação SOA bem sucedida. É curioso notar também que em uma situação onde a empresa decide pela total terceirização de sua área de TI, as 8 funções apresentadas acima talvez sejam as únicas que a empresa decida manter internamente. Para não correr o risco de perder o alinhamento de TI com o negócio.

>>>>>>>>>> SOA #5 – Processos

3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).
4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
Springer (2002).