21 princípios da arquitetura empresarial para o setor financeiro

O artigo lista os princípios de arquitetura mais relevantes para um departamento de TI no mercado financeiro, com detalhes sobre cada princípio. Esses princípios são essenciais para que um departamento de TI assuma uma função estratégica na empresa e para indicar a geração real de valor em decisões de TI, em um ambiente em que pressão e decisão de negócios são essenciais.

Thiago Souza Mendes Guimarães , IT Architect, IBM

Thiago Guimarães Thiago Guimarães trabalhou por seis anos no departamento de TI de um banco de investimento. Durante a metade desse período, foi arquiteto empresarial. Agora é arquiteto de TI nas áreas de ISV e Developer Relations da IBM, no Brasil, com ênfase no setor financeiro.



07/Dez/2012

Estrutura desses princípios

Este artigo foi criado com o fim de propor alguns princípios que devem conduzir uma iniciativa de arquitetura empresarial. A principal motivação que levou ao desenvolvimento dessa lista é a dificuldade de implementar arquitetura empresarial em um ambiente tão hostil quando o mercado financeiro. Há uma grande pressão no segmento de tecnologia, que geralmente não é considerado estratégico. Um desafio ainda maior é mostrar que as decisões de TI podem incluir valor e diferenciais nos negócios.

Esta lista foi criada e organizada com base na seleção e ajuste dos princípios mais relevantes estabelecidos através da minha experiência no mercado financeiro. Apesar de terem sido selecionados no contexto do segmento de mercado de finanças, a maioria dos princípios vale para qualquer tipo de segmento, após alguns leves ajustes.

Definições

Princípios são definições de alto nível de valores fundamentais que orientam o processo de tomada de decisões em TI, servindo de base para a arquitetura de TI, políticas de desenvolvimento e normas.

Os princípios de arquitetura definem regras gerais e diretrizes para usar e implementar todos os recursos e ativos de tecnologia da informação (TI) em uma empresa. Devem refletir um nível de consenso entre vários componentes e áreas corporativos, constituindo a base para futuras decisões de TI.

Cada princípio de arquitetura deve focar principalmente em metas de negócios e aplicações da arquitetura.

Formato de cada princípio

Cada princípio deve ser declarado formalmente. A literatura relacionada apresenta sugestões sobre o formato em que cada princípio deve ser declarado. Este artigo segue o formato sugerido pelo The Open Group Architecture Framework (TOGAF), no qual cada princípio é apresentado de acordo com o seguinte formato:

Nome
O nome deve representar a essência da regra e ser fácil de lembrar. Não é necessário mencionar plataformas tecnológicas específicas no nome ou descrição de um princípio.
 
Descrição
A descrição deve transmitir de forma sucinta e direta a regra fundamental. Muitas descrições de princípios de gerenciamento de informações são semelhantes em diferentes empresas.
 
Lógica
Deve destacar os benefícios de negócios gerados pela adesão ao princípio, usando terminologia de negócios. Deve enfatizar a semelhança entre princípios de informações e tecnologia e aqueles que regulam as operações de negócios. A lógica também deve descrever seu relacionamento com outros princípios e intenções em comparação a uma interpretação balanceada. Deve descrever situações nas quais certo princípio seria mais importante que outro no processo de tomada de decisões.
 
Implicações
Esse item deve destacar requisitos para seguir o princípio, para os negócios e para a TI, em relação a recursos, custos e atividades ou tarefas. Os impactos nos negócios e as consequências de adotar um princípio devem ser detalhados. Os leitores devem poder responder facilmente à pergunta: "Como isso me afeta?". É importante não simplificar, trivializar ou questionar o mérito de tais impactos. Algumas implicações são identificadas exclusivamente como impactos em potencial, com uma característica especulativa, em vez de ser analisadas totalmente.
 

Quatro categorias de princípios

Em geral, há cerca de 20 princípios de arquitetura empresarial que precisam ser seguidos. Uma lista muito curta contém princípios mais genéricos, o que dificulta aplicações práticas. Por outro lado, uma lista excessivamente extensa é específica demais e gera inconsistências e conflitos entre princípios e mudanças que resultam da evolução tecnológica, ambiental e contextual. A lista a seguir tem 21 princípios, organizados em quatro categorias.

  • Princípios gerais
  • Princípios de informações
  • Princípios de aplicativo
  • Princípios de tecnologia

