Update (27/out): Finalmente liberado o arquivo da apresentação.
-
Pra variar há um descompasso entre fornecedores de tecnologia e seus usuários. Parece que 2006 será um ano ‘chave’ para a consolidação de SOA nos EUA. Pelo que percebi, nós tupiniquins aguardaremos mais 2 ou 3 anos. Os poucos early adopters brasileiros não terão o que mostrar no ano que vem, não ao ponto de motivar adesões.
-
Nas palestras, o pessoal com um pouco mais de estrada (desenvolvendo sistemas) percebe rapidamente as vantagens de uma SOA. Como apresento na 1ª parte do evento os conceitos básicos, é natural que se inicie ali um debate sobre “Arquitetura”.
-
É uma pena que eu tenha que atirar um balde d’água fria no ânimo do pessoal no mesmo instante. Faço-o (sem querer) ao lembrar que ainda temos muitas pendências (linguagens para os contratos: WS-*; ferramental de desenvolvimento; um processo para gestão e desenvolvimento e as eternas “questões semânticas”).
-
E compenso tudo mostrando a maior pendência de todas: o Arquiteto (que não existe). Digo, sem o menor medo de errar, que será a profissão com as melhores ofertas e melhores salários nos próximos 5 anos. E nesse ciclo sádico (1 tapa, 1 beijo), apresento um anúncio real para contratação de um Arquiteto. Desanimo uns e provoco todos ao comentar que no próximo ano a Microsoft lançará a nova certificação MCA (Microsoft Certified Architect), um processo que lembrará (muito) a defesa de uma tese de doutorado. (Com um programa que cita o IBM Websphere mais de 1 vez!!!).
Ou seja, só a primeira parte (que dura uns 30-40min) da palestra já gera assunto para 2hs de debate. E, dependendo do público (falo principalmente da estudantada das faculdades), trata-se de uma tsunami de siglas e conceitos novos. Um show de terror ou um show de tédio, dependendo do aluno. Mal sabíamos (na primeira execução pública) que o evento ainda duraria mais 2hs…
-
Uma iniciativa SOA deve ser gerida como um Programa, ou seja, um conjunto (nada pequeno) de projetos. Gosto muito da estrutura do Comitê Gestor que sugiro. Mas fiquei devendo um processo de gestão. Cito o Meta-Scrum (que é uma proposta muito recente) e uma série de ferramentas / frameworks / Padrões (Mapas Estratégicos, MDA, RAS). Todos mereciam mais tempo e espaço. E, principalmente, Estudo!
-
Mas meu maior erro (no artigo – foi corrigido na apresentação) foi citar o RUP e não o EUP (Enterprise Unified Process) como processo básico. O EUP contempla várias disciplinas (totalmente ignoradas pelo RUP) vitais para a gestão do Programa SOA: Enterprise Business Modeling, Portfolio Management, Enterprise Architecture e Strategic Reuse.
-
A audiência parece assimilar bem os conceitos básicos do método Scrum para o gerenciamento dos projetos SOA. Mas deixo (e destaco) aqui outra imensa pendência: um processo “meet-in-the-middle“, fundamental para a análise e projeto (design) dos Serviços. Explico a necessidade: enquanto um Analista de Negócio absorve os requerimentos do projeto, um Analista de Sistemas deve descobrir e mapear todos os ativos de software que podem ser revitalizados pelo novo Serviço. Seu encontro (meet-in-the-middle), intermediado pelo Arquiteto, deve gerar a primeira visão conceitual (lógica?) do Serviço.
Conclusão: é muito mb pro meu hd (ou: “muita areia pro meu caminhãozinho”). E olha que nem me meti em temas como “Governança SOA”, “Segurança SOA”, “Gerenciamento de Transações em uma SOA”… urgh! Preciso “focar” (blergh!) meus estudos se eu quiser parar de gerar “nata” (com alguns metros quadrados de área e 2cm de profundidade). Lógico que meus interesses, desde o início dos estudos, são:
-
Gestão de Projetos (Gestão do Programa em 2º plano);
-
Processos de Gestão e Desenvolvimento;
-
Agilidade; e
-
Perfil dos futuros projetos de TI (onde SOA se encaixa).
Eu e o finito voltamos para eles tratando-os de forma mais específica. Lógico que partindo do ponto que estamos: tudo que sugerimos para Programas e Projetos SOA são úteis em outros tipos de projetos. Vamos maturá-los enquanto SOA não vem…
