SOA: O Fio da Meada
Jeff Schneider, há tempos, escreve sobre SOA. Dicas valiosas. Percebendo um certo descompasso - carência mesmo - em fevereiro começou uma série chamada "Starter SOA". Tem 3 partes até agora. Não se sabe se continuará. Mas o pouco que foi para o ar é de enorme valia.
Na 1ª parte ele fixa as 3 áreas que devem ser 'atacadas' no início de um programa SOA:
Na 2ª parte ele sugere a criação de um "SOA Steering Comittee". No desenho abaixo os membros do comitê e respectivas disciplinas:
A sugestão do Schneider tem algumas semelhanças com aquele desenho que apresentei aqui há quase 2 anos:
Fui mais detalhista em alguns pontos, mas pequei por ignorar por completo a Arquitetura da Informação. Na verdade, joguei nas costas do Arquiteto de Serviços essa responsabilidade. Um serviço encapsula dados e lógica. Mas isso não tem nada a ver com a proposta de Schneider. Como bem explicou Todd Biske, "o gerenciamento da informação é a fonte de consistência entre todos os serviços". Sendo assim, no gráfico acima, o Arquiteto da Informação ficaria logo abaixo do Arquiteto SOA. É seu braço direito e fiscal.
O Gerenciamento do Portfólio é uma das áreas críticas, segundo Schneider. No meu ponto de vista, deveria ser uma responsabilidade do próprio Gestor do Programa ("SOA Leader" na nomenclatura utilizada por ele). Auxiliam no gerenciamento do portfólio o Arquiteto de Negócio e o Gestor da Biblioteca de Ativos (GBA), além do representante do PMO (Escritório de Projetos). Entendo que portfólio são os projetos e os ativos existentes. É grande demais para uma cabeça só. Aproveito para insistir que uma boa ferramenta de apoio para tal gerenciamento, sintética e objetiva, é o Mapa Estratégico. Desde que devidamente adaptado para o programa.
Na 1ª parte ele fixa as 3 áreas que devem ser 'atacadas' no início de um programa SOA:
- Gerenciamento do Portfólio
- Arquitetura Corporativa
- Gerenciamento da Informação
Na 2ª parte ele sugere a criação de um "SOA Steering Comittee". No desenho abaixo os membros do comitê e respectivas disciplinas:
A sugestão do Schneider tem algumas semelhanças com aquele desenho que apresentei aqui há quase 2 anos:
Fui mais detalhista em alguns pontos, mas pequei por ignorar por completo a Arquitetura da Informação. Na verdade, joguei nas costas do Arquiteto de Serviços essa responsabilidade. Um serviço encapsula dados e lógica. Mas isso não tem nada a ver com a proposta de Schneider. Como bem explicou Todd Biske, "o gerenciamento da informação é a fonte de consistência entre todos os serviços". Sendo assim, no gráfico acima, o Arquiteto da Informação ficaria logo abaixo do Arquiteto SOA. É seu braço direito e fiscal.
O Gerenciamento do Portfólio é uma das áreas críticas, segundo Schneider. No meu ponto de vista, deveria ser uma responsabilidade do próprio Gestor do Programa ("SOA Leader" na nomenclatura utilizada por ele). Auxiliam no gerenciamento do portfólio o Arquiteto de Negócio e o Gestor da Biblioteca de Ativos (GBA), além do representante do PMO (Escritório de Projetos). Entendo que portfólio são os projetos e os ativos existentes. É grande demais para uma cabeça só. Aproveito para insistir que uma boa ferramenta de apoio para tal gerenciamento, sintética e objetiva, é o Mapa Estratégico. Desde que devidamente adaptado para o programa.
Marcadores: gerenciamento_de_ativos, soa
segunda-feira, 19 de março de 2007 |
Assine o finito
Lista completa no del.icio.us
Olá PV. Eu fiquei intrigado com essa coisa de information management. Você conhece ou sabe de alguém que publicou algum framework (no sentido amplo da palavra) ou guia de boas práticas para o desenvolvimento de ''service schemas''? Ou será que isso é um nome novo pra algo que a gente tá cansado de ver?
Grande Braga,
Não cara, sinceramente não vi nada de novo no citado front. Mas, de qualquer maneira, concordo com a priorização ao tema dado pelo Schneider: aquele papo de validação dos modelos, esquemas, fontes de dados etc.
Saca só uma breve provocação: meu novo serviço consolidará informações sobre clientes. Elas estão em três fontes distintas (legado em COBOL, um pacote CRM e um pacote ERP - isso é comum pra chuchu!).
Quem determina a fonte que deve predominar (em caso de redundância + diferença nos dados)? Qual impacto meu novo serviço pode ter nas operações de sincronismo das bases de dados?
Respondi apontando pra outro lado mas sei que vc me entendeu. Ou não?
Hehe. Abraços