A Arquitetura e o Desenvolvimento de Produtos de Software

Otavio Pecego Coelho, Microsoft Corporation

Publicado em: 18 de setembro de 2006

Agradecimentos

Ao Carlos Hulot, Aline Rokutan, Fernando Gebara Filho e Alexandre Nardi pelos comentários e revisões.

Nesta página

Introdução
Arquitetura no contexto de Produtos de Software
Cliente
Marketing e Vendas
Engenharia Financeira
Marquitetura ou Gerência de Produto
Gerência de Projeto
Arquitetura Técnica
Resumo: Arquitetura como Análise e Síntese
Referências

Introdução

Desenvolver produtos de software é um exercício complexo. Já passou o tempo romântico em que ter uma idéia e um teclado na mão eram suficientes. Para os que não estavam aqui no início da década de 80, naquele tempo existia uma janela de oportunidades: um mercado em crescimento, como era o mercado do computador pessoal, e sem produtos para consumir. Neste tempo, muitas empresas de software iniciaram em garagens até se tornarem empresas respeitáveis com processos de engenharia e produção mais estruturados.

Hoje, mesmo com novas ondas surgindo, como a Web 2.0 ou o SaaS (Software as a Service), a indústria de software encontra-se em outro patamar, com um bom conjunto de empresas maduras e capitalizadas. Nestas empresas já existem processos de desenvolvimento de novos produtos que envolvem questões como:

  • análise do mercado (tamanho, oportunidade, geografia, etc.);

  • análise de segmento (ou audiência alvo);

  • análise da necessidade do cliente (potenciais funcionalidades que podem agregar mais valor para o usuário);

  • modelo de negócio (modelo de distribuição, forma de licenciamento ou rendimento, etc.);

  • análise das tecnologias vigentes e das possíveis arquiteturas;

  • questões como patentes, legislação, análise etc.

Bem, este não é o procedimento de empresas menos maduras. Como arquiteto de soluções da Microsoft Brasil, ao visitar produtores de software locais eu costumo encontrar padrões de desenvolvimento de produtos bem diferentes destes processos mais orientados a mercado. Na minha experiência, o que é mais comum encontrar é:

  • desenvolvimento baseado em personalizações (também conhecido como customizações). Isto é, o desenvolvimento é voltado à demanda dos clientes atuais, que pedem personalizações para diminuir deficiências do software ou adaptá-lo melhor para o seu negócio;

  • desenvolvimento baseado em novas tecnologias e funcionalidades de fácil desenvolvimento. Neste caso, o surgimento de funcionalidades novas nas plataformas de infra-estrutura é que determina o rumo do produto. Por exemplo, é fácil encontrar produtos que avançaram na direção de serviços para OLAP a partir do momento em que, por exemplo, o SQL Server 2000 tornou OLAP uma commodity;

Isto significa desconhecimento dos processos? Algumas vezes não. Como as empresas têm dificuldades na captação de capital para o seu investimento, elas acabam escolhendo um caminho mais pragmático e voltado ao retorno em curto prazo. Alguns podem chamar de ágil, outros de desenvolvimento oportunístico, mas, por vezes, percebo que algumas empresas perdem oportunidades de alçar vôos maiores com investimentos mais estruturados e de risco menor por simples falta do hábito de olhar de uma forma mais estruturada o mercado. Neste ambiente, muitas vezes o arquiteto de soluções tem sua atuação bastante resumida, focando no design de personalizações ou de pequenas provas de conceitos sobre tecnologias que estão surgindo.

Este artigo apresenta de forma resumida algumas das principais forças que regem a definição de um produto e o papel do arquiteto frente a elas. O intuito é dar ferramentas para que o arquiteto, principalmente o novato, possa aumentar seus horizontes e seja capaz de propor mais conscientemente boas soluções para a linha de produtos da sua empresa.

Arquitetura no contexto de Produtos de Software

Vamos deixar por instantes as definições formais de arquitetura. Seja pelo ANSI/IEEE, SEI (Software Engineering Institute) ou TOGAF (www.togaf.org) (entre outros), a arquitetura é sempre vista como uma atividade estruturante, tendo como partida uma missão de negócios e como fim um conjunto de soluções de TI seja software (arquitetura de solução), infra-estrutura (arquitetura de infra-estrutura), ou conjunto coordenado entre ambos (arquitetura da empresa).

A estruturação tem diversos fins: minimização de recursos, aumento das competências de TI, aderência aos fins de negócio, etc. De certo ponto de vista, o arquiteto deve ser a liga entre a realidade de negócio e a realidade da execução técnica. Ou, melhor, ele deve ter a capacidade de submeter a implementação às razões de negócio. Mas o que é uma razão de negócio frente à criação de um produto de software?

Bem, a definição mais simples tirada do dicionário define produto simplesmente como um bem (artefato ou serviço) feito ou criado. Porém, no contexto do mercado, é um bem que tem que satisfazer alguma necessidade de um usuário ou comprador. Portanto, estabelecer quem de fato é o seu público alvo e compreender suas necessidades é fundamental para conceber um produto.

Cliente

