Arquitetura de Dados

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

Plataformas Arquiteturais

~ Marco Mendes ~ Deixe um comentário

Phillipe Kruchten disse uma vez que a vida do arquiteto é uma longa sucessão de decisões sub-ótimas e parcialmente tomadas no escuro. Nada mais verdadeiro, em minha opinião.

Mas qual seria a decisão mais importante que um arquiteto deve tomar. A decisão sobre o estilo da arquitetura é sem dúvida uma destas decisões. Alguns estilos arquiteturais incluem:

  • Cliente-Servidor
  • P2P
  • Multicamadas (n-tier)
  • Centrado em serviços de negócio (SOA)
  • Centrado em processos de negócio (BPMS)
  • Centrado em computação paralela massiva (Grid)

No que tange à tecnologia, entretanto, o conceito da plataforma é sem dúvida a decisão mais importante. A plataforma é o elemento técnico que dá vida ao estilo arquitetural. Uma plataforma é um arranjo de softwares e servidores organizados de forma coerente para resolver problemas comuns no desenvolvimento de software. Dois exemplos comuns de plataformas incluem o Java EE e o Microsoft .NET. Um outro exemplo de um plataforma é o LAMP, que é um arranjo composto de sistema operacional baseado em Linux, servidor Web Apache httpD, servidor de banco de dados MySql e linguagens dinâmicas como PHP, Perl ou Python.

O Java EE,  .NET ou LAMP são usados normalmente para sistemas de informação Web. Naturalmente existem cenários da realidade de mercado onde necessidades mais específicas surgem. Para estes cenários existem outros tipos de plataformas de mercado, muito além do Java EE e o .NET.

Exemplos incluem:

  • Plataformas de ERP/MRP (Enterprise Resource Planning/Material Resource Planning), usadas para automatizar processos de suporte de organizações. Exemplos de produtos nesta linha são o SAP ECC, o Oracle PeopleSoft e Oracle JD Edwards.
  • Plataformas de portais usadas para a criação de sites que unifiquem informações de diversas fontes. Exemplos incluem o Microsoft SharePoint, o Oracle Portal ou o IBM WebSphere Portal.
  • Plataformas de serviços interoperáveis para estilos centrados em serviços SOA. Exemplos incluem o Microsoft WCF ou o Apache Tuscany (padrão SCA).
  • Plataformas de automação de processos de negócio (BPMS) para empresas que estejam e estágios avançados de implementações BPM. Exemplos incluem o IBM Business Process Manager ou o Oracle BPM.
  • Plataformas de serviços de decisão (BRMS) para empresas que busquem flexibilidade e responsividade extrema para as suas regras de negócio. Exemplos incluem o IBM ILOG Operational Decision Management ou o Redhat JBOSS Drools.
  • Plataformas de BI/ETL para o suporte a inteligência de negócios avançada. Exemplos incluem a suíte de produtos IBM Cognos, Microsoft SISS ou Oracle Hyperion.
  • Plataformas de integração de aplicações chamadas de ESB (Enterprise Service Bus). Exemplos incluem o SAP PI, IBM WebSphere ESB e o Microsft BizTalk.

Se escolhemos uma plataforma arquitetural inadequada teremos graves problemas durante o projeto. Curiosamente, muitos “arquitetos” consideram a plataforma como dada e nem sequer pensam nisso. É a síndrome do arquiteto de uma plataforma só, que coloca a tecnologia na frente do problema.

Arquitetos de soluções racionais agem na direção inversa. Eles tem a mente aberta e fazem uma análise dos condutores arquiteturais. A partir destes condutores eles recomendam a plataforma mais apropriada que irá promover o melhor balanceamento dos condutores.

Em cenários mais sofisticados, uma solução pode exigir um conjunto de plataformas distintas. Em um caso SOA que estamos trabalhando atualmente, uma determinada empresa organizou a sua infraestrutura a partir de um conjunto de soluções integradas de BPMS, SOA e ESB.

Grandes fornecedores de mercado como a IBM, Oracle, TIBCO, SAP, Redhat, entre outros gigantes, possuem esquemas conceituais que nos permitem navegar neste mar de tecnologias. Deixo para os curiosos e aficionados pelo tema duas referências respectivamente da IBM e da Redhat.

Arquitetura Referência IBM

Arquitetura de Referência da IBM

Arquitetura Redhat JBOSS Enterprise Middleware

Arquitetura de Referência RedHat JBOSS

O princípio de Occam aplicado na escolha de soluções técnicas

~ Marco Mendes ~ Deixe um comentário

Consideremos um problema de integração ad-hoc entre duas empresas sobre um canal seguro. A empresa B precisa disponibilizar informações sobre estoques de seus produtos criados em uma aplicação ASP.NET MVC. A empresa A precisa consumir estas informações sincronamente (RPC) em uma aplicação Java EE. Os desenvolvedores nas empresas A e B conhecem suas tecnologias de desenvolvimento e o protocolo HTTP.

Um arquiteto de integração é exposto a três soluções possíveis de RPC:

1. Criar uma API sobre SOAP/HTTPS, expor os serviços da empresa em WSDL e criar objetos de dados complexos em XSD.

2.Expor a API  sobre protocolo HTTPS através dos métodos GET/POST em um mecanismo REST.

3. Criar uma comunicação CORBA sobre GIOP/IIOP a partir do uso de COM+ ou WCF em .NET e consumir o objeto remoto através de um EJB (RMI/IIOP).

A lei da parcimônia nos diz para escolher a solução 2 neste contexto, dada que é a mais simples e irá resolver o problema sem a adição de mais complexidade à solução.

Se houver algum outra variável no problema, a solução é reavaliada naturalmente. Assumi no exemplo que nenhum outra questão se faz presente para tornar a explicação mais didática.A lei da parcimônia é antiga e foi formulada por Willian of Ockham ainda no século 14. Ele descreveu o princípio que é conhecido como lâmina de Occam, que diz  que a explicação para qualquer problema deve assumir apenas as premissas estritamente necessárias à explicação do fenômeno e eliminar todas as que não causariam qualquer diferença aparente nas predições da hipótese ou teoria. Em outras palavras, este princípio recomenda assim que se escolha a teoria explicativa que implique o menor número de premissas assumidas e o menor número de entidades na solução. Na arquitetura e desenho de software, este princípio nos diz que a solução mais simples para resolver um problema deve ser escolhida, quando temos diversas soluções para resolver uma determinada questão.

São contra-exemplos deste princípio:

  • As famigeradas arquiteturas lasanhas do J2EE 1.3 e 1.4 com quase 10 camadas entre a tela  o banco de dados.
  • Objetos de transferência TO/VO iguais aos objetos de domínio (POJO/POCO).
  • Bancos de dados normalizados além da necessidade do problema.
  • Padrões de desenho artificiais.
  • Métodos/Funções com centenas de linhas de código.

Um bom exemplo da simplicidade aplicada é o método EssUP de Ivar Jacobson. Uma lâmina no contexto da essência arquitetural de um projeto é apresentada aqui para os interessados.

“We are to admit no more causes of natural things than such as are both true and sufficient to explain their appearances. Therefore, to the same natural effects we must, so far as possible, assign the same causes.”, Isaac Newton