Já observamos que não existe uma definição única e correta do que é arquitetura corporativa. Várias empresas de consultoria, associações industriais e associações profissionais utilizam conceitos e metodologias ligeiramente diferentes para descrever este conceito. Além disso, esses conceitos e técnicas estão em constante estado de fluxo, portanto, tentar descrever com precisão o que é a arquitetura corporativa de uma forma que reflita o pensamento atual é “atirar em um alvo em movimento”.

De modo geral, ao desenvolver e utilizar a arquitetura corporativa, é claro que é aconselhável aderir a qualquer metodologia que garanta a unidade nas abordagens e nos conjuntos apropriados de ferramentas para descrever a arquitetura. Veremos brevemente as técnicas mais conhecidas em "Técnicas para descrição de arquiteturas. Modelos de Zachman e Gartner, métodos do META Group e TOGAF" e "NASCIO. Modelos "4+1" e SAM. Métodos da Microsoft e outros. Escolhendo o método “ótimo””. Aqui detalhamos nossa compreensão geral do conceito de “arquitetura empresarial”.

A arquitetura empresarial é uma ferramenta dinâmica e poderosa que auxilia as organizações no processo de compreensão de sua própria estrutura e da forma como desempenham seu trabalho e funções. Ele fornece um “mapa” da empresa e um “plano de rota” para mudanças nas áreas de negócios e de tecnologia.

Normalmente, a arquitetura empresarial assume a forma de um conjunto bastante amplo de modelos que descrevem a estrutura e as funções da empresa. Uma importante área de utilização desses modelos é sistematizar o processo de planejamento da tecnologia da informação e proporcionar melhores condições para o processo tomando uma decisão.

Os modelos individuais de arquitetura empresarial são organizados logicamente para que, juntos, forneçam nível de detalhe informações sobre a empresa - suas metas e objetivos, programas corporativos em andamento e estrutura organizacional, sistemas e dados, tecnologias utilizadas e todas as outras áreas de interesse.

Esta é uma definição bastante enfadonha e seca de uma ferramenta que, de facto, pode ter um enorme impacto na resolução de problemas complexos e fornecer uma nova perspectiva sobre as situações complexas e controversas que são constantemente encontradas no trabalho de qualquer organização. A arquitetura corporativa não é fácil de criar. Por outro lado, não se deve exagerar as dificuldades associadas a isto. O resultado final é que, uma vez desenvolvida, a arquitetura empresarial pode proporcionar benefícios significativos.

A arquitetura corporativa é mais um processo do que uma entidade estática. Não diremos que criá-lo é um passeio fácil e divertido. Mesmo assim, pode ser uma atividade atraente e, em certo sentido, fascinante. Arquitetura empresarial não é um assunto simples, mas a seguir tentaremos torná-lo menos “intimidador e desanimador”. Os métodos de descrição da arquitetura empresarial já existentes hoje permitem organizar o processo correspondente na presença de uma quantidade mínima de informações iniciais de forma intuitiva e natural. Ao mesmo tempo, a completude da descrição da arquitetura pode ser aumentada gradualmente, à medida que cresce a compreensão do objeto da descrição da arquitetura – a estrutura e funções da empresa, bem como as tecnologias de informação de suporte.

Ao projetar uma arquitetura corporativa, há muitas dimensões e relacionamentos entre elas que precisam ser levadas em consideração. Portanto, não é coincidência que muitas das técnicas de descrição da arquitetura, que consideraremos a seguir, tenham suas raízes em uma disciplina como a análise de sistemas. De modo geral, o desenvolvimento de arquitetura empresarial não é um processo técnico associado exclusivamente à tecnologia da informação. É claro que para desenvolvê-lo, via de regra, são utilizadas ferramentas tecnológicas adequadas, mas na maioria das vezes são ferramentas que permitem criar diagramas e textos, ou seja, pacotes de software familiares à maioria das pessoas. A utilização de ferramentas tão simples, baseadas em técnicas adequadas, permite, no entanto, recolher informações básicas sobre as atividades da organização, relacionar vários factos e tirar conclusões que simplificam e esclarecem o complexo processo de tomada de decisão que se repete diariamente nos negócios. . Mais importante é o componente criativo deste processo, que será discutido nas aulas 10-12.

Uma boa arquitetura empresarial fornece uma análise equilibrada dos fatos sobre a organização e fornece à administração maneiras de compreender suas organizações e seu funcionamento, ajuda-os a formular novas estratégias e fornece orientação no processo de planejamento de desenvolvimento para garantir que as organizações atendam às condições e condições em constante mudança. prioridades. Estamos, naturalmente, a falar de horizontes de planeamento a médio e longo prazo, tanto do ponto de vista empresarial como tecnológico. Uma boa arquitetura empresarial proporciona capacidade de resposta e flexibilidade, o que se reflete nas formas organizacionais, processos, sistemas, informações e portfólio de aplicações associados.

Os usuários da arquitetura corporativa incluem um público bastante grande de especialistas e gerentes:

• profissionais de sistemas de informação envolvidos em projetos corporativos relevantes para criar aplicações críticas para a empresa;
• arquitetos de sistemas, responsáveis ​​pela criação da arquitetura de sistemas de informação individuais;
• analistas de negócios que lideram o processo de concepção de estruturas organizacionais e processos de negócios;
• gestores interessados ​​em uma análise sistemática e estruturada dos problemas e oportunidades que se abrem para o negócio.

Se você observar os objetivos perseguidos por uma variedade de abordagens para descrever a arquitetura corporativa, poderá encontrar muito em comum em métodos corretos e bem-sucedidos:

• utilização para análise de múltiplos pontos de vista sobre o objeto de estudo (a empresa e seus sistemas de informação) a fim de “dividir e conquistar” no processo de lidar com a complexidade objetiva do mundo real. É importante compreender que nenhum ponto de vista único é suficiente para compreender o todo;
• Para apoiar o processo de síntese, todos os modelos incluídos na arquitetura são associados a outros modelos. São decomposições mais detalhadas ou representações relacionadas. Esta riqueza de relações entre modelos determina diretamente a qualidade da arquitetura.

Portanto, antes de continuarmos, aqui está outra definição de arquitetura empresarial, que é fornecida no site www.geao.org da Global Enterprise Architecture Organization (GEAO):

"A arquitetura empresarial descreve as maneiras pelas quais a visão geral de uma organização se reflete na estrutura e na dinâmica da empresa. Em vários níveis de abstração, ela fornece um conjunto unificado de modelos, princípios, diretrizes e políticas que são usados ​​para criar, desenvolver e garantir a conformidade dos sistemas em escala e contexto das atividades de toda a empresa como um todo."

Observe que o termo “sistema” aqui não se refere necessariamente a um sistema de computador – também pode se referir a estruturas organizacionais, sistemas de gestão, etc. Mas esta definição em si é bastante abstrata, por isso tentaremos dar-lhe um grau crescente de detalhe à medida que a apresentamos.

No texto a seguir utilizaremos informações de diversas fontes e tentaremos compilá-las no âmbito de algum conceito integrado de arquitetura empresarial, que inclua os principais elementos da maioria das técnicas. Em particular, seguiremos as recomendações.

Já observamos que a força motriz por trás da arquitetura empresarial é uma visão holística que ultrapassa as fronteiras organizacionais. Mostrado na Fig. 4.1 o diagrama proposto pelo GEAO ilustra os diferentes níveis de abstração associados à descrição do empreendimento. Observe que dentro de uma organização existe apenas uma arquitetura corporativa, mas no nível de sistemas individuais pode haver um grande número de arquiteturas de soluções (arquitetura de soluções). A arquitetura corporativa abrange os aspectos de negócios e de TI, bem como os processos de desenvolvimento, evolução da arquitetura e estruturas de governança que permitem a transição do estado atual da arquitetura para o estado futuro desejado.

1. Descrição arquitetônica do empreendimento: como tornar visível a organização do trabalho

A arquitetura corporativa é como ela é organizada. Como está organizado (arquitetura) - é quem está trabalhando no quê (quem faz o quê responsável) e quem precisa desse trabalho. Uma empresa é sempre organizada de alguma forma, boa ou ruim. A organização (arquitetura) de um empreendimento é invisível (é um “objeto lógico”), mas pode ser feita uma descrição arquitetônica completamente visível. Se houver uma descrição arquitetônica, então ela poderá ser usada para discutir a organização do empreendimento por todas as partes interessadas nesta organização (incluindo pessoas competentes em questões de organização) - e então há uma chance de que a organização possa ser melhorada. Se não houver nenhuma descrição arquitetônica documentada em algum suporte de informação alienado da cabeça, então todos terão alguma descrição (não pergunte qual) em alguma forma (não pergunte qual) em sua própria cabeça, e mesmo durante uma conversa esta descrição pode mudar três ou quatro vezes para uma pessoa. Ao discutir a organização do trabalho em uma empresa, é garantido que todos tenham ideias diferentes sobre os acordos, e o resultado do trabalho sob tais acordos é descrito na fábula de Krylov sobre o cisne, o lagostim e o lúcio. Mesmo que concordássemos com uma “estrutura organizacional” (a única coisa que normalmente é documentada durante essas conversas), esta é apenas uma pequena parte do que seria correto concordar.

Uma descrição arquitetônica consiste em uma série de diagramas pelos quais as pessoas movem os dedos para compreender a estrutura da organização e então chegar a um acordo sobre o que precisa ser mudado na organização. Uma descrição arquitetônica é, antes de tudo, uma ferramenta para concluir acordos entre pessoas importantes (partes interessadas - partes interessadas) sobre aspectos importantes da organização do trabalho que afetam interesses essas partes interessadas. Não há necessidade de confundir regulamentos organizacionais (que contêm importantes e não muito importantes, e muitas palavras em geral) com uma descrição arquitetônica, que contém apenas o mais importante (coisas que se você mudar, então você precisará mudar muitas outras coisas também) ), mas expresso da forma mais formal possível para evitar erros.

Uma linguagem especial, ArchiMate, é usada para descrever a arquitetura corporativa. Essa linguagem permite anotar o que há de mais importante na organização de um empreendimento – e ignorar os pequenos detalhes.

Façamos imediatamente uma ressalva que no Archimete só podemos descrever a organização do trabalho para o plâncton de escritório. Nenhum objeto de produção material real pode ser descrito no Architem; apenas informações sobre esses objetos são descritas. Nada de ferver batatas, nada de transferir porcos de máquina para máquina - única e exclusivamente informação sobre tudo isto. O Archimate é ideal para bancos e companhias de seguros, sedes (de onde não são visíveis oficinas reais), escritórios de design (onde as vigas pesadas estão apenas em modelos de computador e impressões em papel) e até sedes de construção (onde estão envolvidos na emissão de instruções e na contabilidade de o que foi feito, mas eles próprios não fazem nada com as mãos). Mas aquelas partes do empreendimento que não levam em consideração o aperto das porcas, mas na verdade apertam as porcas enferrujadas após recebê-las do armazém, não podem ser descritas pelo Archimate. Mas, por favor, descreva a contabilidade do armazém ou o projeto e a contabilidade do trabalho.

