Journal idéias para melhores resultados

Transcrição

1 Aprenda a disciplina, busque a arte e contribua com idéias em Journal idéias para melhores resultados 20 Arquitetura em épocas turbulentas Arquitetura em épocas turbulentas Reutilizar, comprar ou construir: componentes e serviços "Longa e próspera vida": retenção de clientes e funcionários em processo ágil Sobrevivendo em épocas turbulentas: como estabelecer prioridades para as iniciativas de TI via arquitetura corporativa Arquitetura prática em épocas impraticáveis Redução de custos de infraestrutura por meio da virtualização Engenharia na nuvem: arquitetura de engenharia Software+Serviços forjada em épocas turbulentas

2 Sumário 20 Apresentação por Diego Dagum 1 Arquitetura em épocas turbulentas por Mike Walker Análise de como a crise está mudando a agenda do negócio, como as prioridades arquiteturais se alteram em decorrência disso, e um método para maximizar as decisões de arquitetura. Reutilizar, comprar ou construir: componentes e serviços por Simon Thurman e Phil Rowland Análise dos atributos que levam a uma decisão, considerações de ordem superior, forças que podem influenciar o processo, e como chegar a uma conclusão após análise equilibrada. "Longa e próspera vida": retenção de clientes e funcionários em processo ágil por Rodney Guzman Lições aprendidas com um estudo de caso concreto sobre como uma loja de software do mundo real entrega no prazo, mesmo com definições mutáveis (por exemplo, aquelas tomadas sob a pressão destes dias) e, assim, mantém clientes e empregados tão satisfeitos, que eles sequer pensam em deixar você. Sobrevivendo em épocas turbulentas: como estabelecer prioridades para as iniciativas de TI via arquitetura corporativa por Martin Sykes e Brad Clayton Como a Microsoft estabelece prioridades para o seu portfólio de projetos para maximizar o retorno do investimento (ROI), definindo quais projetos devem receber alocação de orçamento e recursos. Arquitetura prática em épocas impraticáveis por Matt Valentine Mentalidade, práticas e um conjunto inestimável de estudos de caso do mundo real ilustrativos, que ajudam a compreender que o progresso nada mais é do que a consequência de uma estagnação anterior. Redução de custos de infraestrutura por meio da virtualização por Leandro Sgallari Análise das várias técnicas de virtualização que permitem obter mais, por menos. Este artigo quantifica as margens a serem economizadas, como jamais proposto por nenhum outro artigo sobre virtualização. Engenharia na nuvem: arquitetura de engenharia Software+Serviços forjada em épocas turbulentas por Peter Williams e Simon Cox História do mundo real, de uma empresa que trocou fabricação e entrega de solução hospedada inteiramente por seus clientes em infraestrutura cara, para oferecer o aplicativo como um serviço, com a consequente redução de custo para os seus clientes Inscreva-se para uma assinatura grátis do The Architecture Journal

3 Fundador Arvindra Sehmi Diretor Lucinda Rowley Editor-Chefe Diego Dagum Colaboradores Desta Edição Mark Bloodworth Brad Clayton Simon Cox Darryl D Costa Nirmala Desa Ridi Ferdiana Rodney Guzman Ric Merrifield Matthew Pyle Paulo Rocha Phil Rowland Roger Sessions Leandro Sgallari Ramnish Singh Martin Sykes Simon Thurman Matt Valentine Mike Walker Derek White Peter Williams David Ziembicki Editorial e serviços de produção WASSER Studios Dionne Malatesta, Gerente de programação Ryan Malley, Coordenador de produção Ismael Marrero, Copidesque Dennis Thompson, Diretor de projetos Diagramação, finalização e impressão (BR) Arthéria Comunicação & Multimídia As informações contidas neste Jornal de Arquitetura ( Jornal ) têm finalidade informativa, apenas. As matérias do Jornal não constituem a opinião da Microsoft Corporation (Microsoft) e, tampouco, são recomendações da Microsoft ; assim sendo, você não deve confiar em nenhuma das matérias deste Jornal sem solicitar o aval de um consultor independente. A Microsoft não faz declarações nem oferece garantias quanto à exatidão ou adequação para determinada finalidade de qualquer matéria deste Jornal e, em nenhuma circunstância, a Microsoft aceitará responsabilidade de qualquer tipo, inclusive responsabilidade por negligência (salvo em caso de danos físicos ou morte) com relação a quaisquer tipos de perdas ou danos (incluindo, entre outros, os casos de perda de negócios, de receita, de lucros ou prejuízo imprevisto) resultantes do uso das informações deste Jornal. O Jornal pode ter imprecisões técnicas e erros tipográficos. O Jornal pode ser atualizado periodicamente e, às vezes, poderá estar desatualizado. A Microsoft não se responsabiliza pela atualização das informações deste Jornal nem por deixar de fazê-lo. Este Jornal contém matérias encaminhadas e criadas por terceiros. Até o máximo permitido pela lei aplicável, a Microsoft isenta-se de todas as responsabilidades por qualquer ilegalidade decorrente de erro, omissão ou imprecisão deste Jornal ; além disso, a Microsoft não se responsabiliza pela matéria recebida de terceiros. As marcas comerciais a seguir são marcas comerciais registradas da Microsoft Corporation: Active Directory, BizTalk, Hyper-V, Internet Explorer, Microsoft, Microsoft Dynamics, SharePoint, Silverlight, SQL Server, Terminal Services RemoteApp, Visual Studio, Windows, Windows Live, Windows Server, Xbox, Xbox 360 e Zune. Quaisquer outras marcas comerciais são de propriedade de seus respectivos proprietários. Todos os direitos autorais e outros direitos de propriedade intelectual das matérias publicadas no Jornal pertencem à Microsoft Corporation ou estão a ela licenciados. Cópiar, reproduzir, transmitir, adaptar ou modificar o layout do conteúdo deste Jornal são ações proibidas sem que haja autorização prévia, e por escrito, da Microsoft Corporation e de cada um dos seus autores. Copyright 2009 Microsoft Corporation. Todos os direitos reservados. Caro Arquiteto, amos começar com o básico: o objetivo do nosso papel de arquiteto é alinhar a TI Vcom o desenrolar do negócio. Até aqui, tudo bem, certo? Assim, já que quase todas as empresas têm sido desafiadas em consequência da retração econômica atual, nós como arquitetos somos desafiados a fazer com que as nossas arquiteturas acompanhem o ritmo do negócio que, nos dias que correm, é especialmente alterável e instável. Pensávamos que tínhamos um entendimento claro das regras relativas ao cenário mais recente. Tínhamos elaborado um plano para enfrentá-lo e, no meio da execução, foi-nos dito que a organização deve, agora, implementar outras alterações para manter o andamento do negócio. Foram divulgados os resultados do último trimestre, e as expectativas de crescimento foram revisadas para números menores talvez negativos. Esta edição do The Architecture Journal não vai lhe dizer quando terminará este desastre, nem se nós continuaremos empregados. Ele irá, no entanto, compartilhar estratégias de arquitetura, comportamentos de TI e, por certo, histórias de sucesso. Contei com a colaboração inestimável de Mike Walker como editor convidado para esta edição. Mike escreveu o artigo de abertura, que detalha como arquitetos podem acrescentar valor para o negócio durante momentos tão especiais como este. Ele e os outros autores são arquitetos como você e eu: não viveram durante a Grande Depressão e, mesmo se tivessem, tecnologia e arquitetura de TI, de modo geral, como disciplinas, eram "ligeiramente" diferentes do que são hoje. Foram subitamente desafiados, e reagiram a esses desafios. Agora, eles nos dizem como estão conseguindo. Espero que você encontre inspiração e coragem nestas páginas. A propósito, tal como anunciado na última edição, continuamos a incluir recursos no Jornal para aproveitar o seu atual formato digital, tendência predominante. Introduzimos a seção Para saber mais sobre este tópico no final dos artigos, com material de consulta para aprofundar o seu conhecimento. Nesta edição, incluímos o conceito "colunista convidado". Você verá que os artigos têm um, dois ou até mesmo três convidados. Pretendemos ampliar a cobertura de determinado tema, oferecendo diferentes perspectivas e opiniões. E, mais recursos virão. Além disso, para aqueles interessados em receber uma versão impressa, estamos ainda trabalhando num modelo para impressão por encomenda. Por acaso você está interessado em escrever um artigo para o Jornal? Acabamos de finalizar uma chamada para apresentação de artigos sobre o tema SOA ao final da década, e gostaríamos de agradecer a todos os participantes desta chamada. Você pode ficar a par de outras chamadas para a apresentação de artigos, tornando-se assinante do boletim The Architecture Journal, e visitando o site do The Architecture Journal. Como sempre, as suas opiniões serão bem recebidas. Envie-nos um . Apresentação Diego Dagum Editor-chefe 1

4 Arquitetura em épocas turbulentas por Mike Walker Resumo O objetivo deste artigo é mostrar aos arquitetos como entender as forças-chave que regem os negócios de TI, o que fazer para agregar valor, as principais áreas de enfoque e as tecnologias que podem ajudá-los a devolver valor para o negócio. Introdução A condição econômica que vivenciamos (no momento da criação do artigo) deu origem a um momento particularmente desafiador para os profissionais de tecnologia da informação (TI). Os eventos dos setores financeiros e outros setores relacionados do setor causaram impacto significativo nos produtos e serviços de tecnologia. Embora haja muito debate entre economistas sobre a duração, profundidade e impacto da crise econômica, pode-se deduzir tranquilamente que ela não desaparecerá no futuro próximo (consultar Forrester; 15 de outubro de 2008). A sua duração é o bastante para afetar o negócio e as prioridades de TI de modo significativo por mais um ou dois exercícios fiscais. Apesar da queda econômica, as empresas que continuam a investir e a inovar terão vantagens competitivas durante e depois da crise. Além disso, as empresas que conseguem enxergar além dos desafios imediatos, em direção às oportunidades que a condição econômica apresenta, alcançarão longevidade e sustentabilidade duradouras. Exemplo ótimo disso é o crescimento por aquisições. Fazer avaliações e aquisições importantes de tecnologia pode mudar a posição da empresa no mercado, reduzir o risco e aumentar o valor para o acionista. A TI será o pivô dessa inovação, o principal facilitador para as empresas. Os tomadores de decisões em TI, como arquitetos, ficarão sobrecarregados e sua experiência será usada ao máximo. Os arquitetos apresentam o know-how técnico para tomar decisões complexas e holísticas que representam milhões de dólares para as empresas. O presente artigo abordará como a economia afeta tanto a arquitetura da empresa como o arquiteto tomador de decisões de tantas empresas. Explorando as condições econômicas juntamente com as forças impostas às empresas, serão reveladas as principais áreas de enfoque da tecnologia. Essas áreas de tecnologia resultarão em tecnologias específicas para atender às exigências do negócio. Mudanças nas exigências para arquitetos Nas novas condições econômicas, as empresas começarão a realinhar a posição dos tomadores de decisões de TI de acordo com as prioridades do negócio. Deixar o negócio e os arquitetos alinhados é imperativo. O arquiteto encontra-se no centro das maiores decisões de TI, seja tomando decisões ou agindo como consultor nas decisões em questão. Esse realinhamento mudará naturalmente as prioridades dos arquitetos. Projetos de tecnologia nova, estratégica ou empolgante começarão a desaparecer para dar lugar aos projetos de caráter mais tático. Isso pode ser observado nas atuais tendências e atividades do mercado, como: " Fazer mais com menos. Grandes empresas declaram cortes de até 50% no orçamento de TI, mas mantêm os mesmos contratos de nível de serviço (SLAs) do passado. " Cortar custos de projetos existentes. Seguindo a linha de fazer mais com menos, cortar custos de projeto é atividade imediata e tática que determina a direção específica da TI e do negócio. Especificamente, projetos grandes de arquitetura orientada a serviço (SOA) serão mais pragmáticos e úteis, em vez de iniciativas ambiciosas e plurianuais. " Fusões e aquisições (M&A). Na medida em que as condições de mercado se aproximarem do seu apogeu, os setores se consolidarão. Os sistemas de TI proliferaram por todos os aspectos do negócio. Normalmente, as empresas têm várias implementações de processos e tecnologias similares; no entanto, elas são diferentes. Mais do que nunca, precisamos de arquitetos que compreendam e tenham visão sobre as tecnologias do processo de tomada de decisões de M&A. " Revitalizar a base de habilidades. As pessoas são ativos; elas representam a empresa como um todo. Os tomadores de decisão de TI têm a oportunidade de revitalizar a liderança e perspicácia técnica nesses tempos difíceis para tomar decisões melhores, fazer crescer a empresa, e tirar vantagem da crise econômica como um tempo de inovação. " Novas abordagens de terceirização. Embora utilizando métodos consagrados, existem novas tecnologias capacitadoras que trarão valor para as empresas. Elas incluem fornecedores de Plataforma como Serviço (PaaS) e Software como Serviço (SaaS). Como exemplo, a Microsoft oferece grande variedade de serviços, desde a infraestrutura Azure de serviços na nuvem, com armazenamento de dados hospedados, workflow e desenvolvimento de aplicativos, até soluções de SaaS como Dynamics CRM Live. Para os arquitetos, a condução normal do negócio será diferente; eles precisarão aproveitar o seu conjunto de habilidades diversificado para atender às demandas do setor e da empresa. A seguir estão as habilidades que os arquitetos utilizarão: " Motivação a inspiração Às vezes, decisões complexas de TI que têm o retorno de valor ilusório exigem persuasão adicional para a empresa se interessar. Os arquitetos utilizarão essa habilidade para unir as forças da empresa nas causas certas. 2

5 Arquitetura em épocas turbulentas " Negociação Haverá ocasiões na mesa de decisões em que um arquiteto deverá negociar para conseguir que as coisas sejam realizadas. De modo geral, os arquitetos são contribuintes individuais e não têm potencial organizacional, mas a habilidade para negociar é vital. " Pensamento crítico Ser capaz de pensar de forma rápida e autônoma é muitas vezes uma necessidade para arquitetos, especialmente quando tomar a decisão correta é crucial para a empresa. " Resolução de problemas Os arquitetos precisarão encontrar abordagens novas e inovadoras para solucionar problemas tradicionais. Com várias forças em seu negócio, os problemas do passado mudaram e exigirão modos quantitativos e qualitativos de avaliar e solucionar problemas. " Pensamento amplo Agora, mais do que nunca, o pessoal de TI precisará de uma abordagem mais holística, dadas as pressões sobre as necessidades de controle de custos e ROI (retorno sobre o investimento). Evitar visões estreitas e ser capaz de entender um problema de vários ângulos, para testar a própria lógica, representa um conjunto de habilidades que os arquitetos possuem e serão capazes de demonstrar para o restante da organização de TI. " Forças externas Forças externas às forças da organização e não podem ser controladas " Perspicácia comercial Ter conhecimento profundo do negócio é " Forças do negócio Forças estritamente relacionadas ao negócio essencial para todas as decisões de TI certas; para isso, os arquitetos usarão a sua perspicácia comercial para se comunicar e aprender que podem ter origem interna ou externa " Forças internas Forças cuja origem está na cultura e no modelo operacional de uma empresa com os seus líderes do negócio e especialistas no assunto (SMEs, Subject-matter experts ). Compreender o setor em que se trabalha é essencial, já que ajuda os arquitetos a entender como as decisões de tecnologia tomadas afetam os objetivos do negócio e como ele se sai no setor. " Orientação de processo Pensar em termos de processo é negócio com mais tranqüilidade e menos incertezas. essencial para um arquiteto; é a língua-mãe do negócio. Pensar em Os diretores de informações e de operações e os arquitetos de TI levarão em conta essas forças ao impulsionar decisões, iniciativas, projetos e compras de tecnologia. Compreender essas forças capacitará os arquitetos a se agarrar às prioridades e imperativos do A Figura 1 mostra mais detalhes sobre as forças do setor e os seus termos de líderes do negócio é essencial, da mesma forma que efeitos nas empresas. construir processos reproduzíveis e reutilizáveis como artefatos do trabalho realizado e do modo como operam. Forças externas são eventos ou circunstâncias no mercado mais amplo As habilidades mencionadas como orientação do processo, que afetam a empresa. Diferentemente das forças do negócio, quase perspicácia comercial/técnica, e pensamento crítico ajudarão os sempre são eventos externos incontroláveis que, ao final, precisarão arquitetos a entender melhor como a sua empresa funciona. Toda as ser abordados pelo negócio. empresas são diferentes na maneira como interrompem o setor e A seguir, os fatores que impulsionam as forças do negócio: reagem de maneira correspondente àquele entendimento. " Economia oscilante Não há dúvida de que a economia oscilante Para entender as prioridades de uma empresa, precisamos dar um tenha afetado os negócios drasticamente. A Gartner prevê que o passo atrás para entender o que influencia a direção de nossas crescimento mundial da TI sofrerá queda substancial do previsto empresas. Há influências diretas e indiretas ou forças que anteriormente de 8,9 a 7,3% (previsão de 2008) à previsão atual de determinam o curso de uma empresa. Essas forças podem mudar com 5,8 a 2,3% (consulte Gartner; 31 de dezembro de 2008). o tempo, e pode ser muito difícil prevê-las. Os especialistas (SMEs) do negócio muitas vezes entendem essas forças muito bem, já que ficam " Conformidade normativa A necessidade de atender às sempre atentos a elas para qualificar as suas decisões. Os arquitetos exigências de conformidade sempre foi um requisito para as precisam fazer o mesmo. empresas. Contudo, agora há mais pressão, impulsionada pela crise A TI não é mais uma função de valor estratégico para as empresas econômica. Os governos exigirão uma combinação de normas de TI não é um mal necessário ou centro de custos, mas um fator de verde, segurança e privacidade, auditoria e normas específicas do diferenciação real no negócio de uma empresa. Os arquitetos que setor. Curiosamente, 43% dos líderes de tecnologia acham que as compreendem as forças oferecerão alinhamento inerente com as eleições de 2008 afetarão as decisões de TI daqui em diante metas e objetivos de uma empresa. (consulte CDW IT Monitor; 10 de setembro de 2008). As forças podem ser agrupadas em três grupos de alto nível. Veja quais são eles: Figura 1: Forças do setor nas empresas Negócio Competitivo, M&A, Otimização do negócio Interna Processo, Otimização de soluções e infraestrutura Externa Econômico, Desastre natural, Normativo 3

6 Arquitetura em épocas turbulentas " Desastres naturais As empresas estão cada vez mais vez, isso terá um efeito propagador por todos os setores. As dependentes da disponibilidade e integridade das informações dos atividades de M&A darão origem a uma ampla gama de atividades sistemas de TI. Essa dependência, combinada à disseminação de de TI. Os arquitetos desempenham papel importante nas avaliações desastres naturais, força os arquitetos a avaliar como os sistemas do portfólio de tecnologia, análises de compensação de sistemas, foram construídos. Há, e continuará havendo, uma necessidade de análise de lacunas da arquitetura, análise e avaliação da segurança e planejamento da continuidade do negócio, estratégias de replicação análise de integração. de dados e mecanismos de recuperação de desastres. " Atividades de otimização do negócio Com maior pressão e Forças do negócio são forças que se relacionam diretamente ao projeções modestas da concorrência, o tema da maior parte das negócio; elas afetam como o negócio opera e toma decisões. A lista a empresas será fazer mais com menos. Os arquitetos precisarão olhar seguir mostra as principais forças do negócio que nos afetarão em para as tecnologias capacitadoras para medir, acompanhar e analisar tempos de incerteza: " Concorrência acirrada Os negócios ficam cada vez mais competitivos, conforme o mercado aperta. A concorrência acirrada força os arquitetos a se dedicarem às soluções essenciais do negócio ao qual oferecem suporte. Além disso, a Gartner reforça isso declarando que as empresas não querem divulgar que estão cortando agressivamente os orçamentos de TI por razões competitivas (consulte Gartner; 31 de dezembro de 2008). as atividades do negócio. Forças internas são o resultado das forças externas e do negócio. Essas são as forças em que muitos arquitetos atuam diretamente; elas estão muito mais próximas do negócio de TI: " Aprimoramento do processo De acordo com algumas necessidades da otimização do negócio das empresas, haverá aprimoramento e simplificação do processo. Os arquitetos devem se " Maior número de M&A Em uma economia como a atual (no preocupar com: úas eficiências dos sistemas que medem, acompanham e momento da criação deste artigo), é prática comum haver analisam os processos. aquisições significativas. Vimos isso no setor financeiro, só que desta Tabela 1: Prioridades da IT Serviços DNS Novas prioridades Prioridades menos relevantes Otimização do portfólio atual Com a consolidação do mercado e o realinhamento nos últimos dois anos, as empresas tentarão entender os seus ativos e como aproveitá-los em uma economia em dificuldade. Novos projetos Há uma quantidade cada vez menor de novos projetos sendo iniciados, devido à quantidade assustadora de otimização interna necessária. Programas de redução de custos Tomadores de decisão técnica e arquitetos são pressionados a fazer mais com menos. A introdução de programas que procuram reduzir custos é uma ótima propriedade dos arquitetos. Fusões e aquisições (M&A) Para a maioria das empresas, as M&As são inevitáveis; recentemente, contudo, vem acontecendo um número acelerado de aquisições. Um número de projetos anteriores e posteriores a projetos de M&A ocorrerá durante esse tempo. Conformidade Em todo mundo, surgem novas normas para controlar todos os aspectos de como a TI opera. Exemplos de normas possíveis: " Privacidade. " Fraude " Pagamentos. " Produção e Ti verdes. " Gerenciamento de processo. " Gerenciamento e arquitetura de TI. Projetos de SOA em larga escala Com a disseminação de falhas dos projetos de SOA em larga escala, os arquitetos estão reconsiderando a sua abordagem de SOA em suas empresas. A SOA continuará existindo, mas será pragmática e tática. Projetos da Web 2.0 Haverá atividade para áreas de nicho. Contudo, experimentos para verificar se o paradigma dessa tecnologia é viável não serão considerados cruciais. Substituição de servidores Com o intuito de reduzir custos, os arquitetos de infraestrutura analisarão os ciclos de depreciação de servidores e desktops. É possível que haja uma consolidação dos servidores e que a vida útil dos servidores e desktops seja ampliada, reduzindo, assim, o número de projetos de apropriação de novos hardwares. Projetos de valor agregado voltados ao cliente Isso amplia o alcance da empresa além dos métodos tradicionais para agregar valor para o cliente e para a empresa. Área vital de crescimento é o espaço do telefone celular. Os aplicativos móveis continuarão a crescer e a integrar serviços ao telefone celular. 4

