Carta de Princípios de Arquitetura

Não é incomum nós da área de arquitetura sermos envolvidos em projetos de TI somente quando o projeto dá problemas ou após a definição técnica da solução e fornecedor. Time too late.

Sobre este assunto, eu estava conversando com um amigo que também é gestor de uma área de arquitetura corporativa e compartilhamos esta, entre outras dificuldades que vivenciamos. É impressionante como os profissionais de TI nas empresas brasileiras não se enquadram nos modelos de governança centralizada, onde é exercida gestão e direcionamento para todos os projetos.

Para minimizar o “estrago” proveniente deste comportamento minha sugestão é seguir a recomendação da fase preliminar do ciclo do ADM, a criação e utilização de uma carta de princípios de arquitetura (CPA). Para os colegas que já estão acostumados com políticas corporativas de segurança a CPA  é algo similar.

No cenário recomendado pelo TOGAF a CPA deve variar por projeto, cada projeto deve estabelecer os princípios que serão considerados para nortear as decisões que os stakeholders realizarão durante o projeto. Mas para chegar neste cenário é importante ter a definição da CPA fundamental, ou seja, a coletânia dos princípios mais importantes e a forma de trabalhá-los como um “lego” e incorporá-los aos projetos conforme a necessidade.

 

Disposições gerais sobre a carta dos princípios de Arquitetura Corporativa

Introdução

O objetivo da CPA é orientar todos os stakeholders no que concerne aos padrões arquiteturais de TI para os projetos onde O TOGAF foi escolhido como framework mandatório, didaticamente, conceitos e implicações dos domínios e acordos arquiteturais, que além de atenderem as recomendações dos frameworks de TI adotados (ITIL, ISO27001, TOGAF e PMO) pela TI, devem ser utilizados como direcionadores na construção e disponibilização de soluções de TI para a corporação e também como oportunidade de melhoria contínua dos parâmetros e indicadores.

 

Definições

Os princípios de arquitetura são definições de alto nível, de valores fundamentais que orientam o processo de tomada de decisões em TI. Tais valores ou princípios serão utilizados como base para a construção de soluções de TI, políticas de desenvolvimento e normas. Além disso, não serão abordadas na carta de princípios de arquitetura, tecnologias ou fabricantes específicos como padrões arquiteturais. Cada princípio de arquitetura deve focar principalmente em metas tangíveis para os usuários dos serviços de TI. Por questões didáticas designamos como aplicativos, toda solução sistêmica baseada em software e chamamos de tecnologia todos os recursos de infraestrutura que suportem a existência dos aplicativos.

 

Revisão das soluções e comunicação

Todos os profissionais envolvidos no processo de construção e disponibilização de soluções de TI são responsáveis por conhecer e seguir a carta de princípios arquiteturais. No ato de sua aprovação formal, as soluções propostas serão avaliadas em um comitê de revisão de projetos e um laudo de conformidade será gerado com base nos Princípios de Arquitetura.

Para tornar o processo de revisão transparente, os resultados das atividades de controle realizadas pelo comitê de avaliação de arquitetura, bem como as informações oriundas dos projetos e profissionais nele envolvidos, serão disponibilizadas para todos os interessados. A comunicação do processo de revisão acontecerá dentro do ciclo de projetos. Todos os profissionais, devem ter em mente seu respectivo papel no projeto e quais são as informações importantes a serem comunicadas.

 

Estrutura do documento

Cada princípio será declarado formalmente. O método definido segue o formato sugerido pelo The Open Group Architecture Framework TOGAF 9.1, 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 clara e objetiva a regra fundamental.
  • 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.
  • 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.

 

O conteúdo completo sobre os princípios de arquitetura pode ser encontrado na URL do Open Group e também há mais algumas sugestões de princípios. Abaixo vou listar 10 sugestões de princípios que podem constar na CPA e que em minha opinião são bastante relevantes.

 

1 – Princípio – Alinhamento entre as unidades de negócio e a TI

Descrição

As decisões de TI sobre a implementação de novos aplicativos ou mesmo o cuidado do ambiente atual são sempre tomadas sob a perspectiva do alinhamento entre a TI e as respectivas áreas de negócios.

Lógica

Deve existir uma coesão entre os requisitos do negócio e as possibilidades de TI, e a partir deste alinhamento entre a necessidade e a possibilidade, deve gerar uma solução para suportar um novo processo de negócio ou uma obrigação legal.

