Arquitetura em TI

Written on 19:31 by Sany Mars

Achei esse texto muito interessante, trabalho mais com linux, mas não há como negar, há varios textos e treinamentos muito interessantes. em outros posts irei postar aqui os treinamento gratuitos.

O link desse post está aqui

Os sistemas em TI tornam-se a cada dia mais complexos e, não é de surpreender estarmos testemunhando o surgimento de uma nova profissão em TI, livremente denominada arquitetura de TI. Por hora, vamos ignorar o nome e o enfoque nos problemas que esta profissão tenta resolver.

Definir e projetar estruturas complexas é uma atividade comum, conhecimento exigidos para a composição de sistemas complexos de grande porte não correspondem às habilidades exigidas para pequenas atividades de montagem bottom-up. Em TI, o mesmo problema ficou aparente há cerca de dez anos, e a lacuna entre engenharia básica e projeto de sistema de alto nível só cresceu desde então. O aforismo de Grady Booch, não é possível construir um arranha-céu da mesma forma que se constrói uma casinha de cachorro, engloba o dilema comum existente em projetos de alta complexidade, alta interdependência e pouca transparência: O elevado volume de detalhes exigido em composições complexas é tão impressionante que a função da análise, decomposição e abstração torna-se vital para o sucesso desses esforços.

No setor de construção estrutural, os arquitetos separaram-se dos engenheiros civis e operários da construção há muitos séculos. Eles eram (e ainda são) arrumadinhos, educados e no seu currículo de ensino há conjuntos de habilidades bem diferentes dos seus pares engenheiros. Se fosse perguntado a um engenheiro civil o que é uma construção, a definição estaria enfocada na espessura das paredes, ângulo do telhado, resistência das vigas e no tipo do concreto exigido para as fundações da casa. Os arquitetos, por sua vez, descreverão a casa como um invólucro à volta de um espaço vital, aninhado no ambiente que permite aos seus habitantes realizarem todos os seus desejos na casa.

A seguir está um exemplo de currículo para um programa de estudo de arquitetura estrutural de quatro anos:

•	História e teoria da arquitetura
•	Projeto e construção de edifícios
•	Materiais e métodos
•	Projeto arquitetural
•	Teoria e método na arquitetura
•	Sistemas estruturais
•	Projeto urbano e de obra
•	Espaço e composição
•	Tipos de estruturas
•	Preservação e restauração
•	Aquecimento, refrigeração e iluminação
•	Padrões de assentamento humano
•	Estimativas de construção
•	Planejamento e viabilidade de projetos
•	Sistemas de meio ambiente
•	Estágio arquitetural.

Obviamente, o conhecimento adquirido durante o estudo da arquitetura é diferente e, muitas vezes, se sobrepõe a outras profissões ou artes. Entende-se e aceita-se que arquitetos não têm e não precisam ter conhecimento total da arquitetura – os projetistas de interiores, por exemplo, utilizarão um subconjunto de conhecimento diferente dos arquitetos urbanos ou paisagistas.

Como esses eventos se transferem para TI, de onde emprestamos o nome e o título da arquitetura? Nossa profissão moderna não teve séculos para diversificar-se e evoluir naturalmente. Parece que, agora, denominamos de arquitetura todos os esforços de TI de alta complexidade e não mais de engenharia. Nas palavras de Alan Cooper: "[atualmente] Web Designers são denominados programadores, programadores são chamados de engenheiros; engenheiros de arquitetos, e [verdadeiros] arquitetos nunca são assim denominados".

A importância do conhecimento

Conforme Scott B. Parry, define-se competência por quatro características:

1.	Conjunto de conhecimentos, atitudes, habilidades e outras características pessoais correlatas que afeta a maior parte do trabalho de uma pessoa;
2.	Está vinculado ao desempenho no trabalho;
3.	Pode ser medido contra padrões comprovados;
4.	Pode ser aprimorado por meio de treinamento e desenvolvimento.

Pela perspectiva do crescimento do conhecimento, a mais importante é a quarta característica: a habilidade de aprender e melhorar. Vamos analisar os estágios da competência pelos quais passa uma pessoa na medida em que o conhecimento é absorvido e utilizado durante o trabalho diário (Figura 1):

Iniciante

Pessoas não conscientes da existência ou relevância de determinada área do conhecimento ou que até podem negar a relevância ou a utilidade desse conhecimento são denominados iniciantes. Até que o iniciante reconheça uma deficiência, não é possível aprimorar a habilidade; assim, podemos dizer que a pessoa é incompetente sem estar consciente desse fato.