Que aspectos costumam ser relevantes para entender o cliente? Seus valores.

Algumas perguntas nos ajudam a compreendê-lo melhor. Por exemplo: "Quais são as suas necessidades? Quanto de facilidade posso oferecer? Que alternativas eles têm? Quanto de conhecimento eles têm para reconhecer o valor do novo produto? etc.". Podemos criar este questionário imaginando um produto e identificando potenciais usuários, ou, de forma inversa, identificando necessidades de grupos de pessoas e imaginando um produto que possa ajudá-los.

Desta pesquisa, poderemos encontrar tanto o número quanto a capacidade de compra destes clientes. Este aspecto é importante devido ao fator financeiro. Estamos fazendo um produto para poucos e, portanto, de alto custo, ou, ao contrário, um produto para muitos e com custo baixo. A tendência deste mercado é de crescimento?

Outro fator importante é o da competição. Existem competidores? Quais são seus pontos fortes? Quais são suas fraquezas? Existem estratégias de mercado diferenciadas das quais posso levar vantagem frente à competição? Qual será a estratégia de diferenciação do meu produto? Será custo? Funcionalidades? Forma de licenciamento? Etc.

Marketing e Vendas

Competências de Vendas é um outro aspecto relevante na concepção de um produto. Um software, para ser vendido, necessitará de canais de vendas. A escolha dos canais pode ser determinante para a arquitetura do sistema. Atributos como tamanho do software, dependência de outros softwares, forma de acesso (local, Internet, rede local, etc.) podem ser decisivos.

Outras perguntas não tão óbvias se referem à Marca. Por exemplo: estou lançando uma nova versão ou um novo produto? Que aspectos de funcionalidade ou adereços visuais devo mudar para diferenciar esta nova versão? Quando dividi-lo em um ou mais produtos, facilitando a compreensão e obtendo melhor aderência aos segmentos para quem o produto se destina?

O status atual da sua linha de produtos e o eventual reposicionamento pretendido também são relevantes na definição das novas versões. Por exemplo: qual será a sua estratégia sobre os seus clientes atuais? Migração? Lutar apenas por novos clientes? Ambos?

Neste momento, não estamos mais lidando com o comportamento e necessidades de um cliente ideal (ou a média dos clientes). Estamos tentando entender ou criar um mercado. E, se você der a sorte de encontrar uma nova tendência e se estabelecer num novo mercado, isto vai lhe garantir algum tempo sob baixa competição.

Ao identificar um mercado, devemos também ficar atentos ao como vamos ganhar dinheiro com o produto. A monetização pode vir do licenciamento do software, da cobrança do tempo de uma sessão, número de transações, uso de recursos (memória, hardware, instâncias de banco, etc.) ou propaganda. Como sempre, cada caso implica em requisitos de arquitetura diferentes.

Por fim, características de mercado podem exigir funcionalidades diferentes. Por exemplo, é cada vez maior a demanda por interfaces gráficas econômicas e atraentes. Se este for um diferencial relevante para o mercado alvo e, quem sabe, sobre seus concorrentes, considere o aspecto design no seu produto.

Engenharia Financeira

Todo projeto precisa de financiamento. Muitas vezes, temos que adiar algumas funcionalidades para versões futuras em prol de um Retorno de Investimento rápido, a fim de financiar versões futuras ou simplesmente dar retorno aos acionistas.

O planejamento do investimento é um aspecto importante que pode significar o sucesso ou o fracasso de um projeto. Como numa viagem de carro, temos que entender o quanto temos de gasolina e a distância entre postos de abastecimento.

A engenharia financeira tem que estar casada com o plano do projeto (tempo e recursos) e isto influencia diretamente na arquitetura da versão atual e na preparação para versões futuras.

Marquitetura ou Gerência de Produto

Como podemos notar, são muitas as dimensões de um produto e o arquiteto é responsável por entender e levar em conta todos estes aspectos no seu design.

Estes e outros aspectos, já usuais ao marketing, fazem com que Luke Hohmann (ver [Luke Hohmann]) defina o conceito de marchitecture em contraposição a tarchitecture.

Marchitecture, ou arquitetura de marketing, é a perspectiva de negócio da arquitetura do sistema. Tarchitecture, ou arquitetura técnica, trata da perspectiva tecnológica.

Por vezes conhecido como gerente de produto ou product manager (ver [MSF]), a função de marquiteto pode ou não ser realizada pela mesma pessoa, mas é parte fundamental do planejamento da arquitetura do produto e seus requisitos devem ser bem compreendidos pelo arquiteto técnico da solução. Deixar de lado estes aspectos é arriscar o futuro de um produto. Não adiantará o tempo e esforço gasto numa excelente estrutura técnica de um software se o seu destino final (o cliente) não for levado em conta.

Gerência de Projeto

A gerência de projeto é responsável por garantir que o produto seja construído dentro dos limites dos recursos. Muitas vezes isto é entendido como mera administração operacional. No entanto, a visão deve ser muito maior: o Gerente de Projeto é responsável pelo planejamento e cumprimento do plano financeiro e de construção do produto, repassando a todo o time as limitações impostas.