7 Arquitetura em épocas turbulentas úfazer parte da otimização do processo em si, para se adaptar às condições de mudança. Gene Leganza, da Forrester, declara: Arquitetos corporativos precisam trabalhar nas equipes de desenvolvimento, suporte e operações para impulsionar decisões (consulte Forrester; 28 de outubro de 2008). " Otimização da infraestrutura A otimização da infraestrutura e dos aplicativos é resultado direto de fazer mais com menos. Na medida em que os orçamentos são espremidos e os orçamentos de servidor budgets desaparecem, os arquitetos precisarão avaliar as eficiências de infraestrutura. Na maioria dos casos, há oportunidades para consolidar, virtualizar, centralizar e readaptar investimentos em infraestrutura. Figura 2: Insumos para a tomada de decisões de arquitetura Restrições técnicas Requisitos funcionais Preocupações existentes Exigências do negócio Arquitetura Motivadores do negócio Exigências não-funcionais Restrições Custos " Gerenciamento de portfólio de aplicativos métodos para fazer isso. Os desafios tradicionais devem-se ao fato de Além da infraestrutura, os aplicativos também precisarão ser que os arquitetos quantificavam as decisões em suas mentes. O avaliados. Os aplicativos quase sempre podem ser ilusórios e não desafio, aqui, é que isto está sujeito ao viés e à interpretação dos completamente visíveis aos arquitetos ou tomadores seniores de desafios: não oferece um método reproduzível que produza resultados decisões técnicas. Com a pressão das perspectivas de custos e consistentes. normativas, é crucial compreender e gerenciar bem os aplicativos. Há um método que pode ser usado para produzir esse nível de análise Como os arquitetos podem agregar valor de maneira reproduzível. Esse método chama-se AQM (Architecture Qualification Method, método de qualificação de arquitetura). Como discutido anteriormente, o papel do arquiteto é único. Os arquitetos são alguns dos tomadores de decisão de tecnologia mais O método de qualificação de arquitetura (AQM) imparciais, e têm visão holística das soluções na empresa. Num O AQM é um modo prático de se alinhar com a arquitetura do momento de incerteza, isso pode ser um ótimo ativo para as negócio e, em última análise, de qualificar as nossas decisões de empresas. Esse conjunto de habilidades será usado agora, mais do que arquitetura. Esse método é realizado por arquitetos e pode se encaixar nunca, com a economia oscilante. em estruturas de arquitetura já existentes (por exemplo, TOGAF, FEAF, Sabemos que cortes no orçamento de TI não quer dizer que a TI não é EACOE e IASA), padrões de arquitetura e práticas comprovadas. O importante. Eles mostram a necessidade de simplificar e aprimorar a AQM oferece um conjunto de ferramentas que ajudam os arquitetos a: TI. Portanto, em essência, isso significa mais atividades de TI. Para os " arquitetos, isso significa realinhamento das prioridades arquiteturais. Utilizar um método para capturar os atributos de qualidade da empresa Troca de prioridades " Mecanismos para capturar as definições dos atributos que podem As prioridades arquiteturais mudaram, e as atividades antes ser ajustados à empresa consideradas de alta prioridade para o arquiteto mudaram de curso. Coisas que eram consideradas estratégicas para a empresa agora são consideradas arriscadas ou frívolas. Esta é a vez das iniciativas prudentes, de baixo risco. Nos próximos anos, os arquitetos serão envolvidos em atividades essenciais, de alto ROI (retorno do investimento), e TCO (custo total de propriedade). Figura 3: Diferenças nas prioridades do setor Banco Produção A Tabela 1 mostra exemplos das prioridades de TI que devem mudar nos próximos anos. Na Tabela 1, fica claro que as prioridades deixaram de ser investimentos de larga escala de TI, por vezes arriscados, e passaram a ser atividades e projetos táticos com ROI de médio prazo. Arquitetos dinâmicos e sagazes terão pouco ou nenhum problema para se adaptar a essas mudanças. Métodos para maximizar as decisões de arquitetura Nas seções anteriores, discutimos que devemos mudar nossa mentalidade e deixar nossas soluções mais pragmáticas. Para isso, precisamos usar métodos pragmáticos. Métodos pragmáticos devem quantificar e qualificar as nossas decisões de arquitetura. O desafio é que não há muitos Não tão crítico Agilidade Capacidade de manutenção Crucial Confiabilidade Disponibilidade Segurança Não tão crítico Custo Sustentabilidade Crucial Confiabilidade Capacidade de manutenção Agilidade 5

8 Arquitetura em épocas turbulentas Figura 4: O AQM e as prioridades do negócio AQM Impulsionadores externos Processo Motivadores do negócio Princípios Políticas Padrões Sistema de classificação Impulsionadores internos Matriz de mapeamento de ativos e padrões " Oferecer um modo de capturar análises de arquitetura de modo reproduzível. " Qualificar os atributos de qualidade da arquitetura. " Reduzir a complexidade e a confusão na fase de planejamento de arquiteturas de solução. " Criar uma estrutura de classificação que permita o arranjo dos padrões de arquitetura e padrões de design. " Facilitar a governança pela qualificação do uso de normas e padrões de design. " Reutilizar a arquitetura proativamente pela redução de complexidade. As arquiteturas apresentam preocupações transversais diversas que podem ser difíceis de entender e quantificar. Como o AQM faz isso e por que é diferente? Ferramenta de qualificação O AQM toma uma abordagem estruturada para solucionar problemas arquiteturais. Essa solução é diferente de outras, já que oferece uma maneira das empresas definir suas próprias medidas, com base no " Inteligência que permite a classificação e variabilidade dos atributos negócio que praticam. Consulte a Figura 3, por exemplo. de qualidade A Figura 3 mostra como as prioridades desses dois setores são " Provisão de uma estrutura para racionalizar os atributos para a diferentes. Isso é ampliado pelo fato de as empresas desses setores solução apresentarem modos ligeiramente diferentes de conduzirem os seus negócios, o que pode ter impacto expressivo sobre como criamos " Um modo de regulamentar como as arquiteturas são classificadas e arquiteturas. racionalizadas em toda a empresa Isso é ilustrado no livro de Jeanne Ross Arquitetura Corporativa com O AQM soluciona diretamente as questões usando a complexidade e a Estratégia: Criando uma Fundação para Condução do Negócio (Boston, compreensão de arquiteturas. A Figura 2 mostra o exemplo de um MA: Harvard Business School Press, 2006), em que a autora compara as pequeno subconjunto de insumos para o processo de tomada de diferenças entre duas empresas do mesmo setor (como FedEx e UPS) e decisão da arquitetura. mostra as amplas diferenças nos sistemas de TI que oferecem suporte Como se vê, há insumos de todos os lados. a seus negócios. O AQM (método de qualificação de arquitetura) soluciona os seguintes O que vemos quando olhamos para tudo isso é mostrado na Figura 4. desafios: Oferecer um modo de ter total capacidade de acompanhamento é o princípio do AQM. É absolutamente Figura 5: Como usar a infraestrutura da nuvem para absorção de pico de carga Site da Web crucial ser capaz de, além de justificar nossas decisões, quantificá-las e qualificálas. O único jeito de fazer isso é alinhar as nossas decisões com imperativos do negócio. O AQM é usado com os seguintes componentes, como ilustrado na Figura 4. " Processo Específico do AQM, este componente oferece a integração nos processos existentes e o seu próprio processo exclusivo para executar o AQM. " Sistema de classificação O sistema de classificação cobre dois aspectos: údefinição dos atributos de qualidade na terminologia e nas taxonomias específicas bem compreendidas pela empresa. (A infeliz realidade é que todos temos diversas definições para os termos de arquitetura.) 6

