Resumo e comentário sobre o artigo “Softwares´s Chronic Crisis “

O autor inicia a crônica afirmando que, apesar dos 50 anos de progresso no desenvolvimento de Software (isto em 1994) a indústria do software estava a décadas de alcançar a maturidade de outras áreas da engenharia, sendo que era preciso mudar rapidamente aquele cenário para suprir as demandas da nova sociedade da era da informação.
Ele cita o exemplo do Aeroporto de Denver, uma obra prima da engenharia (civil) moderna, que simplesmente não pode entrar em funcionamento na data prevista e teve atrasos de vários meses por culpa dos problemas em um software de 193 milhões de dólares, o qual deveria fazer o controle automático das bagagens, chegando no auge da crise a gerar um prejuízo de 1,1 milhão de dólares/dia em juros e custos operacionais.
Naquela época, estudos mostravam que para cada seis grandes sistemas que eram colocados em operação dois outros eram cancelados. Em média, metade dos projetos de desenvolvimento de software estouravam seu cronograma, e, para os considerados grandes projetos, esta média era ainda pior.
Três quartos de todos os grandes sistemas apresentavam falhas de operação, seja por não funcionarem como o inicialmente previsto ou porque sequer eram usados.
O autor mostrou que já na década de 60 (1968) um comitê de 50 especialistas nas diversas áreas de TI, definiu que o desenvolvimento de software deveria seguir uma sistemática disciplinada e quantificável para o seu desenvolvimento, operação e manutenção. Esta sistemática foi cunhada de Engenharia de Software. Porém, em 1994, 25 anos depois, nada havia mudado e o desenvolvimento de software ainda era artesanal.
Em 1994 os cientistas da computação sabiam que haveriam mudanças profundas no uso de computadores pela sociedade, e, para que o software pudesse responder a estas mudanças, seriam necessárias também mudanças profundas. Porém, o que se via era um processo meio sem rumo, como dunas que se movem ao sabor dos ventos e sem direção definida.
As fundações da programação tradicional estavam ruindo enquanto o hardware se desenvolvia cada vez mais rapidamente.
Não se podia mais aceitar software sem qualidade. A afirmação amplamente aceita na época de que todo software terá algum tipo de falha precisava mudar. Imagina a gente aceitar uma afirmação de todo prédio um dia vai ruir, é inimaginável.
A quantidade de código em produtos de consumo de massa como aparelhos eletrônicos, carros, eletrodomésticos, entre outros estva se duplicando a cada dois anos e não se poderiam aceitar falhas.
Por outro lado não era muito fácil desenvolver sistemas sem erros pois esta era e ainda é uma atividade complexa. O autor cita o exemplo de um software de controle do satélite Clementine desenvolvido pelo Departamento de Defesa Americano – DOD. O DOD aplica testes rigorosos e caros para garantir a qualidade e a confiabilidade dos software embarcados, mas, mesmo assim um “bug” no programa fez com que o satélite não conseguisse se fixar na órbita lunar planejada.
O motivo sempre citado era a dificuldade de simulação de todos os cenários operacionais possíveis e isto valia para qualquer aplicação, seja científica ou comercial.
Por outro lado, as novas demandas, principalmente no mundo dos negócios, que exigiam sistemas cada vez mais complexos e versáteis, passaram a ser um desafio ainda maior para os desenvolvedores.
Infelizmente existem relatados mais casos de insucesso que o contrário. Em junho de 1994 a IBM fez uma pesquisa em 24 grandes companhias, líderes nos seus setores, que tinham desenvolvido grandes sistemas distribuídos. O resultado, desanimador, mostrou que 55% dos projetos custaram mais do que o esperado, 68% estouraram o cronograma e 88% tiveram que ser substancialmente redesenhados. Os resultados poderiam ser ainda mais desanimadores se eles estivessem incluído questões sobre a confiabilidade dos sistemas que forma implantados.
A conclusão na época era clara: “É necessário mudar a forma como os programadores trabalham”. As demandas estão cada vez mais complexas, sistemas com mais de 1 milhão de linhas de código, distribuídos sobre centenas de modernas e sofisticadas plataformas de hardware com eventos em tempo real. Num sistema deste porte, para o controle do tráfego aéreo por exemplo, um pequeno erro poderia se tornar uma ameaça à segurança pública.
Por outro lado, os custos para o desenvolvimento de software estavam aumentando de forma estratosférica, beirando o nível proibitivo. Todos estes problemas levaram a conclusão de que era necessária uma mudança de rumo radical ma maneira como o software era desenvolvido, de forma a ficar comptível com as demais áreas da engenharia, ou seja, buscar uma metodologia que permitisse entender como medir consistentemente e qualitativamente o processo de desenvolvimento de software bem como a densidade de erros e a produtividade dos programadores.
Uma das primeiras tentativas na busca da melhoria dos processos de desenvolvimento de software foi a introdução do modelo CMM – “Capability Maturity Model”, o qual buscava excelência e qualidade no processo de desenvolvimento de software.
O modelo é composto de 5 níveis de maturidade, sendo o primeiro deles caracterizado pela ausência de uma metodologia padrão de desenvolvimento e o maior (nível 5) considerado como processo de excelência e melhoria contínua. Pesquisas na época indicaram que aproximadamente 75% das empresas estavam no nível 1, uma clara demosntração do “porquê” da baixa qualidade do software.
É um modelo que no quarto e no quinto nível se preocupa com a avaliação quantitativa do software, ou seja, o uso de métricas para avaliar onde o processo pode ser melhorado.
Por outro lado, mesmo projetos muito bem conduzidos podem levar a erros. A arte de programar também implica em retirar erros dos programas, e, quanto mais cedo estes “bugs” forem tratados, menores as chances de causarem ameaças. Os “bugs” devastadores são aqueles detectados na fase final ou fase de entrega.
Algumas empresas, como a Microsoft, lançavamm versões beta dos seus softwares, distribuindo para milhares de voluntários que os testavamm. Mas isto era e ainda é caro e complicado para a grande maioria dos aplicativos de software.
Pesquisadores formulavam estratégias para descobrir e atacar “bugs” logo no início do projeto evitando assim que se propagassem. Uma maneira prática de fazer isto era através da prototipação, a qual permite aos usuários ou clientes do sistema validarem os processos antes ainda da codificação. Por outro lado, protótipos são somente modelos e a maioria dos “bugs” só é detectada após o processo de codificação.
Outra saída estva surgindo do domínio da matemática, através do conjunto de ferramentas providos pela teoria da matemática e do cálculo de predicados. Eles traduziam especificações e programas para métodos formais que ajudavam a provar a corretude dos algoritmos usados.
Embora estes métodos formais consigam provar que um algoritmo está correto os testes funcionais ainda são necessários pois podem ocorrer erros na modelagem dos métodos formais além do que, estes métodos somente podem garantir que um software está de acordo com a especificação mas ele não pode prever as surpresas que o ambiente operacional pode trazer.
Uma abordagem de sucesso conhecida como “sala limpa” estava sendo analisada. O objetivo era usar técnicas rigorosas de engenharia de software de maneira a garantir que o produto sairia perfeito já na primeira tentativa. O sistema é decomposto em partes menores e estes módulos são testados forma exaustiva antes de integrá-los aos demais. Nenhuma sujeira fica debaixo do tapete.
Isto implica em mudar a cultura em relação a testes. Em vez de ficar testando os módulos da maneira como o programador acha que eles serão usados, deverá ser definido e criado um conjunto de casos de testes muito bem planejados. Estes casos de testes não seriam restritos a funcionalidade do módulo em si, mas se preocupam também com a integração e a dependência entre eles. É um processo que testa, “retesta” e testa novamente. Depois de cada fase de testes existe uma fase de análise e validação dos resultados.
Mas não existe uma solução mágica, ou “bala de prata” na metáfora do autor. Desde a década de 60 tinham surgido dúzias de novas tecnologias desenvolvidas com a intenção de aumentar a produtividade dos programadores. Entre elas se destacavam a programação estruturada, ferramentas CASE, orientação a objetos entre outros.
Mesmo assim alguns cientistas e pesquisadores ainda não enxergavam melhorias na produtividade. Outros, como o professor Richard A De Millo da Universidade de Purdue, tinham uma visão diferente, afirmando que as mudanças estavam acontecendo, mas não existia uma definição clara do que seria este aumento de produtividade e quais métricas deveriam ser usadas.
Em relação a gerar código, a produção em 1994 era no mínimo o dobro da apresentada na década de 70. Por outro lado, menos de 10% das companhias americanas mediam a produtividade dos seus programadores.
Mesmo as que mediam não usavam um padrão útil de medida. A mais usada era o número de linhas de código por programador/mês. O problema é que existiam várias linguagens diferentes e não era possível ou viável comparar a produtividade de dois programadores em termos de linhas de código se um codificava em “C” e o outro em ADA, por exemplo.
O fato era que, naquela época, apesar de se falar muito em engenharia de software, esta estava muito aquém das demais tradicionais e maduras áreas da engenharia. Não existia um “handbook” de engenharia de software padronizado e único, os erros de projetos eram repetidos um após outro.
Os pesquisadores e cientistas pregavam a necessidade do Governo tomar a frente do processo de pesquisa e criação de metodologias padrão pois isto envolvia altos investimentos. Havia também a necessidade de criar grandes laboratórios de experimentação para que os pesquisadores e estudantes das Universidades pudessem testar em bancada estas novas propostas.
A idéia, já naquela época, era criar as linhas de produção de software, desenvolvendo componentes intercambiáveis, independentes de plataforma de hardware ou sistema operacional. Os programadores vinham por décadas tentando criar bibliotecas de componentes desenvolvidos. O problema era que estes ficavam rapidamente obsoletos em relação à rápida evolução do hardware e dos sistemas operacionais. Os investimentos na época eram direcionados no sentido de implementar o processo de componentização de software e estes componentes deveriam ser facilmente intercambiáveis para se adequar às mudanças de plataformas e ambientes de negócio.
Até o início dos anos 90 as empresas americanas, como a Microsoft, dominavam a produção de código. Sozinha, a Microsoft produzia durante um ano mais código de computador do que um conjunto de 100 nações juntas.
As mudanças começaram a acontecer quando vários países, principalmente no lado oriental do globo, como a Índia por exemplo, com o apoio de seus governos entraram firmes na produção de software, tirando a hegemonia dos Estados Unidos.
Muitas grandes companhias abriram subsidiárias na Índia com o objetivo de produzir software a um custo menor. O salário dos programadores indianos chegava a ser 8 vezes menor do que nos EUA e isto não implicava em menor qualidade pois a mão-de-obra indiana era altamente capacitada.
Outra grande vantagem eram os fuso horários pois os trabalhadores indianos poderiam corrigir software enquanto os americanos dormiam. No dia seguinte tudo estava funcionando.
Por fim, o autor esperava que uma combinação entre boas práticas em processos de negócios e ferramentas avançadas de tecnologia e componentização poderiam reverter a situação corrente na época em relação aos softwares ruins, ou seja, resolver a famosa crise do software, pois, se nada fosse feito, o desenvolvimento de software iria dificultar o crescimento da indústria e demais áreas de negócios.