Arquiteto é aquele que apresenta uma arquitetura que atinge seus objetivos e que satisfará todas as partes interessadas, todos os stakeholders. Ele cria essa arquitetura, descreve-a na forma de diagramas Archimate e a coordena com várias pessoas importantes. O próprio momento de descrever a arquitetura de Archimete não é importante. Aqueles que simplesmente escrevem em Archimeite (espanhol, suaíli) sob ditado não podem ser chamados de arquitetos, são apenas escribas (escribas). Ok, arquiescribas (arquiscribas). Os arquitetos são aqueles que descobrem o que escrever sobre a organização, e não como expressá-lo no Architem com ícones astutos.

Para muitas pessoas nomeadas como arquitetos (especialmente para aqueles que vieram “de programadores” ou “de administradores de sistema”), acaba sendo uma surpresa completa que a transição inevitável da representação dos resultados de várias entrevistas no Archimet como uma “descrição arquitetônica como está” até escrever uma “descrição arquitetônica a ser” e imediatamente após uma comunicação estreita com a administração sobre a transformação dos diagramas Archimate recém-criados na realidade organizacional da empresa. Um arquimate não o ajudará em seus negócios mais do que um corretor ortográfico, e a capacidade de lidar com estilos do Word o ajudará a ganhar o Prêmio Nobel de Literatura.

Você foi avisado.

2. Atividades, software, hardware

A Archimate considera que o mais importante num empreendimento é a presença de três níveis de trabalho, em cada um dos quais o elemento humano diminui: Atividades, "Programas" E "glândula". Atividades sem “software” são arcaicas e inúteis, “software” sem “hardware” está morto. Hardware sem programas em execução é hardware inútil, e programas sem usá-los em atividades humanas também não têm utilidade para ninguém. Assim, a arquitetura empresarial deve representar todos os três níveis de trabalho em sua inter-relação.

Cada nível tem seu próprio executores de trabalho, e o seu objetos funciona Na verdade, o trabalho consiste no fato de os intérpretes mudarem de alguma forma os objetos de trabalho. Os executores e objetos de trabalho são geralmente representados por substantivos, trabalhos - por verbos e substantivos verbais. É importante que os próprios objetos de trabalho não saibam fazer nada, são passivos. Mas os performers são ativos, são eles que trabalham nos objetos. “Alguém” (o executor do trabalho) está fazendo algo (o trabalho) com alguma coisa (o objeto do trabalho).

O nível de atividade é significativo. As pessoas por trás das informações veem os objetos do mundo circundante que essas informações retratam. Eles olham a previsão do tempo e veem o tempo de amanhã (não a descrição do tempo que estão vendo), olham um relatório de construção e veem o número real de andares (não o relatório real que estão vendo), olham para o lucro e relatório de perdas e veem esse mesmo lucro (sem prestar atenção se esse relatório está na tela ou no papel). As pessoas têm interesses e objetivos, podem ser responsáveis ​​(devem prometer cumprir algumas instruções para outras pessoas), têm autoridade (podem dar instruções a outras pessoas para realizarem o trabalho). A atividade proposital que satisfaz os interesses e objetivos de algumas partes interessadas humanas existe apenas neste nível.

O nível “software” é o processamento das informações contidas nos dados. A partir de alguns dados, os programas criam outros dados que diferem tanto no formato quanto no conteúdo. Ninguém promete nada a ninguém (os programas não podem prometer, só as pessoas nas suas atividades podem fazer isso) e não dá instruções (só as pessoas podem dar instruções). Nesse nível, sabe-se o que os dados significam no mundo real: afinal, é perigoso somar quilômetros a quilogramas. A principal tarefa do nível do programa é garantir que os dados processados ​​da maneira certa, no momento certo, cheguem aos responsáveis ​​certos, desempenhando alguma função na empresa.

O nível de hardware é um mundo sem alma no qual não há mais processamento de dados, mas apenas armazenamento e encaminhamento de dados. É claro que também existem programas (software de sistema) no nível do hardware, mas são de um tipo diferente - ninguém aqui sabe o que esses dados significam no mundo real. A tarefa do hardware, como de qualquer equipamento, é armazenar bytes que são endereçados de alguma forma, sem entrar em seu significado, enviar esses bytes a pedido de programas aplicativos, e também armazenar os próprios programas e permitir sua execução.

3. Elementos e relacionamentos
Uma empresa no Architem é descrita na forma de elementos (representados por ícones diferentes) que estão em algum tipo de relacionamento entre si (diferentes relacionamentos são representados na forma de linhas de conexão desenhadas de forma diferente entre os ícones dos elementos). Archimate é valioso porque oferece tudo para descrever o trabalho de uma empresa
-- 16 tipos de elementos para nível de atividade,
-- 7 tipos de elementos para o nível do programa,
-- 9 tipos de elementos por nível de equipamento,
-- 11 tipos de relacionamentos em que os elementos podem estar entre si, e mostrando as bifurcações (do tipo “e” e “ou”) para esses relacionamentos.

Se você pretende mudar de alguma forma uma empresa na vida real (caso contrário, por que começaria a desenhar diagramas Archimate refletindo sua arquitetura?), então para isso você também pode usar:
-- 7 tipos de elementos para definição de metas e justificativa de mudanças na organização
-- 4 tipos de elementos para projetar a transição para uma nova arquitetura

Há também um comentário e uma relação entre o comentário e alguns outros elementos, bem como um quadro para agrupar os elementos.

Esse é todo o Arquimata, 54 conceitos. Mas não se deixe enganar pela sua simplicidade. O Grande e o Poderoso também tem apenas 33 letras.

4. Não é você que é necessário, é o seu serviço que é necessário.

É importante que nenhum trabalho seja feito na empresa sem motivo, todos eles são necessários para alguém por algum motivo. Serviços são obras úteis para alguns outros intérpretes (mais precisamente, úteis para o trabalho desses intérpretes), visíveis “de fora” de alguma parte do empreendimento. Para os consumidores de serviços, não importa a forma como se organiza a execução deste trabalho: quem trabalha com o quê para expor o serviço ao consumo externo. Para eles, só importa por quais canais (e-mail, janela com uma garota, telefonema, etc. essa atividade foi realizada) e interfaces (se for “software”) esses serviços serão prestados.

Existem serviços de hardware fornecidos para software e serviços de software fornecidos para atividades. Os três níveis da empresa são unidos por esses serviços - de cada nível, apenas os serviços dos outros níveis são visíveis. Você simplesmente não pode mostrar nada além do serviço: são os serviços que permitem abstrair dos detalhes da estrutura empresarial, são os serviços que implementam uma abordagem sistemática e dividem todo o sistema em partes. As arquiteturas modernas são orientadas a serviços.

Essas partes do sistema são funcionais (o objetivo do serviço é executar alguma função em relação ao sistema que o utiliza; serviços são a aparência do trabalho “de fora” do subsistema) e modulares (ou seja, intercambiáveis ​​se o função é preservada). Assim, você pode substituir todo o hardware e o software não notará isso se os serviços de hardware permanecerem os mesmos. O mesmo acontece com o “software”: substitua tudo, mas se os serviços de software permanecerem os mesmos, a atividade não notará isso - todas as mesmas funções de software estarão disponíveis na atividade. Em princípio, isto também se aplica à própria empresa: se os serviços organizacionais que a empresa fornece ao mundo exterior (e a combinação de tais serviços organizacionais e o acordo de nível de serviço que os vincula é denominado produto de serviço organizacional) será realizada por uma atividade organizada completamente diferente, que usa “software” completamente diferente, que por sua vez é executado em hardware completamente diferente, então os clientes não perceberão isso. É disso que os arquitetos empresariais tiram vantagem: eles descrevem a empresa e, em seguida, alteram lentamente as atividades, o software e o hardware, apoiando a entrega de serviços críticos. Isto é chamado de abordagem orientada a serviços: dividir (diferentes níveis de trabalho por serviços) e conquistar. Empresa colado serviços, e para o arquiteto são esses serviços dividido.

A vontade de dividir e conquistar entre os arquitetos é tão grande que eles compartilham serviços e trabalhos até do mesmo nível. Por exemplo, é fácil imaginar programas que prestam serviços não a pessoas, mas a outros programas. Ou “hardware”, cujo significado é servir (prestar serviço, ou seja, “trabalhar para”) outros equipamentos.

Fornecer externamente trabalho visível – serviço precisa ser feito de fora invisível interno trabalho – alterações nos objetos de trabalho pelos executores do trabalho. A presença desta fronteira entre consideração interna e externa (uma “caixa preta” com executores, trabalhos e objetos internos invisíveis versus uma “caixa transparente” quando eles são claramente visíveis) é a presença de uma fronteira sistemas. Modelos arquicompanheiros sistemas, separando partes/níveis da empresa com serviços (embora nenhuma palavra seja explicitamente dita sobre “sistemas” na especificação ArchiMate, apenas dicas).

Aspectos teóricos da arquitetura empresarial. Elementos-chave da arquitetura corporativa. A arquitetura empresarial é a representação mais geral e abrangente de uma empresa como uma entidade econômica com objetivos de curto e longo prazo para a condução de suas atividades principais determinadas pela missão no mercado regional e global e pela estratégia de desenvolvimento, recursos externos e internos necessários cumprir a missão e atingir os seus objetivos, bem como as regras estabelecidas para a condução dos seus negócios principais. Teórico...

Compartilhe seu trabalho nas redes sociais

Se este trabalho não combina com você, no final da página há uma lista de trabalhos semelhantes. Você também pode usar o botão de pesquisa

Introdução

1.3. Camadas na arquitetura

Bibliografia

Introdução

Recentemente, o ambiente externo tem mudado muito rapidamente, pelo que os requisitos de adaptabilidade das empresas aumentam de ano para ano. Vários estudos analíticos têm demonstrado que a maioria das empresas internacionais não tem tempo para se adaptar às mudanças em curso, embora a tendência nesta área seja negativa. O principal problema para garantir a adaptabilidade das empresas é a coordenação e o controlo das mudanças que devem ser realizadas no seu âmbito. Quando os objetivos mudam, a estratégia muda, o que por sua vez leva a mudanças nos processos de negócios e nas prioridades dos projetos, bem como na estrutura organizacional. Tudo isto afecta indirectamente o nível de conhecimento e autoridade na empresa e, como consequência, os fluxos de informação, o que por sua vez exigirá mudanças nos sistemas de informação existentes.

A arquitetura empresarial é a representação mais geral e abrangente de uma empresa como uma entidade econômica que tem objetivos de curto e longo prazo para a condução de suas atividades principais, definidas por uma missão no mercado regional e global, e uma estratégia de desenvolvimento, externa e os recursos internos necessários ao cumprimento da missão e à consecução dos seus objetivos, bem como as regras estabelecidas para a condução da atividade principal do negócio.

1. Aspectos teóricos da arquitetura empresarial

1.1. Elementos-chave da arquitetura corporativa

O gerenciamento da Arquitetura Corporativa fornece uma estrutura para sincronizar objetos em uma empresa, ao mesmo tempo que permite que eles mudem continuamente para fins de otimização de negócios.

