De 23 a 26 de Abril/2018, em Leiden na Holanda ocorreu pela segunda vez a iSAPS, um workshop prático de 4 dias com aulas sobre arquitetura de software e solução ministradas por líderes globais neste campo de estudo.
Formar arquitetos de software e solução não são tarefas triviais e para alcançar este cargo, muitos anos de experiência e projetos reais são necessários.
A proposição do workshop é unir arquitetos experientes com alunos em formação nesta área para que esses alunos percebam de forma real o processo de tomada de decisão e os enfrentamentos que ocorrem na vida real de um arquiteto.
Sete casos de uso, de sistemas reais foram disponibilizados e cada caso de uso contou com a presença de um arquiteto experiente para auxiliar no entendimento do contexto do problema e ajudar cada grupo a propor soluções ou alternativas para resolver os problemas.
|
Cases |
Descrição |
|
O legado é divertido |
Durante alguns anos,você esteve trabalhando com sucesso dentro da Canon. Você provou dominar problemas técnicos complexos e também demonstrou capacidade de liderança em um negócio multicultural. Sua carreira decolou e você se tornou líder de equipes de arquitetura. Seu objetivo principal é definir e evoluir as arquiteturas do sistema de impressão. Neste caso, algumas vezes você enfrentará problemas de tecnologia; e algumas vezes você terá que lidar com os objetivos de negócios. Neste cenário, a empresa vai fechar uma unidade autônoma que é responsável por uma linha completa de impressoras. Estas, chamadas de impressoras planas, têm grande potencial de mercado, mas estão enfrentando quedas de preço devido por exemplo, a competição no extremo oriente. A instalação está localizada na América do Norte e inclui P/D, produção, vendas e serviços. Você será o responsável por implementar a transferência de conhecimento para a Holanda e tomar as decisões corretas para os desenvolvimentos futuros do produto. Note que a nova fábrica não estará localizada perto da instalação de pesquisa e desenvolvimento nos Países Baixos. Como sua experiência está na área de arquitetura de software, você tem sorte: você pode abrir sua caixa de ferramentas e modelar a complexidade do sistema em produtos e processos. Isso ajudará a equipe de arquitetura e projeto a definir a melhor estratégia para o futuro. Mas como você vai fazer isso? |
|
Sistema para cobrança em espécie para a EnsureMe |
A empresa EnsureMe possui um cenário de TI que performa relativamente bem. No entanto, devido à idade do atual sistema de cobrança em espécie, é difícil encontrar pessoal qualificado para manter e desenvolver o sistema. O sistema foi construído utilizando Oracle forms, o que é considerado impróprio para a empresa quando se pensa em futuro. Isso se deve, em parte, à dificuldade de recrutamento mencionada anteriormente, mas também à capacidade de adaptação para arquiteturas solução em TI modernas, como por exemplo SOA e microsserviços. Para garantir uma adequada operação futura e o recebimento eficiente de dinheiro em espécie, um novo (conjunto de) sistema(s) deverá ser desenvolvido. Modernizando o sistema, a empresa vê uma oportunidade para criar um sistema mais genérico que possa ser oferecido como um serviço interno e externo para o recebimento de dinheiro em espécie. O foco principal para o time é de propor uma solução para substituir o sistema de coleta de dinheiro em espécie existente. |
|
Architecting a Vessel Traffic Planning Application |
Este caso de uso visa estender ou refatorar uma aplicação que tem o objetivo de regular o tráfego de embarcações em rios e portos garantindo um fluxo de tráfego seguro e tranquilo. O time deverá propor soluções para estender o antigo sistema existente com novas funcionalidades, permitir a captura e que seja capaz de coletar informações em fontes de dados externas, ter capacidade para alto desempenho, e além disso, os cálculos devem ser concluídos em um tempo muito limitado e estritamente predefinido, deverá prover estabilidade e alta disponibilidade, estabelecer fluxos de dados não confiáveis com outras partes(por exemplo: lidar com dados corrompidos e timeouts durante a troca de dados que sejam cruciais para a aplicação), por fim, a aplicação deverá ser migrada para permitir que a mesma se conecte a uma plataforma SOA no futuro. |
|
Arquitetando uma ferramenta para gerenciamento de APIs e gerenciamento de identidade |
Neste caso particular, o objetivo é de arquitetar uma solução que permita às empresas expor novas APIs assim como o legado por meio de uma única plataforma de gerenciamento de API. Além disso, a solução deve conter um componente de Identity Access Management para expor com segurança as APIs de back-end e ativar a federação de identidade. A solução não será construída do zero. Existem muitas ferramentas, produtos e plataformas disponíveis atualmente e que poderão ser utilizadas como blocos lego para a solução. Um dos objetivos do grupo foi o de combinar os melhores produtos para oferecer uma solução completa. Gerenciamento de API como um serviço (SaaS), incluindo gerenciamento de identidade e acesso. |
|
Refatoramento de Aplicação para controle de Impostos |
A Centric é uma empresa de desenvolvimento de software que cresceu por meio de fusões e aquisições. Seu portfólio de produtos consiste em muitas aplicações que foram construídas nas empresas que foram adquiridas. O resultado dessa estratégia é que o portfólio de produtos é diversificado. Uma parte relativamente grande das aplicações foi construída no século passado e expandida nos últimos 20 anos. O resultado é que essas aplicações são ricas em funcionalidades e são muito aderentes nas empresas que as utilizam. A desvantagem é que as aplicações são muito grandes, complexas e não são construídas com as mais recentes tecnologias. Trata-se de uma aplicação antiga implementada por meio de arquiteturas diferentes sem nenhum padrão de integração definido onde a solução pode ser instalada on premises ou hospedada na empresa fornecedora. É o típico cenário de uma solução que cresceu sem nenhum controle ou padronização. |
|
Atualização ou Refatoração de uma solução SaaS |
A Centric é uma empresa de desenvolvimento de software que cresceu por meio de fusões e aquisições. Seu portfólio de produtos consiste em muitas aplicações que foram construídas nas empresas que foram adquiridas. O resultado dessa estratégia é que o portfólio de produtos é diversificado. Uma parte relativamente grande das aplicações foi construída no século passado e expandida nos últimos 20 anos. O resultado é que essas aplicações são ricas em funcionalidades e são muito aderentes nas empresas que as utilizam. A desvantagem é que as aplicações são muito grandes, complexas e não são construídas com as mais recentes tecnologias. Trata-se de uma aplicação antiga, largamente utilizada que entre outros aspectos precisa ser modernizada para reduzir custos com manutenção além de permitir seu crescimento de forma cadenciada. |
|
Khonraad: Solução que oferece acompanhamento de prontuário eletrônico para pacientes com problemas psíquicos e que necessita ser atualizada para obedecer aspectos relacionados à legislação do país. |
Um sistema que oferece serviços por meio de aplicativo móvel e desktop para controlar informações sobre pacientes com problemas psíquicos. Khonraad oferece serviços ao governo local, para as unidades de assistência à saúde mental e social que lhes permitem, entre outras coisas, colaborar por meio de prontuários eletrônicos. Além disso, decisões formais são tomadas, registradas e comunicadas como parte do gerenciamento seguro dos prontuários eletrônicos. Os serviços oferecidos são equipados com funções abrangentes de gerenciamento de fluxo de trabalho que monitoram o progresso do processo e o cronograma dos atendimentos. Este serviço é restrito a Holanda. |
Além das aulas com experiências reais, aulas teóricas também foram ministradas por nomes reconhecidos na academia e que possuem larga experiência prática em projetos e alguns deles inclusive, são autores de livros consagrados na área de Engenharia de Software como Len Bass, Philippe Kruchten, Ipek Ozkaya, Antony Tang entre outros.
O Case Khonraad
Meu time escolheu trabalhar com o case da solução que oferece acompanhamento de prontuário eletrônico para pacientes com problemas psíquicos e que necessita ser refatorada para obedecer aspectos relacionados à legislação do país.
Neste cenário, no primeiro dia do workshop, tivemos a participação da professora Patricia Lago como mediadora, e no período da manhã, tivemos aula com o professor Antony Tang sobre o tema Software Architecture Design Reasoning and Thinking (algo como Arquitetura de Software Design, Raciocínio e Pensamento).
A aula pela manhã foi dividida em duas partes e na primeira parte discorreu sobre assuntos como crença, racionalidade, síndrome da perda, lógica para decisão de design, dificuldades no design de software, problemas com idéias, o viés cognitivo (e os erros sistemáticos de julgamento que cometemos no papel de arquitetos), decisões de arquitetura baseadas na representatividade subjetiva, escolhas (o perder e o vencer), opções de design.
Já a segunda parte da aula, focou em caminhos para melhorar e alcançar boas decisões de design de soluções e discorreu sobre assuntos como a experiência do arquiteto e as técnicas que podem ser utilizadas para alcançar melhores decisões de soluções que incluíram técnicas para viabilizar o planejamento, técnicas para compreender a complexidade de projetos, técnicas para realizar uma melhor análise de problemas com perguntas melhores elaboradas, o entendimento de contexto e ao final apresentou o seguinte insight:
Sabemos que os preconceitos ocorrem, estamos racionalmente ligados e ao mesmo tempo satisfeitos. Nós não sabemos os detalhes de como essas características humanas influenciam uma tomada de decisão.
Como a psicologia e a neurologia funcionam em nós podem ser deixadas para os cientistas nesses campos, temos que entender quais são esses fenômenos e como eles afetam a tomada de decisão na área de Arquitetura de Software.
Podemos ensinar arquitetos a pensar melhor? Com melhores ferramentas, métodos e educação?
No período da tarde, as técnicas discutidas pela manhã foram aplicadas para fazer um entendimento preliminar do problema. O responsável pelo sistema apresentou uma visão geral de alto nível sobre o sistema e explicou sua necessidade e desejos. Inicialmente, aplicamos a técnica do Modelo de Tomada de Decisão Conceitual (com Raciocínio de Design) proposto pelo professor Antony Tang:
E então elencamos as preocupações, os problemas e por fim um esboço de alternativas de solução.
O case em questão era bastante complexo, trata-se de um software com pelo menos 20 anos de desenvolvimento, por uma empresa privada, e que obteve um crescimento em seu uso muito grande por resolver de forma digital uma demanda governamental relacionado ao rastreamento de informações sobre pacientes psiquiátricos. O software rastreia desde o momento em que o paciente é conduzido por um assistente social, policial ou agente público até uma unidade de assistência à saúde e consegue dar a visibilidade para toda a cadeia envolvida inclusive com informações sobre o prontuário médico do paciente, ações ocorridas no passado e contra medidas já aplicadas.
Na Europa, este tipo de assistência é totalmente provido pelo estado e o estado toma para si a responsabilidade de direcionar o tratamento adequado a este tipo de paciente.
Este sistema, fora todo desenvolvido em Java e possui as seguintes particularidades:
- Todas as regras de negócio que informam o fluxo de atendimento do paciente foram escritas por um único desenvolvedor simulando um BRMS(Business Rule Management System)
- O proprietário da aplicação não demonstrou conforto em explicar alguns detalhes técnicos para o time o que dificultava o entendimento do problema.
- Todo o código encontra-se em Dutch, o idioma oficial na Holanda
- As regras de negócio exigem um fluxo complexo e que não possui documentação clara.
- Há um aplicativo móvel que inicialmente, foi desenvolvido para funcionar em um Nokia Communicator 9000 para ser utilizado pelos agentes públicos para gerar pedidos.
- Mais tarde, o sistema evoluiu rapidamente através de uma arquitetura cliente-servidor baseada em WAP para a aplicação WEB atual. Baseado em dispositivos móveis (iOS, Android) e aplicativos de desktop
- Nos últimos 20 anos, várias refatorações arquiteturais foram aplicadas sem que houvesse algum controle de evolução de software.
No segundo dia, a aula pela manhã foi proferida pelo professor Philippe Kruchten e a aula tratou do tema "O que os arquitetos de software fazem?"
A agenda desta aula incluiu temas como a definição de Arquitetura de Software e o papel do arquiteto, arquitetos e sua interação com as outras partes interessadas, tipos de arquitetura que orbitam o mundo de TI. O professor Philippe Kruchten apresentou exemplos reais de sua vivência incluindo o case para o projeto de automação do sistema para controle do tráfego aéreo Canadense o qual ele foi um dos principais líderes. Detalhou alguns dos problemas enfrentados e apresentou a estratégia utilizada para salvar o projeto que já estava desacreditado. Note que este é um projeto do ano de 1992 ou seja, 26 anos e os problemas enfrentados neste projeto foram identificados por alguns participantes do workshop como sendo muito similares a exemplos reais que enfrentamos nos dias de hoje, incluindo o trabalho de convencer o cliente a não cancelar o projeto.
Outro tópico abordado intensamente foi relativo ao papel do Arquiteto onde o professor Philippe Kruchten iniciou o assunto com a definição de arquiteto por Marcus Vitruvius Pollio.
[O arquiteto] deve ser um homem de letras, um habilidoso desenhista, um matemático, familiarizado com estudos históricos, um diligente estudante de filosofia, familiarizado com a música; não ignorante da medicina, aprendido nas respostas de jurisconsultos, familiarizado com astronomia e cálculos astronômicos.
Na concepção do professor, o papel do arquiteto envolve:
- Ser um visionário, um formatador de ideias
- Ser um designer capaz de fazer escolhas para alcançar um objetivo
- Atuar como um bom comunicador que consegue atuar entre vários tipos de clientes
- Ser um solucionador de problemas
- Atuar como um arauto ou um farol que pode ser utilizado e consultado por outros integrantes do projeto
- Um zelador que cuida de aspectos não considerados por outros integrantes do projeto
Por fim, o modelo de visões 4+1 criado por ele em 1995 foi apresentado mais uma vez:
Os outros dois dias do workshop incluíram aulas com professor Lenn Bass falando sobre a relação entre DevOps e Arquitetura, Ipek Ozkaya do SEI falando sobre o gerenciamento do Débito Técnico, o professor do MIT Rich Hilliard com o tema Architecture Description onde apresentou conceitos, métodos e melhores práticas usados para representar arquiteturas de sistemas, e a aula do professor Ian Gorton da Northeastern University em Seattle/EUA.
E qual a importância de um workshop como este?
A iSAPS, ocorre anualmente em Leiden/Holanda no Instituto Lorenz Center e é organizado por um grupo de professores que convidam outros profissionais reconhecidos no mercado e na academia para participar do workshop. Os experts convidados atuam em grandes empresas como a CGI com sede na Holanda que possui larga experiência com desenvolvimento de Arquiteturas de Soluções e treinamentos.
Neste ano, 36 participantes de diferentes nacionalidades foram selecionados e ao longo do workshop, os 36 alunos trabalharam em sete grupos nos estudos de casos industriais sob a supervisão de um pesquisador sênior e em colaboração com um arquiteto de software/sistema da indústria (de três grandes empresas e uma PME). O resultado de cada trabalho de grupo foi uma solução para arquitetar problemas formulados nos respectivos estudos de caso pelos proprietários do caso. Essas soluções são a principal entrega do workshop. Os resultados secundários são o conhecimento e as habilidades que os estudantes de doutorado e arquitetos adquiriram durante as palestras, as conexões estabelecidas entre academia e a indústria, e os problemas de pesquisa aberta que foram formulados e podem ser considerados trabalhos futuros para os estudantes de doutorado.
Muitos estudantes de doutorado comentaram que aprenderam muito mais do que esperavam e usarão as lições aprendidas em seus projetos de pesquisa. Vários deles não sabiam que a arquitetura é um papel que exige tanto soft skills quanto habilidades técnicas. Outro momento de "iluminação" foi que as discrepâncias entre a arquitetura implementada e a ideal não são necessariamente ruins. Tanto os estudantes de doutorado como os arquitetos admitiram que gostaram de trabalhar uns com os outros e encontraram ligações entre o tópico o qual trabalham em seu dia a dia e outros tópicos abordados durante a escola.
O workshop busca formar profissionais que conheçam o mundo real e que entendam que construir arquiteturas não se trata apenas de escrever um documento ou código. Ele busca apresentar de forma transparente que existem muitas facetas que um arquiteto precisam enfrentar até conseguir uma solução.
E qual o custo para participar do workshop?
Não há custo para participar do workshop porém a aceitação é baseada em análise de curriculum. São avaliados a experiência como estudante de doutorado ou mestrado assim como a experiência como profissional da área capaz de contribuir nas discussões em grupo.
Conclusão
A iSAPS ocorre anualmente e é organizado para que a cada ano, mais e mais participantes se juntem ao grupo.
A troca de experiência e as lições aprendidas são importantes para que se possa entender como outras culturas tratam arquitetura de software e solução e ao final, entender que em um grande espectro, as dificuldades vividas são as mesmas. Falta de escopo, falta de entendimento e falta de alinhamento entre áreas incluindo o cliente que se beneficiará da solução.
Para se manter atualizado sobre os últimos acontecimentos, siga a o Twitter da iSAPS ou siga os organizadores do workshop.
O próximo workshop já tem data marcada e acontecerá em Junho/2019.