Comentários:

Passados 13 anos desde a publicação do artigo, pode-se dizer que ocorreram melhorias nos processos e nas tecnologias de desenvolvimento de software, inclusive com a consolidação de algumas tecnologias que eram avaliadas na época. Porém, as queixas em relação à baixa produtividade e também sobre projetos que falham, continuam altas.
O Standish Group publicou em 2006 os resultados de uma pesquisa que mostrou que somente 35% dos projetos de desenvolvimento de software que foram iniciados tiveram sucesso, ou seja dois terços de falhas. Números muito parecidos com 1994. Este número muito alto levou Grady Brook, um dos pais da UML, a declarar que “uma doença que dure tanto tempo quanto esta, francamente, deveria ser considerada uma normalidade”.
A Engenharia de Software evoluiu, novas técnicas e processos, comprovados em laboratórios, melhoraram consideravelmente o processo de desenvolvimento de software. Pode-se afirmar que software hoje é desenvolvido ou projetado por engenharia, não mais manufaturado no sentido clássico.
Orientação a Objeto, Inteligência Artificial, Redes Neurais, Computação Paralela, Ferramentas CASE, UML, entre outras, que em 1994 ainda eram promessas, hoje são largamente usadas na prática.
Outro conceito que ainda era pouquíssimo desenvolvido na época e hoje é largamente usado são as Fábricas de Software. A produção de software segue o conceito de linha de produção, com reutilização, componentização entre outros, o que faz diminuir consideravelmente o “lead time” de desenvolvimento de software.
Por outro lado a complexidade dos problemas também cresceu. A Internet e o Comércio Eletrônico, nem citados no artigo, explodiram. Hoje os negócios exigem sistemas distribuídos em larga escala, conectados de forma colaborativa, rodando em plataformas distintas, desenvolvidos com tecnologias distintas, trocando informações em tempo real para mover os negócios e porque não dizer o mundo, tudo isto sobre a Internet, uma rede que conecta milhões de usuários ao redor do Globo e, apesar de versátil, é totalmente insegura. Não é errado dizer que quase nenhum negócio no mundo funciona sem o apoio dos sistemas de informação.
O que se observa hoje é que a baixa produtividade das pessoas que usam sistemas de informação ou mesmo sistemas de informação que não funcionam adequadamente e não dão os resultados esperados, são causados, na sua grande maioria, pela falta de alinhamento dos sistemas às estratégias de negócios das empresas bem como o mau uso das ferramentas disponíveis para o desenvolvimento de sistemas. A tecnologia não deve ser mais considerada a vilã.
Da mesma forma que os especialistas afirmam que o aumento da produtividade relacionada a implantação de sistemas de informação é mais o fruto na mudança e otimização dos processos do que a tecnologia por si só, pois esta produz um aumento marginal, podemos também afirmar que a baixa produtividade não é culpa da tecnologia ou dos sistemas, mas das mudanças inadequadas nos processos de negócio. Os manuais de engenharia estão aí, o problema é que não são corretamente usados pelos desenvolvedores.
Outro problema está relacionado aos famosos e difundidos “softwares de prateleira” para gestão de negócios, os quais são usados pela maioria das empresas.
Eles são bem desenvolvidos, seguem os conceitos da moderna engenharia de software, mas eles acabam engessando os negócios ou mesmo modificando a maneira como as pessoas trabalham. As empresas são obrigadas a se adequarem aos modelos de negócios implementados nestes sistemas, desfigurando seu modelo de atuação e eliminando diferenciais competitivos.
Em muitos casos ocorre a falta de comprometimento dos executivos de negócios com a definição e implantação destes sistemas, fato este que contribui para a implantação de sistemas pouco adequados ao negócio o que acaba causando um impacto negativo na produtividade.
Mas, mesmo em relação aos problemas de falta de gestão estratégica da TI, as mudanças estão ocorrendo. Os modelos de govenança de TI que prometem colocar ordem em todo o processo de definição, modelagem, implantação e operação de sistemas de informação, estão sendo adotados em larga escala pelas empresas, seja por necessidade, seja por força da lei (exemplo da lei SOX).
As empresas estão aprendendo que, seja através de equipes internas de TI, seja através de processos de terceirização, é importante investir em profissionais capacitados a usar estas novas tecnologias na sua plenitude. A informação é hoje um dos principais ativos das empresas e os sistemas que manipulam estas informações não podem ficar sob a responsabilidade de amadores.
A união da governança de TI e das modernas ferramentas de modelagem e desenvolvimento de sistemas com pessoas especializadas e comprometidas com os negócios da empresa, prometem sepultar de vez a famosa crise do software.