O controle das mudanças e a consistência de todos os elementos da arquitetura contribuem para aumentar a adaptabilidade do empreendimento, que atualmente é um fator importante na luta competitiva. Ao mesmo tempo, os sistemas de informação podem muitas vezes tornar-se um factor de atraso nas mudanças, o que significa que deve ser dada especial atenção à sincronização de elementos da arquitectura empresarial e da arquitectura de TI. Para gerenciar a arquitetura corporativa, é utilizado um ciclo padrão, composto pelas seguintes etapas: descrição da arquitetura existente, desenho de seu estado alvo, formação de um plano de transição da arquitetura existente para a arquitetura alvo. O primeiro passo é determinar quais elementos arquitetônicos e em que medida precisam ser descritos.

Por um lado, o detalhe da descrição criada significa uma elaboração mais profunda e, por outro lado, existem custos de mão-de-obra desnecessários tanto para criar a própria descrição como para mantê-la atualizada. Como diz o ditado, “o melhor é inimigo do bom” e, portanto, descrever os elementos da arquitetura com muitos detalhes não ajuda. Nesta fase, é importante identificar os elementos-chave da arquitetura empresarial entre todos os possíveis e focar na sua descrição e análise.

A prática mostra que o primeiro desencontro na arquitetura empresarial, via de regra, surge entre objetivos, processos de negócios e estrutura organizacional. Em muitos casos, múltiplos objetivos não são apoiados pelos recursos e processos de negócios necessários. Consequentemente, já no processo de análise da arquitetura é possível determinar um plano de trabalho para otimizar as atividades do empreendimento nesta área. Se analisarmos as tecnologias de informação de uma empresa, elas também são muitas vezes inconsistentes com os seus processos de negócios existentes e, mais ainda, com os processos de negócios alvo. Também aqui existe um vasto campo para otimizar atividades.

Além da inconsistência entre os elementos-chave de uma arquitetura empresarial, muitas vezes surgem problemas dentro de um único elemento, principalmente duplicação, bem como lacunas organizacionais e de informação, etc. Contudo, não é apenas o número de mudanças e a exigência de adaptabilidade empresarial que tem causado tanta atenção às questões de gestão arquitetônica. A complexidade dos sistemas tecnológicos está a aumentar, o que significa que a sua fiabilidade está a diminuir. Neste caso, a formalização da arquitetura passa a ser a base para garantir os procedimentos de gestão dos riscos operacionais na empresa, pois se os seus principais elementos forem formalizados, a identificação dos riscos e a análise da eficácia dos procedimentos de controlo deixam de ser particularmente difíceis. Portanto, o gerenciamento da arquitetura é mais crítico em grandes empresas que utilizam tecnologias complexas que envolvem muitos riscos operacionais e tecnológicos.

Apesar da variedade de metodologias na área de gestão de arquitetura, na prática a maioria das empresas limita-se aos seguintes elementos: objetivos de negócio; estrutura organizacional; Indicadores Chave de Performance; processos de negócios; portfólio de projetos; documentação; Sistemas de informação; conhecimento da equipe. Este é o mínimo necessário que permite coordenar os elementos básicos da arquitetura entre si. No entanto, se os objectivos, os indicadores, a estrutura organizacional e os processos de negócio já estão de alguma forma interligados, então muitas vezes não existe tal relação entre processos e sistemas de informação. Neste sentido, uma das principais tarefas para muitas empresas é a transição dos modelos e regulamentos de arquitetura de negócios para a determinação dos requisitos de tecnologia da informação e a construção de uma arquitetura de TI que lhes corresponda.

A lacuna de informação é causada pela transferência de informações de analistas de negócios para especialistas de TI e, neste ponto, a formalização de elementos arquitetônicos como requisitos, funções de TI, transações, estrutura de dados juntamente com processos de negócios nos permite reduzir essa lacuna. Nesta fase, é importante utilizar corretamente as recomendações contidas nas metodologias de arquitetura empresarial, como o TOGAF.

Assim, para eliminar a “lacuna de informação” é necessário ampliar a descrição da arquitetura empresarial existente e, em particular, da arquitetura de negócios na direção da arquitetura de TI, levando em consideração a unidade da metodologia de descrição utilizada tanto para analistas de negócios e especialistas em TI. Com esta transição da descrição da arquitetura de processos de negócios para a descrição da arquitetura de TI, é importante formalizar vários elementos adicionais da arquitetura. Em primeiro lugar, é necessário descrever a arquitetura de dados, que é construída com base nas informações e documentos que são utilizados nos processos de negócios, após a qual a arquitetura da aplicação e a infraestrutura de TI devem ser formadas.

Para construir uma arquitetura de dados é necessário identificar as principais entidades e agregar a elas todos os “quanta” de informações coletadas a partir da descrição dos processos de negócio. A prática mostra que para resolver este problema, deve-se utilizar uma metodologia padrão para descrição de dados - o Modelo Entidade-Relacionamento (ERM), dentro do qual todas as informações podem ser claramente estruturadas. O próximo estágio na formalização da arquitetura de TI é a transição da arquitetura de processos de negócios e arquitetura de dados para a criação da arquitetura de aplicativos. Nesta fase é importante determinar as classes de sistemas de informação necessárias à automação, bem como os módulos para cada sistema de informação. A base para projetar a arquitetura de aplicativos e sua sincronização com a arquitetura de negócios é um mapa de processos (uma representação generalizada de todos os processos de negócios de uma empresa). No modelo de arquitetura de aplicação estão localizados os principais tipos de sistemas de informação, que são detalhados no modelo de módulos de sistema de informação e posteriormente no nível de transações de formulários de tela individuais.

Outro elemento-chave da arquitetura do ponto de vista do relacionamento entre a arquitetura de negócios e a arquitetura de TI são os requisitos do sistema de informação. Na verdade, os modelos de requisitos são a funcionalidade alvo de uma solução de TI, que é estruturada por processos de negócios ou departamentos. Com base nestes requisitos e nos modelos de processos de negócio existentes, bem como tendo em conta os modelos de dados construídos, é projetada uma nova arquitetura de aplicação (alvo). Ao mesmo tempo, além das metodologias de gerenciamento de arquitetura empresarial, os padrões da indústria também devem ser utilizados para resolver os problemas atribuídos. Por exemplo, no caso das empresas de telecomunicações, podem ser utilizados como base os materiais da metodologia New Generation Operation System and Software (NGOSS), que foi criada em 2001 pelo TeleManagement Forum e contém os seguintes modelos:

1. modelo de operações de empresas de telecomunicações eTOM (Enhanced Telecom Operations Map eTOM);
2. modelo de informação telecomunicações empreendimentos (SID do modelo de dados e informações compartilhadas da estrutura de informações para toda a empresa);
3. estrutura de aplicação da empresa de telecomunicações ( Quadro de Aplicações Mapa de Aplicações de Telecom TAM).

1.2. Modelos e ferramentas de arquitetura de aplicativos

A arquitetura de aplicativos cobre uma área ampla que começa com a identificação de quais sistemas de aplicativos uma empresa precisa para executar processos de negócios e inclui aspectos como design, desenvolvimento (ou aquisição) e integração de sistemas de aplicativos. Na arquitetura aplicacional, via de regra, existem duas áreas principais: a formação e gerenciamento de um portfólio de sistemas aplicativos corporativos e o desenvolvimento de sistemas aplicativos.

Um portfólio de sistemas de aplicativos corporativos é um esboço amplo de como as necessidades dos processos de negócios de uma empresa são suportadas por um conjunto de sistemas de aplicativos. Determina a área de responsabilidade e prioridade de cada aplicação, bem como a forma como a funcionalidade necessária será alcançada: através do desenvolvimento do sistema, através da compra de aplicações prontas, aluguer de uma aplicação, ou integração e utilização das capacidades de aplicativos existentes. O portfólio de sistemas aplicativos descreve aplicativos projetados para executar funções organizacionais, bem como trocar informações entre clientes, fornecedores e parceiros da empresa. Ao mesmo tempo, também são descritos os canais de possível interação do usuário com as aplicações: navegadores web, interface gráfica do cliente “grosso”, dispositivos móveis, etc.

O campo de desenvolvimento de sistemas aplicativos descreve as tecnologias que são utilizadas para construir sistemas, dividi-los em componentes funcionais, criar interfaces, personalizá-los, bem como templates, guias, etc. Esta área também define a organização do processo de desenvolvimento, as ferramentas utilizadas para isso, o ciclo de desenvolvimento do sistema adotado pela empresa, o controle de versões, o gerenciamento de configuração, o middleware utilizado e as ferramentas de design. O principal objetivo da área é reduzir o custo de criação de sistemas aplicativos e melhorar sua qualidade, fornecendo abordagens unificadas de desenvolvimento. Isto, por sua vez, leva a uma redução no número total de diferentes cenários técnicos associados ao projeto de arquitetura, suporte operacional, arquitetura de integração de sistemas e treinamento de pessoal. É aqui que o envolvimento dos arquitetos de sistemas aplicativos é necessário. É claro que faz sentido destacar esta área apenas para as organizações que desenvolvem ou refinam aplicações de forma independente, em oposição ao modelo de terceirização. Levando em consideração esses comentários e a identificação de duas áreas na arquitetura de aplicações - portfólio de aplicações e desenvolvimento - podemos dizer que a introdução de um novo sistema em uma empresa, como o faturamento, faz parte do gerenciamento do portfólio de aplicações corporativas. Ao mesmo tempo, as tecnologias e princípios que são utilizados na concepção do sistema, bem como na sua implementação e manutenção, pertencem à área do desenvolvimento. Futuramente falaremos sobre arquitetura de aplicações, ou seja, antes de tudo, o portfólio de sistemas aplicativos. Idealmente, o portfólio de aplicativos de uma empresa deveria incluir o conjunto atual de aplicativos e algum modelo para entender quais sistemas de aplicativos serão necessários no futuro para atender às novas necessidades empresariais e organizacionais. O portfólio de aplicações também deve definir as relações entre os componentes funcionais e tecnológicos (operacionais) do ambiente de tecnologia da informação empresarial, ou seja, explicar por que certas tecnologias foram incluídas na infraestrutura para a construção de um portfólio de sistemas de aplicativos empresariais. Este aspecto é importante porque os investimentos em infra-estruturas constituem uma parte significativa das despesas de capital e requerem uma justificação séria. Finalmente, o portfólio de aplicações deve fornecer informações sobre quanto custará em termos de custos financeiros e quanto tempo a organização levará para migrar para o estado futuro desejado usando esses sistemas de aplicações. Assim, um portfólio de sistemas aplicativos é um conjunto integrado de IP empresarial que atende às necessidades de negócios e inclui os seguintes aspectos:

