Mês: janeiro 2014

O design de interação e a usabilidade também são preocupações do arquiteto de software

~ Marco Mendes ~ Deixe um comentário

O design de interação é uma disciplina ainda imatura no brasil. Embora até tenhamos cursos lato-sensu na área, ela é ainda confundida injustamente com o desenho puramente estético de páginas Web, ela é muitas vezes ignorada por analistas e desenvolvedores no processo de construção de sistemas. Em muitas empresas, inclusive, é esperado que o Web Designer (que é um outro tipo de profissional) cuide de aspectos associado à usabilidade, acessibilidade e o design de interação.

O design de interação deve ser pensado como um aspecto econômico em sistemas de informação. Cito um exemplo real ocorrido em São Paulo, onde um projeto de refatoração de usabilidade foi realizado para permitir que os atendentes praticamente duplicassem a quantidade de transações de negócio efetuadas em um dia. Neste caso, não houve compras de máquinas adicionais nem refatorações de performance do sistema. Apenas o trabalho de usabilidade gerou maior assertividade na entrada de dados com redução de cliques e esforço dos usuários. Este aspecto da usabilidade, em particular, é chamado de eficiência operacional.

Arquitetos modernos devem se preocupar com aspectos de acessibilidade e usabilidade, dado que a usabilidade pode gerar trade-offs com outros requisitos técnicos como a segurança, desempenho ou escalabilidade.

Arquitetos devem capturar estes requisitos de forma quantitativa.

Exemplos incluem:

  • A acessibilidade das páginas do Web Site XPTO deve atender ao padrão WCAG no nível AA.
  • O tempo de resposta para interações em combos e lookups não deve exceder 1 segundo.
  • O sistema deve fornecer teclas de atalho e aceleradores para que as operações comuns do sistema sejam realizadas sem o uso de mouse.

Um contra-exemplo são os desejos ambíguos como “interfaces amigáveis” , naturais no vocabulário dos usuários. Requisitos objetivos e mensuráveis sempre devem ser capturados pelos arquitetos.

Após capturar os requisitos de forma quantitativa, os arquitetos podem então contar com os profissionais especializados para a implementação destes requisitos (engenheiros de usabilidade e desenvolvedores) e para os testes destes requisitos (analistas de testes).

Arquitetos são então a ponte. Eles ligam os desejos de negócio e os desejos econômicos e tornam estes desejos concretos em requisitos de usabilidades. Eles fazem a tradução destes requisitos para a linguagem dos engenheiros de usabilidade e desenvolvedores e acompanham os testes de usabilidade realizados pelos analistas de teste.

Para aprender mais sobre este assunto, arquitetos podem contar com questionários baseados em modelos com o FURPS+ ou a série ISO 25000. Para os iniciados em usabilidade, as perguntas e os testes podem ser organizadas ao longo dos seguinte temas:

  • Simplicidade. Contra-exemplos são telas que possuem campos raramente usados ou um número de grupos de campos excessivos que sobrecarregam a memória de curto prazo (STM) dos seus usuários.
  • Linguagem simples. Contra-exemplos são telas que apresentam erros de banco de dados (ORA600 ou java.lang.NullPointerException) para os seus usuários finais.
  • Minimização do uso de memória do usuário. Um contra-exemplo é um sítio de comércio eletrônico no Brasil (que não vou citar aqui por delicadeza) que requer que o usuário avance por 12 telas até que ele chegue no fim da compra.
  • Consistência. Contra-exemplo são sistemas onde existem diversas formas de fazer a mesma coisa ou que apresentam telas completamente diferentes com a mesma função. Bizarro!
  • Feedbacks. Contra-exemplo são sistemas que não fornecem retorno sobre ações do usuário. Bons exemplos são sites que mostram contextualmente  falhas na digitação de campos no local e no momento que acontecem. Bem vindo o AJAX.
  • Atalhos. Contra-exemplos são sistemas que obrigam o usuário a pegar o mouse para cada mínimo movimento necessário na tela.
  • Auxílio e documentação. Contra-exemplo são sistemas que não fornecem ajuda contextual ou ajuda on-line.
  • Prevenção de erros. Sistemas devem guiar o usuário de forma correta e evitar erros. Contra-exemplos são alguns sites bancários onde digitar um CNPJ parece ser um jogo para testar o seu estresse.

A técnica de provas de conceitos arquiteturais pode ser usada para trabalhar o tema usabilidade. Arquitetos modernos, como diz Grady Booch, devem pensar sistemas de forma holística e contribuir na sua plenitude para a construção de sistemas melhores e mais eficientes.

Don’t make me think”, Steve Krug, Don’t Make Me Think: A Common Sense Approach to Web Usability.

Como organizar uma prova de conceito arquitetural

~ Marco Mendes ~ 2 Comentários

O termo prova de conceito (POC) em arquiteturas de software e dados tem se tornado muito popular. Provas de conceito são instrumentos de mitigação de riscos técnicos, criação de arquiteturas executáveis e podem servir a vários propósitos gerenciais em um projeto. Apresentamos abaixo um modelo mental para guiar arquitetos na escolha e organização de uma prova de conceito. O nosso modelo é baseado em seis questões de análise

1. Que requisitos e cenários são candidatos a uma prova de conceito?

Observe a figura abaixo, que mostra os tipos de requisitos típicos de um sistema. Como exemplo, se considerarmos um site de comércio eletrônico veremos que os cenários de negócio ligados à venda de produtos e que fazem comunicações com sistemas de processamento de pagamento diversos são críticos para o negócio e ao mesmo tempo desafiantes tecnicamente em termos do tempo de reposta, disponibilidade, escalabilidade e vazão.

Tipos de Requisitos em projetos de software.
Tipos de Requisitos em projetos de software.

Os requisitos do quadrante 1 são aqueles que devem ser investigados pelo arquiteto e que normalmente derivam provas de conceito.

2. Quantas provas de conceito devo ter?

O número de provas de conceito é proporcional ao grau de risco de um projeto e portanto não é um número pré-determinado. Como regra geral, o número de provas de conceito deve tornar o risco técnico do projeto baixo e administrável ao longo do seu ciclo de vida.

3. O que uma prova de conceito irá explorar?

Provas de conceito normalmente exploram dois aspectos (estruturas ou comportamentos).

Provas de conceito que exploram estruturas normalmente são usadas para compararmos ou selecionarmos tecnologias, determinar viabilidade tecnológica de uma pilha tecnológica ou mesmo a descoberta de uma melhor prática técnica (ex. JEE ECB ou ASP.NET MVC). Provas de conceito que exploram comportamentos normalmente querem explorar algum caso de uso, história do usuário ou cenário de negócio potencialmente complexo em um sistema.

4. O que uma prova de conceito irá produzir?

A figura abaixo fornece tipos comuns de provas de conceito, que podem ir desde uma leitura de um artigo, passando por uma simulação simples de uma solução e até mesmo um protótipo evolutivo. Como regra geral, quanto maior o risco, mais densa tende a ser uma prova de conceito.

Tipos de provas de conceito

O conjunto dos produtos resultantes das provas de conceito de um produto é chamdo de arquitetura executável, composta por modelos, artigos, rascunhos, códigos descartávels ou mesmo códigos evolutivos.

5. Quando devo fazer as provas de conceito?

Use a regra do terço. No primeiro 1/3 de um projeto você deve ter todas as provas de conceito de um projeto finalizadas de forma a acomodar riscos e determinar a arquitetura executável do seu sistema.

6. Como encaixar as provas de conceito no processo de software da minha empresa?

  • Se você usa métodos ágeis, mescle provas de conceito ao longo dos primeiros sprints de um projeto. Se possível, crie o conceito do Sprint 0 dedicada apenas ao tema prova de conceito.
  • Se você usa o processo unificado (IBM RUP, Enterprise Unified Process, Open-UP, Essential UP ou similar), a fase de elaboração foi criada para lidar com provas de conceito.

Extraordinary claims require extraordinary evidence – Carl Sagan

A evolução do BPM, o iBPM

~ Marco Mendes ~ Deixe um comentário

A Target é uma gigante americana que trabalha no mercado varejista e que desenvolveu nos últimos anos um sofisticado sistema de análise preditiva que lhe permite avaliar, com boa precisão, as preferências de compra de cada consumidor individualmente. Este modelo é resumido no esquema abaixo.

Este modelo demonstra o conceito de Intelligent Business Operations e mostra como empresas podem obter vantagem competitiva com o uso de tecnologia da informação.
Modelo de análise preditiva de compras da Target, para permitir o envio de propagandas mais assertivas e melhorar a probabilidade de compras de novos produtos e portanto aumento do seu faturamento financeiro.

Baseado neste modelo, esta empresa conseguiu até mesmo detectar grávidas no segundo trimestre da gravidez, o que lhe promoveu vantagem competitiva e fidelização das novas mamães e papais. Para referência, antes da Target as empresas somente conseguiam detectar automaticamente as novas mães no terceiro trimestre da gravidez. Este caso foi até citado na revista Veja na edição que fala sobre BigData e representa o que Gartner Group chama de IBO (Intelligent Business Operations). O IBO é o processo de melhoria das operações de uma empresa, que se tornam mais inteligentes e responsivas através da integração de BPM, análise preditiva, tecnologias sociais e móveis. As organizações que já entenderam o potencial do IBO estão avançando e ocupando espaços de outras organizações mais lentas e reativas.

Para que uma empresa implemente um IBO, ela precisa possui uma plataforma de automação de TI apropriada. Esta plataforma é o iBPM, ou o intelligent Business Process Management.

Um BPM tradicional, mesmo que muito robusto, pode ser visto como a coleção das seguintes peças:

  • Modelador de processos, com suporte a linguagem como BPMN.
  • Simulador de processos, para análise futura de melhorias de processo.
  • Orquestrador de processos, que é um ambiente de execução que permite que um processo BPM seja executado e enlace serviços de TI.
  • IDE para modelagem e orquestração de processos, que é o ambiente de desenvolvimento do analista de BPM
  • Monitor de processos (BAM), que avalia em tempo real as métricas e indicadores de um processo de negócio.
  • Repositório de processos, que permite manter as versões de processo e governar os ativos de processos de uma organização.

Um iBPM vai muito além. Ele inclui também:

  • Suporte à mídia social para incorporar fontes de dados  externas e perspectivas externas (como especialistas e as vozes dos clientes) e dados de contexto em todo o ciclo de vida de um processo. A mídia social pode melhorar e fornecer mais informações sobre o contexto situacional. A mídia social também apoiará técnicas analíticas adicionais, tais como análise de rede social para apoiar as decisões de um processo. Em termos práticos, um processo de promoções de vendas pode olhar os feedbacks sobre um produto no Twitter e Facebook e tomar decisões baseados nestas questões.
  • Suporte de dispositivo móvel para dar aos contribuintes individuais e supervisores acesso 24/7  para manter a capacidade de respostas em qualquer momento .
  • capacidades analíticas ativas em áreas como monitoramento de atividades de negócios (BAM) e tecnologias CEP (Processamento de eventos complexos) para fornecer análises melhores e mais amplas.
  • painéis de negócios mais elaborados para fornecer melhor visibilidade em tempo real sobre o desempenho do processo.
  • Um conjunto crescente de ferramentas de gestão de decisões, incluindo
    suporte poderoso para a gestão de regras de negócio (BRM e BRMS), tecnologias de otimização e simulação, bem como motores de otimização baseados em restrições que utilizam técnicas matemáticas avançadas para pesar
    trade-offs e gerar a decisão mais eficaz disponível.
  • O acesso a fontes de informação não-estruturados e externas, incluindo vídeo, áudio e streams sociais
  • Integração com ferramentas analíticas on-demand.

Para se implementar um iBPM, é necessário uma boa arquitetura de integração, a escolha e seleção de um bom fornecedor de iBPM e a presença de bons arquitetos para habilitar com sabedoria esta nova e complexa plataforma.

PegaSystems, Appian e IBM largaram na frente e ofertam as soluções mais robustas de iBPM, segundo o quadrante mágico do Gartner Group (Ver quadro abaixo). Mas muitas outras empresas também ofertam soluções interessantes e já habilitam a sua empresa para avançar no caminho das operações inteligentes de negócio.

O quadrante mostra os principais fornecedores da segunda geração de ferramentas BPM do século XXI
O quadrante mostra os principais fornecedores da segunda geração de ferramentas BPM do século XXI, o iBPM.

Texto originalmente postado em: http://www.betapyx.com/blog/2014/01/08/a-evolucao-do-bpm-o-ibpm/.

Tendências de Arquitetura de Software para 2014

~ Marco Mendes ~ Deixe um comentário

2014 é o primeiro ano onde o número de dispositivos mobile irá ultrapassar o número de dispositivos tradicionais (desktops), em análise recente realizada pelo Gartner Group. Esta mudança tem sido impulsionada por fatores econômicos como a redução dos preços de celulares e tables e também por aspectos culturais como o Bring Your Own Device (BYOD), Bring Your Own Appliance (BYOA) e a Internet das Coisas.

Para quem trabalha com arquitetura, estas e outras novidades trazem novos desafios para os arquitetos. Destaco alguns destes desafios em 5 tendências de arquitetura de software.

  1. Arquiteturas Móveis Corporativas

Muitos técnicos, ao pensar em aplicações móveis, pensam que o problema está apenas localizado no lado cliente, nas aplicações que rodam Android e iOS. Em verdade, a maioria das aplicações móveis faz comunicações com servidores e portanto é crítico e complexo a correta montagem arquitetural da camada servidora para lidar com aspectos como a gerência de estado offline da aplicação, sincronização de dados cliente e dados do servidor, picos de escalabilidade e renderização em múltiplos dispositivos. Este tipo de arquétipo tem sido chamado de MADM (Mobile Application Development Platform) e é um tema cada vez mais presente na realidade das grandes empresas.

2. HTML5 como linguagem multi-dispositivo

O HTML 5 ganha força e tende a se tornar uma linguagem padrão para a renderização Web e também para a renderização iOS,  Android e Windows Phone. Esta tendência, hoje implementada por diversos frameworks Web/Mobile de mercado, tem suas motivações no alto custo da geração de aplicações nativas em diversos dispositivos e uma ausência de dominância clara do mercado de dispositivos móveis por um único fornecedor.

3. A chegada dos “Arquitetos das Nuvens“

A virtualização já e um fato estabelecido na indústria de TI Brasileira e a tendência da computação nas nuvens ganha força a cada dia. Compreender, escolher e arquitetar os diversos tipos de plataformas de nuvens tem se tornado um desafio formidável. Exemplos incluem o IAAS, PAAS, SAAS, DAAS, NAAS, XAAS, nuvens públicas, nuvens privadas, nuvens híbridas, nuvens pessoais, entre outros sabores de nuvens.

A necessidade de profissionais que consigam pensar apropriadamente o uso da computação nas nuvens é cada vez mais requisitado nas empresas de médio e grande porte do Brasil.

4. Arquiteturas Sensíveis ao Contexto

A Internet das Coisas liga pessoas, coisas, informações e lugares em um modelo único de valor aos seres humanos. Um exemplo futurístico pode ser visto no filme Minority Report (no ano 2053). Exemplos Reais do seu dia a dia em 2014 podem ser visto no uso do Waze para vencer o trânsito caótico das cidades, nas plataformas inteligentes da Akamai para otimizar o tráfego de dados sobre os principais backbones da Internet ou mesmo nos Smart Grids em modernas redes de distribuição de energia elétrica.

As arquiteturas sensíveis ao contexto, que podem ser observadas nos níveis mais avançados do modelo OSIMM (Open Group Service Integration Maturity Model), são arquiteturas que ligam hardware, dados e tecnologias através de conceitos avançados como iBPMS, SOA 2.0, BRMS, CEP e Analytics.

5. A proliferação de tecnologias para construir aplicações corporativas

De 1997 a 2010, o mercado de TI esteve relativamente fixado nas linguagens Java e C#, com alguns grupos de TI trabalhando em linguagens dinâmicas como PHP, Ruby e similares.

Nesta década, temos visto uma proliferação de tecnologias, como por exemplo Ruby on Rails, Sinatra, Node.JS, F#, Scala, Objective C, Erlang, Java para Android, entre outras. É uma nova era da diversidade tecnológica, onde os desenvolvedores ganham liberdade para escolher as tecnologias mais apropriadas à realidade da sua empresa.