Elton Dietrich

Operation - Leadership

RESENHA CRÍTICA COMPLETA

DADOS GERAIS
Disciplina: CE-278 Modelagem e Gestão de Processos
Professor: Edgar Toshiro Yano
Aluno: Elton Dietrich
ANÁLISE DO TEXTO
Título do Artigo: Operation - Leadership
Autor (es): Peter Schoomaker
PALAVRAS-CHAVES DO TEXTO
Liderança,Iniciativa,Forças de Operações Especiais,Operações não convencionais

DESCRIÇÃO DO ASSUNTO
O autor argumenta que nos dias de hoje, até mesmo em instituições altamente hierarquizadas como as Forças Armadas, nas quais normalmente é seguido o modelo rígido de cadeia de comando, onde manda quem pode e obedece quem tem juízo, é necessária uma mudança de visão em relação à liderança.

Os cenários onde atuam as forças de combate mudou. As forças especiais de combate precisam estar preparadas para atuar em conflitos cada vez menos convencionais e o processo de tomada de decisão em relação às ações que precisam ser tomadas está mais horizontalizado, dependendo mais do momento vivido do que de uma estratégia previamente elaborada e autorizada pelos comandantes, ou seja, os combatentes, em todos os níveis, precisam desenvolver qualidades como iniciativa e liderança.