1. Portfólio existente de sistemas aplicativos. Este é um catálogo de aplicativos disponíveis e um componente que reflete seus relacionamentos com os processos de negócios que eles suportam, interfaces com outros sistemas, informações usadas e necessárias e modelos de infraestrutura usados. Para ser uma ferramenta verdadeiramente útil, deve também ajudar a identificar os elementos do portfólio que podem ser reutilizados e reutilizados em toda a empresa e incentivar essa reutilização.
2. Portfólio planejado de sistemas aplicativos. Representa a funcionalidade necessária para atingir o estado desejado do negócio e da arquitetura de informações corporativas.
3. Plano de migração. O processo de transição do portfólio atual para o futuro de sistemas aplicativos em projetos de TI. Os projetos também podem ser combinados em portfólios de projetos. O primeiro passo no planejamento de um portfólio de aplicações é avaliar o estado atual do portfólio e como ele atende às necessidades da organização do ponto de vista estratégico e tecnológico, ou seja, do ponto de vista dos objetivos, das estratégias de negócio e do ponto de vista da condição técnica e das estratégias de utilização da tecnologia na empresa. A conformidade com as estratégias de negócios é avaliada com base na contribuição dos sistemas aplicativos para a obtenção de resultados de negócios, conforme determinado pela arquitetura de negócios da empresa. A conformidade tecnológica é avaliada com base em uma análise de como os sistemas aplicativos cumprem os princípios e padrões tecnológicos adotados na arquitetura tecnológica empresarial. Existem diferentes maneiras de avaliar um portfólio e diferentes classificações de sistemas aplicativos empresariais. Um dos modelos possíveis para avaliar um portfólio de sistemas aplicativos é avaliá-los segundo dois critérios: valor do ponto de vista comercial e condição técnica. Uma avaliação de portfólio serve como ponto de partida para identificar áreas problemáticas e oportunidades para melhor atender às necessidades de negócios e decidir se deve investir em novos sistemas ou atualizar os existentes. Como resultado desta avaliação, os sistemas de aplicação enquadram-se numa de quatro categorias possíveis:
   1. os sistemas correm o risco de descomissionamento (substituição) ou consolidação;
   2. sistemas que requerem reavaliação ou reposicionamento;
   3. sistemas que requerem atualização;
   4. sistemas que requerem manutenção e desenvolvimento.

A condição técnica é avaliada com base em uma série de características, incluindo a precisão e exatidão dos dados, arquitetura, estrutura do código do programa, velocidade de resposta, tempo de inatividade, nível de suporte técnico, capacidade de obtenção de relatórios, etc. O valor comercial de um sistema refere-se à capacidade do sistema de suportar as funções essenciais de uma empresa, departamento ou processo. A próxima edição apresentará as características de cada categoria de sistemas de acordo com esta classificação.

1.3. Camadas na arquitetura

O conceito de camadas é um dos modelos comumente usados ​​por desenvolvedores de software para dividir sistemas complexos em partes mais simples. As arquiteturas de sistemas de computador, por exemplo, incluem camadas de código de linguagem de programação, funções do sistema operacional, drivers de dispositivos, conjuntos de instruções de CPU e lógica interna de chips. Num ambiente de rede, o protocolo FTP opera sobre o protocolo TCP, que, por sua vez, opera “sobre” o protocolo IP, localizado “acima” do protocolo Ethernet. Então, consideremos os principais motivos de interesse nas camadas de arquitetura de sistemas de software:

As camadas são fáceis de formalizar. Intuitivamente, se um sistema for dividido em várias camadas, então a camada n é um componente ou conjunto de componentes do sistema que usa apenas os componentes da camada n-1 e só pode ser usado pelos componentes da camada n+1.

As camadas possuem semântica simples e clara. Normalmente, em uma arquitetura de sistema de software, as camadas representam camadas de abstração. A camada n+1 utiliza a camada n, portanto a abstração dos conceitos da camada n+1 não é pelo menos inferior à da camada n e, idealmente, se a arquitetura do sistema for eficaz, seu nível de abstração deverá ser maior. Assim, a camada n oculta (encapsula) a lógica de trabalhar com conceitos definidos nesta camada, permitindo assim que a camada n+1 implemente o trabalho com conceitos mais complexos e organize lógicas mais complexas utilizando os meios expressivos da camada subjacente.

As camadas são generalizadas. Na verdade, um número bastante grande de sistemas de software, especialmente quando se trata de sistemas de software em escala empresarial, possui uma estrutura em camadas. Claro, muitas vezes há uma situação em que a estrita estrutura camada por camada do sistema é violada; via de regra, isso é uma consequência da erosão da arquitetura (defeito arquitetônico) e sua eliminação na maioria dos casos pode trazer benefícios tangíveis ( esses aspectos são discutidos abaixo).

Implementação alternativa. Você pode escolher uma implementação alternativa das camadas base; os componentes da camada superior são capazes de funcionar sem quaisquer alterações nas camadas subjacentes, desde que as interfaces sejam preservadas.

A dependência entre as camadas, ou seja, as interfaces fornecidas pelas camadas inferiores às superiores, pode ser minimizada. Esta minimização de interfaces permite aumentar a flexibilidade do sistema.

O esquema de camadas arquitetônicas também apresenta algumas desvantagens:

Mudanças em cascata. As camadas podem encapsular muita coisa com sucesso, mas não tudo: a modificação de uma camada às vezes envolve a necessidade de fazer alterações em cascata em outras camadas. Um exemplo clássico da área de aplicativos de software corporativo: um campo adicionado a uma tabela de banco de dados deve ser renderizado em uma GUI e deve encontrar um mapeamento correspondente em cada camada intermediária.

Diminuição da produtividade. A presença de camadas redundantes geralmente reduz o desempenho do sistema. À medida que você passa de uma camada para outra, os dados normalmente passam por transformações de uma representação para outra. Apesar disso, o encapsulamento de funções subjacentes muitas vezes pode trazer benefícios muito significativos. Por exemplo, otimizar a camada de transação geralmente resulta em melhor desempenho para todas as camadas acima dela.

Para fins de análise de sistemas, a arquitetura empresarial pode ser considerada em dois aspectos:

1. estático - de acordo com o estado do banco em algum momento fixo;
2. dinâmico - como um processo de transição (migração) de um banco do seu estado atual para algum estado desejado no futuro.

A arquitetura empresarial considerada de forma estática consiste nos seguintes elementos:

1. missão e estratégia, metas e objetivos estratégicos;
2. arquitetura de negócios;
3. arquitetura do sistema.

Vista em dinâmica, a arquitetura empresarial é um plano integral e logicamente conectado de ações e projetos coordenados necessários para transformar a arquitetura existente da organização em um estado definido como uma meta de longo prazo, com base nos projetos atuais e planejados. objetivos de negócios e processos de negócios organizações.

Assim, a arquitetura corporativa é geralmente descrita pelas seguintes seções sequencialmente dependentes:

1. missão e estratégia formuladas do banco, metas e objetivos estratégicos;
2. arquitetura de negócios no estado atual (como está) e planejado (como será),
3. arquitetura do sistema no estado atual (como está) e planejado (como será);
4. planos de atividades e projetos para a transição do estado atual para o planejado.

Assim, a arquitetura de sistema planejada é a arquitetura “futura” apenas em um determinado estágio de desenvolvimento empresarial.

Ao mesmo tempo, regressar ao nível estratégico da missão e das metas e objectivos estratégicos não significa a necessidade de rever a missão e a estratégia. Mas no final de cada ciclo é necessária uma análise da eficácia das atividades desenvolvidas e implementadas; se necessário, durante a segunda iteração, a arquitetura de negócios e a arquitetura do sistema são ajustadas e novos planos de migração são implementados. Em qualquer momento pode haver vários ciclos; cada um desses ciclos não afeta necessariamente toda a empresa como um todo; o ciclo pode afetar áreas individuais, questões empresariais individuais e pode ser registrado na forma de um projeto separado.

Com um plano de migração passo a passo, para registrar os resultados alcançados, é possível construir arquiteturas intermediárias (de migração) de uma ou mais. A missão, a estratégia e as metas de negócios determinam a direção do desenvolvimento da empresa e estabelecem metas e objetivos de longo prazo.

As seguintes camadas devem ser diferenciadas na arquitetura corporativa:

1. Recepção