9 Arquitetura em épocas turbulentas úcriação das classificações, propriedades e limiares em atributos de qualidade. Este é um dos aspectos mais importantes do AQM. Este mecanismo oferece um modo de qualificar por inteiro os atributos de qualidade por meio da definição apropriada do que significam para a sua empresa. Por meio dessas classificações, propriedades e limiares, o AQM é capaz de quantificar e qualificar as arquiteturas. " Matriz de mapeamento de padrões e ativos Assim que um sistema de classificação é criado pelo AQM, você pode começar a correlacioná-lo com coisas reais "coisas reais" significan seus padrões de design, normas, políticas e ativos de TI existentes (sistema ou aplicativo). Assim, você pode ter um modo sistemático de prescrever que padrões usar para soluções e mais adiante automatizar a tomada de decisões, torná-la rastreável e facilitar a governança. Como exemplo, há um cenário comum que me ocorre. Digamos que a sua empresa tenha normas para um conjunto de tecnologias de comunicações. E ainda, que essas normas sejam FTP, SFTP, Web Services, CIFS/SMB, Connect Direct e Microsoft SQL Server Integration Services (SSIS). Como todas elas fazem parte da lista de normas, os desenvolvedores ou arquitetos talvez não escolham a norma ideal por inúmeras razões que poderiam incluir fatores de custo, complexidade ou falta de compreensão da tecnologia ou preferências pessoais. No cenário em questão, o arquiteto escolhe o FTP porque é barato e fácil de implementar. O problema é que os impulsionadores da solução pedem que as transações sejam altamente seguras e adaptáveis. O FTP não é a escolha aqui. Portanto, com o AQM, podemos qualificar esses padrões para mostrar em que circunstâncias deveriam ser usados. Isso se aplica a todos os atributos de qualidade da arquitetura (como escalabilidade, segurança, confiabilidade, interoperabilidade, etc.) " Ferramenta de qualificação A ferramenta de qualificação entra Alinhar Figura 6: Imperativos arquiteturais essenciais Consolidar Alinhar Terceirizar Otimizar desse método, você pode esperar um nível superior de precisão e qualidade na tomada de decisões arquitetural. Quatro imperativos arquiteturais essenciais A Figura 6 mostra os imperativos que os arquitetos precisam ter em mente em tempos de incerteza. Esses imperativos compreendem quatro imperativos universais: " Alinhar Encontrar vínculos diretos a imperativos do negócio. " Otimizar Fazer mais com o que se tem. " Terceirizar Mover os ativos de TI que não agregam valor para fora do ambiente operacional de TI. " Consolidar Reduzir as redundâncias. em jogo quando o arquiteto quer planejar uma solução. Como mencionado no cenário anterior, a ferramenta oferece um modo de encaixar todas as peças de forma fácil. Toda a complexidade é retirada, para que arquiteto possa se concentrar na criação de uma solução, em vez de ter de consultar milhares de páginas de padrões para (finalmente) encontrar algo que possa ou não ser útil. Então, como usar o AQM? Uma coisa é definir a metodologia, outra coisa inteiramente diferente é torná-la útil. A lista a seguir mostra como o AQM é racionalizado e imediatamente acionável e pragmático: A pressão de muitas forças sobre o negócio forçará o alinhamento da TI com os objetivos do negócio. Agora, mais do que nunca, as empresas se esforçam para este alinhamento. Os arquitetos precisarão investir em melhor qualificação das decisões de arquitetura para garantir a agregação de valor para o negócio. Essa qualificação geralmente é ilusória e difícil de determinar. Compreender as áreas a observar é essencial. Na lista a seguir, você verá as principais áreas em que pode começar a quantificar as decisões de arquitetura. Esta lista não é abrangente, mas ponto de partida para arquitetos reunirem pontos-chave de informação: " Os modelos baseados no Office Excel, que podem ser usados por " Métricas essenciais Todo arquiteto luta por modos de praticamente todos os arquitetos, desde o início quantificar seus esforços, especialmente arquitetos de níveis mais " Integração em repositório de metadados de arquitetura altos (como arquitetos corporativos). Em vez de definir métricas específicas de TI, as empresas de arquitetura precisarão operar mais " Definições de processos de padrões no Office SharePoint como um negócio. Assim, além de demonstrar a sua eficácia, elas A Figura 5 mostra capturas de tela de vários aspectos do AQM. Os dados não foram preenchidos, para fins bem específicos. Contudo, na amostra, os dados são preenchidos na matriz de classificação para mostrar os valores de amostra. Isso foi bem simplificado e mostra apenas que tipos de dados seriam representados. Em implementação do mundo real, o repositório poderia lidar com grande parte disso unindo múltiplos relacionamentos a informações e classificadores de um atributo de qualidade. A planilha é um mecanismo de exibição. Oferecemos uma visão de alto nível do AQM e mostramos a finalidade, os métodos e as ferramentas associadas a ele. Por meio precisarão quantificá-las. " Avaliações Maneiras reproduzíveis e uniformes de avaliar soluções para o negócio são imprescindíveis. Essas avaliações devem ditar como as decisões são tomadas e ilustram como as compensações arquiteturais ocorrem. As avaliações incluem viabilidade da arquitetura, análise de compensações arquiteturais, documentos de decisões de arquitetura, e avaliações do pedido de oferta (RFP, request for proposal) dos padrões. 7