APRECIAÇÃO CRÍTICA DA OBRA

No meio militar o bom senso diz que para se obter sucesso em qualquer campo de ação deve-se seguir uma estrita cadeia de comando, ou seja, a hierarquia rígida é tida como fundamental, algo que não pode ser quebrado sob nenhuma hipótese.
O General Peter Schoomaker, comandante das forças especiais americanas argumenta que no atual cenário de operações este modelo pode ser perigoso. Da mesma maneira que no atual cenário dos negócios onde a palavra chave é “mudança”, os cenários onde atuam as Forças de Operações Especiais Americanas – SOF também muda constantemente, sendo que, terá mais capacidade de vencer, aquele que apresentar soluções mais criativas para as circunstâncias que se apresentarem. Ele afirma que “todos precisam aprender a ser lideres”.
Para o General Schoomaker, o fim da guerra fria marcou o início de um novo cenário de operações, passando das grandes guerras convencionais onde os detalhes de cada operação eram planejados por generais reunidos em centros de comando e controle e as forças de operações eram meros executores, para um novo modelo, onde as missões são mais rápidas e complexas, em cenários não muito bem conhecidos e o ambiente é de incertezas. Outra característica é que são executadas por forças de operações menores. Este novo campo de atuação exige que os membros dessas forças saibam lidar com as opções que se apresentam, quase nunca previsíveis, sabendo que na maioria das vezes não podem contar com a cadeia de comando para liderar suas ações.
Para comprovar suas afirmações o general Schoomaker apresenta alguns exemplos recentes como o conflito na fronteira do Iraque, nos campos de refugiados Kurdos (antes da guerra do Iraque que derrubou Saddam Hussein), os conflitos na Bósnia, a guerra do tráfico na Colômbia, conflitos étnicos na Namíbia entre outros.
Em todos esses casos, as forças de operações especiais encontraram cenários não convencionais a uma guerra tradicional, com refugiados famintos, a necessidade de convocar membros das comunidades locais para executar algumas operações de apoio, conversar com as pessoas para tomar conhecimento da situação, combater contra milícias, guerrilheiros, entre outros.

Para todos estes casos a iniciativa e a liderança são palavras-chave, estas equipes devem estar capacitadas para dar resultado a qualquer tempo em qualquer lugar. Para alcançar estes resultados, esta nova versão de organização militar deve ser muito bem treinada e composta por militares especialistas, lideres que podem operar em todos os níveis da organização.
Para alcançar estes objetivos, o general Schoomaker define um conjunto de sete princípios e práticas que devem ser seguidos pelos membros das forças especiais, principalmente por seus lideres.

1. Identifique claramente todas as variáveis envolvidas e foque sua missão em cima delas:

Se o foco de uma missão mudar é preciso desenvolver novas capacidades para tratar com ela de forma adequada. Os membros das forças especiais não são somente guerreiros que vão ao campo de batalha seguir ordens e procedimentos previamente definidos. Eles vão encontrar situações não previstas e precisam desenvolver capacidades de comunicação com as populações locais, capacidades de negociações, capacidades para resolver problemas não previstos e habilidades criativas para tratar com cada situação delicada que se apresentam.
Os membros das Forças Especiais se consideram como “Guerreiros Diplomatas” e “profissionais discretos”, ou seja, não buscam mais ser simplesmente heróis e não são mais simplesmente homens de batalha. Eles procuram seguir a abordagem do mestre Sun Tzu, o qual afirmava que “Conquistar o inimigo sem lutar é alcançar o ápice da destreza”. Esta destreza envolve analisar uma série de variáveis que se apresentam, principalmente aquelas que envolvem a capacidade reação ou o poder do inimigo, escolher o melhor caminho, e, mais importante, conseguir implementar rapidamente as ações.

2. Escolha as melhores pessoas e monte a melhor equipe:

Por experiência própria o general Schoomaker afirma que nunca de deve confundir entusiasmo com capacidade, não basta querer fazer, tem que saber fazer.
Você precisa ter pessoas capazes de cumprir uma missão com sucesso caso contrário é melhor nem tentar. Você precisa selecionar as melhores pessoas, as mais capazes, aqueles que tem o sucesso estampado no rosto e depois educar, treinar e avaliar constantemente suas qualidades. As forças especiais possuem 4 princípios fundamentais: Pessoas são mais importantes do que máquinas, a qualidade é melhor do que a quantidade, os membros das forças especiais são pessoas diferenciadas ou únicas naquilo que fazem, e, por último, devem estar sempre prontos para entrar em ação.
Os membros das forças especiais não são mais avaliados somente por suas qualidades militares, precisam desenvolver capacidades de negociação com oficiais de outras forças, população civil local, com guerrilheiros, entre outros. Eles são considerados embaixadores americanos. Para isto são treinados e colocados nas mais variadas situações e só os melhores é que permanecem.

3. Para ser um líder é preciso demonstrar liderença.