Front-officecomo um sistema de contabilidade externo (emarquitetura de negócios corporativos- é uma coleçãoprocessos de negócios, procedimentos, documentos normativos (regulamentos), livros de referência, formulários impressos, unidades organizacionais e de pessoal que garantem a interação direta com o cliente por parte da empresa:

1. Recebimento e entrada para posterior processamento de documentos primários,
2. Imprimir e fornecer informações e documentos ao cliente,
3. Ligar para clientes e enviar mensagens informativas aos clientes,
4. Receber chamadas telefônicas, solicitações e fornecer informações.

Front-Office (Front Office) como um sistema de contabilidade externa (emarquitetura de sistema empresarialé um conjunto de sistemas de informação, incluindo bancos de dados e diretórios, voltados para a automaçãoprocessos de negóciosinteração com o cliente.

1. Escritorio do meio

Escritório intermediário em arquitetura de negócios - Trata-se de um conjunto de processos de negócio, procedimentos, documentos normativos (regulamentos), livros de referência, formulários impressos, unidades organizacionais e de pessoal que garantem a preparação e a tomada de decisões.

Exemplos de unidades de middle office:

Unidade de verificação do mutuário no serviço de segurança,

Divisão de Gestão de Risco.

Escritório intermediário em arquitetura do sistema -Trata-se de um conjunto de sistemas de informação, incluindo bases de dados e diretórios, que visa automatizar processos de negócio relacionados com a preparação e tomada de decisões.

Exemplos de sistemas de informação de middle office:

Sistema de contabilidade de posição,

Sistema de verificação de mutuários em agências de histórico de crédito,

Sistema para cálculo da pontuação de um pedido de empréstimo.

1. Back-office

Backoffice (backoffice) como um sistema de contabilidade interna (emarquitetura de negócios) as empresas são um conjunto de processos de negócios, procedimentos,documentos normativos (regulamentos), livros de referência, formulários impressos, unidades organizacionais e de pessoal que implementam a contabilidade diária (registro) de transações. Geralmente, registrar contabilidade é um diário de transações com contrapartes, não relacionado a contas contábeis, não é bidirecional.

Backoffice em arquitetura do sistemaAs empresas são um conjunto de sistemas de informação, incluindo bancos de dados e diretórios, que implementam a contabilização de transações em diário (registro).

1. Contabilidade

Contabilidade empresarial ( arquitetura de negócios) é um conjunto de processos de negócios, procedimentos, documentos normativos (regulamentos), livros de referência, formulários impressos, unidades organizacionais e de pessoal que implementam contabilidade e relatórios de acordo com RAP (Regulamentos de Contabilidade - padrões de contabilidade russos) e IFRS (Padrões Internacionais de relatórios financeiros ), mantendo o balanço da empresa.

1. Armazém de Dados (DWH)
2. Comunicando

Reportando a arquitetura de sistema - conjunto de sistemas de informação, incluindo bancos de dados e diretórios, que automatizam a construção de relatórios com base nos dados do repositório de informações.

Exemplos de sistemas de relatórios:

Sistema de relatórios de gestão,

Sistema de relatórios analíticos,

Sistema de indicadores-chave de desempenho das divisões empresariais,

Um sistema para gerar indicadores para calcular uma pontuação para um pedido de empréstimo.

Bibliografia

1. Vasiliev R. B., Kalyanov G. N., Levochkin G. A., Lukinova O. V. Gestão estratégica de sistemas de informação; Universidade de Tecnologias da Informação da Internet, Binom. Laboratório de Conhecimento - Moscou, 2013. - 512 c.
2. Gritsenko Yu.B. Arquitetura empresarial: Textbook / Gritsenko Yu.B.2011.256 p.
3. Danilin A.V., Slyusarenko A.I., curso de treinamento Arquitetura Empresarial [recurso eletrônico] - Modo de acesso:http://www.intuit.ru/department/itmngt/entarc/
4. Kalyanov G.N. Modelagem, análise, reorganização e automação de processos de negócios. Livro didático: M.: Finanças e Estatística, 2006.

PÁGINA 17

Outros trabalhos semelhantes que podem lhe interessar.vshm>
803.		Arquitetura hoteleira	36,04KB
	Aspectos arquitectónicos da construção e colocação de hotéis. O papel do interior e do design do hotel na oferta hoteleira. Introdução A especificidade dos hotéis reside na variedade de funções destes objetos. Condições de vida favoráveis ​​​​para os hoteleiros são garantidas pela criação de conforto tanto no próprio edifício do hotel como na área adjacente.
17390.		Arquitetura de Veliky Novgorod	324,25 KB
	O ponto de vista predominante é que a cidade velha é a chamada Gorodishche, localizada na margem direita do Volkhov, a dois quilômetros da cidade moderna. Para conhecer mais profundamente a arquitetura desta cidade, foi escolhido o tema da obra: Arquitetura de Novgorod dos séculos XI-XV. A técnica de tais trabalhos consistia em aplicar um desenho em folhas de cobre enegrecidas com um cortador e fundir fio de ouro em suas ranhuras. Pode ser considerado um dos mais antigos: o quadro onde está escrito é muito antigo em vários traços e caráter...
19556.		Verticalismo stalinista e arquitetura	24,72KB
	Para compreender as especificidades do próprio percurso soviético e a formação e conteúdo da arquitectura soviética, é necessário estudar as restrições e regulamentações que foram impostas pela organização nacional da actividade profissional à forma de pensar de determinados mestres. e por outro lado - planos para apartamentos em estilo do Império Estalinista contendo terraços, salas de estar para empregadas, etc.: Neoclassicismo neoclassicismo é um termo adotado na história da arte soviética para denotar diferentes orientações sociais e ideológicas...
17255.		Arquitetura do templo de Moscou	595,99KB
	O colorido vivo das paredes de tijolo da Igreja da Trindade, dissecadas por elegantes acabamentos decorativos em pedra branca esculpida e azulejos coloridos, o revestimento em ferro alemão branco, as cruzes douradas nas cúpulas de azulejos verdes, tudo em conjunto criava uma impressão irresistível. ..
13405.		Arquitetura do Antigo Reino Babilônico	528,04KB
	Seu centro era a cidade de Babilônia Babili, que significa Porta de Deus, cujos reis eram reis no segundo milênio. O apogeu do antigo reino da Babilônia ocorreu durante o reinado do sexto rei da 1ª dinastia babilônica, Hamurabi. Sob ele, a Babilônia deixou de ser uma pequena cidade e se tornou o maior centro econômico, político e cultural da Ásia Ocidental.
7046.		Arquitetura e estrutura do PC. Princípio de von Neumann	9,14 KB
	Um PC é um microcomputador universal relativamente barato, projetado para um usuário. Os PCs modernos são projetados com base no princípio da arquitetura aberta.
6695.		Arquitetura de banco de dados. Independência física e lógica	106,36KB
	Ele fornece as seguintes definições de banco de dados de banco de dados e SGBD: Banco de dados BnD é um sistema de bancos de dados de dados especialmente organizados de linguagem técnica de software, ferramentas organizacionais e metodológicas projetadas para garantir a acumulação centralizada e o uso coletivo multifuncional de dados. Um banco de dados é uma coleção nomeada de dados que reflete o estado dos objetos e seus relacionamentos na área de assunto em consideração. Sistema de gerenciamento de banco de dados SGBD é um conjunto de linguagens e...
18392.		Desenvolvimento de um complexo educacional e metodológico para a disciplina “Arquitetura de Computadores”	606,23 KB
	Então o círculo de usuários se expandiu principalmente devido aos cientistas que usaram computadores para realizar experimentos em máquinas. Um livro didático eletrônico é um produto de natureza educacional que só pode ser reproduzido por meio de ferramentas de informática, incluindo um computador, correspondente a um programa de treinamento aprovado ou a um programa desenvolvido pelo autor para o curso proposto e com características fundamentalmente novas em comparação com um livro regular livro didático. Um livro eletrônico pode ser destinado a. ..
9225.		ARQUITETURA E ELEMENTOS BASE DE REDES LOCAIS DE COMPUTADORES DE AERONAVES	150,96KB
	O advento do século XXI e do terceiro milénio coloca cada vez mais a questão: que caças proporcionarão superioridade aérea? A questão colocada tem uma resposta inequívoca - serão caças da próxima, 5ª geração, da era dos jatos da aviação. Traçar uma linha clara entre as gerações de aeronaves é difícil e nem sempre possível. E a própria mudança de gerações é um processo bastante lento.
21769.		Processadores Intel, arquitetura de processador, chipsets e suas características	95,27KB
	Unidade central de processamento (microprocessador, CPU) é uma parte do hardware do computador responsável por realizar operações aritméticas especificadas por programas e coordenar o funcionamento de todos os dispositivos do computador. O processador é um cristal semicondutor especialmente desenvolvido no qual os transistores estão localizados

Victor Galaktionov, 20/05/2002
Revista "IS Director", nº 05, 2002 // Editora de Sistemas Abertos (http://www.osp.ru/)

Nas condições modernas, é especialmente importante coordenar constante e corretamente os aspectos de TI da estrutura de uma empresa automatizada moderna com os aspectos de negócios atuais. Isto deve ser feito começando pela definição da arquitetura de negócios da empresa e pelo desenvolvimento de uma arquitetura de sistema (arquitetura de TI) consistente com ela. Neste artigo, o autor compartilha experiência prática no desenvolvimento de arquiteturas de sistemas para grandes bancos e dá conselhos específicos sobre como isso pode ser feito, inclusive para empresas de outros setores.

Sou geógrafo, não um viajante. Sinto muita falta dos viajantes. Afinal, não são os geógrafos que contam cidades, rios, montanhas, mares, oceanos e desertos. O geógrafo é uma pessoa muito importante, não tem tempo para passear. Ele não sai do escritório. Mas ele hospeda viajantes e registra suas histórias.

Antoine de Saint-Exupéry. “Um pequeno príncipe”. Capítulo 15. Geógrafo

É sabido que os negócios de qualquer empresa moderna estão cada vez mais dependentes da tecnologia da informação. O desenvolvimento de certas áreas de negócio, por exemplo o desenvolvimento do “negócio de cartões” nos bancos, tornou-se possível apenas graças ao advento das TI modernas. Naturalmente, isto também se aplica a empresas de outros setores. Portanto, pode-se esperar que a experiência apresentada possa ser utilizada nos negócios de qualquer outra empresa não bancária sem esforços significativos de adaptação.
A peculiaridade do atual nível de desenvolvimento das tecnologias de informação bancária é que em muitos bancos que conseguiram manter os seus negócios após a crise de 1998 e hoje continuam a desenvolvê-los e expandi-los ativamente, soluções bancárias de alta tecnologia estão sendo implementadas no contexto da operação contínua de sistemas e complexos de software de gerações anteriores, muitas vezes moralmente obsoletos. Por outro lado, parar a actividade bancária, mesmo que por algumas horas, e muito menos pará-la durante um ou vários dias para desactivar software obsoleto e colocar novo software em funcionamento, na maioria dos casos será equivalente à perda de negócios. Nesta situação, em cada momento é necessário ter uma compreensão clara do estado actual de todos os sistemas de informação que estão a ser implementados e operados, bem como uma compreensão igualmente clara do seu futuro desenvolvimento, tendo em conta as perspectivas de desenvolvimento do banco, sua arquitetura como arquitetura corporativa. (Na literatura de língua inglesa - métodos, artigos, padrões - isto corresponde ao termo arquitetura corporativa.)
Deve-se notar que a arquitetura corporativa existe independentemente tanto da nossa consciência quanto do tamanho desta empresa - seja uma corporação global, uma pequena fábrica, uma pequena empresa comercial, etc. Uma pequena empresa tem a mesma arquitetura que uma grande, mas não diferem muito na composição componentes. No entanto, alguns gestores compreendem isto e podem dar-se ao luxo de prestar atenção a todos os aspectos da organização da sua própria empresa (são, em regra, chefes de grandes empresas), enquanto outros não. Outra questão é que uma pequena empresa pode ter apenas dois ou três produtos, a missão e a estratégia não estão explicitamente declaradas (este problema, aliás, ocorre frequentemente em grandes empresas), o número de funcionários é de 30 pessoas e dois computadores com MS são usados ​​​​na produção do Word 97. Mas mesmo neste caso, isso é tudo o que constitui a arquitetura deste empreendimento.
O artigo apresenta uma abordagem bastante abrangente e ao mesmo tempo pragmática para organizar o trabalho de análise da arquitetura da empresa como um todo e de planejamento da arquitetura do sistema, incluindo sua documentação. Os principais objetivos da documentação do conhecimento empresarial (desenvolvimento da arquitetura empresarial) são garantir a segurança dos investimentos empresariais e a transparência empresarial em todos os níveis.
A transparência empresarial começa com uma compreensão transparente da arquitetura empresarial, com uma divisão clara da mesma em três níveis interdependentes: o nível estratégico, o nível da arquitetura empresarial e o nível da arquitetura do sistema. A arquitetura do sistema é determinada pela arquitetura de negócios, e seu design só pode ser baseado na arquitetura de negócios, que por sua vez depende da estratégia empresarial. Esta abordagem permite, em nossa opinião, não só organizar correctamente o trabalho em si e fazer uma correcta divisão das funções e responsabilidades do arquitecto de negócio (“business developer”), a quem cabe o desenvolvimento do negócio, ou seja, a arquitectura de negócio da empresa e do arquiteto do sistema, mas também, o mais importante é construir uma arquitetura empresarial equilibrada que corresponda adequadamente à sua missão e estratégia.
No início do artigo são fornecidas definições básicas. Em seguida, são considerados a composição e o conteúdo da arquitetura do sistema, são analisadas as relações entre as entidades da arquitetura de negócios e da arquitetura do sistema. As fases e participantes do ciclo de vida da arquitetura do sistema, em particular as funções dos participantes, são considerados com detalhes suficientes. Finalmente, a estrutura de conhecimento subjacente à arquitetura do sistema é resumida e as conclusões finais são tiradas.

Conceitos Básicos

Arquitetura Corporativa- esta é a representação mais geral e abrangente de uma empresa, neste caso um banco, como uma entidade económica que tem objetivos de curto e longo prazo para a condução das suas atividades principais, determinados pela missão a nível regional e global, em o nosso caso - o mercado financeiro e de crédito, e a estratégia de desenvolvimento, os recursos externos e internos necessários ao cumprimento da missão e à concretização dos objetivos traçados, bem como as regras estabelecidas para a condução da atividade principal (negócio).
Para fins de análise de sistemas, a arquitetura empresarial pode ser considerada em dois aspectos:

• estático - de acordo com o estado do banco em algum momento fixo;
• dinâmico - como um processo de transição (migração) de um banco do seu estado atual para algum estado desejado no futuro.

A arquitetura empresarial considerada de forma estática consiste nos seguintes elementos:

• missão e estratégia, metas e objetivos estratégicos;
• arquitetura empresarial;
• arquitetura do sistema.

Arquitetura empresarial vista em dinâmicaé um plano de ação integral e logicamente conectado e projetos coordenados necessários para transformar a arquitetura existente da organização em um estado definido como uma meta de longo prazo, com base nas metas de negócios e processos de negócios atuais e planejados da organização.

Arroz. 2.

Assim, a arquitetura corporativa é geralmente descrita pelas seguintes seções sequencialmente dependentes (ver Fig. 1 e Fig. 2):

• missão e estratégia formuladas do banco, metas e objetivos estratégicos;
• arquitetura de negócios no estado atual (como está) e planejado (como será),
• arquitetura do sistema no estado atual (como está) e planejado (como será);
• planos de atividades e projetos para a transição do estado atual para o planejado.

Na Fig. 1 mostra que a implementação do plano de migração não significa congelar o desenvolvimento da arquitetura de negócios e de sistemas. Assim, a arquitetura de sistema planejada é a arquitetura “futura” apenas em um determinado estágio de desenvolvimento empresarial. Ao mesmo tempo, regressar ao nível estratégico da missão e das metas e objectivos estratégicos não significa a necessidade de rever a missão e a estratégia. Mas no final de cada ciclo é necessária uma análise da eficácia das atividades desenvolvidas e implementadas; se necessário, durante a segunda iteração, a arquitetura de negócios e a arquitetura do sistema são ajustadas e novos planos de migração são implementados. Em qualquer momento pode haver vários ciclos; cada um desses ciclos não afeta necessariamente toda a empresa como um todo; o ciclo pode afetar áreas individuais, questões empresariais individuais e pode ser registrado na forma de um projeto separado.
Com um plano de migração passo a passo, para registrar os resultados alcançados, é possível construir arquiteturas intermediárias (de migração) de uma ou mais.
Missão, estratégia e objetivos de negócios determinar a direção de desenvolvimento do banco e definir metas e objetivos de longo prazo.
Arquitetura de negócios Com base na missão, estratégia de desenvolvimento e objetivos de negócio de longo prazo, determina a estrutura organizacional necessária, estrutura do canal de vendas e modelo funcional do banco, documentos utilizados no processo de desenvolvimento e venda de produtos. O modelo funcional descreve processos de negócios destinados a implementar tarefas atuais e metas de longo prazo.
A arquitetura de negócios inclui:

• produtos e serviços oferecidos e previstos para venda pelo banco (incluindo esquemas individuais para sua produção), formalizados na forma de cadastro unificado de produtos e serviços, que também contém segmentação de clientes, tarifas e proprietários de produtos;
• canais de comercialização de produtos e serviços, construídos tanto com base nas divisões estruturais e territoriais do banco, como com base nas modernas tecnologias de informação;
• funções e processos para implementação de produtos e serviços externos e internos, formando árvores de funções e processos (doravante denominadas funções de negócio e processos de negócio);
• documentos financeiros e administrativos (em papel e em formato eletrônico), formalizados na forma de cadastro único (álbum de formulários) de documentos bancários;
• fluxos de documentos determinados por regulamentos sobre fluxo de documentos internos e externos;
• estrutura organizacional, incluindo o quadro de pessoal do banco e suas divisões territoriais, que são unidades econômicas independentes (pessoas jurídicas), comitês, grupos de trabalho e funções de funcionários individuais, descrições de cargos, regulamentos sobre divisões e órgãos de trabalho e outros documentos que regulam o relacionamento e distribuição de responsabilidades entre os funcionários do banco, bem como entre as divisões estruturais do banco.

Arquitetura do sistema(arquitetura de TI, arquitetura de SI empresarial) - define um conjunto de soluções tecnológicas e técnicas para fornecer suporte informativo ao trabalho do banco de acordo com as regras e conceitos definidos pela arquitetura de negócio.
Além disso, por “soluções” entenderemos, dependendo do contexto, não apenas equipamentos e softwares e sistemas de informação específicos, mas também os princípios, padrões e metodologias utilizadas no desenvolvimento ou seleção de sistemas de informação e software, na seleção e configuração de equipamento.
Planos de migração determinar o cenário de transição do banco do estado atual para o futuro, determinado por metas e objetivos estratégicos. Os planos de migração definem as transformações da arquitetura de negócios e de sistemas. Durante a migração faseada, com o propósito de formalizar resultados intermediários, são desenvolvidas intermediárias (migração) uma ou mais arquiteturas de negócios e sistemas. Os planos de migração, de acordo com a metodologia de gestão de projetos do banco, são formalizados sob a forma de projetos separados, incluindo, nomeadamente:

• definir um projeto como um conjunto de tarefas e trabalhos;
• fases e prazos de implementação do projeto como um todo e as tarefas e obras que compõem o projeto;
• análise do ambiente competitivo e dos riscos associados à implementação do projeto;
• composição das rubricas de despesas do orçamento do projeto;
• critérios para o sucesso do projeto e o efeito económico esperado.

Arquitetura do sistema

A arquitetura do sistema consiste em três componentes inter-relacionados: arquitetura de aplicação, arquitetura de dados e arquitetura técnica (veja a Figura 3). A arquitetura do sistema no sistema de padrões de uma determinada empresa determina as regras para formar seus componentes e garantir a interação entre eles.

Arroz. 3.

Componentes da arquitetura do sistema

Arquitetura de aplicativo inclui:

• sistemas aplicativos (aplicativos) que garantem a execução de funções e processos de negócios;
• interfaces para interação de sistemas aplicativos entre si e com sistemas externos e fontes de dados ou consumidores;
• ferramentas e métodos para desenvolver e manter aplicativos.

A arquitetura de dados inclui:

• bancos de dados automatizados que proporcionam acúmulo, armazenamento e processamento de dados determinados pela arquitetura de negócios;
• sistemas de gestão de bases de dados ou de armazéns de dados utilizados para este fim;
• regras e meios de autorização de acesso aos dados.

Arquitetura técnica consiste em arquitetura de rede e arquitetura de plataforma.
Arquitetura de rede inclui:

• redes informáticas locais e territoriais, incluindo canais de comunicação físicos próprios e alugados e equipamentos formadores de canais;
• protocolos de comunicação, serviços e sistemas de endereçamento utilizados em redes;
• planos de emergência para garantir o funcionamento ininterrupto das redes em situações de emergência.

Arquitetura de plataforma inclui:

• hardware de computador - servidores, estações de trabalho, drives e outros equipamentos de informática;
• sistemas operacionais e de controle, utilitários e sistemas de software de escritório;
• planos de emergência para garantir o funcionamento ininterrupto de equipamentos (principalmente servidores) e bancos de dados em situações de emergência.

Para resolver problemas de arquitetura de sistema, uma empresa geralmente cria um Serviço de arquiteto de sistema. Este serviço é responsável pela resolução das seguintes tarefas:

• coordenar o trabalho dos departamentos de TI para documentar a arquitetura atual do sistema na fase inicial e, posteriormente, manter atualizada a base de conhecimento sobre a arquitetura do sistema;
• determinação de rumos promissores para o desenvolvimento da arquitetura de sistemas de acordo com as metas e objetivos estratégicos do banco, detalhados na forma de uma arquitetura de negócios promissora;
• concepção (em conjunto com outros departamentos especializados em tecnologias de informação) de uma futura arquitectura de sistema e planos de migração do estado actual para o futuro;
• formular requisitos e restrições para ferramentas de automação criadas ou implementadas que garantam a qualidade e integridade da arquitetura do sistema;
• controle da consistência das arquiteturas de sistemas desenvolvidas no âmbito de diversos projetos;
• monitorar o cumprimento dos requisitos para garantir a qualidade e integridade da arquitetura do sistema pelas divisões bancárias envolvidas no desenvolvimento, manutenção e operação de sistemas de informação.

Separadamente, devemos nos deter em uma questão fundamental: quem desenvolve a arquitetura do sistema - um arquiteto de sistema ou um desenvolvedor de software, tecnólogo. A solução correta é quando a responsabilidade pelo desenvolvimento da arquitetura do sistema é atribuída aos departamentos de TI que realizam o projeto, desenvolvimento, teste, manutenção (incluindo descomissionamento) de sistemas e complexos de software e hardware. A documentação da arquitetura do sistema faz parte da documentação obrigatória de projeto e operacional. Essa abordagem permite criar um serviço de arquiteto de sistema de um pequeno número. Caso contrário, o desenvolvimento de uma arquitetura de sistema por um serviço dedicado requer um aumento significativo no número de arquitetos de sistema, e os processos de desenvolvimento ficam muito mais lentos ou a arquitetura do sistema em desenvolvimento torna-se inadequada já durante o seu desenvolvimento.

Relação entre arquitetura de sistema e arquitetura de negócios

A arquitetura corporativa é completamente descrita pelas seguintes entidades (ver Fig. 4):

1. Missão e estratégia do banco, metas e objetivos estratégicos.
2. Produtos e processos de negócios.
3. Documentação.
4. Estrutura organizacional.
5. Formulários.
6. Dados.
7. Equipamento.
8. Planos de atividades e projetos para a transição do estado atual para o planejado.

Arroz. 4. Inter-relação de entidades do nível superior da arquitetura empresarial

Na Fig. 4 mostra apenas entidades de nível superior. Cada uma das entidades se divide em uma coleção de entidades mais detalhadas. Assim, apenas a entidade “Produtos” se divide em mais de dez tabelas, incluindo grupos de produtos, planos tarifários, segmentos de clientes-alvo, etc.
É óbvio que existem fortes relações entre todas estas entidades. Por exemplo, a implementação de um produto é acompanhada de determinados documentos e é suportada por suporte de informação por determinadas aplicações e módulos que utilizam determinadas bases de dados. Vários funcionários e departamentos estão envolvidos na implementação deste produto. O produto tem dono.

Arroz. 5. Arquitetura corporativa e o lugar da arquitetura do sistema nela

Na Fig. A Figura 5 mostra uma exibição gráfica ampliada da arquitetura corporativa e seus componentes definidores.
Um exemplo das principais relações entre os principais elementos da arquitetura de negócios e da arquitetura do sistema é mostrado na Fig. 6 na forma de um diagrama ER.

Arroz. 6.

Essências e relações de duas arquiteturas

Ciclo de vida da arquitetura do sistema

Para regular os ciclos de vida (LC) dos sistemas em geral (incluindo as empresas), bem como dos seus sistemas de informação e software (PS), em particular, existem uma série de normas. Prevêem a possibilidade de adaptação de modelos de ciclo de vida, incluindo fases (etapas), às características de um determinado empreendimento e projeto. Assim, as fases do ciclo de vida descritas nesta e nas próximas seções não contradizem as normativas e não são dogmas. A vantagem em termos de uso neste artigo é a simplicidade e a experiência prática.

Arroz. 7.

O ciclo de vida da arquitetura do sistema consiste nas seguintes fases: (veja a Figura 7):

• documentação inicial;
• uso;
• projeto;
• migração.

OBSERVAÇÃO. Após a conclusão da fase de migração, o processo se repete, com a próxima iteração começando com a fase de uso. Pode não haver fase inicial de documentação no desenvolvimento de novos SI. O desenvolvimento da arquitetura do sistema começa com a fase de design.
Na fase de utilização, o desenvolvimento evolutivo da arquitetura do sistema é realizado de acordo com princípios previamente formulados e sem alterar as soluções técnicas e tecnológicas básicas.
EXEMPLO. Suponha que durante a fase de projeto foi desenvolvida a arquitetura do sistema do programa de contabilidade da central e filiais e realizada sua implementação (fase de migração). O conhecimento sobre a arquitetura do sistema desta solução vai para a fase de utilização até que surjam novos requisitos de negócio para a conclusão/atualização do sistema construído. O conhecimento da arquitetura do sistema da solução criada é utilizado pela empresa para construir um data warehouse de forma a consolidar a informação e posteriormente obter relatórios de gestão. Mas com base neste conhecimento, desenha-se a arquitectura do sistema do data warehouse e a seguir o sistema de reporte de gestão, que posteriormente, tendo passado pelas suas fases de migração, entram nas fases de utilização. Assim, podemos falar de um modelo de arquitetura de sistema multicamadas, no qual a arquitetura do sistema em diferentes camadas pode estar em diferentes estágios do ciclo de vida (ver Fig. 8).

Arroz. 8.

Na fase de projeto, uma arquitetura de sistema promissora (futura) é desenvolvida, novos princípios para a construção de uma arquitetura de sistema são formulados e novas soluções técnicas e tecnológicas básicas são desenvolvidas de acordo com esses princípios. Normalmente, o motivo da execução desta fase são mudanças significativas na arquitetura de negócios, o surgimento de novos requisitos de negócios que afetam significativamente a arquitetura do sistema.
Na fase de migração, é realizado um conjunto de medidas organizacionais, técnicas e tecnológicas para garantir a transição da arquitetura do sistema do estado atual para o promissor ou para o próximo estado intermediário durante a migração fase a fase de acordo com o planos de migração elaborados na fase anterior.
O ciclo de vida da arquitetura do sistema está relacionado ao ciclo de vida do software. O ciclo de vida do software (Software) consiste nas seguintes fases principais:

• análise de viabilidade;
• desenvolvimento de especificações técnicas;
• desenvolvimento de projeto técnico;
• desenvolvimento e documentação de software;
• Testes PS;
• implementação do PS;
• operação da subestação;
• descomissionamento da subestação.

O arquiteto do sistema monitora as decisões de projeto durante todo o ciclo de vida do software. O controle é realizado na forma de aprovação de documentos de projeto elaborados e enviados ao arquiteto do sistema pelos departamentos responsáveis ​​​​pela implementação de uma ou outra fase do ciclo de vida do software.
A seguir são apresentadas as descrições das fases do ciclo de vida da arquitetura do sistema, o escopo dos trabalhos de arquitetura do sistema realizados em cada fase, os executores desses trabalhos, bem como o cumprimento das fases do ciclo de vida do software.

Documentação inicial

A fase de “documentação inicial” do ciclo de vida da arquitetura do sistema não tem correspondência direta nas fases do ciclo de vida do software. Em termos de conteúdo, esta fase é representada pelas funções dos seus participantes ativos (ver Tabela 1).

Tabela 1.

Uso

A fase “Uso” do ciclo de vida da arquitetura do sistema corresponde às seguintes fases do ciclo de vida do software:

• Desenvolvimento de especificações técnicas para o PS.
• Desenvolvimento do projeto técnico da subestação.
• Testes PS.

(Ver nota, Fig. 8 e exemplo acima. A partir do exemplo, vemos que o desenvolvimento de especificações técnicas, especificações técnicas, testes e implementação de um data warehouse e sistema de relatórios gerenciais utilizam conhecimento sobre a arquitetura do sistema do sistema de contabilidade, que é em operação industrial, e cuja arquitetura do sistema está atualmente em fase de uso. A arquitetura do sistema de data warehouse está atualmente em fase de projeto.)
As funções de seus participantes ativos na fase “Uso” são apresentadas na Tabela. 2.

Mesa 2.

Projeto

Aqui pode surgir a pergunta: para onde foi o desenvolvimento da definição do problema? E é mesmo necessário? A fase “Design” do ciclo de vida da arquitetura do sistema corresponde às seguintes fases do ciclo de vida do software:

• Elaboração de especificações técnicas do PS.
• Elaboração do projeto técnico da subestação.

Claro, o que é necessário, para colocar em linguagem oficial, é a fase de “Análise do objeto de automação”, incluindo o desenvolvimento de uma declaração de problema, a formulação de requisitos de negócio, e tal fase, claro, existe. No entanto, uma consideração detalhada destas questões está além do escopo do artigo, que se limita à consideração da arquitetura do sistema.
Deixe-me explicar de qualquer maneira. A necessidade de mudar o negócio e, consequentemente, a necessidade de reestruturar a arquitetura do negócio pode ser devida a:

1. mudanças na missão ou estratégia;
2. mudanças na situação do mercado;
3. autoridades reguladoras.

Depois de perceber essa necessidade, os requisitos de negócio são formulados, mas tudo isso acontece enquanto ainda estamos na camada de arquitetura de negócio (ver Fig. 4). As setas das entidades “Produtos” e “Documentos” direcionadas às entidades “Equipamentos”, “Programas” e “Dados” correspondem à declaração do problema (requisitos de negócio). Voltemos ao nosso exemplo, a partir do qual vemos que o desenvolvimento de especificações técnicas, especificações técnicas, testes e implementação de um data warehouse utilizam conhecimentos sobre a arquitetura do sistema de contabilidade, que já está em operação comercial, e sua arquitetura de sistema é atualmente em fase de uso. A arquitetura do sistema do data warehouse está atualmente em fase de projeto (ver Fig. 8).
As funções dos participantes ativos na fase “Design” são apresentadas na Tabela. 3.

Tabela 3.

Migração

As seguintes fases do ciclo de vida do software correspondem à fase de “Migração” do ciclo de vida da arquitetura do sistema:

• Teste de software.
• Implementação de software.

As funções dos participantes ativos na fase “Migração” são apresentadas na Tabela. 4.

Tabela 4.

Assim, a arquitetura do sistema é efetivamente afetada nas seguintes fases do ciclo de vida do software:

• Em fase “Desenvolvimento de especificações técnicas da subestação”é realizada uma análise da arquitetura do sistema existente com vista à possibilidade e viabilidade de utilização dos recursos existentes para resolver novos problemas de negócio. Além disso, na elaboração das especificações técnicas são tidos em conta, sempre que possível, os requisitos e limitações impostos pela arquitetura do sistema existente.
• Em fase “Desenvolvimento do projeto técnico da subestação”É realizada a própria formação ou alteração da arquitetura do sistema necessária para a implementação das tarefas de negócios recém-definidas. Os requisitos e limitações impostos pela arquitetura do sistema existente são levados em consideração para garantir a continuidade e minimizar os custos de modernização.
• Nas fases "Teste" e "Implementação" Os requisitos de software desenvolvidos da arquitetura do sistema são utilizados para formar o ambiente tecnológico necessário para testes e operação dessas subestações.

Composição da base de conhecimento da arquitetura do sistema

Como as listas do que você precisa saber apenas sobre arquitetura de sistema são muito grandes para apresentação em um artigo de jornal (elas equivalem a dezenas de posições), apenas seções da base de conhecimento correspondente são descritas abaixo e é feita uma tentativa de pelo menos delinear o conteúdo dessas seções.
A base de conhecimento da arquitetura do sistema deve consistir em pelo menos três seções:

1. Arquitetura atual do sistema.
2. Arquitetura de sistema em perspectiva (planejada).
3. Planos de migração.

As seções “Arquitetura Atual do Sistema” e “Arquitetura Prospectiva do Sistema” possuem a mesma estrutura e consistem nas seguintes subseções:

1. Princípios de construção de arquitetura de sistema.
2. Soluções técnicas e tecnológicas básicas.
3. Requisitos e padrões.
4. Arquitetura aplicada.
5. Arquitetura técnica.
6. Arquitetura de dados.

Princípios de construção

Os requisitos e limitações impostos à arquitetura do sistema pelo lado da arquitetura de negócios são fornecidos. Todos os requisitos e restrições são indicados - tanto os formulados diretamente na arquitetura de negócios, quanto os adicionais formulados pelo arquiteto do sistema.
É fornecida uma descrição dos princípios de construção de uma arquitetura de sistema decorrentes dos requisitos e limitações acima.

Soluções básicas

São descritas as principais soluções técnicas e tecnológicas que constituem a base da arquitetura do sistema. Por exemplo, esta poderia ser uma decisão de utilizar o computador AS/400 como principal plataforma de hardware do sistema de informação do banco ou uma decisão de utilizar o DB2 DBMS como principal ferramenta de gestão dos recursos de informação do banco.
Cada solução é fornecida com um comentário explicando como esta solução corresponde aos princípios da arquitetura do sistema formulados acima.
As principais decisões tomadas durante o projeto da arquitetura do sistema são documentadas em documentos separados, com uma breve exposição dos antecedentes, a essência do problema e a solução fundamental adotada para o problema, que é obrigatória no posterior projeto, desenvolvimento e implementação do sistema de informação.

Requisitos e Padrões

São indicados todos os requisitos, padrões e restrições aos quais a arquitetura do sistema atende. Se necessário, padrões individuais (requisitos, restrições) ou referências a eles podem ser duplicados em capítulos subsequentes.
São fornecidos links (código, nome, edição, etc.) para padrões externos. Se necessário, os textos das normas externas são fornecidos total ou parcialmente.
São descritas as normas internas (normas empresariais), indicando o código (se atribuído), nome, edição e órgão aprovador.
São descritos requisitos e restrições adicionais que devem ser atendidos pela arquitetura do sistema e pelos elementos da infraestrutura de informações que não receberam status padrão.
É explicado exatamente quais os princípios da arquitetura do sistema ou as decisões técnicas e tecnológicas básicas adotadas que levaram à necessidade de utilizar/ter em conta esta norma/requisito ou limitação.

Arquitetura de aplicativo

São descritos sistemas aplicativos (aplicativos) que garantem a execução de funções e processos de negócios e sua interação. O nível de detalhe da descrição deve corresponder ao módulo de software, entendido como uma unidade de software armazenada de forma independente como um arquivo ou seção de biblioteca.

Arquitetura técnica

Arquitetura de rede

Contém descrições de infraestrutura de comunicação territorial e redes locais (LAN).

Arquitetura de plataforma

Contém uma descrição de sistemas operacionais e equipamentos separadamente para servidores e estações de trabalho.

Arquitetura de dados

Bancos de dados e armazéns de dados

Contém uma descrição de bancos de dados e matrizes de informações organizadas.

Sistemas de Gerenciamento de Banco de Dados

Contém uma descrição dos sistemas de gerenciamento de banco de dados utilizados.

Plano de migração

Contém um plano de migração da arquitetura atual do sistema para o futuro.
Se a migração etapa por etapa for assumida, então os planos de migração intermediários também serão incluídos aqui.
Conforme afirmado anteriormente, o plano de migração é escrito na forma de um projeto. Assim, para cada plano, a seção inclui todos os documentos previstos na metodologia de gestão de projetos do Banco, tanto aprovados como em desenvolvimento ou aprovação.

Conclusão

Mostramos acima que a composição e o conteúdo do conhecimento sobre arquitetura de sistemas é um conjunto profundamente estruturado de informações altamente inter-relacionadas. Além disso, os relacionamentos não se limitam às conexões entre as entidades da arquitetura do sistema (ver Fig. 3), mas também estão intimamente relacionados às entidades da arquitetura de negócios. Assim, na prática, muitas vezes é necessário encontrar uma resposta para as seguintes questões:

• Quem no banco desempenha esta ou aquela função empresarial, com que regularidade a desempenha, que evento desencadeia a execução desta função empresarial, a execução desta função empresarial é automatizada ou não?
• Que informações estão incluídas em uma determinada função empresarial, quem é o fornecedor dessas informações e de que forma elas chegam?
• Quais ferramentas de software são utilizadas para realizar esta ou aquela função de negócio, quais outras funções de TI são executadas por esses programas, quais bancos de dados e diretórios são utilizados, quais telas e quais relatórios são gerados pelo programa?
• Que informações são recebidas e enviadas para um determinado programa, de que forma as informações recebidas são recebidas e as informações de saída são geradas?
• Como é organizada a interação de informações entre dois programas: através da formação/leitura de um arquivo, diretamente pela API, através do email, através de sistemas middleware, qual a estrutura de troca de informações, qual a frequência?
• Quais departamentos usam este ou aquele programa e quem precisa ser notificado quando o programa ou qualquer regulamento mudar?
• Esta ou aquela função de TI do programa é utilizada atualmente, por quem é utilizada, com que frequência?

É claro que muitas outras questões também surgem, de uma forma ou de outra, relacionadas à arquitetura de sistemas e negócios.
Devido ao tamanho limitado do artigo da revista, a análise dessas questões está além do seu escopo. Ressaltamos apenas que para estruturar e documentar esse conhecimento as capacidades do MS Word ou MS Excel são indispensáveis. É necessária a utilização de sistemas de software mais desenvolvidos, mas ainda mais importante é a utilização de técnicas ou mesmo metodologias adequadas. Um desses guias, que, na experiência do autor, satisfaz os requisitos necessários, é a “metodologia ARIS” (ARchitecture of Integrated Information System). No entanto, este é um tópico completamente diferente, talvez para outro artigo.

O segundo artigo sobre a consciência mitológica também será curto. Hoje vou contar a quais problemas a consciência mitológica leva ao modelar a arquitetura corporativa.

O famoso modelo de Zachman tenta responder à questão do que é arquitetura corporativa e fala sobre como ela deve ser modelada. A base deste modelo são as questões que se propõem a serem respondidas: quem, quando, onde, por que e como faz algo sobre algo. Parece uma estrutura lógica para descrever a arquitetura empresarial, e muitas pessoas pensam que é.

Porém, mesmo uma rápida olhada nesta estrutura deixa um sentimento de insatisfação, porque não está claro como responder à pergunta: quem usinou a peça e por quê? Quem: Ivan Ivanovich, ou o torneiro, cujo papel foi desempenhado por Ivan Ivanovich? Por quê: porque o torneiro recebeu a tarefa, ou porque Ivan Ivanovich celebrou um contrato segundo o qual se compromete a desempenhar a função de torneiro em troca de comida? Por quê: porque Ivan Ivanovich quer comer ou porque falta a peça na oficina de montagem?

Um estudo mais aprofundado deste referencial faz pensar na sua aplicabilidade à descrição de processos tecnológicos. Por exemplo, digamos que o milho esteja crescendo em um campo. Ao aplicar o modelo de Zachman, tenho que responder a perguntas. Quem? Milho. O que ele está fazendo? Crescente. Por que? Porque é assim que o mundo funciona. Para que? Mas quem sabe por que o milho cresce?!

Um leitor treinado na descrição de arquiteturas corporativas me corrigirá rapidamente. Ele dirá que estou fazendo as perguntas incorretamente. Devemos perguntar: quem cresce, por que cresce, o que cresce. Mas acontece que posso descrever a atividade do sujeito que cultiva milho, mas não consigo descrever o crescimento em si. Tendo aceitado o facto de não conseguir descrever o processo de cultivo, ainda tenho questões não resolvidas: quem cultiva milho e porquê (ver acima)?

Acontece que quando faço perguntas aparentemente lógicas, na melhor das hipóteses obtenho várias respostas e, na pior das hipóteses, não as recebo. Se considerarmos o caso extremo em que temos uma empresa completamente robótica sem nenhuma pessoa, então a resposta à pergunta “quem?” será “ninguém”. Como resultado, não podemos dizer nada sobre este empreendimento! É verdade que existe uma saída para essa situação, um pouco astuta - você só precisa usar a consciência mítica e animar os robôs. Então, tendo animado o inanimado, poderemos responder à pergunta: quem? Robô. Por que? Porque é assim que funciona este robô, ou porque o programador o programou desta forma. À segunda pergunta recebemos novamente respostas estranhas. Por que isso aconteceu e que perguntas realmente valem a pena ser feitas? Tentarei expor brevemente minha opinião sobre este assunto, falando sobre os erros lógicos que encontrei no modelo de Zachman.

Se você observar as perguntas feitas no modelo de Zachman, verá que elas estão exatamente alinhadas com a teoria da atividade. A atividade é uma função mental de um sujeito (grupo de sujeitos). Portanto, respondendo às questões de Zachman, construímos um modelo da função mental do sujeito (sujeitos). A ciência que estuda as funções mentais dos sujeitos é chamada de psicologia. Acontece que Zachman responde às perguntas que os psicólogos fazem: por que o sujeito faz esta ou aquela ação? Ou como motivar um sujeito a realizar determinadas ações? Estas questões são certamente interessantes e importantes, mas as respostas descrevem a arquitetura empresarial? Para responder a essa pergunta, você precisa entender o que é uma empresa?

Como o design empresarial realmente acontece e quais artefatos surgem? Antes de projetar um empreendimento, é construído um modelo de requisitos para ele. O modelo de requisitos é formado com base nos requisitos apresentados a esta empresa por todos os seus participantes, contrapartes e partes interessadas. Um análogo em TI são os requisitos para um produto de software. A seguir, com base nesses requisitos, é construído um modelo de processos empresariais com o grau de detalhe necessário. Um análogo em TI seria uma lista de funções de um produto de software. A seguir, constrói-se um modelo de objetos funcionais, ou, em linguagem especializada, locais técnicos que deverão participar dos processos anteriormente elencados. Um análogo em TI seria uma descrição dos procedimentos e uma explicação de quais procedimentos estão envolvidos em quais funções. A seguir, são selecionados os equipamentos que podem desempenhar as funções dos locais técnicos listados. O análogo em TI é o código do programa.

Uma empresa é um objeto funcional criado para satisfazer determinados requisitos. Nesse sentido, uma empresa não difere de um objeto como um relógio ou uma linha de produção. Freqüentemente, em vez do termo objeto funcional, você pode ouvir o termo localização técnica. Uma localização técnica difere de um equipamento porque o equipamento atua como uma localização técnica. Por exemplo, um transformador atua como um conversor de tensão, enquanto em momentos diferentes diferentes transformadores podem atuar como o mesmo conversor. Outro exemplo de localização técnica é um cargo, departamento, divisão ou estado. Por exemplo, um torneiro está envolvido na função de fabricação de peças. Este é um local técnico, cuja função pode ser desempenhada por diferentes equipamentos (indivíduos) em momentos diferentes. Escrevi brevemente sobre as dificuldades de modelar locais técnicos e equipamentos em um artigo.

Ao modelar locais técnicos, descrevemos os processos e os participantes desses processos. Observo que são os participantes, e não os performers, que o transformador não pode transformar tensão, porque não é um ser animado. Escrevi sobre isso em um artigo anterior. Se, no entanto, dissermos que um transformador “converte” tensão, então isto é uma metonímia, que se revela da seguinte forma: um transformador desempenha o papel de um conversor de tensão, que (o conversor) participa no processo de conversão de tensão. Você pode ler sobre metonímia no livro “Metáforas pelas quais vivemos”, autores: George Lakoff, Mark Johnson. Outra metonímia comum é “um computador resolve problemas”. Aqueles que realmente acreditam que um transformador ou um computador realmente fazem alguma coisa, animam o inanimado, usando a consciência mítica.

Observe que até agora não dissemos uma palavra sobre objetivos, desempenho e relações de causa e efeito. Falamos apenas dos requisitos, das funções e dos participantes nessas funções – locais técnicos. As metas permaneceram na fase de formação de requisitos para o empreendimento e não foram além. Podemos ou não conhecer esses objetivos; isso não importa para o modelo empresarial. O modelo empresarial responde à questão de como satisfazemos os requisitos, e não de onde vêm esses requisitos. Também não há artistas, porque não precisamos de usar a teoria da actividade para descrever os participantes na actividade. Não construímos relações de causa e efeito. Se você precisar construir um modelo de relações de causa e efeito, este é outro modelo adicional. Esse é o conhecimento que os tecnólogos usam ao projetar um empreendimento, e nunca vi ninguém construir tais modelos. Este é o conhecimento da indústria e tem sido ensinado em institutos há muitos anos. É incrivelmente difícil modelar por que um avião voa, e ninguém faz isso. Eles simplesmente simulam o vôo de um avião.

Então, o modelo de Zachman não inclui requisitos para o empreendimento, inclui um modelo de processo, mas de uma forma bastante específica - indicando os executores do processo, que, como eu disse, só pode ser encontrado na teoria da atividade, e não separa a maquete dos locais técnicos e os modelos dos equipamentos.

Como disse anteriormente, o modelo de Zachman tem mais a ver com actividade. Ao mesmo tempo, seria bom se o modelo de Zachman fosse usado para o propósito pretendido - como uma forma de descrever a atividade. Isto permitiria analisar os motivos e o interesse das pessoas pelo seu trabalho, mas o problema é que este modelo é utilizado de forma incorrecta. Por exemplo, para a pergunta “por que um torneiro afia uma peça?” você pode obter a resposta: “é necessário na oficina de montagem”. Mas sua necessidade na oficina de montagem não responde à questão de por que um torneiro afia uma peça. A resposta não foi para a questão colocada, mas para alguma outra. Por exemplo, para tal resposta a pergunta correta seria: em que processo ou operação a peça torneada deveria estar envolvida? Ou em que local de trabalho é necessário? Você vê que esta não é uma questão de “por quê?”. Além disso, estou muito confuso com a dotação de Zachman de um computador ou sistema de informação com a capacidade de fazer alguma coisa. Muito provavelmente ele não os anima, mas usa metonímia na modelagem, o que na minha opinião é inaceitável.

As perguntas certas seriam: Quais são os requisitos para a empresa? Que processos ocorrem na empresa? Quais locais técnicos estão envolvidos em quais processos? Quais equipamentos desempenham as funções de quais locais técnicos e quando?

Na verdade, isso é tudo. Feliz Ano Novo e nos vemos novamente!