10 Arquitetura em épocas turbulentas Figura 7: Evolução dos serviços terceirizados Terceirização Tema: Gerenciar serviços de TI Barreira: Alta Complexidade: Alta Integração: Proprietária Conectividade: Limitada/fechada Processamento: Lotes Comercialização: Ampliada Integração com LOB: Fraca Relevância no mercado: Relevante Principal questão: Custos altos, falta de agilidade ASP MSP Nuvem/SaaS Tema: Terceirizar aplicativos Barreira: Boa Complexidade: Boa Integração: Aberta/binária Conectividade: Fechada/internet Processamento: Tempo real Comercialização: Melhor Integração com LOB: Fraca Relevância no mercado: Obsoleto Principal questão: Desconexão do processo, segurança, SLAs, escala Tema: Soluções e processo Barreira: Melhor Complexidade: Boa Integração: Aberta/binária Conectividade: Fechada/internet Processamento: Tempo real Comercialização: Melhor Integração com LOB: Boa Relevância no mercado: Diminuindo Principal questão: Desconexão do processo, segurança, SLAs, escala Tema: Segurança, conectividade, abertura Barreira: Melhor Complexidade: Boa Integração: Aberta Conectividade: Internet Processamento: Tempo real Comercialização: Melhor Integração com LOB: Boa Relevância no mercado: Emergente Principal questão: Novo modo de programação 80s 90s 00s " Gerenciamento das exigências Por que os arquitetos devem se úvínculos para o modo de suporte da solução. preocupar com as exigências? Simplificando, elas impulsionam não " Gerenciamento de ciclo de vida do aplicativo (ALM, Application só a funcionalidade, mas também a arquitetura. Capturar as life-cycle management). Enquanto o gerenciamento de portfólio exigências funcionais e não funcionais de maneiras reutilizáveis cuida da empresa holisticamente, o ALM é muito mais concentrado. ajudará a alinhar as arquiteturas com o negócio. Esse é o modo mais Os aperfeiçoamentos do ALM podem incluir otimizações do rápido e fácil de obter esse alinhamento. processo para simplificar os esforços, novas ferramentas para " automatizar e acelerar o desenvolvimento de aplicativos e pontos de Gerenciamento da arquitetura A área de preocupação que vem reunião de informações para dar suporte aos esforços de arquitetura a seguir é observar o que já foi feito e como se encaixa nos e quantificar o valor do negócio. imperativos novos e existentes do negócio. O gerenciamento da arquitetura vincula-se a processos-padrão, como gerenciamento de " Revisitando ferramentas de arquitetura e desenvolvimento. portfólio e processos de PMO. Otimizando as ferramentas usadas no planejamento real do Otimizar desenvolvimento e da arquitetura será essencial para as empresas. Tempos de menos trabalho em projetos são ideais para repensar as Com a diminuição dos orçamentos de TI e o desaparecimento de ferramentas. projetos explosivos, a atenção estará voltada à otimização das soluções existentes. Impulsionar a obtenção de mais valor (com aquilo que a " Otimizando soluções. Além de melhorias do processo, as soluções empresa já tem) será imperativo essencial. Os arquitetos precisarão avaliadas e classificadas no gerenciamento de portfólio precisarão avaliar as soluções atuais e determinar como serão usadas, se são ser otimizadas de alguma forma. Isso dará oportunidade aos executadas de modo ideal, se são redundantes e se se encaixam ao arquitetos para que sejam criativos em suas soluções. Com uma uso pretendido para o negócio. nova onda de inovações na computação social, arquiteturas cientes Essas questões são muito difíceis de responder. Para respondê-las, é do contexto, arquiteturas baseadas na nuvem e SaaS (para citar necessário uma grande quantidade de informações que podem ou alguns), há maneiras de apresentar menores riscos, custos e suporte não ser capturadas. Há uma forte dependência do processo. Se a para a sua empresa empresa tiver processos flexíveis com relação a desenvolvimento de software e processos arquiteturais, a qualidade ou as informações em Terceirizar si podem ficar ausentes. Conforme classificam as soluções por meio de métodos como gerenciamento de portfólio e ALM, as empresas serão capazes de As atividades-chave que ajudarão os arquitetos a obter as informações determinar os aplicativos que agregam valor estratégico. Isso ditará as são: decisões do negócio por essas soluções. Há inúmeras opções " Gerenciamento de portfólio. Analisar o portfólio de TI de disponíveis para essas empresas; ficará por conta dos arquitetos ajudar aplicativos permitirá aos arquitetos fazer o inventário dos sistemas os líderes de TI e do negócio a determinarem o melhor curso de ação. existentes ou revisar os sistemas já catalogados. Na escolha pela Desde o início da TI há uma certa tendência a terceirizar os ativos de otimização do negócio, o gerenciamento de portfólio é muito TI. Observamos isso com a terceirização tradicional, provedores de importante; ele supera todos os aspectos-chave de uma solução e serviços de aplicativo (ASPs, application service providers) e nos oferece as seguintes informações: provedores de serviços gerenciados (MSPs, managed services úcomo a solução vincula-se de volta ao negócio e (às vezes) a um providers). processo ou capacidade do negócio. Como mostra a Figura 7, o conceito de terceirização de serviços, úscorecard da solução por todas as soluções. aplicativos ou processos inteiros do negócio não é completamente úcusto geral da solução. novo, mas evoluído. 8

11 Arquitetura em épocas turbulentas Para toda solução, está claro que há benefícios e desvantagens Consolidar soluções vai ser essencial para baixar os custos e a distintos. Algumas, como modelos ASP, estão completamente complexidade dentro da empresa. obsoletas, enquanto a terceirização sofre em áreas cruciais como o " mainframe. O mais evidente é que essas tecnologias e métodos estão Processo. O gerenciamento de processo é muitas vezes ignorado, evoluindo. mas pode ser um exercício valioso para consolidar processos desconexos e redundantes. Isso simplifica os esforços arquiteturais É o momento perfeito para pensar em terceirizar os serviços de TI. providenciando medidas reproduzíveis e previsíveis. Fornecedores de solução independentes (ISVs, independent solution vendors) e provedores de plataforma como a Microsoft (com o Live Por meio desses quatro imperativos arquiteturais, será mais ameno Services e o Azure Cloud Services) solucionam problemas tradicionais tolerar a tempestade econômica turbulenta. As vantagens são de tecnologia. enormes para os arquitetos. Além de se alinhar firmemente ao negócio, eles também serão vistos como verdadeiros parceiros da TI. Como em todas as soluções de tecnologia, se implementadas Os arquitetos serão capazes de agregar valor significativo ao reduzir o corretamente, soluções como SaaS e baseadas na nuvem oferecem TCO. vantagens significativas às empresa:. " Conclusão Adoção acelerada de tecnologia A barreira para ganhar acesso No estado econômico frágil em que nos encontramos (no momento a novas tecnologias é tão fácil quanto uma assinatura da criação deste artigo), as empresas podem se destacar com inovação investimento relativamente pequeno em soluções de protótipos ou e otimização da economia. Aquelas que capitalizarem as condições de tecnologias inovadoras que no passado envolveriam licenciamento e mercado como oportunidade para simplificar, consolidar e adquirir compra de software, questões de implantação e treinamento ao ativos de TI e/ou negócios inteiros gozarão de longevidade muito pessoal de suporte (entre outros). além da crise econômica. " Complexidade O SaaS permite especificamente que as empresas O objetivo deste artigo é mostrar aos arquitetos como entender as reduzam a complexidade das soluções que tradicionalmente forças-chave que regem os negócios de TI, o que fazer para agregar criariam ou comprariam. Combinar a força dos padrões de Internet, valor, as principais áreas de enfoque e as tecnologias que podem segurança e XML à experiência de solução de fornecedor do SaaS ajudá-los a devolver valor para o negócio. reduz muitas das complexidades técnicas antes ameaçadoras. " Custo total de propriedade (TCO) mais baixo Reduzindo o número de staffs, a aquisição de servidores físicos, licenças de Sobre o autor Mike Walker (Mike@MikeTheArchitect.com) é arquiteto principal da software, e os custos operacionais gerais, o TCO das soluções de Microsoft, responsável por criar a estratégia para gerenciar, distribuir e todos os serviços de TI pode ser diminuído. comunicar a posição da Microsoft com relação a arquitetura " corporativa. Ele é responsável por impulsionar as estratégias mundiais Agilidade Permitir que as empresas agilizem a distribuição de Enterprise 2.0 e Enterprise Architecture da Microsoft em segmentossoluções em tecnologias modernas e reduzir as complexidades da chave do setor. integração de aplicativos de linha de negócio (LOB) deixará as empresas muito mais ágeis do que do que antes. Mike ingressou na Microsoft no começo de Seu histórico é de estrategista e arquiteto corporativo de serviços financeiros, Consolidar especializando-se em transformação do negócio em torno da A pressão de todos os lados forçará os arquitetos a pensar em fazer tecnologia, planejamento de infraestrutura estratégica, gerenciamento mais com menos. Isso reduzirá a complexidade e a redundância na de portfólio de projetos de tecnologia e arquitetura de soluções. empresa. Conforme os arquitetos otimizam o gerenciamento de Como líder de pensamento, Mike combina a sua experiência com forte portfólio, o ALM e o rejuvenescimento de ferramentas da empresa, dedicação na execução estratégica. procurarão maneiras de otimizar e consolidar aplicativos. Visite o blog do Mike Walker. Áreas-chave em que a consolidação vai ocorrer: " Infraestrutura de TI. O backbone do hardware de uma empresa é, em geral, o primeiro a ser consolidado às vezes, o mais fácil de todos os esforços de consolidação com as soluções comuns e de virtualização sempre em evolução. Embora seja fácil virtualizar, há um planejamento cuidadoso necessário, já que isso poderia levar ao mesmo problemas da dispersão do servidor. " Serviços de TI. Colaboração, VoIP, , inteligência do negócio, portais, monitoração do sistema e sistemas de gerenciamento de projeto (para citar alguns) são serviços de TI que podem ser simplificados pela criação de padrões, consolidação de vários fornecedores ou terceirizados a provedores de serviços fora do firewall. " Arquiteturas de solução. As empresas muitas vezes encontram redundâncias em soluções que abrangem LOBs ou áreas funcionais. Para saber mais sobre este tópico " Otimização da Plataforma de Aplicativos: " Gerenciamento de Ciclo de Vida do Aplicativo: " Externalização para a Nuvem: 9

12 Arquitetura em épocas turbulentas Infraestrutura de TI e Otimização de Aplicativos por Ramnish Singh O modelo de infraestrutura de TI e otimização de aplicativos da Microsoft ajuda os clientes a entender e, assim, aprimorar a situação atual de sua infraestrutura de TI e dos aplicativos e o que isso quer dizer em termos de custos, riscos de segurança e agilidade operacional. A economia dramática de custos pode ser realizada partindo de um ambiente não gerenciado em direção a um ambiente dinâmico. A segurança passa de altamente vulnerável em infraestrutura básica a dinamicamente proativa em infraestrutura mais amadurecida. A infraestrutura de TI e o gerenciamento de aplicativos passam de altamente manuais e reativos a altamente automatizados e proativos. A Microsoft oferece tecnologias, processos e procedimentos para ajudar os clientes pela jornada da otimização. Os processos deixam de ser fragmentados ou inexistentes para otimizados e reproduzíveis. A capacidade dos clientes de usar a tecnologia para aprimorar a agilidade do negócio e oferecer valor de negócio aumentará conforme saem do estado básico em direção ao estado dinâmico capacitando funcionários e gerentes da informação e oferecendo suporte a novas oportunidades de negócio. Trabalhando com a Microsoft e usando esse modelo como estrutura, as empresas compreendem rapidamente o valor estratégico e as vantagens do negócio para a organização em passar do nível básico de maturidade (em que a infraestrutura de TI é geralmente considerada um centro de custos) em direção de um nível mais dinâmico (em que o valor do negócio da infraestrutura de TI é compreendido e a infraestrutura de TI é vista como um ativo e facilitadora do negócio). O modelo concentra-se no valor do negócio e preenche a lacuna entre a TI e empresas do negócio. O mapeamento claro é mostrado entre os impulsionadores do negócio e as prioridades das soluções de tecnologia que são integradas nas capacidades da plataforma proporcionando TI dinâmica e oferecendo agilidade do negócio. Exemplos de arquiteturas são discutidos para os seguinte setor ou solução horizontal: Insight do negócio, Insight do cliente e do desempenho, Gerenciamento de documentos e registros, Capacitação da força de trabalho móvel, ERP, Sistemas de saúde, Aperfeiçoamento do atendimento ao cliente, Operações de manufatura, Otimização das operações do negócio, Otimização das operações financeiras, Gerenciamento do desempenho, Setor público, Vendas, Sistemas de armazenamento, Gerenciamento da cadeia de suprimentos e Plataforma da Web. Ramnish Singh (ramnishs@microsoft.com) é arquiteto certificado da Microsoft em Bangalore, Índia. Figura 1: Sequência de otimização, de básico para dinâmico Figura 2: Modelo de infraestrutura de TI e otimização de aplicativos da Microsoft Identificar o seu lugar Identificar aonde quer chegar Pessoal Processo Tecnologia BDM Compreender necessidades e prioridades do negócio Capacidades potenciais de solução TDM Capacidades da plataforma Básico Padronizado Racionalizado Dinâmico Abordagem de plataforma integrada ITPro Análise de integração da otimização Mapa da solução 10

13 Reutilizar, comprar ou construir: componentes e serviços por Simon Thurman e Phil Rowland Resumo A finalidade deste artigo é realçar e discutir as considerações necessárias para fazer a escolha adequada entre reutilizar, comprar ou construir componentes e serviços. Introdução Comecemos com uma afirmação simples: Se todas as coisas forem iguais, a escolha deveria ser reutilizar, comprar e então construir componentes e serviços para entregar a solução necessária para o negócio. Mas nem todas as coisas são iguais, e isto é o objetivo deste artigo: destacar e discutir as considerações necessárias para fazer a escolha adequada. Naturalmente, isto é algo que todos os arquitetos têm feito, todo o tempo embora, provavelmente, pela perspectiva de componentes de software refinados. O que queremos fazer é esclarecer essa escolha de componentes da solução e verificar se é aplicável ao mundo dos serviços. Para explorar este assunto mais detalhadamente, identificamos três áreas que consideramos dignas de discussão: um framework de avaliação, forças e um jogo de equilíbrio. Porque é algo que todos conhecemos, veremos essas áreas primeiramente no contexto de componentes. Em seguida, experimentaremos se o mesmo raciocínio pode ser aplicado aos serviços. Já de início, afirmaremos que, em última análise, é uma decisão do negócio e não da tecnologia. Definições Aqui estão as definições do Oxford English Dictionary dos termos reutilização, comprar e construir : Reutilizar A ação de usar algo novamente. Em termos arquiteturais, reutilização pode significar coisas diferentes para diferentes arquitetos. Por exemplo, poderia significar reutilizar uma solução completa de TI existente, criando outra instância dela para satisfazer alguns outros requisitos do negócio. Alternativamente, poderia significar que um número de usos de soluções, de mesma funcionalidade, está contida em outra solução para satisfazer as partes ou todos os seus requisitos. Comprar Obter algo em troca de pagamento. Em termos arquiteturais, a compra de pacotes tem sido lugar comum durante muitos anos. Para os fins deste artigo, comprar refere-se à aquisição de um componente ou serviço de software. respeito ao desenvolvimento de uma solução personalizada usando ferramentas e metodologias de desenvolvimento de software. Framework de avaliação É nossa opinião que as considerações e a decisão de reutilizar, comprar ou construir recaem nas seguintes categorias: estratégica, operacional, comercial e técnica (ver Figura 1). Considerações estratégicas, que lidam com a visão de longo prazo e a orientação de uma organização. Como as coisas devem ser sem a influência externa de outros fatores. Estas incluem: " Quota e diferenciação de mercado. " Crescimento. " Gerenciamento estratégico de mudanças. " Portfólio gerenciado. Naturalmente, existem outros fatores que determinam o caminho que uma decisão pode tomar. Esses fatores se enquadram na categoria operacional e incluem: " Governança. " Gerenciamento de mudanças. " Habilidades. " Suporte e manutenção. Juntamente com as considerações estratégicas e operacionais, há aquelas que se enquadram nas categorias técnica e comercial. As considerações do negócio são aquelas que suportam os objetivos do negócio a curto e médio prazos. Estas incluem: " Custos de entrega e execução. " Gerenciamento de contratos. " Depreciação de ativos. " Provisões internas ou externas. Figura 1: Categorias de consideração Estratégica Negócio Construir Criar agrupando peças ou materiais. Para os fins deste artigo, construir, no âmbito da comunidade de arquitetura, pode ser um conceito enganoso para alguns. Assim, construir neste artigo diz Operacional Técnica 11

14 Reutilizar, comprar ou construir: componentes e ser viços Tabela 1: Framework de avaliação Reutilizar Comprar Construir Positiva Prazo de entrega Complexidade Custo Vencimento Prazo de entrega Suporte Vencimento Correspondência de requisitos Manutenção Suporte Negativa Compromisso com requisitos Manutenção Suporte Compromisso com requisitos Manutenção Complexidade Custo Prazo de entrega Complexidade Custo Vencimento Considerações Governança Consolidação Cultura Integração Personalização Habilidade Relevância A consolidação descreve o desejo de minimizar a quantidade de ativos que fornece funcionalidade semelhante. Talvez isso represente alcançar uma variedade de resultados, que variam da redução do custo global à entrega de fontes de dados que apresentam uma versão única da verdade. Para ser executada com êxito, a consolidação precisa ter fortes vínculos com a governança. Por fim, é preciso que a organização tenha a cultura correta para ter êxito ao tentar reutilizar ativos. Isso pode resultar em capacidade de compromisso para satisfazer as necessidades mais importantes do negócio, em vez de satisfazer completamente as necessidades de um projeto específico. Na categoria reutilização, também vale a pena afirmar que algum esforço de desenvolvimento pode ser necessário para conseguir reutilizar um ativo, ou seja, não se trata simplesmente de reutilizar um ativo e, então, ignorar completamente as outras categorias. A maioria das organizações têm uma estratégia técnica que afirma A integração e a personalização são as considerações quais tecnologias podem ser usadas e para quais finalidades. As de ordem superior dentro da categoria comprar. A integração é, considerações nesta categoria incluem: provavelmente, autoexplicativa, quando um componente escolhido para reutilização precisa ser integrado ao que já está instalado e ao " Escolha da tecnologia. planejado para o futuro. É preciso estar atento ao nível de " Interoperabilidade/integração. interoperabilidade do ativo. Vale a pena lembrar que interoperabilidade facilita a integração. Evidentemente, a integração " Repositório de ativos. não é só uma consideração técnica; refere-se também a outras áreas, Embora seja importante entender as considerações de nível superior como pessoas, processos e ferramentas. que afetam a direção do negócio, é provavelmente mais valioso para Cuidado com a personalização. Um elevado grau de personalização os nossos propósitos explorar um pouco mais fundo e identificar as pode eliminar alguns dos benefícios atribuídos à categoria compra e considerações de nível inferior. Para tanto, criamos um framework de pode introduzir novos inconvenientes. avaliação. Novamente, similar à categoria reutilização, é bastante provável que Framework de avaliação algum esforço de desenvolvimento seja necessário quando se compra O framework de avaliação oferece uma classificação para os tipos de um ativo. O valor também pode depender do nível de considerações no contexto do negócio. Agora, queremos avançar e interoperabilidade do ativo. examinar as considerações elementares: Por fim, a categoria construção tem habilidade e relevância como as O framework de avaliação identifica sete atributos que influenciam a suas duas considerações de ordem superior. Habilidade refere-se aos decisão de contratação. Estes são: prazo de entrega, complexidade, conhecimentos necessários para desenvolver um ativo. Isso pode ser custo, vencimento, compromisso/correspondência com requisitos, uma decisão binária simples: você tem a habilidade ou não? manutenção e suporte. A nossa esperança é que a escolha das palavras Evidentemente, a resposta a esta pergunta talvez não elimine, ofereça explicação satisfatória do que queremos dizer; portanto, não necessariamente, o desenvolvimento como opção; há abordagens falaremos mais. alternativas, tais como off-shore (modelo de realocação de processos No entanto, acreditamos vale a pena discutir os itens na coluna do negócio). No entanto, esta é, provavelmente, uma outra discussão. considerações. A idéia aqui é identificar os fatores de ordem superior Assim, para fins deste assunto, a decisão poderá ser um pouco mais que devem ser considerados na tomada de decisão. Também vale a fácil se não houver nenhuma habilidade. pena notar que a consideração específica pode não ser exclusiva para Se a capacidade a ser implementada for relevante ao negócio ou a categoria à qual está alinhada. Assim, por exemplo, reconhecemos seja, um diferenciador provavelmente a categoria construir será a que a governança é também uma consideração na compra ou no melhor abordagem ou a única. Vale notar que relevante não significa, desenvolvimento de um ativo, mas acreditamos que seja de automaticamente, relevante para o negócio ou vice-versa. Uma importância superior quando se pensa em reutilização. capacidade pode ser considerada relevante para o negócio, mas não a base do negócio; uma função de recursos humanos pode bem ilustrar Na categoria reutilização, governança, consolidação e cultura são as este ponto. considerações prioritárias identificadas. A governança abrange áreas como propriedade de uma capacidade específica e dados do negócio. Consideramos inclusive uma quarta categoria, um híbrido de duas ou O responsável pode ser considerado o guardião do ativo, que lida com mais das categorias. Isto é algo que acontece com bastante coisas como solicitações de alteração da funcionalidade e dos regularidade no âmbito de setores específicos. Por exemplo, é muito dados.identificar o responsável é tarefa que não deve ser subestimada: comum no setor de petróleo e gás para duas ou mais empresas pode ser muito difícil, desafiadora e carregada de política. A diretiva concorrentes desenvolverem algo juntas e, depois, reutilizá-lo entre que descreve a motivação e a execução da estratégia de reutilização elas. Provavelmente, há muito o que se aprender com esses tipos de também estaria no âmbito da governança. atividades, embora essa discussão fique fora do escopo deste artigo. 12

15 Arquiteturas econômicas por Mark Bloodworth A principal preocupação da arquitetura é proporcionar agilidade pela estabilidade ou seja, poder acomodar as alterações inevitáveis com um mínimo de esforço e ruptura. Técnicas tradicionais, como baixo acoplamento e alta coesão certamente ajudarão, mas não serão suficientes. Lida-se melhor com a incerteza tomando a decisão da responsabilidade no último momento; adotar a incerteza desta forma resultará, naturalmente, em uma arquitetura que cuida da mudança. Teorias projetadas para lidar com a incerteza em outros setores, como a Real Options, também podem ser aplicadas de modo útil à tomada de decisões arquiteturais. Voltando ao presente, as mais prementes questões são onde e como fazer investimentos. A teoria utilitária pode ser aplicada para decidir onde investir: tendo um grupo de pessoas, atribuir valor e custo aos candidatos é uma aplicação simples desta teoria. O valor e o custo devem ser feitos em unidades; não é importante o significado das unidades, desde que sejam consistentemente aplicadas. Durante o processo, também é importante separar o custo do valor. Esta técnica proporciona um meio de comparação, juntamente com uma explicação e registro de como chegou-se à decisão. Esta também é uma técnica que pode ser facilmente aberta a todas as partes interessadas (alguns talvez não consigam fazer avaliações de valor e outros, talvez, não consigam fazer avaliações de custos, mas a contribuição global é o que interessa). Quando esta decisão for tomada, teremos de decidir se ampliamos um sistema ou serviço existente, ou introduzimos um novo sistema ou serviço (com a decisão associada de construir vs comprar). Deve-se notar que o mapeamento de função para área do negócio tende a resultar em maior integridade conceitual a qual, por sua vez, torna a arquitetura mais facilmente compreendida e duradoura. Um bom princípio a seguir é implementar o menor número de recursos possível que se encaixa bem com a tomada de decisão no último momento responsável. O passado não deve ser ignorado na confrontação das decisões arquiteturais. Analisando em retrospecto as decisões arquiteturais, é possível identificar tendências e problemas. Pode-se observar os sistemas e serviços difíceis de serem alterados, e estratégias podem ser concebidas para saber como substituí-los e assim reduzir a sobrecarga. Se houver um registro de como foram tomadas as decisões anteriores, será possível analisar a eficácia dessas decisões e aprimorar o processo da tomada de decisão. Mark Bloodworth (marblood@microsoft.com) é arquiteto evangelista da equipe Developer and Platform Evangelism na Microsoft do Reino Unido. Figura 2: Empurrar/puxar forças ou motivadores Sustentabilidade Custo Decisão Tempo Qualidade Em todos esses casos, é importante reconhecer o impacto de tais considerações sobre a decisão final, e classificá-las dessa forma proporciona um mecanismo para garantir a aplicação de uma abordagem objetiva ao processo de seleção e à exposição das oportunidades. Forças Naturalmente, existem outras forças que influenciam as decisões. Nós nos referimos a elas como forças que empurram e puxam, mas algumas pessoas podem considerá-las motivadores (consulte a Figura 2). Estas forças empurram e/ou puxam as decisões da solução em direções específicas, embora alguns talvez as vejam como menos do que o ideal, o que é inevitável. Cada conjunto de motivadores pode ser considerado único em uma organização; exemplos típicos de motivadores são os seguintes: " Custo O motivador deve permanecer neutro em custos ou, talvez, mais rentável por exemplo, financeiramente viável, ROI positivo (retorno financeiro) e, por fim, as implicações do custo de não fazê-lo. " Qualidade O motivador para alcançar um resultado que atende ou excede as expectativas de qualidade de um cliente por exemplo, de % de disponibilidade. " Tempo O motivador deve estar no mercado em primeiro lugar para ajudar a ser diferente dos concorrentes. " Sustentabilidade O motivador deve reduzir o consumo de energia e melhorar a pegada de carbono da organização. A intenção destas e de outras forças identificadas pela organização é a de garantir que sejam simples (ou seja, é racional para a organização), mensuráveis (ou seja, a organização pode reconhecer quando foi cumprida), possíveis e realistas (ou seja, está dentro das possibilidades da organização) e, finalmente, oportuna (ou seja, pode ser entregue no prazo acordado). Regra prática: assegurar que as forças escolhidas sejam INTELIGENTES. Jogo de equilíbrio Em última análise, qualquer decisão para a solução tomada por um arquiteto é, quase sempre, um jogo de equilíbrio (consulte a Figura 3) entre os sete atributos, as considerações de ordem superior e as forças. Não será nenhuma surpresa o fato de não acreditarmos que exista uma solução com a qual um arquiteto possa alimentar todos esses insumos, abrir a porta e exibir a resposta; tampouco acreditamos que qualquer dos três tenha prioridade maior sobre cada um deles. 13

16 Reutilizar, comprar ou construir: componentes e ser viços Figura 3: Descrição do jogo do equilíbrio Negócio Requisitos Custo Prazo de entrega Motivadores do negócio Técnica Manutenção Suporte Vencimento Complexidade Assim, onde ficamos depois de tudo isso? Como com qualquer processo de tomada de decisões, consideramos importante assegurar que as decisões para a solução sejam transparentes, claramente transmissíveis e compreendidas por aqueles que precisam saber e devem aceitá-las. A nossa abordagem nos levou à conclusão de que utilizar o framework de avaliação com uma compreensão das forças da organização proporciona uma ferramenta de avaliação simples para o uso de arquitetos que devem fornecer uma proposta equilibrada. Em nenhum aspecto considera-se esta abordagem um substituto para o necessário rigor exigido para arquitetar soluções, e não diminui a necessidade de uma compreensão mais sofisticada e mais profunda da arquitetura e do uso de metodologias que existem, e que arquitetos usam hoje e usarão no futuro. Por exemplo, a medição de cada força SMART pode ser de especial importância e relevância na avaliação das opções da solução. Um diagrama tipo aranha (Spider Diagram), como mostra a figura seguinte, pode ajudar a comunicar o ajuste relevante que a solução tem de um conjunto identificado de motivadores do negócio. No primeiro exemplo (Figura 4), o diagrama tipo aranha ajudaria uma organização para a qual a qualidade é importante (talvez uma empresa de engenharia) a identificar que um componente da solução não tem qualidade aceitável e, portanto, não pode ser usado. No segundo exemplo (Figura 5), a mesma organização engenharia poderia ficar tranquila pois o componente da solução é de alta qualidade para o uso pretendido, e a empresa estaria disposta a aceitá-lo. A produção de diagramas tipo aranha como esses, para cada opção da solução, pode ajudar a destacar visualmente qual deles oferece o melhor ajuste. Serviços Desde o momento em que surgiu a função, os arquitetos têm respondido as questões que propusemos aqui. Nos últimos anos, acreditamos que as questões têm sido mais relevantes para componentes de software, e não para serviços, tema do nosso artigo até agora. No entanto, o surgimento de serviços e coisas como computação na nuvem fazem e continuarão a fazer com que o dilema da reutilização, compra ou construção seja mais relevante do que nunca. Sem dúvida, o ponto de partida dos serviços é um pouco diferente daquele dos componentes especificamente, na categoria de reutilização. Se uma empresa já utiliza um serviço, as chances desse serviço ser reutilizado em outra circunstância são extremamente elevadas. Tomemos, por exemplo, qualquer conjunto de dados comum que utiliza várias soluções talvez um instrumento de verificação de crédito no setor bancário ou uma lista de revendedores no setor automobilístico. O projeto e a implementação deles, como serviços, significa que podem ser reutilizados por outros sistemas no âmbito da organização. Além disso, não é inconcebível sugerir que também pode surgir como um produto novo no portfólio de produtos da organização para a compra por outras organizações por exemplo, um serviço de pesquisa de endereço para resolução de endereços postais. Abre-se outra discussão (para outra oportunidade) sobre uma dimensão adicional possível para o framework de avaliação, que aborda o consumo externo e interno ou a prestação de serviços. Tudo isso levanta uma pergunta: a capacidade deve ser entregue como um componente de software ou serviço? Se tudo for igual, se a motivação for a reutilização, a resposta pode ser muito simples embora, evidentemente, isso possa ter a influência de vários fatores. Embora seja interessante e importante decidir se componente ou serviço, neste momento o que nos preocupa é saber se construímos ou compramos o próprio serviço. Além disso, a experiência e as regras que utilizamos no passado são aplicáveis? Figura 4: Diagrama de forças opção de solução 1 Figura 5: Diagrama de forças opção de solução 2 Custo Custo Sustentabilidade Qualidade Sustentabilidade Qualidade Tempo Tempo 14

17 Reutilizar, comprar ou construir: componentes e ser viços Conclusão Neste artigo, discutimos três áreas principais: framework de avaliação, forças e equilíbrio. Ao considerarmos as opções comprar ou construir, vamos analisar uma área de cada vez e as possibilidades de aplicação aos serviços de cada uma delas: Comecemos com o framework de avaliação. Parece que os sete atributos aplicam-se aos serviços da mesma forma que aos componentes; as considerações, no entanto, talvez não. Sobre comprar, integração e personalização foram as considerações de ordem superior identificadas. É o mesmo caso da integração; no entanto, a personalização não deve ser uma preocupação prioritária. Se tivermos de considerar, talvez haja um problema com a escolha do serviço; por exemplo, o compromisso nos requisitos é muito alto para ser aceitável. A situação é diferente para a categoria construir. Neste caso, as considerações de alta prioridade foram habilidade e relevância. Essas duas considerações são fatores importantes para os serviços. Da mesma forma que com componentes, exige-se habilidade para construir um serviço; e, se esse serviço for relevante para o negócio, é muito provável que a opção de construir será a preferida. Provavelmente, os serviços garantem uma dimensão adicional ao framework de avaliação, para aplicar outras considerações. Acordos de nível de serviço são sempre um tema controverso na questão dos serviços. O serviço oferece disponibilidade, confiabilidade e escalabilidade necessárias para a demanda do negócio? Se considerarmos o exemplo anterior de verificação de crédito, se este serviço fizer parte de um processo do negócio mais amplo (o que, provavelmente, é o caso) e se o processo ponta a ponta tiver de ser concluído em um prazo predeterminado, as questões de serviço (como confiabilidade) são uma consideração essencial. Notamos também que as empresas com acordos de parceria firmados com outras organizações no curso das suas atividades aceitam um modelo de serviços. Conseguem ver claramente as vantagens, compreendem a abordagem e os riscos, e têm a vontade e a cultura do êxito. Exemplo dessa atividade é o setor da aviação. Hoje, o setor trabalha com inúmeros parceiros para entregar o serviço ponta a ponta para os seus clientes por exemplo, check-in inicial, o voo propriamente dito e, finalmente, recuperação da bagagem no destino. Refletindo sobre o que discutimos, acredito que as forças e o jogo de equilíbrio são tão úteis na análise dos serviços quanto para componentes. Assim, arquitetos devem confiar e usar o conhecimento de experiências passadas em projeto de componentes de software, no projeto de soluções que incluem serviços. Sobre os Autores Simon Thurman, (simont@microsoft.com) arquiteto evangelista da Microsoft, é arquiteto do grupo de desenvolvedores. Nos últimos 20 anos, ele arquitetou e desenvolveu software em mainframes, nas arquiteturas cliente-servidor e na Internet. Esse software importante garante que você tenha o endereço correto, algoritmos de roteamento e simplificação do processo de movimentação interno. Hoje, ele ajuda os clientes a fazer coisas inovadoras com novas tecnologias para gerar valor ao negócio. Ele passa as suas horas de lazer ao lado da esposa e filhas, e praticando de mountain biking. Phil Rowland (philip.rowland@capgemini.com) é arquiteto corporativo da Capgemini UK plc. Nos últimos 20 anos, ele desempenhou com êxito uma série de funções, incluindo prevendas, estratégia técnica, consultoria técnica, análise de negócios, projeto de soluções, desenvolvimento de software e gerenciamento de implantações. O cabedal de conhecimento de Phil e a sua experiência permitiram-lhe projetar uma série de soluções altamente disponíveis, escaláveis e robustas para clientes dos setores público e privado; além disso, prestou assessoria e consultoria para empresas e o setor de arquitetura de soluções. 15

18 Reutilizar, comprar ou construir: componentes e ser viços Arquitetos e a resistência econômica por Nirmala Desai Resumo: Nestes tempos de restrições globais de orçamento, aqui vão algumas dicas para ajudar os arquitetos a se defrontarem com os seus desafios normais, e também com o conceito faça mais com ainda menos. Este artigo concentra-se no investimento, sensato, em estratégias e novas tecnologias que irão modernizar o negócio, seguido de uma nota curta sobre as áreas que ajudam a reduzir o custo total de propriedade (TCO, total cost of ownership). Subir na cadeia de valor A primeira forma de subir na cadeia de valor é usar tecnologia para gerar receitas para o negócio, seja fornecendo um canal adicional de marketing em sites de rede sociais ou promovendo o conteúdo em celulares. A outra, é reduzir os custos de manutenção pela automatização dos processos trabalhosos e, em seguida, otimizar e promover a reutilização de componentes técnicos. Enfrentar o desafio de manter a coluna vertebral de TI flexível Você talvez já esteja estudando o gerenciamento de processos do negócio e a arquitetura orientada a serviço. Embora não tenham se comprovado como a panacéia de todos os males, forneceram flexibilidade para a automação do processo e recursos de interoperabilidade que provaram ser uma vantagem definitiva. A arquitetura empresarial é um resultado da evolução. Para domesticar esse animal, você poderia criar modelos de domínio e usá-los para fornecer um rumo geral para a arquitetura e, assim, evitar muita redundância, ou você poderia criar uma biblioteca de ativos que promovesse a reutilização na organização. Enfrentar desafios da modernização do legado Em conjunto com preocupações de orçamento, falta de know-how também é um desafio. Embora existam ferramentas que ajudam no desenvolvimento orientado a modelo, analisadores de código que podem elaborar um modelo do código legado exigem inteligência que ainda não está disponível. Arquitetos de produto podem procurar inovar com base em ferramentas e tecnologias para transformar aplicativos legados em plataformas mais modernas. Arquitetos corporativos podem analisar as suas necessidades de modernização e estabelecer estratégias para construir parcerias duradouras com fornecedores relevantes de serviços e produtos. Enfrentar as necessidades de colaboração Se comparadas ao , as tecnologias de colaboração fornecem maneiras ainda mais rápidas para a aprovação de documentos e tomada de decisões, removendo a dinâmica múltipla necessária entre pessoas diferentes. Mais recentemente, a conferência pela Internet está atendendo a essas necessidades. No entanto, existe uma lacuna que impede estabelecer uma conferência com pessoas que não utilizam, necessariamente, a mesma infraestrutura. Implementar a comunicação unificada Embora as vantagens das ferramentas de colaboração sejam bem conhecidas, a comunicação unificada ainda tem que chegar a uma fase em que seja bem compreendida pelas equipes de infraestrutura e implementação. Isso pode ser um bom momento para rever as ferramentas disponíveis e preparar um caso comercial para a sua implementação. O cenário em que isso pode ser benéfico será aquele em que um gerente de projeto necessita por pouco tempo e urgentemente um recurso que tenha determinado o conjunto de habilidades. O gerente de projeto poderia localizar rapidamente a pessoa necessária, acessando um diretório interativo (não no mesmo domínio do gerente de projeto), comunicar-se por mensagem instantânea e então continuar com uma chamada de voz ou até mesmo uma chamada em vídeo tudo na mesa do gerente de projeto, e em minutos. Esse recurso pode estar localizado em outra região e ser disponibilizado para a tarefa virtual ou fisicamente, e por contrato. Preparar-se para a retomada Isso é algo que nem todo mundo está considerando. A economia voltará a prosperar, quando um novo sistema financeiro estiver implantado, mais transparente e, talvez, mais avesso ao risco. As pessoas estão segurando os investimentos, não porque acreditam que o sistema está contaminado, mas porque têm medo. Nesse momento, parece ser uma perspectiva sensata para as empresas prever a necessidade de transparência e de construir estratégias claras de avaliação e redução de riscos; os arquitetos devem preparar os seus sistemas para o mesmo não só no financeiro, mas em todos os setores. Reduzir o TCO As áreas que ajudam a reduzir o TCO incluem a virtualização, que torna redundante a disponibilidade física de sistemas, e a computação na nuvem, pela qual as empresas deixam de se preocupar com a manutenção de seus equipamentos e aplicativos e podem se concentrar na sua atividade principal. Você também pode aproveitar os seus sistemas ERP já implantados para oferecer mais valor. Cortar o excesso pode exigir consolidação do seu cenário de IT, dos locais de armazenamento de dados mestre, revisar os seus mecanismos de integração e torná-los todos menos complexos. Nirmala Desai (Nirmala.desai@patni.com) fornece gerenciamento de projetos e consultoria técnica a clientes em todo o mundo. Atualmente, está envolvida no desenvolvimento de métodos inovadores para modernizar os aplicativos legados para a plataforma Microsoft. 16

19 Vida longa e próspera : retenção de clientes e funcionários com um processo ágil por Rodney Guzman Resumo Este artigo traça o perfil da evolução em uma empresa de serviços profissionais concentrados no desenvolvimento de aplicativos de software. Introdução Construir software é uma arte. E assim como um edifício, um software bem construído terá uma vida longa sem exigir atualizações e manutenção constantes. No entanto, diferentemente da construção civil, cada parte construída é exclusiva. Se os desenvolvedores de software não podem fazer moldes para construir os seus aplicativos de software, como fazem com os módulos de uma casa, como podem se tornar mais eficientes? Ser mais eficiente nos permite criar software de maior qualidade em menos tempo. E menos tempo significa gastar menos dinheiro. Desde a elaboração de bibliotecas de controles reutilizáveis à execução de um processo de desenvolvimento ágil e promover a evolução dos funcionários com a ajuda de mentores, cada aspecto do desenvolvimento de software pode ser aprimorado para reduzir o custo da criação de software. Este artigo traça o perfil da evolução em uma empresa de serviços profissionais concentrados no desenvolvimento de aplicativos de software. Nos últimos 10 anos, este negócio teve de se tornar mais eficiente para se manter competitivo e diferenciado em um mercado que transformou em mercadoria muitos aspectos de suas ofertas. Muitas duras lições foram aprendidas, mas os resultados conferiram vigor ao negócio, mesmo na economia atual. No centro de tudo está uma metodologia híbrida e ágil aplicada a tudo, desde aplicativos de âmbito corporativo até aplicativos para testes de uma semana. O motor desse processo são aplicativos de software e engenheiros de sistema, de projeto e de engajamento, todos, em sincronia. Descubra o processo que esse negócio utiliza hoje para construir o seu software de maneira uniforme, dentro do prazo e do orçamento. Faça do cliente o seu aliado Os seus clientes podem ser extremamente diversos, com formações e expectativas muito diferentes sobre como o desenvolvimento de software personalizado é executado. Ou então você pode ter sorte e ter apenas clientes internos, que estejam muito bem familiarizados com o seu processo de desenvolvimento de software. Em um ou noutro caso, o seu trabalho será lembrado pelo cumprimento da promessa de fornecer o que havia dito que seria fornecido. pensavam que seriam desenvolvidos não foram, ou estavam atrasados e não souberam disso em tempo hábil. Eles podem ficar constrangidos porque as promessas que fizeram foram quebradas pelo mesmo motivo: um recurso que deveria ter sido fornecido não está disponível. O desenvolvimento de software personalizado pode ganhar vida própria depois que o projeto começar. Sabe-se bem que é praticamente impossível detalhar cada requisito de cada recurso, antes que o código seja gerado. Já se foram os dias em que semanas (ou mesmo meses) eram gastos na documentação de requisitos que tornavam-se obsoletos rapidamente durante o projeto. A indústria de software já percorreu um longo caminho, e os seus clientes já acumularam muito conhecimento. O conceito de maturação dos recursos à medida que o projeto avança não é desconhecido, e os clientes esperam que você seja capaz de reagir a mudanças durante o projeto. Manter o cliente envolvido e integrante do processo de tomada de decisão quanto a tais mudanças é a coisa certa a se fazer. Todos sabem que ocorrerão mudanças durante a construção de uma solução personalizada, novos recursos aparecerão e prioridades serão alteradas. Adotar essa fluidez e imergir os clientes nela permite que todos estejam no mesmo passo. Quando os seus clientes querem um novo recurso, ele é colocado em um backlog (lista de espera) de recursos a serem criados. Uma prioridade lhe será atribuída e todos deverão concordar que, sem uma alteração de âmbito ou cronograma, outros recursos não serão desenvolvidos no produto final. Permitir que seus clientes mudem as prioridades durante o projeto e ajudá-los a compreender as ramificações da implementação dessa ação permite que eles se tornem parte da solução e, assim, seus aliados. Os seus clientes se sentirão habilitados por poderem influir no projeto. Eles devem participar de reuniões de comunicação de estado o mais frequentemente possível (como duas vezes por semana) para que estejam sempre a par do andamento do projeto, e isso não pode ser feito com relatórios semanais de status que ninguém lê. Se os clientes forem parte do processo de criação, e não simplesmente recebam um produto ao final de um sprint (etapas curtas e rápidas que geram um produto intermediário), eles já saberão o que está sendo entregue antes de ver o produto, bem como poderão ajustar as expectativas de forma ativa. O risco de retrabalho para agradar um cliente é bastante reduzido, você completa o trabalho no prazo prometido e a sua equipe de projeto pode ser liberada de acordo com o programado, para trabalhar em outros projetos. Os seus clientes voltarão a pedir mais trabalhos e o indicarão para novos clientes. O que deve ser reconhecido é que não importa a qualidade da solução técnica que você produza: o sucesso será medido pelo grau de satisfação das necessidades dos clientes. O processo utilizado para criar soluções personalizadas deve envolver de forma proativa os tomadores de decisão, que julgarão se o resultado é ou não bem- sucedido. Os seus clientes nunca devem ficar surpresos ou constrangidos. Eles podem ser surpreendidos quando os recursos que Pode-se pensar que o que se está defendendo aqui é uma receita para um projeto sem fim, o que não poderia estar mais longe da realidade. A meta do processo é dirigir o avião, ou o seu projeto, até a aterrissagem de forma íntegra, intacto, e o mais próximo possível do que o cliente queria. O fato de que alguns detalhes possam estar faltando no produto final será algo com o qual o seu cliente já terá concordado. 17

20 Vida longa e próspera : retenção de clientes e funcionários com um processo ágil Os atores As pessoas fazem o processo ser executado. Certamente existem ferramentas de software, como o Microsoft Team Foundation Server, que possibilitam o processo, mas não se pode atingir eficiência apenas pela instalação e utilização de um produto. Existem atores principais nessa dança e que conferem agilidade ao processo: gerentes de projeto, desenvolvedores e pela falta de um termo consagrado no setor gerentes de engajamento. O trabalho que poucos querem e menos ainda são capazes de desempenhar Muitos desenvolvedores veem o gerenciamento de projetos como um mal necessário. Está claro que as expectativas de um gerente de projetos (PM) variam enormemente de uma empresa para outra. Aqui, elas ajudam a trazer ordem para o caos. Eles são os heróis desconhecidos do fornecimento e estão propensos a serem considerados os vilões pelos desenvolvedores. Eles garantem que nenhum detalhe seja deixado de lado, e mantêm a responsabilidade da equipe e dos clientes. Depois do início do projeto, o PM é o principal ponto de contato com o cliente. O PM intermedeia todas as conversas com o cliente (inclusive é quem recebe uma cópia de todas as mensagens de ) e é responsável pela decisão final para tudo que afete o programa e o âmbito. O PM não deixa chegar aos desenvolvedores minúcias de ordem política que frequentemente acontecem em um projeto. O PM inicia e facilita conversas com os clientes quando os desenvolvedores não querem aceitar a interpretação de um recurso. Comunicações constantes é o mantra do PM e a proteção contra malinterpretações dessas comunicações é essencial. Toda comunicação não registrada pode resultar em decisões centrais tomadas e alterações de âmbito, bem como itens acionáveis dos quais depende a equipe para o cumprimento de prazos intermediários. Essas interações devem ser documentadas e redistribuídas via a todos os participantes para que todos, incluindo o cliente, compreendam como a equipe interpretou a conversa. A primeira vez que você tiver de se apoiar em uma dessas mensagens de para demonstrar por quê algo que um cliente não esperava ocorreu durante o projeto será a última vez que você precisará de uma prova para se justificar, ou seja: definitivamente vale a pena registrar tudo. Não ter aquela mensagem para servir de apoio é muito pior e pode significar que você tenha de compensar, às próprias custas, o tempo necessário. Para a equipe, o PM irá monitorar o progresso de cada produto intermediário. O progresso deve ser medido diariamente, com produtos intermediários (para manter o cliente envolvido no nível apropriado) a serem fornecidos a cada duas semanas. Os seus desenvolvedores devem informar o número de horas gasto ao final de cada dia, de uma forma que fique claro o esforço despendido em suas tarefas e quanto tempo eles estimam que será necessário para concluí-las. Toda manhã, o PM deve aplicar sua determinação e verificar a cadência do projeto e o impulso que está tendo na direção da entrega dos itens intermediários. Pequenas correções de curso, como dar ajuda adicional para desenvolvedores para que não fiquem girando em falso, podem ser feitas todos os dias. Manter todos se movendo na direção do produto intermediário é o trabalho de um PM. Desenvolvedores, desenvolvedores, desenvolvedores, desenvolvedores Para uma organização que cria software personalizado, nada é mais oneroso que substituir um desenvolvedor. O processo é projetado para proteger os desenvolvedores contra comprometimentos irreais, 18 erros de comunicação entre cliente e equipe, e horas extras constantes. Promover um ambiente de feedback, participação e senso de propriedade contínuos acabará com sentimentos de impotência e com não dar mais a mínima para o resultado do projeto. Muitos desenvolvedores conferem a si poderes sobre-humanos quando se trata da velocidade da qual se acham capazes para realizar tarefas. Muito frequentemente, porém, não consideram o tempo gasto na discussão de detalhes, as reuniões, redação de documentos, teste de unidades e implantação de códigos. Assim como você deve incluir o seu cliente como membro ativo do projeto, deve fazê-lo com os seus desenvolvedores. Dar a toda a equipe um senso de propriedade dos produtos a serem entregues é o que deve ser buscado com empenho. Para os desenvolvedores, o senso de propriedade pode ser obtido permitindo que façam estimativas de suas tarefas. No início, as estimativas serão muito imprecisas, e eles sofrerão as consequências com turnos de trabalho prolongados para cumprir o que estimaram. Mas bastará um pouco de experiência para que aprendam a dar estimativas bem mais realistas. O resultado final é o senso de propriedade dos produtos a serem entregues, e enfatizar isso nunca é demais. Afinal de contas, trata-se de desenvolvimento de software, e nem tudo sai de acordo com o que planejamos. Às vezes, é necessário um esforço adicional para colocar o trem de volta aos trilhos. O processo de comunicações constantes na equipe é projetado para impedir que o trem descarrile por completo. Contudo, os membros da equipe precisarão trabalhar horas extras para voltar ao caminho certo. E com o senso de propriedade, terão muito mais vontade de corrigir as coisas. Todo projeto tem um desenvolvedor com uma função especial: este é o colega técnico do PM. Essa pessoa lidera a equipe de desenvolvedores e é responsável pelo design, arquitetura e desenvolvimento das partes mais complexas do projeto. Os padrões de código são impostos pelo líder, que serve de mentor à equipe de desenvolvimento e faz análises de código, conforme a necessidade. O líder técnico é subordinado ao PM e, sem um consenso com o PM, não pode se desviar das tarefas que foram acordadas. O seu cliente muitas vezes estabelecerá uma relação especial com o líder técnico, e às vezes tentará passar por cima do PM e contatá-lo diretamente. O líder é responsável por garantir que a equipe faça estimativas com a maior precisão possível. Os que pagam o almoço A função de um gerente de engajamento é estabelecer um relacionamento com o seu cliente, que inclua todos os projetos passados, atuais e futuros em potencial. Mais que um vendedor, esses gerentes compreendem os negócios do cliente e os detalhes técnicos do que está sendo entregue. Eles merecem uma menção honrosa aqui, porque o gerente de engajamento é a pessoa que o PM e o líder técnico podem aproveitar para persuadir o cliente a alinhar suas expectativas com as da equipe. O fato é que nem todo detalhe do seu projeto pode ser documentado. Muitas conversas, acordos e entendimentos que nunca chegam ao papel são formulados quando o projeto é inicialmente concebido. O gerente de engajamento é quem constantemente relembra o cliente de todas as discussões e acordos passados, e irá manter o espírito do produto a ser entregue vivo e de acordo com o que foi estipulado na assinatura do contrato. Isso poderá ser feito durante as reuniões com clientes, nas quais o gerente de engajamento sempre participa. O líder técnico e o PM trabalham juntos do gerente de engajamento, assim, ações preventivas podem ser executadas para gerenciar as expectativas do cliente. Trata-se de um processo ativo que funciona como política de segurança para manter os produtos a serem