O processo de seleção de líderes das forças especiais é rigoroso. Para Schoomaker, liderança é a capacidade que as pessoas tem de lidar com a mudança, eles devem ser treinados para fazer algo que antes eram incapazes de fazer e capacitá-los para executar rapidamente. Como não existe uma receita de bolo para cada situação, estes lideres precisam ter como principais atributos qualidades psicológicas e intelectuais destacadas.
Os candidatos a lideres precisam demonstrar capacidade de liderança para resolver problemas complexos, tanto sozinhos como trabalhando em grupos. São colocados frente a dilemas morais e situações reais de maneira que possa ser analisado como eles agem em todos os casos. A sua criatividade também é testada quando são colocados frente os mais diversos problemas logísticos, materiais, entre outros e com o mínimo recursos disponíveis para solucioná-los.
Para complicar, todas as situações são preparadas para serem executadas sob condições extremas de estresse psicológico e emocional.

4. Ensine as pessoas como fazer e não o que fazer:

“Não de o peixe, ensine as pessoas a pescar”. As forças especiais precisam de membros que consigam operar num mundo misterioso e sofisticado onde as complicações aumentam a todo o instante. Não é possível criar um “checklist” explicando como os membros devem agir sobre cada circunstância. Para resolver os problemas não estruturados que os membros irão encontrar em campo eles precisam estar preparados para pensar em como resolve-los e não somente ensinar o que fazer para resolve-los
Isto não implica que eles podem fazer o que bem entendem, pois os valores éticos americanos e o interesse dos Estados Unidos precisam sempre estar a frente.
Tendo isto em mente os membros são incentivados a tomar iniciativas pois, na maior parte das operações, os problemas precisam ser resolvidos rapidamente e a maior parte das situações é não prevista. Se o líder fosse obrigado a pedir autorização a toda a cadeia de comando a demora ia ser grande.
O líder recebe um resumo do problema que irá encontrar e o seu papel é definir uma solução mais adequada.

5. Valores chave para manter os membros unidos:

A idéia não é ensinar como se usa cada ferramenta disponível para resolver problemas, mas ensinar um conjunto de valores centrais e preparar os lideres para resolver os problemas com as ferramentas disponíveis no momento, ou seja, ensinar um conjunto de princípios centrais que podem ser aplicados em qualquer situação.
Os valores chave que nunca podem ser desconsiderados são:
 Tome iniciativas, não espere respostas de cima pois elas raramente existirão;
 As coisas raramente são justas;
 Tudo muda rapidamente – O primeiro relatório apresentado deve ser sempre suspeito;
 Espere o inesperado – antecipe-se, prepare-se;
 Planeje e prepare-se como se não existissem regras;
Mais alguns bons princípios: Preserve sua liberdade de ação; sempre crie opções (plano B); nunca tome decisões que podem lhe abater futuramente; Procure sempre por possibilidades que ainda não foram vistas; O que mais poderia ocorrer?; procure ter a visão de floresta da situação.
O que não se pode perder de mente é que estes valores devem fazer parte de todos os membros e funcionar como motor de união entre eles.

6. Aprenda em ação:

A melhor maneira de aprender é em ação, porém, não é possível fazê-lo em situações reais onde o erro não é admissível.
Cenários são preparados para simular as situações que os membros das forças especiais vão encontrar nas missões reais.
Estas situações de combate simulam não só o ambiente físico que irão encontrar mas as populações locais, os inimigos etc.
Estes treinamentos são acompanhados por observadores e depois de terminados eles são completamente revisados. Porque uma decisão foi tomada, qual foi o motivo do erro ou do acerto, entre outros.
O erro é permitido e até estimulado pois é no erro que mais se aprende e na simulação ele não causa prejuízos maiores. Na vida real eles não podem acontecer. Só não são permitidos a negligência, a desobediência e o mau comportamento.

7. Ensine todos os membros a ensinar:

A última característica de um bom líder é a capacidade de ensinar, inspirar e desenvolver seu time.
O bom líder faz com que sua equipe consiga atuar bem mesmo sem a sua presença pois foi bem treinada para isto.

Conclusão