Uma coleção coesa de áreas disponíveis do conhecimento de uma profissão ajudaria os iniciantes a identificar as deficiências para que pudessem determinar como adquirir as habilidades e tornarem-se aprendizes.

Aprendiz

Os aprendizes estão conscientes da existência e relevância da habilidade; a deficiência nessa área fica quase sempre exposta por tentativa e erro para realizar a habilidade faltante e gera uma sede de conhecimento.

Em condições ideais, um aprendiz se compromete a aprender e praticar a nova habilidade até atingir o nível de proficiência adequado.

As pessoas nessa etapa precisam urgentemente de fontes de conhecimento e treinamento relevantes. Um índice de referência de fontes de aprendizado poderia direcioná-las às melhores fontes.

Trainee

Quando determinada habilidade pode ser realizada de forma confiável e voluntária, atinge-se o estágio de competência consciente. Os trainees precisam estar concentrados para executar a habilidade de modo deliberado: ainda não têm o comando intuitivo para tal. O conhecimento está presente, mas exige prática para tornar-se "instintivo".

Concentração e análise da habilidade exigem lembretes e diretrizes freqüentes. Uma única fonte de informações para ajudar os trainees a seguir as etapas reduziria o tempo necessário para desenvolver competência inconsciente.

Especialista

Este é o estágio em que uma habilidade é realizada sem preocupações, como dirigir, nadar ou esquiar. Torna-se tão natural que a decisão de fazê-lo não é consciente: este é o estágio de aptidão em que uma habilidade começa a tornar-se arte e o especialista pode tornar-se um professor.

Ensinar algo que se tornou instintivo pode ser difícil. As pessoas que se tornaram especialistas em domínios específicos, por muito tempo, podem ter, às vezes, dificuldade de explicar os conceitos básicos. Um guia de estudo coerente, com fundamento lógico por trás de cada habilidade também serviria para os especialistas como ferramenta útil de ensino.

Profissão e conhecimento especializado de TI

A arquitetura de TI torna-se, gradualmente, em profissão independente, distanciando-se da engenharia e do desenvolvimento de software. Como carreira vocacional e prospectiva, tem o seu próprio corpus de conhecimento especializado que a fará diferente das outras profissões.

"COMO ESSES EVENTS SE TRANSFEREM PARA TI, DE ONDE EMPRESTAMOS O NOME E O TÍTULO DA ARQUITETURA? NOSSA PROFISSÃO MODERNA NÃO TEVE SÉCULOS PARA DIVERSIFICAR-SE E EVOLUIR NATURALMENTE. PARECE QUE, AGORA, DENOMINAMOS DE ARQUITETURA TODOS OS ESFORÇOS DE TI DE ALTA COMPLEXIDADE E NÃO MAIS DE ENGENHARIA. NAS PALAVRAS DE ALAN COOPER: '[ATUALMENTE] WEB DESIGNERS SÃO DENOMINADOS PROGRAMADORES, PROGRAMADORES SÃO CHAMADOS DE ENGENHEIROS; ENGENHEIROS DE ARQUITETOS E [VERDADEIROS] ARQUITETOS NUNCA SÃO ASSIM DENOMINADOS".

Porém, ter conhecimento especializado não é suficiente se a arquitetura de TI tornar-se disciplina respeitada e desejada, no mesmo patamar das outras disciplinas das ciências da computação. O título de arquiteto de TI deveria ser adquirido depois de se alcançar um nível definido de competência por meio de prática e experiência, comprovadas por algum tipo de qualificação formal e, talvez, controladas por organismos profissionais os quais, assim, protegeriam a reputação e o código de prática.

Você poderia perguntar, por que tanto rigor? Como com qualquer profissão que surge, existe o risco de se usar os novos termos—nomes, títulos ou credenciais—sem controles e confirmação. Atualmente, o título de arquiteto é usado para descrever tudo, de engenheiros notáveis a desenvolvedores, de consultores seniores a especialistas experientes em vendas.

Conhecimento geralmente aceito

A arquitetura de TI é uma profissão recente e de rápida evolução, por isso existem tantas áreas que ainda não são aceitas como predominantes. Um ArcBOK deveria se concentrar em identificar e descrever todo o conhecimento e apenas aquele geralmente aceito na comunidade arquitetural.