Implicações

Ajustar as entregas de TI com a demanda gerada pelas áreas de negócios demandantes 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 é capaz de promover essas mudanças. Baseado nos padrões arquiteturais, a TI deve direcionar suas soluções visando atender o negócio com melhor custo benefício. O gerenciamento de TI deve incluir um catálogo com as soluções disponíveis, indicadores de disponibilidade e ciclo de vida. Além disso, os padrões arquiteturais devem ser divulgados para que os critérios de decisão sejam amplamente conhecidos pelos colaboradores da empresa. Algumas áreas devem renunciar às suas preferências específicas para o benefício da empresa como um todo.

2. – Princípio – Custos, benefícios e proteção do investimento

Descrição

As decisões estratégicas das soluções devem buscar maximizar os benefícios gerados para os negócios com o menor risco e com o melhor TCO (Total Coast of Ownership do Inglês, Custo Total de Propriedade) possível. Além disso, as soluções devem proteger ao máximo o investimento realizado.

Lógica

O critério de custo não será o único direcionador nas definições que envolverem projetos de TI, quer seja de aplicações ou suas respectivas necessidades de infraestrutura. As decisões serão avaliadas inicialmente sobre o prisma dos requisitos de negócio, prazos de entrega, qualidade, riscos e benefícios. É sabido que soluções com custos muito abaixo da média de mercado podem apresentar maiores riscos ou menor qualidade e que pode acarretar num TCO maior ou reduzir os benefícios provenientes do projeto. Além disso, serão considerados os fatores referente a proteção dos investimentos realizados, cuidando do nível de obsolescência dos ativos e preservando o máximo possível o investimento realizado em TI.

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 quantificar seus benefícios. Sempre que possível, é recomendado o cálculo do retorno do investimento realizado no projeto de implementação ou adoção de um aplicativo. O estudo com o TCO versus a projeção de recuperação dos investimentos deve ser submetido ao comitê de PMO que decidirá sobre a execução ou não do projeto.

Os riscos operacionais da não existência da aplicação devem ser quantificados sempre que possível. A infraestrutura de TI deve ser otimizada com base em requisitos de negócios e capacidade tecnológica de gerar custos e riscos menores, beneficiando assim, o resultado da empresa. O prazo mínimo de ciclo de vida considerado para as soluções de TI é de 3 anos, ou seja, nenhuma solução deverá ser trocada ou considerada obsoleta num período menor do que o declarado. Também será avaliada toda a solução que estiver sendo sugerida ou considerada para que não seja implementada qualquer solução já em seu ciclo final de vida, suporte e comercialização.

3 – Princípio –  Disponibilidade e velocidade 

Descrição

Os aplicativos devem estar disponíveis para serem utilizados sempre que requeridos pelas áreas de negócio. Todos os recursos tecnológicos que suportam o seu funcionamento devem ser dimensionados para atender a demanda de uso. Este item específico não trata apenas da disponibilidade do recurso, mas também a velocidade necessária para que o uso seja considerado satisfatório pelo usuário.

Lógica

Em fase de projetos, a TI deve verificar com a respectiva área de negócio quais são os parâmetros de disponibilidade e velocidade necessários para a aplicação e fazer todas as adequações necessárias no ambiente de TI para suportar a função de negócio de forma assertiva, sem excessos geradores de custos retidos e desnecessários, mas também, sem subestimar as necessidades, evitando assim, “gargalos”, tanto por conta de paradas, quanto por conta de lentidão excessiva dos recursos.

Implicações

As soluções de TI devem estar disponíveis sempre que forem requeridas, mas em caso de queda por algum motivo alheio à vontade da TI – os tempos de recuperação devem ser conhecidos e pré-acordados com os principais usuários do aplicativo em questão.
Todos os aplicativos devem ter um SLA (Service Level Agreement do inglês, Nível de Serviço Contratado) conhecido e assinado pelo usuário responsável pelo uso do aplicativo. De preferência além do SLA de disponibilidade, deve-se buscar parâmetros de velocidade que atendam à demanda do negócio quanto à volumetria de processamento. (SLA de Performance/Desempenho).

4 – Princípio –  Simplicidade e acessibilidade

Descrição

Os aplicativos devem ser fáceis de usar e a tecnologia que os suporta deve ser transparente para os usuários, permitindo que eles concentrem-se nas suas atividades principais. As informações geradas através dos aplicativos devem estar acessíveis e inteligíveis para que os usuários realizem suas respectivas tarefas. Sistemas de TI são concebidos para suportar atividades de negócio e não devem por definição de TI alterar o processo de negócio a menos que haja um consenso que uma adequação é necessária e que irá gerar valor no final da cadeia de utilização do aplicativo.

Lógica

Quanto mais os usuários precisarem entender a tecnologia usada, menor será a sua produtividade. O conceito KIS (Keep it Simple, do Inglês faça de forma simples) é 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 homogêneo. 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.
A adoção de sistemas cliente servidor estão fortemente desencorajadas, pois estes requerem gerenciamento descentralizado, são mais complexos sobre vários pontos de vista e tornam as mudanças extremamente arriscadas e mais caras.

Implicações

Quando possível os aplicativos devem ter a mesma aparência e layout de aplicativos já existentes. Portanto, é recomendado desenvolver um layout padrão e implementar critérios de teste de usabilidade. 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 às informações não significa necessariamente conceder privilégios de acesso a usuários para modificá-las ou divulgá-las. Isso exige um processo de conscientização e mudança na cultura da empresa. 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.

Aplicações web não podem estar vinculadas a um determinado tipo de navegador, elas devem ser totalmente agnósticas quanto ao fabricante do navegador.

5 – Princípio –  Integração de sistemas e reuso de serviços 

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. Software e hardware devem seguir padrões estabelecidos que promovam a interoperabilidade entre dados, aplicativos e tecnologia.

A arquitetura empresarial é desenvolvida sobre componentes reutilizáveis, modulares e deve ser de simples manuseio e atender aos requisitos de negócios. Sempre que algum grau de complexidade for requerido, ele deve ser encapsulado para promover a simplicidade das soluções.

Lógica

O acesso necessário a informações consistentes é essencial para melhorar a qualidade e eficiência do processo de tomada de decisões. O custo e o trabalho necessário de se manter informações centralizadas é menor do que manter informações descentralizadas em mais de um aplicativo. Os padrões ajudam a garantir a coerência, melhorando a capacidade de gerenciar sistemas, aumentando a satisfação do usuário e protegendo os atuais investimentos em TI, maximizando assim, o retorno sobre o investimento (ROI – Return on Investment, do Inglês Retorno sobre investimentos).

Os padrões de interoperabilidade também garantem o apoio de vários fornecedores a seus respectivos produtos, facilitando assim, a integração entre aplicativos. 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 nos módulos afetados.

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 capazes de migrar informações de um sistema existente para outro ambiente.
É 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. 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.
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 praticado um processo que estabeleça padrões, revisões periódicas e exceções. A arquitetura estabelece padrões e diretrizes para desenvolver componentes de sistema.
Integrações utilizando-se de database links (DBLink) é altamente desencorajada pelo alto nível de acoplamento que ela produz nos bancos de dados conectados. Casos excepcionais que requeiram DBLinks como única forma de conexão deverão conter aprovação executiva para serem realizados.
Por outro lado, tecnologias que promovem dinamismo e confiabilidade em integrações de sistemas e dados de forma online e offline, tais como SOA e ETL, são encorajadas. Integrações por meio de API´s também são vistas como simples, efetivas, seguras. E por isso fomentadas em boas práticas da arquitetura.

6 – Princípio –  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 devem ter uma definição comum para que seja possível o compartilhamento entre as aplicações. Uma terminologia em comum facilita a comunicação e promove diálogos eficientes.

Implicaçõ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 às várias definições de dados devem ser substituídas por uma única definição aceita e entendida por toda a empresa.
Várias iniciativas de normalização de dados devem ser coordenadas.

7 – Princípio –  Segurança é responsabilidade de todos os stakeholders

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 classificação da informação para manter o controle apropriado. É necessário considerar práticas atuais que envolvem o uso de sistemas separados para diferentes níveis de confidencialidade e sua integração mandatória com o IDM corporativo (do Inglês, Identity Management).

Para oferecer acesso apropriado a informações e manter a segurança, as restrições de segurança devem ser autorizadas e autenticadas de forma centralizada, com fluxos de aprovação por alçada e com rastreabilidade. 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 públicas, internas, confidenciais e sensitivas. 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.
Além dos direcionadores encontrados no TOGAF a área de Arquitetura Corporativa segue a Política de Segurança da Informação mantida pela área de Segurança Corporativa e divulgada na intranet.

8  – Princípio –  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. Este princípio rege sobre a independência da TI Corporativa em face aos fabricantes de TI. Os padrões atuais estão divulgados na intranet corporativa e devem ser seguidos, o intuito deste princípio é demonstrar a isonomia dos padrões estabelecidos.

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 à 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 ou vice versa.
Isso aplica-se a todo e qualquer fornecedor de tecnologia, sistema ou serviço. Deve-se ter independência e evitar as mais diversas formas de “Lock In”.

Implicações

Este princípio exige padrões que oferecem suporte para a portabilidade, geralmente chamados de padrões abertos. Interfaces de programa de  plicativo (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. Os demais padrões estão disponíveis na intranet corporativa e também na seção de documentos complementares no início deste documento.


Glossário

Descrição dos acrônimos ou termos de TI utilizados.

Handover – Processo formal de transição de papeis e responsabilidades, normalmente é uma das fases de projetos e considera a transição de um ambiente não produtivo para o status de produtivo.

Interoperabilidade é a capacidade de um sistema (informatizado ou não) de se comunicar de forma transparente (ou o mais próximo disso) com outro sistema (semelhante ou não)

ITIL – (Information Technology Infrastructure Library do inglês Biblioteca de Infraestrutura para a Tecnologia de Informação) – é um conjunto de boas práticas para serem aplicadas na infraestrutura, operação e manutenção de serviços de tecnologia da informação

ETL (Extract Transform Load do inglês Extração Transformação Carga) – são ferramentas de software cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de negócios e pôr fim a carga dos dados

PMO – (Project Management Office do inglês Escritório de Projetos) – é do que um departamento dentro das organizações que tem por missão de manter uma visão integrada do plano estratégico em toda a cadeia de valor da organização e o objetivo de garantir a implementação dentro do prazo e custo definidos no plano estratégico.

QA (Quality Assurance do inglês Garantia da Qualidade – é o processo que garante a qualidade do desenvolvimento de softwares focalizando todas as etapas e artefatos produzidos pelo desenvolvimento. Assegurando que todos eles estejam em conformidade com as necessidades predefinidas.

Roadmap – é uma espécie de “mapa” que visa organizar as metas de desenvolvimento de um software ou tecnologia. Nele podem ser encontradas ainda as possíveis datas de lançamento das próximas versões, bem como um registro do lançamento e notas das versões anteriores.

ROI (Return on investment do inglês Retorno Sobre Investimento) – é a relação entre a quantidade de dinheiro ganho (ou perdido) como resultado de um investimento e a quantidade de dinheiro investido.

SaaS (Software-as-a-Service do inglês Arquitetura Orientada a Serviços) – é uma forma de distribuição e comercialização de software. No modelo SaaS o fornecedor do software se responsabiliza por toda a estrutura necessária para a disponibilização do sistema (servidores, conectividade, cuidados com segurança da informação) e o cliente utiliza o software via internet, pagando um valor pelo serviço oferecido.

SOA (Service-Oriented Architecture do inglês Arquitetura Orientada a Serviços) – é um princípio de arquitetura de software onde as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços.

TOGAF – (The Open Group Architecture Framework do inglês O grupo aberto de arquitetura) – é um framework de arquitetura corporativa que provê uma abordagem global ao design, planejamento, implementação e governança de uma arquitetura corporativa.

ROADMAP – é uma visão estendida do futuro de um campo escolhido de investigação composto de uma coletânea de conhecimento. Nele podem ser encontradas as possíveis datas de lançamento das próximas versões, bem como um registro do lançamento e notas das versões anteriores.

API – (Application Programming Interface, do inglês Interface de Programação de Aplicativos) – é um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades por aplicativos que não pretendem envolver-se em detalhes da implementação do software, mas apenas usar seus serviços.

IDM – (Identity Management, do inglês Gerenciamento de Identidade e Acesso) – é o processo, políticas, práticas e tecnologias para proporcionar acesso aos recursos e informações, baseado em regras de negócio associadas com papéis e perfis dentro da organização, de maneira segura.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Você pode gostar...

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *