Friday, July 21, 2006

GASP - Primeiro aniversário!

O GASP – Grupo de Arquitectura de Software Português, foi criado há um ano, em Julho de 2005 em Lisboa e finais de 2005 no Porto, com o objectivo de permitir a troca de ideias em volta de temas relacionados com a arquitectura de software.


Desde o início apoiado pela Microsoft Portugal, apesar de technology agnostic, reúne um conjunto de profissionais de diversas áreas e com variadas experiências e focos profissionais.  O grupo tem reuniões mensais à volta de uma “távola redonda”, nas duas cidades, sendo a interactividade um factor essencial. Já foram apresentado e discutidos temas como Software Factories, Domain Specific Languages, Metodologias/Práticas Ágeis (Scrum e TDD), Geração de Código, Padrões de Desenho, Workflow, Software as a Service, Service Oriented Architectures, Frameworks,  sistemas de manufactura de circuitos, modelos de evolução de produtos, entre outros. Recentemente experimentou-se com o formato “Design Lab”, uma workshop prática com o objectivo de resolver um problema de arquitectura proposto, com resultados muito interessantes.


Passado um ano, o grupo tem um site (www.arquitecturadesoftware.org) com blogs e fóruns de discussão, e já teve a participação de convidados como Beat Schwegler (Microsoft EMEA), Peter Himschoot (U2U) e Paul Preiss (Presidente da IASA, de que o GASP é o chapter português, um dos mais activos dos 60 à volta do mundo), este último animando uma viva discussão sobre o papel da Arquitectura de Software e de uma organização como a IASA na criação da profissão do Arquitecto de Software.


Um dos desafios do modelo actual – e que se tem discutido aturadamente - é a restrição logística à participação de mais pessoas, pelo que se têm procurado encontrar formas alternativas de permitir uma participação e interacção mais alargada. Esta pode vir a passar tanto por web casts, tendo uma “emissão experimental” sido testada com sucesso no início desta semana, como por eventos em espaços maiores e com mais pessoas, dos quais queremos organizar o primeiro ainda este ano.


Até lá, queria convidar-vos a trocar ideias nos fóruns do site, a dar ideias  tanto sobre outras formas de reunir mais gente interessada em torno do tema, como de permitir uma participação mais alargada, ou de assuntos que possam ser interessantes discutir.





A terminar com algumas notas pessoais (backstage stuff): a ideia do grupo apareceu depois de ter assistido com o Tiago Pascoal à apresentação do Juval Lowy ao Dutch .Net User Group, na véspera do arranque do TechEd 2005 em Amsterdão. Neste conheci o Hugo “SOA” Batista, e os 3 propusemos a ideia à Microsoft, que juntou outras “like minds” e a ideia teve asas.


À partida, como disse acima, o objectivo sempre foi muito simplesmente o de trocar e discutir ideias, deixando um pouco de lado questões específicas de tecnologia, e este aspecto tem sido absolutamente chave.  Outros dois aspectos muito valiosos têm sido o conhecimento do mercado, e muito especialmente os contactos com pessoas que andam por aí a fazer coisas muito interessantes, e a quem sei poder telefonar se quiser discutir algum assunto (e alguns nomes que posso referir são o do Filipe Clérigo da Viatecla, ou os professores Paulo Sousa do ISEP e Luis Falcão do ISEL, entre outros). Curiosamente, apesar de todos estarmos em empresas concorrentes, este não tem sido um factor limitativo. Quanto ao apoio logístico-organizativo, o Nuno Costa e o José António Silva da Microsoft têm sido inexcedíveis.


That’s it for now! Outro post destes daqui a um ano, no segundo aniversário, esperamos poder contribuir ainda mais para a comunidade nestes próximos 12 meses do que nos 12 que passaram. :-)

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Saturday, July 15, 2006

Arquitectura Ágil

A primeira vez que li sobre formas ágeis de fazer desenho/concepção de sistemas foi numa entrevista ao Martin Fowler (parte 1, 2, 3 e 4), em que ele diz o seguinte:


«I distinguish between planned and evolutionary design. Planned design says that when you think about a piece of software, you create the design first, then you code it. A planned design could take the form of UML diagrams. Or you could express it in terms of dividing a system into subsystems and defining the interfaces between those subsystems. With planned design, there's a definite switch between the two modes of creating the design and then coding it. And those tasks may often be performed by different people. Architects come up with design. The developer then code it. The design is not necessarily considered completely fixed, but it is considered mostly fixed. You can argue that the better the design, the less it will change as you code it.


With evolutionary design, you expect the design to evolve slowly over the course of the programming exercise. There's no design at the beginning. You begin by coding a small amount of functionality, adding more functionality, and letting the design shift and shape.


[...]


I think there's still room for some upfront design, but not a lot. People like Kent Beck and Ron Jeffries say it is eliminated. In a way they are right; you could build even a complex system purely through evolutionary design. But there are cases where you'll go faster with some upfront design. So I would disagree with the idea that you don't put your database in before you evolve your need for a database. I would make an initial decision about the presence of a database and go from there, but I would still evolve most of the design.»


Esta posição, já de 2002, exprime uma separação que parece haver entre metodologias ágeis e a arquitectura de software, se entendida como algo que se faz antes de se desenvolver um sistema. Pessoalmente, parece-me uma visão algo ortodoxa, e simultaneamente muito optimista. Não tenho nada contra a evolução e iteração, pelo contrário, mas considero essencial haver uma linha condutora.


No Channel 9 há duas entrevistas que também abordam este assunto. A primeira é com Colin Bird, CTO da Conchango, e outra com Roy Osherove, autor do blog ISerializable.com. Ambos dizem essencialmente o mesmo, que é sempre necessário ter uma arquitectura, e que esta vai também evoluir.


Diz o Colin: «The challenge of Agile Architecture is how deep you go, how soon. [...] You can't have no idea where you are going, you need a direction, a vision, and the vision of the architecture will evolve. [...] What you get with agile is an evolving architecture, a process of refactoring not just at the code level, but a rewrite of the architecture as you understand the problem space better, as the business changes.»


E diz o Roy: «Agile doesn't say "don't do design for the future", but do enough design so that when changes happen, you are able to handle them. [...] Architecture is a good thing. But doing one year of architecture before development is not good. [...] Design upfront is not bad, you just have to know when to stop. A good skeleton is enough.»


As opinião são semelhantes, e bem menos "ortodoxas" que a do Martin Fowler. Aquilo que me parece que fica a faltar, no entanto, é como introduzir esse elemento de concepção em metodologias ágeis tipo Scrum. Outras pessoas da Conchango estiveram no Architecture Insight 2006 da Microsoft no País de Gales, e fizeram uma apresentação sobre este tema. Infelizmente, não me parece que esta tenha informação suficiente a detalhar como é que a tal visão e arquitectura são construídas, sendo antes muito vaga. Há um arquitecto na equipa de cada Sprint do Scrum? Fica claro que tem de haver uma arquitecura, que esta tem de ser "minimalista", capaz de evoluir, e apenas a necessária e suficiente, mas não como é que isto se enquadra no espírito das metodologias ágeis.


Uma questão que se me coloca relativamente ao ponto específico da capacidade de evoluir, é se isso não passa apenas por recorrer a princípios/padrões como Loose Coupling ou Dependency Injection, que já são regra geral considerados boas práticas, seja a metodologia ágil ou não.


Quanto à granularidade a que se deve ir no desenho, infelizmente não há respostas. O Colin diz «It depends.», para mais à frente referir que esta pode incluir Diagramas de Classes, artefactos que tipicamente seriam produzidos já em sprints.


Não me parece que haja respostas claras nesta questão, mas certamente que voltarei ao assunto. Afinal, "IT have been the bad guys for a while, it's time to change that.", e estas metodologias podem claramente ajudar.


[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Arquitectura

Em qualquer discussão de Arquitectura de Software ou de tópicos como gestão de projecto são frequentes as analogias com Arquitectura no seu sentido "tradicional", quer reforçadas quer negadas. Não pretendo tentar definir Arquitectura de Software (isso pode ficar para outro post), mas é interessante ver como é que se define arquitectura "tradicional":


Segundo a wikipedia em português, "A arquitectura é a arte ou técnica de projetar e edificar o ambiente habitado pelo ser humano. Quando se fala em arquitectura fala-se, entre muitas outras coisas, da organização do espaço. A arquitetura como atividade humana existe desde que o homem passou a se abrigar das intempéries. Uma definição mais precisa da área envolve todo o design do ambiente construído pelo homem, o que engloba desde o desenho de mobiliário (desenho industrial) até o desenho da paisagem (paisagismo) e da cidade (urbanismo), passando pelo desenho de construções (considerada a atividade mais comum dos arquitetos), como prédios, casas, igrejas, etc. O trabalho do arquiteto envolve, portanto, toda a escala da vida do homem, desde a manual até a urbana."


Para a wikipedia em inglês, "Architecture is the art and science of designing buildings and structures.


A wider definition would include within its scope the design of the total built environment, from the macrolevel of town planning, urban design, and landscape architecture to the microlevel of creating furniture. Architectural design usually must address both feasibility and cost for the builder, as well as function and aesthetics for the user.


In modern usage, architecture is the art and discipline of creating an actual, or inferring an implied or apparent plan of any complex object or system. The term can be used to connote the implied architecture of abstract things such as music or mathematics, the apparent architecture of natural things, such as geological formations or the structure of biological cells, or explicitly planned architectures of human-made things such as software, computers, enterprises, and databases, in addition to buildings. In every usage, an architecture may be seen as a subjective mapping from a human perspective (that of the user in the case of abstract or physical artifacts) to the elements or components of some kind of structure or system, which preserves the relationships among the elements or components."


Mesmo que a realidade seja diferente, e parecendo-me óbvio que a Arquitectura e a Arquitectura de Software têm graus de maturidade completamente diferentes, há alguns paralelos muitos óbvios entre as duas disciplinas (artes?). Os diferentes âmbitos, a escala, as preocupações/requisitos, entre outros. A matéria-prima, no entanto, é muito diferente.


Numa das próximas reuniões do GASP planeamos trocar ideias com alguns destes Arquitectos (hesito em chamar-lhes "tradicionais"...), para perceber afinal de contas até que ponto é vão as semelhanças.


Na página em português da wikipedia está uma citação de Goethe muito interessante: "A arquitectura é musica petrificada." Poderemos dizer o mesmo do que fazemos?


[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Tuesday, July 11, 2006

BizTalk Mapper: Reverse Map's Links Direction

In data sincronization or entity integration scenarios developed using BizTalk Server, there are frequently situations where bi-directional maps have to be developed between two schemas: from A to B and from B to A. If these schemas are large and the maps complex, it can be quite tiresome to develop the two "symetric" maps, specially because of some usability limitations of the BizTalk Mapper in BizTalk Server 2004 (like the inability to copy&paste functoids and the time-consuming way parameters are set).


To help alleviate this problem, I developed a very simple tool that creates a reverse map from an existing one. All it does is replace the source and target schemas, and reverse the direction of all the links. I use it to produce B->A after I created A->B in the Mapper. You still have to manually check the result map and all the functoids, but at least most direct links should be correct.


The command-line tool was developed using VS2003/C#, and tested with BizTalk 2004 maps. I am not sure if the btm file format changed in BizTalk 2006, but even if it did, it should be very easy to adapt the tool to accomodate changes.


You can download the solution here. Hope it's helpful.


[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Tuesday, July 4, 2006

BizTalk 2004/2006: Cross References

Um dos cenários em que o BizTalk é usado com frequência é para fazer sincronização de entidades entre diferentes sistemas. Neste tipo de aplicações, sucede existirem nesses sistemas identificadores diferentes para o mesmo "conceito". Por exemplo, num sistema um Cliente pode ser representado pelo BI, e noutro pelo Número de Contribuinte. Outro exemplo de situação é a utilização de valores do tipo "enumerado" com bases diferentes: por exemplo, num determinado sistema o sexo masculino é 0 e feminino 1, e noutro M e F. Outros exemplos semelhantes são listas de países, estados civis, etc. Um terceiro cenário, frequente não apenas em BizTalk, consiste na realização de mapeamentos, ou traduções, entre códigos de erro e mensagens legíveis por um operador humano.


Existem várias formas de resolver esta questão ao nível do BizTalk, que tipicamente passam por fazer um mapeamento entre os diferentes domínios de entidades ou informação. Estes mapeamentos podem ser estáticos ou dinâmicos. No primeiro caso, a opção é fazer algum tipo de IF/Switch, seja em código seja num BizTalk Map. No segundo caso há várias opções, todas elas tendo por base algum repositório dinâmico, por exemplo: a BD do Single Sign-On (o que garante segurança), o motor de regras do BizTalk (aqui com a vantagem de já termos um interface gráfico tipo "Backoffice", e com versionamento incorporado), ou pura e simplesmente uma Base da Dados específica, a que acedemos com uma API própria, ou usando um Database Functoid, caso estejamos a fazer a transformação num BizTalk Map.


O BizTalk inclui uma "pequena pérola" pouco conhecida, mas que permite resolver precisamente esta classe de problemas, chamada Cross Referencing.


Usando Cross Referencing, podemos armazenar mapeamentos como os referidos em tabelas criadas especificamente para o efeito na BizTalkMgmtDb (a BD de configurações do BizTalk), usando uma ferramenta de comando de linha chamada Cross Reference Import tool (btsxrefimport.exe). Esta ferramenta lê um conjunto de mapeamentos pré-definidos num conjunto de 9 ficheiros XML, inserindo-os na BizTalkMgmtDb, em tabelas com prefixo "xref_".
Para lhes aceder, há depois duas formas: ou por utilização dos métodos da classe Microsoft.BizTalk.CrossReferencing.CrossReferencing ou usando alguns dos functoids da categoria Database, como o Get Common Value, Get Common ID, Get Application Value, Get Application ID ou Format Message.


Não vou descrever em detalhe cada um destes, mas queria dedicar algum tempo a explicar os vários ficheiros XML necessários ao aprovisionamento das tabelas no BizTalk, uma vez que os seus significados - tal como documentados - não são intituitivos à primeira vista.


O btsxrefimport.exe recebe como parâmetro o nome de um único ficheiro XML. Este ficheiro de "Setup" contém apenas o nome de 8 outros ficheiros, que descrevo de seguida.


Definição de aplicações e instâncias


- listOfAppType: Xml com uma enumeração das aplicações que intervêm nos mapeamentos. Valor típicos seriam, por exemplo: SAP, MSCRM, SIEBEL, etc. Costumo chamar este ficheiro de "ApplicationTypes.xml".
- listOfAppInstance: Para cada uma das aplicações do ficheiro anterior, podem definir-se várias instâncias, por exemplo para considerar ambientes de desenvolvimento/qualidade/produção. Caso este conceito não seja aplicável, podem simplesmente declarar-se instâncias com o mesmo nome da aplicação. Costumo chamar este ficheiro de "ApplicationInstances.xml".


Definição de mapeamentos entre identificadores entidades (ID's)


- listOfIDXRef: ficheiro que define os objectos que se vão cruzar, como sejam: Cliente, Conta, Utilizador, etc. Costumo chamar este ficheiro de "Entities.xml".
- listOfIDXRefData: ficheiro com os mapeamentos de identificadores nas várias instâncias de aplicações, e um valor comum, interno. Assim, por exemplo, podemos indicar que no SAP de Qualidade, o cliente com ID 100 vai mapear para um ID interno de 12345, e que no Oracle é o cliente com ID 98765 que mapeia para esse ID interno 12345.
Este "ID Interno", ou "Common ID", é boa prática que seja o valor num dos sistemas designado como "dono" da entidade, por forma a que o BizTalk não tenha de gerir esse conjunto de identificadores. Costumo chamar este ficheiro de "EntityMappings.xml".


Definição de mapeamentos entre valores de enumerados


- listOfValueXRef: ficheiro que define os nomes de valores "enumerados" que estão a ser mapeados. Exemplos são País, Sexo, etc. Costumo chamar este ficheiro de "Domains.xml".
- listOfValueXRefData: ficheiro que define mapeamentos, para cada instância de aplicação, entre um valor enumerado e um "valor interno". Costumo chamar este ficheiro de "DomainMappings.xml".


Estes dois últimos ficheiros (enumerados) e os dois anteriores (identificadores de entidades) são, como de pode perceber, muito semelhantes. O critério de selecção é o seguinte: os primeiros devem ser usados em situações em que exista dinamismo nas entidades manipuladas, e os segundos quando os elementos sejam fixos, como nos enumerados. Por exemplo, o primeiro para Contas Bancárias ou Utilizadores, o segundo para Sexo ou Estado Civil. Um dos factos a considerar é que é possível adicionar novos mapeamentos dinamicamente no primeiro caso, o que não sucede no segundo.
Isto pode ser feito usando o Functoid "Set Common ID" (que cria um mapeamento entre dois valores, para uma instância de uma aplicação), ou o método SetCommonId da classe CrossReferencing. De notar que este método cria um "common id", se este não for especificado como input.


Definição de mapeamentos simples de tradução de texto, para uma língua


- listOfMessageDef: ficheiro que define códigos de mensagem textual, com uma descrição e eventual referência a uma entidade. Podemos usar este ficheiro para conter uma lista dos códigos de erro dos nossos desenvolvimentos, ex: INVALID_CODE, INVALID_DATE_OF_BIRTH, NAME_TOO_SHORT, etc. Costumo chamar este ficheiro de "MessageCodes.xml".
- listOfMessageText: Por analogia com o mapeamento de valores de enumerados, este ficheiro contém o mapeamento dos códigos anteriores para mensagens numa determinada língua (pt-pt, en-gb, etc.). Costumo chamar este ficheiro de "MessageTranslations.xml" (por vezes com a língua como sufixo).


O acesso às traduções acima pode ser feito usando o functoid "Format Message", ou o método CrossReferencing.FormatMessage() .


A concluir


Uma rápida consulta às tabelas criadas na BizTalkMgmtDb permite compreender rapidamente como funcionam, mas coloca-se imediatamente a questão: existe alguma ferramenta para fazer a sua gestão? A resposta, infelizmente, é não. Não seria complexa de desenvolver, pelo contrário, mas não existe. Um exemplo disponibilizado pelo Scott Woodgate inclui um simples script SQL para limpar as tabelas que pode ser útil, mas também se pode recorrer a um DTS, por exemplo


Além dos links que fui incluindo, estes dois posts podem ser interessanes: Ben Cops e BizTalkLATAM (em espanhol).


Obrigado ao meu colega Tiago Oliveira por apontar esta potencialidade do BizTalk Server! :-)


[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]

Monday, July 3, 2006

BizTalk Server Most Valuable Professional (MVP)!

Desde dia 1 de Julho sou oficialmente MVP de BizTalk Server. Obrigado ao Nuno Costa da Microsoft pela nomeação, espero continuar a contribuir com qualidade para a comunidade BizTalk em Portugal e a merecer o reconhecimento. :-):-)


PS: e obrigado ao Zé Tó pelo encorajamento! :-)

[Cross-Posted de http://www.arquitecturadesoftware.org/blogs/joaomartins]