Princípios gerais

Princípio 1. Alinhamento entre TI e negócios

Descrição

As decisões de gerenciamento de informações são sempre tomadas sob a perspectiva do alinhamento de negócios, para gerar o máximo benefício para a empresa como um todo.

Lógica

Este princípio significa "serviço acima de tudo". Um alinhamento entre TI e negócios deve gerar uma vantagem competitiva para a instituição financeira.

As decisões baseadas na perspectiva corporativa têm maior valor de longo prazo que decisões baseadas em certa perspectiva de um grupo com um interesse específico. O melhor ROI exige que as decisões de gerenciamento da empresa estejam alinhadas com as prioridades e o posicionamento da empresa. Nenhuma área sozinha deve afetar o benefício da empresa. No entanto, este princípio não deve impedir alguém de realizar tarefas ou atividades.

Implicações

Alinhar a TI com os negócios e promover benefícios corporativos ideais exige mudanças na maneira como as informações são planejadas e gerenciadas. A tecnologia sozinha não basta para promover essas mudanças.

A TI deve direcionar seus processos para o front office.

O gerenciamento de custos da TI deve ser direcionado para estabelecer uma vantagem competitiva.

O gerenciamento de TI deve incluir indicadores de responsividade e disponibilidade.

A arquitetura de TI deve implementar uma visão de TI completa que tenha seu foco nos negócios.

Algumas áreas podem precisar renunciar a suas preferências específicas para o benefício da empresa como um todo.

As prioridades de desenvolvimento de aplicativos devem ser estabelecidas por e para toda a empresa.

Os componentes de aplicativos devem ser compartilhados entre todas as áreas da instituição financeira.

Iniciativas de gerenciamento de informações devem ser realizadas com base em um plano corporativo. As áreas individuais devem seguir as iniciativas de gerenciamento de informações de acordo com planos e prioridades corporativos. O planejamento é modificado sempre que necessário.

Quando surgirem novas necessidades, as prioridades devem ser ajustadas proporcionalmente. Um comitê corporativo de representação deve tomar tais decisões.

Princípio 2. O máximo de benefícios com o menor custo e risco

Descrição

As decisões estratégicas das soluções devem sempre buscar maximizar os benefícios gerados para os negócios com o menor risco e menores custos.

Lógica

Não se deve tomar decisões apenas procurando atingir menores custos de solução. Cada decisão estratégica deve ser avaliada pelas perspectivas de custo, risco e benefícios. Menores custos geralmente representam maiores riscos e, talvez, menos benefícios.

Implicações

Uma solução deve ser selecionada com base em uma avaliação qualitativa ou quantitativa de custo, risco e benefício.

Na maioria das vezes, avaliações quantitativas são mais simples quando baseadas na perspectiva de custo, porém mais complexas para riscos e ainda mais difíceis para benefícios. A avaliação quantitativa deve ser realizada sempre que possível e suficiente.

Uma avaliação qualitativa de uma ou duas perspectivas é suficiente quando uma avaliação quantitativa de outras perspectivas (por exemplo, custo) é realizada apropriadamente e já leva a uma decisão.

Os riscos operacionais devem ser quantificados sempre que possível.

A infraestrutura de TI também deve ser otimizada com base em requisitos de negócios e capacidade tecnológica de gerar custos e riscos menores, beneficiando assim o foco da empresa.

Princípio 3. Continuidade de negócios

Descrição

As atividades corporativas devem ser mantidas, a despeito das interrupções do sistema.

Lógica

À medida que as operações de sistema tornam-se mais inerentes, nós ficamos mais dependentes delas. Portanto, precisamos considerar a confiabilidade desses sistemas ao longo de sua criação e aplicação. As áreas de negócios em toda a empresa devem poder continuar realizando suas atividades normais, a despeito de eventos externos. Falhas de hardware, desastres naturais e falta de integridade de dados não devem interromper as atividades de negócios. As atividades de negócios devem poder usar mecanismos alternativos para transmitir informações.

Implicações