O texto apresenta uma visão interessante da necessidade de se desenvolver líderes capacitados para tomar decisões, independente da cadeia hierárquica, mesmo que a organização pertença ao hierarquizado ambiente militar.
Os conceitos apresentados são muitos semelhantes ao que se espera de um líder em qualquer setor da sociedade, seja no mundo dos negócios, no meio político, um líder de bairro, entre outros.
Ficou claro que alguns dos conceitos apresentados se aplicam a situações especiais vividas pelas forças de operações especiais americanas. Um líder normalmente não precisa passar por situações de estresse, como são as operações militares, onde vidas estão em perigo e porque não dizer a soberania de uma nação inteira.
Conclui-se que estes conceitos podem ser aplicados para as equipes de operações especiais que são pequenas e focadas, não às forças armadas como um todo. Um quartel precisa de lideres, mas se todos forem lideres a disciplina hierárquica tende a ficar comprometida, e, numa guerra convencional, se não existirem os pilares da hierarquia e da disciplina o caos vai se formar e a derrota será uma conseqüência natural.

A business-Oriented Foundation for Service Orientation

A business-Oriented Foundation for Service Orientation

Ulrich Homann

Comentário sobre o artigo

O autor apresenta uma proposta de modelagem da arquitetura de negócios com foco na orientação a serviços. Esta arquitetura seria mais estável e eficiente do que o tradicional processo de modelagem de negócios o qual se preocupa com detalhes do “como fazer” para uma proposta baseada no mapeamento das capacidades de negócios, ou seja “o que fazer”.
A atual dinâmica do mundo dos negócios requer que as empresas sejam capazes de se adaptar rapidamente a mudanças. O autor começa o texto com uma frase de impacto de autoria de Charles Darwin, relacionada a evolução das espécies, mas que se adapta perfeitamente ao atual ambiente de negócios: “Não é a espécie mais forte ou inteligente que irá sobreviver, mas aquela que consegue se adaptar mais rapidamente às mudanças”. Esta frase pode ser complementada com outra, também de impacto, que Joelmir Betting gosta de usar em suas palestras: “No mundo dos negócios de hoje, não é o maior ou mais forte que engole o mais fraco, mas o mais rápido que engole o mais lento”.
Como a palavra chave hoje é “mudança”, o autor argumenta que as tradicionais arquiteturas que modelam os processo de negócios baseado no “como” eles fazem acabam engessando a empresa dificultando as adaptações necessárias.
O atual mundo competitivo e globalizado no qual as empresas atuam exige uma arquitetura de negócios e sistemas de informação capazes de superar os limites físicos da empresa e devem considerar requerimentos mais flexíveis que envolvem colaboração entre redes de empresas e parceiros de negócios que compartilham recursos e informações. Estas redes são dinâmicas, os mercados são dinâmicos e os sistemas que dão suporte a esta troca de informações devem ser capazes de adaptarem-se a estas mudanças.
A orientação a serviços ou “Web Services” é uma arquitetura de sistemas voltada para a distribuição e flexibilização da comunicação entre sistemas complexos, em plataformas distintas e fisicamente distribuídas, com tecnologia de desenvolvimento distinta. Esta flexibilização da comunicação reflete a atual realidade do mundo dos negócios.
Orientação a serviços significa oferecer serviços (informação) com confiabilidade e operacionabilidade, de forma protegida e controlada sobre a WEB, usando padrões comuns. Esses serviços são publicados e consumidos através de interfaces padronizadas. A principal característica desse protocolo é permitir a interoperabilidade independente da plataforma, do provedor e da localidade, ou seja, é sinônimo de flexibilidade.
O autor afirma porém que os “web Services” sozinhos não resolvem todos os problemas de TI da empresa, como aderência a estratégias de negócios e, principalmente, garantir espectativa máxima de vida dos sistemas apesar de constante ambiente de mudanças.
Para alcançar estes objetivos ele sugere a modelagem do negócio baseado no mapeamento das capacidades de negócio da empresa.
Uma rede de capacidades de negócios irá modelar “o que” a empresa faz, comportamento visível externamente, diferente do “como” ela faz, o qual é um comportamento interno. Uma capacidade também se preocupa com seu esperado nível de performance. O “como” ela faz é tratado como uma caixa-preta neste nível de abstração.
Capacidades são descritivas o bastante para entender como uma função se encaixa no negócio e o que é necessário para interagir com ela. As capacidades são estáveis, por exemplo, vender produto. Isto a empresa sempre terá que fazer. Já o “como” eu vou vender estes produtos pode variar. Por exemplo, um processo de reengenharia que irá mudar de um canal tradicional de vendas para o comércio eletrônico.
O aspecto de rede dessas capacidades descreve como elas interagem para executar os requerimentos de negócios. É nesse cenário que o modelo de capacidades e os “web services” se casam. Os “web services” publicam ou disponibilizam os serviços ou informações independente de quem vai consumir ou como vai consumir. Eu posso tranqüilamente mudar o processo, o componente que executa o “como”, que o serviço de acesso aos serviços ou informações ainda estará disponível na interface padrão.
O processo de integração entre empresas (“Supply Chain”) é um bom exemplo. Ocorreu através dos tempos a evolução de uma arquitetura linear, que já era complexa, para uma muito mais complexa rede de parceiros de negócios que trocam informações, serviços e produtos entre si de forma colaborativa extrapolando os limites da empresa.
O paradigma hoje é a integração e a cooperação com clientes e demais parceiros de negócios. O problema ocorre porque, na maioria dos casos, os sistemas das empresas não foram modelados para absorver estas mudanças, o foco até então era a integração de aplicativos internos e este novo paradigma é muito mais do que isto.
Como não é possível para as atuais arquiteturas serem adaptadas para este ambiente de mudanças constantes é necessário um modelo mais adequado. Estas mudanças caminham no sentido de se buscar um modelo mais estável de arquitetura, baseado nas capacidades de negócios, ou seja buscar elementos que poderão garantir vida mais longa para a aplicação e permitam tratar melhor com este ambiente de mudanças.
A proposta do autor é modelar o negócio como uma estrutura de capacidades interconectadas, na forma de camadas, de maneira a alinhar o conceito de orientação a serviços com os direcionadores de negócios.
Este mapa de capacidades de negócios e orientação a serviços provê um conjunto de ferramentas que modelam o negócio para além de suas fronteiras físicas, formando uma rede que inclui toda sua cadeia de valor, integrando clientes, fornecedores e demais parceiros.
Como trata-se de uma rede de capacidades, um dos aspectos mais importantes do modelo está relacionado a como uma capacidade se relaciona com outras capacidades ou como modelar esta conexão.
A modelagem das conexões é extremamente importante pois é ali que podemos tratar com as questões da mudança enquanto as capacidades permanecem estáveis como caixas pretas.
Uma capacidade provê um serviço que é consumido por outras capacidades. Aí está força do modelo para tratar com questões da mudança. Cada capacidade é modelada como um componente que possui interfaces de consumos de serviços (entrada) e a interface de serviços produzidos (saída). Eu posso trocar um componente que produz os serviços por outro componente sem afetar os demais, ou seja, componentes são independentes.
Esta modelagem focada na conexão provê flexibilidade de se poder trocar quem executa o serviço pois não foca nos detalhes de como o processo é executado, mas na interface exposta.
O modelo proposto pelo autor se baseia num conjunto de capacidades de negócios aninhadas de maneira hierárquica.
No primeiro nível hierárquico são representadas as capacidades base, ou de fundação, e endereçam todo o ecossistema de negócio. São representadas em duas categorias: Capacidades de operação e capacidades de ambiente.
As capacidades de operação estão relacionadas ao ambiente interno de negócio e são assim classificadas:
1. Desenvolver produtos e serviços ou pesquisa & desenvolvimento;
2. Gerar demanda para estes produtos e serviços;
3. Produzir e entregar serviços e produtos;
4. Colaboração e comunicação com parceiros;
5. Planejamento e gerência do negócio;

As capacidades de ambiente são:
1. Relacionamento com clientes;
2. Gerenciamento de canais de distribuição;
3. Fornecedores;
4. Serviços de logística externa;
5. Instituições financeiras;
6. Infra estrutura e legislação.

No segundo nível ou nível 2 são modelados os grupos de capacidades. Elas representam o detalhamento das capacidades do nível 1. Por exemplo, a capacidade de nível 1 “Desenvolver produtos e serviços” pode possuir um grupo de capacidades “Planejar produtos e serviços”.
São descritos os níveis de serviços necessários, as restrições, os impedimentos e quem são os responsáveis mais adequados para executá-las.
No terceiro nível cada grupo de capacidades é decomposto em capacidades de negócios, as quais, por sua vez podem ser decompostos em um conjunto mais granular de capacidades de negócio até modelar todo o atual status do negócio.



Conclusão:

A grande força deste modelo é a integração do conceito de “web Services” com a modelagem dos processos de negócios.
Modelando as capacidades como componentes, com interfaces definidas de serviços providos e requeridos, sem a preocupação do “como” ela funciona para prover estes serviços (caixa preta) realmente é garantida estabilidade ao modelo pois é possível substituir um componente sem afetar os demais.