Engraçado é que o estopim para todo esse trampo veio da noção do fundo do poço: num grupo de discussão, no 2º semestre do ano passado, alguém falou que o AN não serve para nada. Ou, em outras palavras, disse que “não via utilidade nos AN’s”.

Contei a “estorinha” no workshop e muitos pegaram carona na provocação: “você acredita nos AN’s e em sua aposta?” Eu disse que a melhor evidência estava na sala: lotada. Quando a Tempo Real Eventos lançou o workshop não tínhamos a menor idéia sobre qual seria a aceitação. Foi uma aposta mesmo. Seguida de uma gratificante surpresa.

“Abrir a ‘caixa preta’ que é a organização de TI das empresas”
– Gilson Silva

“Alinhar TI com o negócio”

• “O Alinhamento deve mostrar evoluções no plano de negócios”
• “O Alinhamento se mantém atualizado na medida em que o negócio evolui”
• “O Alinhamento ultrapassa obstáculos aos seus propósitos”
• “O Alinhamento é planejado”

– Paul Strassmann

E aí vieram SOA, BPM, ITIL, SOX… todas buscando, de uma forma ou de outra, o tal “alinhamento”. Por isso eu acredito tanto nos Arquitetos e Analistas. Arquitetos Corporativos (ou De Negócios) e Analistas de Negócios. Por isso eu acho que o BABoK desperdiça uma grande oportunidade. E que os trabalhos que falam que AN’s e AN’s de TI são “negócios” diferentes estão um tanto equivocados . Negócio é negócio. Ponto.

Momento “Catorze Zero Meia”

Leitores do finito interessados em participar da próxima edição do workshop “Formação para Analistas de Negócios” acabam de ganhar um belo incentivo: desconto de 10% em cima do preço promocional* (para inscrições realizadas até o dia 13/jul).

Para tanto, basta informar o código promocional (cpvfan) na página de inscrições.

1406 + “modelito vivarina”: todos os participantes terão acesso ao exclusivo grupo de discussões, e terão garantia de atualização da apostila até ela se transformar no prometido livro.

“Desgraça pouca é bobagem”, como a gente costuma falar aqui nas Geraes.

* Válido para os 20 primeiros.
(ps: Nunca pensei que fosse utilizar as detestáveis letrinhas miúdas…)

1. Talvez seja o primeiro AN de facto do Brasil. É um dos melhores, não tenho dúvidas. Aliás, ele é bem mais que um AN. Não sei se foi sorte dele ou azar nosso, mas alguns de seus maiores trabalhos foram realizados em Portugal, Espanha, Austrália, Nova Zelândia, África do Sul…
2. The Squandered Computer
   Paul A. Strassmann – The Information Economics Press (1997).
3. UML for the IT Business Analyst
   Howard Podeswa – Thomsom / PTR (2005).

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).

• TI agrega real valor ao plano de negócios;
• Não resiste às mudanças;
• Combate a resistência às mudanças; e
• É planejado.

Os três primeiros itens da lista são traduzidos em considerável ganho de Agilidade. SOA promete a criação de uma estrutura que reproduz fielmente, em mapeamento um-para-um, os processos e atividades de negócios. Tamanha aproximação deve gerar uma arquitetura flexível, que favorece as mudanças. Mas os ganhos possibilitados pela implementação de uma Arquitetura Orientada a Serviços não ocorrem por acaso ou de forma pontual. Uma implementação SOA é uma iniciativa de longo prazo – é a execução de um bem elaborado Plano Estratégico.

SOA é uma arquitetura de software. Uma arquitetura de software é “um conjunto de definições que descreve componentes de software e associa a funcionalidade do sistema a tais componentes. Descreve a estrutura técnica, restrições e características dos componentes e das interfaces entre eles. A arquitetura é uma ‘planta baixa’ para o sistema e um plano de alto nível para sua construção” .

Serviços em uma SOA são a representação direta de entidades, tarefas, atividades ou processos de negócio. Por representação direta entende-se a paridade em sua granularidade e o uso de um vocabulário comum, que deve ser a terminologia padrão do negócio. São características-chave de uma Arquitetura Orientada a Serviços:

• Acoplamento fraco dos serviços;
• Independência de tecnologias e protocolos;
• Uso irrestrito de padrões; e
• Incentivo à reutilização de ativos.

SOA é composta de quatro elementos principais: Frontends de Aplicações, Serviços, um Repositório de Serviços e um Mecanismo de Execução e Comunicação (Bus) para os serviços.

Os Frontends de Aplicações representam a “ponta do iceberg” de uma SOA. Eles são a interface dos serviços para os usuários finais. Portanto são de sua responsabilidade a iniciação e o controle da execução dos Serviços.

Os Serviços são componentes de software que representam um processo, entidade, atividade ou tarefa de negócio. É importante salientar que são componentes de alto nível, diferentes daqueles existentes em plataformas como o J2EE e o Microsoft .NET, que são muito granulares e mais orientados a tecnologia, não ao negócio. Existem quatro tipos de Serviços:

• Básicos: que representam os elementos básicos de um processo de negócio, como Entidades e Tarefas básicas de Negócios;
• Intermediários: são o único tipo de Serviço mais orientados a tecnologia em uma SOA. Fornecem pontes, conversores ou funcionalidades adicionais aos demais serviços;
• Processos: são os serviços que representam de forma direta um processo ou atividade de negócio, do início ao fim.
• Públicos: extensão aos serviços do tipo Processo que possibilita sua exposição para clientes (usuários) que estejam fora das fronteiras da organização.

Todo serviço, independente de seu tipo, é sempre composto por três partes principais, como ilustrado na Figura 1 acima. A primeira parte é um Contrato, um acordo que é fechado entre os consumidores de um serviço e seus provedores. Este documento explica os propósitos do serviço, contexto, regras de utilização, restrições, níveis de serviço esperados, além de apresentar uma definição formal da interface do serviço.

Interface esta que é implementada em separado, sendo o segundo elemento de construção de um serviço. Trata-se do único meio de comunicação com um serviço, seja seu cliente um frontend de uma aplicação ou outro serviço. A terceira e última parte de um Serviço é sua Implementação propriamente dita, através da realização da Lógica do Negócio e acesso e manutenção de seus Dados, de forma a atender todos os objetivos fixados no Contrato.

O Repositório armazena todos os Contratos dos Serviços disponíveis, o que o torna o ponto de partida para utilização destes. Além dos Contratos, o Repositório pode armazenar informações adicionais e mais específicas acerca dos serviços, como localização física, restrições de uso e segurança etc. Apesar de ser apresentado por alguns autores como um elemento opcional em uma SOA, o Repositório pode ser fator crítico de sucesso em grandes implementações, principalmente naquelas que envolverem a disponibilização de serviços do tipo Público.

Por fim temos o Mecanismo de Execução e Comunicação para os Serviços, ou simplesmente Bus, que interconecta todos os participantes de uma SOA, abstraindo a complexidade técnica que existe nas camadas inferiores. Um Bus pode ser constituído de várias tecnologias e/ou produtos, dependendo da infra-estrutura existente e dos requerimentos de distribuição dos serviços.

>>>>>>>>>> SOA #3 – É o Negócio, Estúpido!

2. “The Squandered Computer”, Paul Strassmann
The Information Economics Press (1997).
3. “Enterprise SOA – Service-Oriented Architecture Best Practices”, Dirk Krafzig, Karl Banke e Dirk Slama
Prentice Hall (PTR) (2005).