O que é conhecimento "geralmente aceito"? O Project Management Institute no seu Guide to the Project Management Body of Knowledge (PMBOK) define o conhecimento geralmente aceito do gerenciamento de projeto desta forma:

“Geralmente aceito” significa que o conhecimento e as práticas descritas aplicam-se à maioria dos projetos, na maior parte do tempo, e que existe consenso amplo sobre o seu valor e utilidade. "Geralmente aceito" não significa que o conhecimento e as práticas descritas são ou edqevueipriea mqu ese gr earpelniccaiad oos p dreo jmetood éo s uenmifporrem ree sepmon tsoádvoesl poos rp droejteetroms;i naa r o que é apropriado para determinado projeto.

Na arquitetura de TI temos outro nível de complexidade: O exercício da arquitetura assume várias nuances, e mais subdisciplinas arquiteturais surgem a cada ano. O conhecimento geralmente aceito de uma solução arquitetural típica é bastante diferente do conhecimento geralmente aceito de um arquiteto corporativo ou de segurança. O ArcBOK deve compreender todos e, além disso, distinguir claramente área fundamental da área de apoio, dependendo da subdisciplina arquitetural.

O corpus de conhecimento

Precisamos ser muito precisos na definição do ArcBOK: deve ser todo o conhecimento disponível na área da arquitetura de TI, classificado conforme a taxonomia apropriada das áreas de conhecimento. O desenvolvimento e reconhecimento de um corpus de conhecimento é essencial para o desenvolvimento da profissão, credenciais e das matérias universitárias.

A tecnologia da informação evolui tão rápido que o próprio conhecimento arquitetural deixaria o ArcBOK obsoleto mesmo antes de estar consolidado, revisado e publicado. Em lugar de capturar e republicar o conhecimento em si, o ArcBOK deveria tornar-se uma base de referência de meta-conhecimento, com visão completa, de 360 graus, do material de referência exigido para realizar adequadamente o trabalho de um arquiteto de TI.

O processo de construção do ArcBOK deve seguir o processo de construção de consenso, solicitando à comunidade e às entidades profissionais feedback e comentários. Deveria estar dividido e subdividido em áreas de conhecimento, os principais componentes de uma disciplina ou em subcampos de estudo.

O exemplo a seguir é um modelo superficial de áreas de conhecimento do ArcBOK (Figura 2):

•	Gerenciamento de projeto - atividades relacionadas à reunião das exigências de agrupamento, modelagem, visualização e comunicação dos projetos de TI.
•	Gerenciamento de análise - atividades relacionadas à análise, dedução, inovação criatividade e resolução de problemas.
•	Gerenciamento de entrega - atividades relacionadas a projeto, contratação, transformação, desenvolvimento, planejamento,

"O QUE É CONHECIMENTO GERALMENTE ACEITO PARA ARQUITETURA DE TI? O EXERCÍCIO DA ARQUITETURA ASSUME VÁRIAS NUANCES, E MAIS SUBDISCIPLINAS ARQUITETURAIS SURGEM A CADA ANO. O CONHECIMENTO GERALMENTE ACEITO DE UMA SOLUÇÃO ARQUITETURAL TÍPICA É BASTANTE DIFERENTE DO CONHECIMENTO GERALMENTE ACEITO DE UM ARQUITETO CORPORATIVO OU DE SEGURANÇA. O ARCBOK DEVE COMPREENDER TODOS E, ALÉM DISSO, DISTINGUIR CLARAMENTE ÁREA FUNDAMENTAL DA ÁREA DE APOIO, DEPENDENDO DA SUBDISCIPLINA ARQUITETURAL.

•	Gerenciamento de pessoas - atividades relacionadas a liderança, políticas organizacionais, participantes e gerenciamento de relações.
•	Gerenciamento de estratégia - atividades relacionadas à definição do objetivo do negócio, estratégia corporativa e roadmaps.
•	Gerenciamento financeiro e jurídico - atividades relacionadas a faturamento, terceirização, legislação e compras.
•	Gerenciamento do ciclo de vida - atividades que se concentram em vários estágios do ciclo de vida de TI, inclusive concepção, gerenciamento de SLA, de mudanças e descomissionamento de TI.

Cada área de conhecimento deveria ser dividida em competências do conhecimento, específicas de área, e cada competência deveria obter a lista de recursos disponíveis.

Por exemplo, uma área de conhecimento básico para arquitetos é o gerenciamento de projeto. Nosso exemplo divide a área em quadro competências e lista as várias técnicas, frameworks, ferramentas e habilidades de cada competência (Figura 3).