A dependência de aplicativos compartilhados significa que é necessário esperar e planejar-se antecipadamente para os riscos de interrupção nos negócios. O gerenciamento inclui, entre outros, revisões periódicas, vulnerabilidade e testes de exposição, ou designação de serviços essenciais para garantir a continuidade através de redundâncias ou recursos alternativos.

A capacidade de recuperação, a redundância e a manutenção devem ser abordadas na concepção.

A gravidade e o impacto dos aplicativos na missão da empresa devem ser avaliados para determinar qual nível de continuidade é necessário e qual plano de recuperação correspondente deve ser implementado.

Princípio 4. Conformidade com normas e políticas

Descrição

Os processos de gerenciamento de informações corporativos devem estar de acordo com todas as políticas e regulamentos internos aplicáveis.

Lógica

A política corporativa de gerenciamento de informações deve estar de acordo com políticas e regulamentações internas. Isso não evita a melhoria de processos corporativos que realizam alterações em políticas e regulamentos.

Implicações

A empresa deve garantir a conformidade com todas as políticas e regulamentos internos em relação à transmissão, retenção e gerenciamento de dados.

Deve informar sobre todas as regras aplicáveis e torná-las acessíveis. Eficiência, necessidade e senso comum não são os únicos incentivos. Mudanças nas normas e nos regulamentos podem levar a mudanças em processos ou aplicativo.

Princípio 5. Adoção das melhores práticas do mercado

Descrição

As atividades de TI devem estar sempre alinhadas com as melhores práticas do mercado em relação a controle, processamento e gerenciamento.

Lógica

Uma empresa sempre busca adotar as melhores práticas de seu segmento de mercado em suas atividades de negócios. A área de TI de uma empresa deve seguir a mesma estratégica para aprimorar as atividades de negócios. A área de TI deve entregar projetos e acordos de nível de serviço (SLA) em prazos cada vez mais custos e com qualidade cada vez maior em um processo efetivo de controle de custos.

Implicações

As melhores práticas para disciplinas de TI devem ser identificadas e estudadas para implementá-las corretamente. Estas áreas, entre outras, devem seguir melhores práticas:

  • Os processos de TI devem ser passíveis de certificação e usar métricas estabelecidas.
  • Deve haver uma perspectiva de risco global, com foco em falha 0, e registros de incidentes e eventos.
  • O gerenciamento de custos de TI por serviço (receita e despesa) deve ser comparável financeiramente aos do mercado.
  • O gerenciamento de TI deve se concentrar em indicadores e uma perspectiva de programa.
  • A equipe deve ser cada vez mais qualificada e motivada.
  • A arquitetura de TI estabelecida deve ser aplicada efetivamente em projetos.

Princípios de informações

Princípio 6. Informações tratadas como um ativo

Descrição

As informações são um ativo valioso para a empresa e são gerenciadas com base nesse conceito.

Lógica

As informações representam um recurso corporativo valioso, com valor real e mensurável. Elas são a base do processo de tomada de decisões. Portanto, devem ser cuidadosamente gerenciadas para garantir um conhecimento constante de sua localização a confiabilidade de seu conteúdo e o acesso quando e onde seja necessário.

Implicações

Este é um dos três princípios relacionados sobre informações:

  • Informações são um ativo
  • Informações são compartilhadas
  • Informações podem ser acessadas facilmente

A implicação diz respeito a uma tarefa de conscientização implementada para garantir que todas as áreas de uma empresa entendam o relacionamento entre o valor das informações, o compartilhamento e a acessibilidade.

Princípio 7. Informações compartilhadas

Descrição

Os usuários têm acesso às informações necessárias para o desempenho de suas respectivas tarefas. Portanto, as informações são compartilhadas entre diferentes áreas e cargos corporativos, dependendo dos níveis de segurança estabelecidos para esse conjunto particular de informações.

Lógica

O acesso necessário a informações precisas é essencial para melhorar a qualidade e eficiência do processo de tomada de decisões da instituição financeira. É menos caro manter informações integrais em um único aplicativo e compartilhar que manter informações duplicadas em mais de um aplicativo.

A empresa tem muitas informações, mas elas estão armazenadas em centenas de bancos de dados incompatíveis. A velocidade com que as informações são obtidas, criadas, transferidas e absorvidas depende da capacidade da organização de compartilhar efetivamente essas ilhas de informações em toda a empresa.

Informações compartilhadas promovem melhores decisões, pois dependem menos de fontes menos confiáveis e informações gerenciadas no processo de tomada de decisões.

Implicações

Para permitir o compartilhamento de informações, um conjunto comum de políticas, procedimentos e normas deve ser desenvolvido e seguido para regular o gerenciamento de informações e o acesso de curto e longo prazos.

No curto prazo, para preservar um investimento significativo em sistemas existentes, são necessários investimentos em software capaz de migrar informações de um sistema existente para um ambiente de informações compartilhado.

É necessário desenvolver modelos de dados normalizados e metadados que definam esses ambientes compartilhados, além de um repositório para armazenar os metadados e torná-los acessíveis.

Quando os sistemas existentes são substituídos, acesso comum às informações e diretrizes para desenvolvedores devem ser adotados e implementados para garantir que todas as informações em novos aplicativos continuem disponíveis no ambiente compartilhado.

No curto e no longo prazo, métodos e ferramentas comuns para criar, manter e acessar informações compartilhadas devem ser adotados em toda a empresa.

O compartilhamento de informações significa uma mudança cultural significativa.

O princípio de compartilhamento de informações é confrontado constantemente com o princípio de segurança de informações. O compartilhamento de informações não deve comprometer a sua confidencialidade sob nenhuma circunstância.

Informações compartilhadas devem ser usadas por todos os colaboradores para realizar suas respectivas tarefas. Isso garante que apenas as informações mais atualizadas e precisas sejam usadas no processo de tomada de decisões. As informações compartilhadas devem tornar-se a única fonte virtual de informações corporativas.

Princípio 8. Informações acessíveis

Descrição

As informações estão acessíveis para que os usuários realizem suas respectivas tarefas.

Lógica

O acesso sem restrição às informações aumenta a eficiência e eficácia do processo de tomada de decisões e diminui o tempo de retorno das respostas para solicitações de informações e entregas de serviço. Os funcionários perdem menos tempo, e a consistência das informações é aprimorada.

Implicações

A acessibilidade envolve a facilidade com que os usuários obtêm informações.

A maneira em que as informações são acessadas e disponibilizadas deve ser flexível o suficiente para satisfazer um grande conjunto de usuários corporativos e seus respectivos métodos de acesso.

O acesso a informações não significa necessariamente conceder privilégios de acesso a usuários para modificá-las ou divulgá-las. Isso exige um processo educacional e a mudança da cultura da empresa.

Princípio 9. Terminologia comum e definições de dados

Descrição

Os dados são definidos de forma coerente em toda a empresa, e as definições são compreensíveis e podem ser acessadas por todos os usuários.

Lógica

Os dados usados no desenvolvimento de aplicativos deve ter uma definição comum para que os dados possam ser compartilhados. Uma terminologia em comum facilita a comunicação e promove diálogos eficientes. Além disso, dados e interfaces devem ser compartilhados entre diferentes sistemas.

Implicações

Nós acreditamos que essa questão seja tratada corretamente, pois há pessoas com funções de "administração de dados" e responsabilidades declaradas. No entanto, é necessário uma energia significativa adicional, além dos recursos aplicados nessa tarefa. Isso é essencial para desenvolver o ambiente de informações.

A empresa precisa, primeiro, estabelecer uma terminologia comum para as atividades de negócios. Essas definições devem ser usadas de maneira uniforme em toda a empresa.

Sempre que uma nova definição de dados é necessária, esforços em relação à definição devem ser coordenados e adaptados ao "glossário" de descrição de dados corporativos. O administrador de dados da empresa precisa ser responsável por essa coordenação.

As ambiguidades que surgem devido a várias definições de dados devem ser substituídas por uma definição aceita e entendida por toda a empresa.

Várias iniciativas de normalização de dados devem ser coordenadas.

Responsabilidades de administração de dados funcionais devem ser designadas.

Princípio 10. Segurança de informações

Descrição

As informações são protegidas com base na integridade, disponibilidade, confidencialidade, incontestabilidade e autenticidade. Cada informação é submetida a uma avaliação de segurança com base nesses cinco fatores.

A rastreabilidade de segurança inclui a concepção e aplicação adequadas do sistema de auditoria e das ferramentas de monitoramento.

Lógica

O compartilhamento e a divulgação abertos de informações devem ser balanceados com a necessidade de restringir a disponibilidade de informações confidenciais, proprietárias e sensíveis.

As leis e regulamentos atuais exigem privacidade de dados e, simultaneamente, permitem acesso livre e sem restrição. As informações temporárias (projetos em andamento para os quais a divulgação ainda não foi autorizada) devem ser protegidas para evitar especulação injustificada, erros de interpretação e uso impróprio.

Implicações

A adição de dados confidenciais e não confidenciais requer análises e procedimentos de "desconfidencialidade" para manter o controle apropriado. Os proprietários de dados e usuários funcionais devem determinar se a adição aumenta o nível de confidencialidade. Devem ser implementados políticas e procedimentos adequados para lidar com essa revisão, incluindo o processo de "desconfidencialidade".

É necessário considerar práticas atuais que envolvem o uso de sistemas separados para diferentes níveis de confidencialidade. Existe uma solução de software para separar dados confidenciais e não confidenciais? É mais caro gerenciar dados não confidenciais em um sistema confidencial. Atualmente, a única maneira de combinar ambos é colocar os dados não confidenciais no sistema confidencial, onde eles permanecem.

Para oferecer acesso apropriado a informações abertas e manter a segurança, as restrições de segurança devem ser identificadas e implementadas no nível dos dados, não no nível de aplicativo.

A segurança de dados pode ser aplicada para restringir o acesso a status de somente leitura ou sem leitura. Rótulos de sensibilidade devem ser estabelecidos para acesso a informações temporárias, decisivas, confidenciais, sensitivas ou proprietárias.

A segurança deve ser planejada nos elementos de dados desde o começo, e não incluída posteriormente. Sistemas, dados e tecnologias devem ser protegidos contra o acesso e manuseio não autorizados. A fonte de informações deve ser protegida contra modificações não autorizadas ou acidentais, fraude, catástrofe ou divulgação.

As informações devem ser classificadas de acordo com os cinco fatores estabelecidos neste princípio. É essencial quantificar o impacto financeiro de violar cada um para informações mais críticas.


Princípios de aplicativo

Princípio 11. Independência tecnológica

Descrição

Os aplicativos não dependem de opções tecnológicas específicas e, portanto, podem funcionar em diferentes plataformas tecnológicas. A arquitetura de TI deve ser planejada para reduzir o impacto das mudanças tecnológicas nos negócios.

Lógica

A independência de aplicativos tecnológicos permite que sejam desenvolvidos, adaptados e operados na melhor relação custo/benefício. Ou a tecnologia (que está sujeita a dependência de fornecedor e obsolescência) torna-se a motivação dos usuários em vez de seus requisitos.

Este princípio se baseia no conceito de que cada decisão de TI nos deixa dependentes de tal tecnologia. O propósito deste princípio é garantir que o software não dependa de um sistema operacional específico ou hardware em particular.

Implicações

Este princípio exige padrões que oferecem suporte para a portabilidade, geralmente chamados de padrões abertos.

Interfaces de programa de aplicativo (APIs) devem ser desenvolvidas para integrar os aplicativos existentes com ambientes operacionais e aplicativos desenvolvidos com base na arquitetura empresarial.

Middleware deve ser usado para desassociar aplicativos de soluções de software específicas.

Princípio 12. Aplicativos fáceis de usar

Descrição

Os aplicativos são fáceis de usar. A tecnologia é transparente para os usuários, portanto, permite que eles concentrem-se nas suas tarefas em vez de preocupar-se com problemas do sistema operacional.

Lógica

Quanto mais os usuários precisarem entender a tecnologia usada, menos produtivos eles serão. O conceito de fácil de usar é um reforço positivo para usar aplicativos. Ele encoraja os usuários a trabalhar dentro do ambiente de informações integradas, em vez de desenvolver sistemas isolados para realizar tarefas fora do ambiente corporativo integrado. A maior parte do conhecimento necessário para operar sistemas é muito semelhante. A formatação é mantida no mínimo, e o risco de mau uso do sistema é baixo.

Usar um aplicativo deve ser tão intuitivo quando dirigir um carro de outra marca.

Implicações

Todos os aplicativos devem ter a mesma aparência e layout. Portanto, é necessário desenvolver um layout padrão e implementar critérios de teste de usabilidade.

Princípio 13. Reutilização e simplicidade de componentes

Descrição

A arquitetura empresarial é desenvolvida sobre componentes reutilizáveis, modulares e de baixo acoplamento que implementam serviços.

A arquitetura de sistemas deve ser o mais simples possível de manter, mas atendendo a todos os requisitos de negócios e corporativos. Sempre que complexidade for necessária, ela deve ser encapsulada para promover a simplicidade das soluções desenvolvidas na arquitetura.

Lógica

Os componentes reutilizáveis representam oportunidades de reduzir o tempo e o custo do desenvolvimento de TI. Os componentes reutilizáveis alavancam investimentos no sistema atual. Os componentes modulares aumentam a capacidade dos sistemas de adaptar-se às necessidades de evolução, pois a mudança é isolada dos módulos afetados.

Implicações

A arquitetura estabelece padrões e diretrizes para desenvolver componentes de sistema.

Princípio 14. Adaptabilidade e flexibilidade

Descrição

Sistemas de TI são concebidos para gerar mudança e refletem alterações nas leis, necessidades sociais ou outros tipos de mudanças.

A adaptabilidade e flexibilidade reduzem a complexidade e promovem a integração, o que melhora as atividades de negócios de uma empresa.

Customização excessiva aumenta os custos e reduz a capacidade de adaptar-se.

Lógica

A adesão a esse princípio tem vários benefícios:

  • Permite que a infraestrutura suporte mudanças que ocorrem frequentemente nos processos de negócios em uma empresa.
  • Deixa a infraestrutura mais adaptável a mudanças de TI e pontos fortes do mercado de TI.
  • Permite a melhoria de processo de negócios.
  • Promove um processo de integração de sistema mais simples e rápido, com menos processos de revisão
  • Permite que os sistemas evoluam para adaptar-se às necessidades de negócios e às mudanças

Sistemas complexos com várias funções de dados e transacionais são difíceis de gerenciar e tornam as mudanças extremamente arriscadas.

O objetivo é evitar falhas de dependência que podem surgir em aplicativos com alta ligação.

Implicações

Inicialmente, pode ser necessário mais tempo para criar os sistemas e maior consideração sistêmica quando as operações passarem os limites tradicionais dos sistemas.

Os custos iniciais podem ser maiores, mas o processo de integração será menos caro.

Os sistemas durarão mais, portanto, o retorno será maior.

Um sistema pode não ser otimizado no curto prazo, mas apresentar ganhos de otimização no longo prazo.

É necessário estabelecer métricas de adaptabilidade e flexibilidade.

O desenvolvimento de aplicativos com base em componentes deve ser promovido e facilitado.

Um número mínimo de fornecedores, produtos e configurações deve ser mantido para permitir um mínimo de flexibilidade ao implementar mudanças.

Configurações excessivamente complexas de componentes, ajuste customizado indevido e customização de hardware e software com base em condições temporárias ou locais devem todos ser evitados.

A disciplina da configuração deve ser mantida, sacrificando o desempenho e a funcionalidade em alguns casos.

É necessário considerar as restrições de recursos.

Princípio 15. Convergência com a arquitetura empresarial

Descrição

A convergência com a arquitetura empresarial é promovida no momento certo e é alinhada à estratégia de investimento da empresa.

A convergência com a arquitetura empresarial é realizada à medida que novos aplicativos são desenvolvidos, novas tecnologias são implementadas e sistemas mais antigos são atualizados ou aposentados. Pode haver exceções à arquitetura empresarial em casos específico, se houver um consenso de que os benefícios de usar uma solução de uma tecnologia específica superam os benefícios da adoção da arquitetura.

Lógica

A convergência oferece as seguintes vantagens:

  • Permite que a arquitetura empresarial evolua e acomode mudanças nos negócios e nas tecnologias.
  • Evita a conversão de sistemas obsoletos, que são extremamente caros.
  • Ao longo do tempo, preserva o investimento enquanto promove os benefícios da arquitetura empresarial.

Implicações

Um atraso na convergência pode reduzir os benefícios da arquitetura empresarial.

A convergência exige uma abordagem realista e tangível para a migração para a arquitetura empresarial.

Requer uma estratégia de transição explícita para sistemas atuais após a tecnologia de destino ser identificada.

Permite desatribuir um sistema mais cedo, quando for apropriado.

A convergência não permite esperar para sempre. Requer um caso de negócios para exceções, um processo de exceção e uma estratégia de saída. Deve estabelecer exceções temporárias ou permanentes, além de estratégias de saída para exceções temporárias.

A convergência exige patrocínio para substituir tecnologias obsoletas.

Princípio 16. A arquitetura empresarial também aplica-se a aplicativos externos

Descrição

Quando novos contratos e acordos de terceirização forem firmados, eles devem refletir e incorporar os princípios de arquitetura empresarial.

Essa é uma das maneiras de manter a arquitetura empresarial alinhada com os negócios. As atividades terceirizadas não devem ser exceções à arquitetura apenas por serem terceirizadas.

Lógica

Para ter sucesso, a arquitetura corporativa deve ser integrada a todos os estágios de projetos de TI: concepção, planejamento e aquisição.

Implicações

As áreas de compra devem receber treinamento em arquitetura empresarial.

Isso exige parcerias e comunicação eficiente entre negócios, compras, gerenciamento de contrato e áreas de TI para obter os benefícios oferecidos pela arquitetura.

As aquisições de TI devem incluir requisitos com base na arquitetura empresarial.

A visão de investimentos dos negócios deve incluir os requisitos de TI.

Princípio 17. Interfaces de baixo acoplamento


Descrição

As interfaces têm baixo acoplamento, têm descrição própria e oferecem baixo impacto sobre a instituição financeira em caso de mudanças.

Lógica

As interfaces de baixo acoplamento são preferidas porque, quando interfaces entre aplicativos dependentes têm alto acoplamento, são menos genéricas e mais suscetíveis a causar efeitos secundários indesejados quando são alteradas.

Implicações

Baixo acoplamento significa que os serviços (APIs corporativas, por exemplo) são criados sem uma afinidade com certo consumidor do serviço.

Portanto, o serviço é totalmente desacoplado de um consumidor. No entanto, o consumidor do serviço depende do serviço (ou seja, contém referências para interfaces do serviço).

O serviço também é responsável pelo tratamento de exceção. O resultado é uma arquitetura de baixo acoplamento.

Princípio 18. Aderência a domínios funcionais

Descrição

As regras de negócios e funcionalidade de um sistema são consistentes com a missão do sistema. Há uma aderência completa ao domínio funcional em que o sistema está localizado.

Lógica

O propósito desse princípio é evitar redundância funcional entre os sistemas.

A redundância funcional pode causar perda da integridade de dados e aumentar os custos de manutenção relacionados à regra de negócios redundante.

Implicações

Os sistemas devem estar localizados em domínios funcionais, com definição explícita do gerente responsável pelo domínio.

Cada nova solicitação de funcionalidade deve ser enviada ao gerente respectivo.

Aplicativos que já estão em produção com redundância funcional devem ser substituídos inteira ou parcialmente em tempo hábil. A redundância funcional desses aplicativos não deve ser promovida.


Princípios de tecnologia

Princípio 19. Mudanças com base em requisitos

Descrição

Mudanças em aplicativos e tecnologias são implementadas apenas para atender a necessidades de negócios.

Lógica

Este princípio promove uma atmosfera na qual o ambiente de informações muda para refletir as necessidades de negócios, em vez de mudar os negócios para refletir as mudanças de TI. Isso garante que a operação do negócio seja a base para qualquer proposta de mudança.

Os efeitos involuntários das mudanças de TI nos negócios são minimizados.

Mudanças de tecnologia podem criar oportunidades para melhorar o processo de negócios e, consequentemente, alterar as necessidades de negócios.

Implicações

As mudanças em implementação seguem uma avaliação completa das mudanças propostas, com base na arquitetura empresarial.

Um desenvolvimento de sistema ou melhoria técnica não é implementado a menos que haja uma necessidade de negócios documentada.

Uma necessidade de negócios deve ser considerada, mas deve também ser alinhada com outros princípios de arquitetura empresarial. Deve haver um equilíbrio entre necessidades de negócios e operações de TI.

Princípio 20. Controle de diversidade técnica e fornecedores

Descrição

A diversidade tecnológica é controlada para minimizar custos significativos relacionados à manutenção de conhecimento e conectividade entre vários ambientes de processamento diferentes.

O gerenciamento de fornecimento deve focar no menor número de fornecedores possível para atender as necessidades de negócios e reduzir riscos.

Lógica

Há um custo real e significativo relacionado à infraestrutura necessária para suportar tecnologias para ambientes de processamento. Há outros custos de infraestrutura para manter a arquitetura de vários processadores interconectados.

A limitação do número de componentes e fornecedores suportados simplifica e reduz os custos de manutenção e gerenciamento.

Um número menor de fornecedores e pacotes de software representa maior facilidade e menores custos de integração.

As vantagens de negócios da diversidade técnica mínima incluem:

  • Empacotamento de componente padrão
  • Impacto de implementação previsível
  • Retornos e validações previsíveis
  • Testes definidos
  • Maior flexibilidade para acomodar avanços tecnológicos

Uma tecnologia em comum em toda a empresa gera economias escaláveis para a empresa. O gerenciamento técnico e os custos de suporte são melhor controlados quando os recursos limitados focam exclusivamente nesse conjunto de tecnologias compartilhadas.

Implicações

Políticas, padrões e procedimentos que regulam a aquisição de tecnologia ou a contratação de novos fornecedores devem ser diretamente ligados a esse princípio.

As decisões sobre tecnologia são orientadas pelo blueprint tecnológico.

É necessário desenvolver e implementar procedimentos para aumentar o conjunto de tecnologias aceitáveis para atender aos requisitos evoluídos.

Esse princípio não exige congelar a linha de base tecnológica. Avanços tecnológicos são bem-vindos e, incorporados ao blueprint tecnológico quando são compatíveis com infraestruturas atuais, devem melhorar a eficiência operacional, ou será preciso aumentar a capacidade.

A seleção de fornecedores contratados deve ser uma decisão estratégica, sempre considerando outros tipos de serviços que poderiam ser fornecidos pelo mesmo fornecedor.

Princípio 21. Interoperabilidade

Descrição

Software e hardware devem seguir padrões estabelecidos que promovam a interoperabilidade entre dados, aplicativos e tecnologia.

Lógica

Os padrões ajudam a garantir a coerência, melhorando a capacidade de gerenciar sistemas, aumentar a satisfação do usuário e proteger os investimentos em TI atuais, maximizando assim o retorno sobre o investimento e reduzindo os custos.

Os padrões de interoperabilidade também garantem o apoio de vários fornecedores a seus respectivos produtos, facilitando assim a integração.

Implicações

A interoperabilidade e os padrões de mercado devem ser seguidos, a menos que haja uma razão de negócios obrigatória para implementar uma solução não padrão.

Deve ser estabelecido um processo para estabelecer padrões, revisão periódica e exceções.

As plataformas de TI atuais devem ser identificadas e documentadas.


Resumo dos princípios

Princípios gerais

  1. Alinhamento entre TI e negócios
  2. Benefício máximo com o menor custo e risco
  3. Continuidade de negócios
  4. Conformidade com normas e políticas
  5. Adoção das melhores práticas para o mercado

Princípios de informações

  1. Informações tratadas como um ativo
  2. Informações compartilhadas
  3. Informações acessíveis
  4. Terminologia comum e definições de dados
  5. Segurança de informações

Princípios de aplicativo

  1. Independência tecnológica
  2. Aplicativos fáceis de usar
  3. Reutilização e simplicidade de componentes
  4. Adaptabilidade e flexibilidade
  5. Convergência com a arquitetura empresarial
  6. A arquitetura empresarial também aplica-se a aplicativos externos
  7. Interfaces de baixo acoplamento
  8. Aderência a domínios funcionais

Princípios de tecnologia

  1. 19. Mudanças com base em requisitos
  2. Controle de diversidade técnica e fornecedores
  3. Interoperabilidade

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=848587
ArticleTitle=21 princípios da arquitetura empresarial para o setor financeiro
publish-date=12072012