|
|||||
As Ondas ArquiteturaisO termo “arquitetura” em TI pode denotar muitas coisas e isso normalmente gera muita confusão e ambiguidade em times e projetos. Discutimos neste post a idéia das “ondas arquiteturais”, que mostra a relação alguns tipos de arquiteturais de TI comumente encontradas em empresas e projetos. A figura abaixo mostra estes níveis de arquitetura em ondas.  Diversos níveis de arquitetura de software O primeiro nível (mais interno) na figura mostra a arquitetura de software. Esta arquitetura lida com o desenho de aplicações corporativas em nível de software. O desenho inclui o uso de boas estratégias para a modelagem de software e a aplicação correta de tecnologias (ex: Java EE, .NET, Ruby ou COBOL) para a construção e entrega destes softwares. O arquiteto de software é o papel responsável por estas atividades. O DeArchitectura lida primordialmente com artigos de arquiteturas de software, para o arquiteto de software. O segundo nível apresenta a arquitetura de sistemas. Uma arquitetura de sistemas inclui a arquitetura de software bem como outros tipos de arquiteturas como por exemplo as arquiteturas de integração de sistemas (EAI), arquiteturas de dados, arquiteturas de segurança e arquiteturas de infra-estrutura. Normalmente um time de arquitetos (arquitetos de software, segurança, DBAs e arquitetos de infra-estrutura) opera em conjunto para realizar as atividades deste nível. O terceiro nível endereça a arquitetura de TI. A arquitetura de TI lida com todos os aspectos que a TI deve suportar desde a infra-estrutura, bancos de dados, aplicações, portais e até mesmo processos de negócio. A arquitetura de TI é responsável pelo alinhamento da TI às estratégias de uma organização. Uma arquitetura SOA é um bom exemplo de uma arquitetura neste nível. Exemplos deste tipo de arquitetura incluem também modelos formais como o Zachman Framework ou o TOGAF. O quarto e último nível endereça as arquiteturas empresariais. Arquiteturas empresariais são elementos que enlaçam toda uma organização desde os seus modelos operacionais, as arquiteturas de negócio e as arquiteturas de TI subjacentes. Uma arquitetura empresarial modela uma empresa em todos os seus elementos e enlaça a arquitetura de TI. Podemos notar que a arquitetura empresarial é um assunto da área de administração, mas que merece também a nossa atenção. Afinal, todo o trabalho do arquiteto de software, sistemas ou TI deve ser dirigido pelas arquiteturas empresariais. Os últimos dois níveis são território do arquiteto corporativo, normalmente um estrategista generalista com fortes conhecimentos de administração, de negócios e de governança de TI. Ele dialoga diariamente com o CIO (Chief Information Officer) e também com outros CxOs de uma organização e pode muitas vezes ser o CTO (Chief Tecnhology Officer) de uma área de TI. Todas as arquiteturas são especialmente importantes, mas cada uma possui os seus limites e requer profissionais especializados para uma execução eficaz e eficiente. 6 comments to As Ondas Arquiteturais |
|||||
|
Copyright © 2010 Arkhi - All Rights Reserved |
|||||
Marcos,
Muito interessante seu post. Quando li o quinto parágrafo falando sobre arquitetos de TI logo relacionei com o CTO e mais embaixo você confirmou isso. Nesse “nível” está correto afirmar que ITIL é outro exemplo de modelo?
Além disso, você acredita que existe o papel de “arquiteto de sistemas”? Pelo que entendi este profissional teria que conhecer muito bem de todas as áreas, então imagino que o cargo até possa existir, mas não sozinho, ou seja, ele depende de uma equipe (DBAs, Infra, etc) para auxiliá-lo nas decisões, tal como você escreveu.
Obrigado.
Ola Marco.
Legal o post. Esse tipo de assunto faz parte do meu cotidiano e embora (acredito eu) essas definições não sejam “politicamente corretas”, elas são reais e fazem parte do cenário atual de TI.
Digo que não são “politicamente corretas” no sentido da corrente agilista, que afirma que na verdade a melhor forma de se desenvolver um software é com um bom time e não com uma boa divisão departamental. De qualquer maneira procuro ser o menos tendencioso possível para assumir o que é certo e o que é errado e acredito que as duas abordagens possam coexistir. Entendo que uma boa divisão departamental seja crucial para um bom entendimento dos deveres e responsabilidades de cada área e é muito útil em discussões estratégicas de nível gerencial, de diretoria e até presidencial.
Porém quando o assunto é desenvolver software, essa divisão pode ser até meio prejudicial pois ela incentiva a passagem de bastão (jogo da batata quente) entre as áreas que fogem desesperadamente de suas SLA’s. Quem está em alguma posição de liderança, tem a obrigação de ter esse tipo de questionamento e de alguma forma tentar achar uma solução viável olhando sempre para o core business da empresa. Para os superficiais de plantão: Não existe solução enlatada! Você vai ter que fazer muita pesquisa e por o tico e o teco pra funcionar!
[]’s
-l30-
Olá, Marcos. Obrigado pelo feedback. Concordo com as suas afirmaçòes. O ITIL é um corpo de conhecimento que pode nos ajudar a estruturar uma arquitetura de TI, embora ele seja diferente em propósito do TOGAF ou Zachman Framework. Também concordo que o papel “arquiteto de sistemas” realmente seria preenchido por um time com especialistas diversos.
Olá, Leo. Quando lidamos com arquiteturas tão “distantes” quanto Arquiteturas Corporativas ou Arquiteturas de Sistemas precisamos envolver profissionais com “skills” mais exóticos ao mundo técnico (governança corporativa, administração ou processos de negócio).
Apesar disso, concordo com a visão ágil sobre o desenvolvimento de software e do trabalho colaborativo. No artigo citamos primordialmente papéis e podemos ter pessoas e times com interseção assumindo estes papéis. Inclusive, o Scott Ambler tem um trabalho interessante a respeito: “Agile Enterprise Architectures”, que postei em PANGEA. http://pangeanet.org/group/enterprisearchitecture/forum/topics/arquiteturas-empresariais
Dando meus dois tostões sobre o assunto…
A “corrente agilista” acredita que bons times multidisciplinares são uma ótima estratégia para produzir bons softwares, de ponta a ponta, que realmente atendam às necessidades de seus clientes. Mas não significa que não acredite na divisão de papeis. FDD, por exemplo, define alguns papeis: Gerente de Projetos, Especilista de Negócio, Arquiteto, Gerente de Desenvolvimento, Programador Chefe e Programador. Mesmo em times XP há o papel do Líder Técnico, que é bem próximo ao papel do arquiteto de software que popularmente conhecemos (exceto talvez pelo fato de que ele normalmente envolve os outros programadores nas decisões; o que normalmente não acontece em abordagens fabris).
Agora, pelo que entendi deste post, Marco está falando sobre possíveis disciplinas de arquitetura que podem haver em corporações, o que está além de um projeto de software desenvolvido sob uma abordagem ágil ou não.
Por exemplo, um “arquiteto de software” está em um time que está desenvolvendo um projeto de softare. Este projeto, por sua vez, pode ou não estar sendo desenvolvido sob uma abordagem ágil. Se estiver, ótimo!
Já os outros arquitetos desempenham papeis que vão além de um projeto [que pode ou não ser desenvolvido sob uma abordagem ágil]. Aliás, em alguns casos, estes arquitetos (dependendo da posição na “onda”) vão atuar em projetos que nem mesmo de desenvolvimento de software são. A partir da segunda posição na onda, os papeis dizem mais respeito a dizer como as coisas funcionam e se relacionam em uma corporação – quardados os seus devidos escopos, claro.
(Só pra constar, há alguns anos andei dando uma olhada em TOGAF, por influência de um amigo. Mas não achei que seja a minha praia.)
[]s
Leandro
{leandrosilva.com.br}
No site de Bredermeyer Consulting existe uma clasificação só as ondas arquiteturais.
http://www.bredemeyer.com/who.htm
Como conclução existen diferencia entre as ondas arquiteturais pero muitos arquitetos trabalhan en varias delas.
Brigado.