Este exemplo de modelo não recebeu nenhum tipo de confirmação, tampouco foi aceito pela comunidade: representa apenas uma provocação para ganhar intensidade e chamar à participação.

Possível uso impróprio

Analisamos os benefícios de ter o ArcBOK como documento de consulta diária para arquitetos; também vale a pena discutir os possíveis usos impróprios dessa coleção de conhecimentos.

O uso impróprio mais evidente do ArcBOK seria a idéia de que alguém precise saber alguma coisa que esteja no corpus para usar o título de arquiteto. Você pode imaginar situações de irregularidades, como ter a promoção recusada por um gerente tacanho por você não ter demonstrado competência em subdisciplina remota, ou ser submetido à exigência de citar trechos inteiros do ArcBOK durante uma entrevista, como comprovação de conhecimento arquitetural. Esse uso impróprio está acontecendo com o PMBOK e, portanto, seria ingênuo não imaginar que isso não aconteceria também com o ArcBOK.

Outro uso impróprio previsível é a pressuposição de que conhecer o ArcBOK faria de qualquer pessoa um arquiteto. Todos sabemos como é comum estudar de véspera para o exame MCSE (Microsoft Certified Systems Engineer), quando os candidatos memorizam informações inúteis apenas para serem aprovados no exame. A cilada possível do ArcBOK seria os candidatos para o MCA ou para outras certificações arquiteturais fariam o mesmo com o conteúdo do ArcBOK, na esperança de que isso poderia ser suficiente para ser aprovado pelo conselho de análise. O ArcBOK não deve tornar-se um guia do tipo "MCA para iniciantes" e deve ser bastante explícito sobre isso.

Colocar todos os tipos de escala de avaliação acima do ArcBOK seria outro possível uso impróprio. As áreas de conhecimento são diversas e não correlatas; seria errado avaliar e calcular a média das competências contra uma escala unificada—"Tirei 4 em modelagem e 2 em análise de compensações; portanto, a minha nota média em arquitetura é 3", não seria avaliação útil de nada.

Chamada à ação

Como seria com qualquer outro corpus de conhecimento, construir o ArcBOK deve ser o esforço de um grupo, exige o consenso de muitos profissionais que exercem a profissão, em arquitetura de TI e em profissões correlatas. A comunidade MCA formou um SIG para trabalhar no ArcBOK. Se você estiver interessado em participar, ter uma idéia do que se trata ou se apenas quiser saber mais sobre o projeto, registre o seu interesse enviando um email para o seguinte endereço: miha.kralj@ microsoft.com. Você não precisa ter a certificação MCA; desde que esteja interessado, pessoal e profissionalmente em arquitetura de TI, a sua participação é muito bem-vinda.

Por que peço para registrar o seu interesse? Existem várias formas que o trabalho no ArcBOK poderia progredir. O nível de interesse baseado no seu feedback determinará o curso que tomaremos:

•	se ninguém estiver interessado, de fato, além de alguns poucos arquitetos da comunidade MCA, continuaremos nosso trabalho lentamente, trocando mensagens para envio das minutas entre nós mesmos;
•	se houver interesse em ler e usar o ArcBOK, mas não de participar na sua criação, consideraremos um blog ou qualquer outra forma para publicar o andamento dos trabalhos;
•	se houver indicação de que muitos entusiastas gostariam de acrescentar as suas opiniões e conhecimento obtido, um wiki ou ferramenta de colaboração similar será lançado para apoiar este esforço.

Resumo

O Architectural Body of Knowledge (ArcBOK) é uma grande peça de trabalho e exige forte apoio da comunidade para a sua construção e adoção. A profissão de arquitetura de TI deve compor esse trabalho, cedo ou tarde, para elevar o nível de qualidade. Quando for a hora certa, todas as peças do ArcBOK serão agrupadas, com pouco esforço.

Referências

“Just what is a competency?” Scott B. Parry, material de treinamento, 1998.

Sobre o autor

Miha Kralj é arquiteto do Industry Solutions Group, parte da organização Microsoft Enterprise Services. O seu tempo de serviço em consultoria começou na Europa e estendeu-se até o Pacífico Sul, onde trabalhou como arquiteto de soluções e consultor de estratégia corporativa. Ele tem antecedentes em infra-estrutura e certificação como arquiteto MCA. Use o endereço miha.kralj@microsoft.com para enviar as suas mensagens sobre o ArcBOK para Miha.

If you enjoyed this post Subscribe to our feed