Bons arquitetos não se indispõem com estas limitações. Ao contrário, tornam-se sócios do gerente de projeto para identificar trilhas mais rápidas para implementar um produto de boa qualidade. Projetam, assim, bibliotecas, frameworks, linguagens para domínios específicos, etc. , aumentando a produtividade do time. Por vezes, tratam de educar o gerente de projeto para que um planejamento mais realista seja feito, indicando prós e contras do corte ou aumento de recursos ou do tempo de projeto.

O risco é investir tanto no caminho da trilha que a estrada principal acabe ficando abandonada. Já vi alguns casos de hiper investimento em frameworks que levaram mais tempo e recursos do que o próprio projeto. Esta pode ser uma decisão de negócio consciente e estratégica, caso o futuro reuso do framework seja intenso e o atraso do lançamento do produto seja aceitável. Quando feito de forma inconsciente, temos uma boa chance de investimento desperdiçado.

Arquitetura Técnica

A arquitetura técnica, idealmente, deve ser subserviente à arquitetura de negócio - isto é, a estratégia de negócio definida para a empresa e/ou produto. É problema do arquiteto encontrar meios práticos para organizar e produzir soluções de TI que produzam os efeitos desejados.

O Arquiteto deve ter à mão não só os requisitos de produto e financeiros, mas também um bom conhecimento dos limites impostos como:

  • A quantidade/qualidade dos profissionais de desenvolvimento;

  • Os processos praticados pela empresa;

  • As ferramentas utilizadas;

  • As tecnologias disponíveis;

Com este material em mãos, cabe a ele identificar e comunicar soluções que possam ser realizadas pela equipe dentro do tempo definido e que cumpram os requisitos financeiros e de marketing. Por solução devemos entender tanto seus componentes, as relações entre eles, as entre eles e o ambiente como um todo, assim como os princípios que guiam seu design e evolução (ver definição de arquitetura no IEEE Standard 1471-2000 em http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html

Não é simples. Por vezes temos que mudar o conhecimento da nossa equipe (treinamento ou contratações) ou mudar os processos de produção (veja, por exemplo, o conceito de fábrica de software em [SwFact] ).

No mundo real não existem programadores perfeitos. Além disto, temos softwares legados para conectar, tecnologias antigas a serem mantidas, tecnologias inovadoras desconhecidas, poucos recursos financeiros e arquitetos também imperfeitos.

A complexidade é sempre muito maior do que podemos lidar por três simples motivos:

  • o tempo para dar a solução é finito;

  • o número de variáveis é imensa (e as equações não são lineares);

  • e os requisitos do mundo real, com certeza, mudam!

Portanto, esqueça qualquer tentativa de uma solução ótima e concentre-se numa satisfatória e realista.

Resumo: Arquitetura como Análise e Síntese

Desenvolver um produto é um processo de análise e síntese e são muitas as forças que vão determinar a arquitetura adequada do produto.

Costumo definir as competências para desenvolvimento como internas e externas. Por competências externas, me refiro às forças que vêm direto do cliente e de sua visão de mundo. Entre as principais estão: o grau da necessidade do produto; a aderência deste à sua necessidade; a qualidade percebida dos produtos existentes no mercado; o conhecimento do cliente sobre o contexto do problema e solução; e, por fim, o como são percebidas as ofertas de soluções pelo cliente. Estas forças, em conjunto, dão uma percepção do valor do produto para o cliente.

Do ponto de vista interno, identificamos competências de Vendas/Marketing, competências de Desenvolvimento e Produção e, por fim, a competência financeira (que abarca todas as competências internas). Estas três, juntas, vão determinar o custo do produto. E o preço ao consumidor deverá ser algo entre o valor percebido pelo cliente e o valor de custo.

A figura abaixo resume as competências mencionadas neste artigo.

Cc518039.softwaredev(pt-br,MSDN.10).jpg

Devemos lembrar que esta é apenas uma visão abstrata e pouco detalhada. Literaturas como [Luke Hohmann] abordam com profundidade a gerência de produto em seus vários aspectos.

São muitas competências, sem dúvida. Porém, mesmo que sua empresa não tenha condições de montar um time com especializações nestas áreas, lembre-se que você mesmo pode assumir alguns dos vários "chapéus", preparando-se para uma visão mais holística do processo de definição do seu software.

Para finalizar, vale a pena mencionar que os processos oportunísticos ou os baseados em personalizações podem ser uma necessidade ou um mero hábito. Em ambos os casos, conhecer a existência de processos mais centrados no cliente e mercado é uma oportunidade de melhoria e adaptação frente aos processos atuais. O objetivo é sempre diminuir o risco do investimento e/ou maximizar o seu sucesso.

Referências

[Luke Hohmann] Beyond Software Architecture: Creating and Sustaining Winning Solutions, Addison-Wesley Professional;

[MSF] http://msdn.microsoft.com/vstudio/teamsystem/msf/;

[SwFact] http://msdn.microsoft.com/vstudio/teamsystem/workshop/sf/default.aspx;

Mostrar: