noSQL and SQL databases: Not an exclusive decision


When trying to find real-world noSQL modeling cases to get some inspiration I ran into the NoSQL Data Modeling Techniques from Highly Scalable Blog. After reading the post and its comments I remembered the discussions around one Semantic Web class I attended last year at NCE-UFRJ. During that class we discussed the future of Triple Stores and that maybe OLTP systems would never leave the relational model and start using Triple Stores. Maybe representing data as RDF would be just another way of representing data the way OLAP systems do.

Almost everytime people talk about noSQL database they end up comparing it to SQL database and the relational model. My opinion at the moment is that it’s not an exclusive (XOR) decision. Since everybody say noSQL databases are better in high traffic/load evironments and SQL databases are better in OLTP env (where data change very frequently), we should take advantage of both at the same time. I mean, let’s have a noSQL database be another form of  data representation that is also in relational databases.

I will try to find how Facebook, Foursquare, Twitter etc use noSQL and SQL/Relational databases. If you see any article, presentation or post that talks about how the use such databases types, or if you have used both together please, share it here by posting a comment. It would be better if it shows an end-to-end architecture using both and not just a peace of it, ok?!

Keep in touch!

Governança SOA e Kanban


Não é novidade para ninguém que ao seguir uma estratégia de construção de uma Arquitetura Orientada à Serviços em qualquer empresa é necessário endereçar o tema governança soa. Isto acontece devido ao seguinte fato: Não existe mágica!

Toda empresa tem como objetivo aumentar sua margem de lucro e uma das formas de alcançar este objetivo é maximizando o retorno em cima dos investimentos feitos ao comprar ou construir um ativo. E SOA justamente vem para nos ajudar nesta tarefa, com a orientação a serviço começamos a construir diversos serviços atomicos, granulares que ficam disponíveis em um repositório corporativo e que podem atender diversos propósitos diferentes de negócio, por meio da composição do mesmos e outros ativos da empresa. E é neste ponto que as pessoas se iludem e esperam por um truque de mágica, o que acontece é que cada vez mais são feitas ligações entre serviços, dados, aplicações e outros ativos, o que pode sugerir complexidade. Mas isso é bom, pois estamos maximizando o retorno em cima do investimento feito, lembram?

Bom, mas para não criarmos complexidade em demasia, causar confusões e aumentar o custo com operação, precisamos manter este repositório de ativos bem organizado, disponível para toda empresa, e uma parte crucial, que é o foco deste post, os ativos devem estar aderentes aos processos e requisitos de negócio, diretrizes técnicas, de qualidade, segurança, devem ter documentações relativas a implantação, manutenção e uso. E para atender a todos estes pontos é necessário um processo bem definido, com artefatos obrigatórios, papéis, e etapas que endereçem todos os pontos mencionados anteriormente.

O caminho comum de toda a empresa é procurar um software que suporte este processo. Mas existe uma solução alternativa, que está muito aderente ao cenário atual em que várias empresas se encontram, que é o de ter um pensamento Lean e fazer uso de metodos agéis. Esta alternativa é bem mais barata e que dependendo da disciplina do time pode ser bem mais eficaz que um software. Estou falando do Kanban. Para quem não conhece, Kanban segundo Wikipedia

E seguindo na mesma linha em que os sábios do google pregam a muito tempo de experimentar, errar rápido, e baseado nos dados concretos oriundos da experiência evoluir a solução e acertar, criamos em minha empresa uma primeira versão de um quadro Kanban. Ele contempla todo o ciclo de vida de um serviço, desde a análise de uma demanda/projeto e identificação de um serviço até o seu deploy. Cada fase do ciclo de vida vira uma etapa do processo, e consequentemente uma coluna no quadro. Adicionamos também etapas/colunas que são passos de aprovação, QA e acompanhamento pós deploy. Uma ação que está agregando valor,  foi definição de “critérios de pronto” para cada etapa, ou seja, um serviço só sai da fase de modelagem e vai para fase de construção se alguns artefatos forem entregues como por exemplo os cenários de teste e o contrato do serviço.

Um benefício interessante de utilizar o quadro é que temos um “modelo mental coletivo e colaborativo” que fica mais fácil de todos do time seguirem, guardarem e contruibuirem para a evolução do mesmo.Ele ainda  nos ajuda a focar no que é necessário e agrega mais valor para o negócio (Lean) e ainda no momento que é necessário, seguindo a filosofia do just in time.

Se tiverem experiências parecidas com Governança SOA e Kanban ou outras filosofias e metódos ageis, por favor compartilhem!

Http Request
Get /taas/autor/carlosfilho HTTP/1.1
Http Response
HTTP/1.1 410 Gone