Universitários formados para exportação

Fonte: Jornal Sol

ATSI 7/7 - Conclusões

A metodologia seguida inicia-se com a definição da visão, missão e o ambiente de negócio em que a organização se enquadra. Delinearam-se os elementos fulcrais do negócio com recurso aos modelos das forças competitivas e da cadeia de valor.

Para fazer o levantamento dos processos de negócio, devem ser identificados os vários actores na organização para garantir uma visão completa. O resultado deverá ser uma listagem de processos coerentes com a perspectiva de cada actor e claramente complementares entre si, mas que no seu conjunto são difíceis de integrar numa só visão. Para resolver este problema, os processos devem ser reorganizados segundo o objectivo.

O levantamento das entidades informacionais deve seguir uma metodologia bottom-up. Os itens de informação necessários à execução dos processos devem ser identificados e agregados progressivamente, para formar entidades informacionais compostas por vários itens relacionados.

A identificação das aplicações deve seguir igualmente uma metodologia bottom-up. As aplicações candidatas devem ser propostas indivualmente e com nomes descritivos.

O impacto mais evidente na organização é o colmatar do fosso existente entre a visão de negócio e os sistemas informáticos. Tipicamente, quer a engenharia dos processos de negócio, quer a engenharia do software recorrem a muito detalhe, o que torna impossível a conversão de uma para outra linguagem de representação. A aproximação da Arquitectura de Sistemas de Informação desvaloriza o detalhe em ambos os lados, esbatendo a sua fronteira e criando a visão do conjunto focada no objectivo.

"One of the manifestations of the information processing profession’s youth is its tendency to dwell on detail. There is the notion that if we can get the details right, the end result will somehow take care of itself and we will achieve success. It’s like saying that if we know how to lay concrete, how to drill, and how to install nuts and bolts, we don’t have to worry about the shape or use of the bridge we are building. Such and attitude would drive a more mature civil engineer crazy."
- W.H. Inmon in “Building the Data Warehouse”


As metodologias abordadas para auxiliar a criação da arquitectura de aplicações envolvem os trabalhos de Spewak, Zachman e Inmon nesta área.

Uma das principais dificuldades na realização do levantamento de processos é conseguir uma visão por processos numa estrutura organizacional com divisão funcional (departamentos).

A metodologia de Spewak evidencia uma preocupação com a “forma de trabalho” para a obtenção da Arquitectura da Empresa, de onde se destaca o valor 80/20 como nível de detalhe necessário e suficiente. Além desta regra, conclui-se que ao identificar processos e identidades com algum detalhe é útil responder à pergunta “em que medida é que esse novo elemento identificará a existência de uma nova aplicação ou caracteriza melhor as aplicações existentes?”. Deste modo, pode-se averiguar da verdadeira importância dos processos e entidades levantadas.

Por outro lado, os documentos padrão apresentados por Spewak têm um nível muito elevado de detalhe que parece desalinhado com a regra dos 80/20.

A framework de Zachman, tem o seu principal valor na sua capacidade de identificar tudo o que é importante e decisivo na concepção de uma Arquitectura de Sistemas de Informação. A independência das ferramentas para identificar os elementos de cada célula da matriz (diagramas Entity Relationship, etc.), garantem a flexibilidade na sua aplicação. No entanto, tornam a framework difícil de ser utilizada como uma metodologia de construção da Arquitectura de Sistemas de Informação.

O trabalho de Inmon, é especialmente relevante na caracterização de dados e na cisão entre aplicações com dados operacionais e históricos. O uso das regras de Inmon, permitem caracterizar um dos factores tecnológicos mais importantes da aplicação: a natureza do seu repositório. Este repositório pode ter um de três tipos: repositório partilhado, repositório isolado ou repositório histórico (data warehouse).

ATSI 6/7 - Arquitectura Tecnológica

A arquitectura tecnológica define os tipos de tecnologia para suportar as aplicações que gerem e acedem à informação da organização. A definição destes ambientes pretende encarar a tecnologia de forma independente dos componentes funcionais e dos dados.

Os princípios tecnológicos propostos são:

Sistemas

• preferir sistemas abertos que sejam portáveis, escaláveis e que garantam a compatibilidade na interacção com outros sistemas;
  
• garantir o suporte ao multi-canal (atendimento directo, telefone, web, dispositivos móveis);
  
• definir, aplicar e auditar políticas de segurança respeitantes a todas as vertentes dos sistemas de informação: dados, software e hardware;
  

Comunicação

• utilizar protocolos de comunicação que sejam normas internacionais;
  
• facilitar o acesso aos sistemas promovendo a mobilidade e garantindo o débito adequado na comunicação;
  

Software

• preferir linguagens e ferramentas de programação abertas;
  
• utilizar metodologias estruturadas para o desenvolvimento de sistemas;
  

Dados

• capturar os dados relevantes apenas uma vez e o mais perto possível da fonte;
  
• minimizar a utilização de transacções distribuídas, preferindo manter a informação o mais perto possível do local onde é mais frequentemente utilizada;
  
• definir uma política de salvaguarda de dados e de recuperação de desastres adequada à importância de cada aplicação nos processos de negócio.
  
• preferir a utilização de bases de dados relacionais, utilizando SQL normalizado para aceder à informação;
  
• implementar o acesso a bases de dados numa camada própria;
  
• classificar todas as aplicações de acordo com o seu tipo principal de repositório: isolado, partilhado e histórico; e implementá-las no ambiente respectivo;
  

Interfaces

• definir, aplicar e auditar regras base comuns para as interfaces utilizador das aplicações, que facilitem a sua posterior integração. As principais características das interfaces deverão ser a simplicidade e a usabilidade;
  
• as aplicações deverão ter ou permitir a implementação de interfaces utilizador baseadas em tecnologias Web (HTML, etc.);
  
• as aplicações deverão ter ou permitir a implementação de interfaces programáticas baseadas em tecnologias de Web Services (XML, SOAP, etc.);
  

Sugerem-se os seguintes tipos de repositórios de dados para suportar as aplicações:

• repositório integrado - para as aplicações que partilham a maior parte dos dados umas com as outras;
  
• repositório isolado - para as aplicações cuja maior parte dos seus dados são de consumo próprio e apenas alguns são partilhados com outras aplicações;
  
• common data interface - repositório comum de dados onde são publicados os dados dos repositórios isolados que são partilhados (com o objectivo de garantir a independência computacional);
  
• repositório histórico (data warehouse) - para as aplicações que acedem a dados históricos apenas em modo de consulta.
  

O repositório integrado, os repositórios isolados e a common data interface deverão conter apenas dados operacionais. Toda a informação histórica deverá ser colocada no data warehouse. A principal razão para a separação física dos dados históricos dos dados operacionais é o tipo de acesso que se pretende e o tempo de resposta. No caso dos sistemas operacionais, são característicos os acessos frequentes de leitura e escrita a pequenos volumes de dados com tempos de resposta curtos. No caso dos sistemas de exploração de dados, são característicos os acessos a grande volume de dados, dispersos no tempo, de leitura e com tempos de resposta longos.

Em resumo:
Aplicações com repositório integrado - fazem a maior parte do processamento de dados resultantes da actividade.

Aplicações com repositório isolado, com publicação na common data interface - fazem um processamento de dados mais restritos, dispondo de repositórios de dados individualizados.

Aplicações com repositório de dados históricos - acedem ao repositório de dados históricos e executam pesquisas heterogéneas aos dados armazenados. Em regra geral são pesquisas de âmbito estratégico para apoio aos decisores.

A descrição da tecnologia de cada aplicação inclui os seguintes aspectos:

• Repositório – tipo de repositório da aplicação: integrado, isolado ou histórico;
  
• Tecnologia de armazenamento de dados – tipo de armazenamento de dados da aplicação: base de dados relacional ou ficheiros;
  
• Decomposição em camadas – arquitectura de camadas da aplicação: uma camada (monolítica), duas camadas (cliente - servidor) ou três camadas (apresentação - negócio - dados);
  
• Middleware – tipos de middleware utilizados pela aplicação - plataforma;
  
• Hardware – requisitos especiais da aplicação relativamente ao sistema computacional que a vai executar;
  
• Ambientes – ambientes necessários para suportar a aplicação durante o seu ciclo de vida (desenvolvimento, testes, pré-produção, produção);
  
• Interfaces – interfaces a desenvolver para a aplicação;
  
• Backup and disaster recovery – política de salvaguarda periódica de dados da aplicação e política de recuperação de desastres.
  

ATSI 5/7 - Arquitectura de aplicações

Um dos principais propósitos da definição da Arquitectura de Sistemas de Informação é resolver os problemas de incoerência e redundância nos dados e aplicações da organização.

A definição da Arquitectura de Processos de Negócio e a Arquitectura de Informação são o primeiro passo nesta definição, para garantir o alinhamento dos processos de negócio com as entidades informacionais.

O segundo passo consiste em utilizar as arquitecturas definidas e alinhadas entre si anteriormente, para conceber a Arquitectura de Sistemas de Informação. Esta concepção deve ter duas preocupações: o alinhamento dos sistemas de informação com os processos de negócio e, simultaneamente, o alinhamento dos sistemas de informação com as entidades informacionais. Assim sendo, assegura-se que os Sistemas de Informação suportam as acções desempenhadas pelos actores nos processos de negócio e que gerem exactamente a informação necessária (nem a mais, nem a menos).

Depois de definidas as aplicações, deve-se assegurar a conformidade futura a nível do alinhamento tecnológico, propondo uma Arquitectura Tecnológica e um Plano de Implementação

A arquitectura de aplicações define e descreve o conjunto de sistemas ideal para uma organização, identificando as inter-dependências existentes. O seu objectivo é identificar os componentes funcionais da arquitectura e assegurar que estes estão alinhados com o negócio e com a estratégia, promovendo a gestão eficaz da informação. Esta definição é independente da tecnologia.

O ponto de partida para esta definição é uma Matriz de CRUD que resume as Arquitecturas de Processos de Negócio e de Informação.

A metodologia para definir a arquitectura de aplicações é a seguinte:

• Análise da matriz inicial obtida pelo cruzamento dos processos de negócio com as entidades informacionais, identificando as principais concentrações de criação (C) e actualização (U) de entidades;
  
• Identificação de aplicações candidatas, com definição do nome e objectivo:
  
  • partindo directamente da matriz:
    
    • aplicações orientadas às entidades (colunas da matriz);
      
    • aplicações orientadas aos processos (linhas da matriz);
      
  • partindo do conhecimento do problema adquirido durante a definição dos processos de negócio e entidades informacionais;
    
• Criação da lista de aplicações eleitas, através da combinação das várias listas de candidatas com eliminação de aplicações repetidas e redundantes;
  
• Análise iterativa da matriz para identificação dos aglomerados correspondentes às aplicações. Agrupamento de entidades e processos por afinidade, através de permutas de linhas e colunas. Ajuste das aplicações eleitas;
  
• Definição da lista final de aplicações a propor, com descrição completa dos objectivos e das macro funcionalidades.
  

A descrição de cada aplicação deve incluir os seguintes aspectos;

• Objectivo – descrição dos problemas que a aplicação pretende resolver;
  
• Tipo de Sistema – classificação do tipo de sistema de acordo com o nível da organização em que é utilizado (TPS/KWS/MIS/DSS/ESS - ver abaixo);
  
• Macro Funcionalidades – descrição das principais funcionalidades da aplicação, agrupadas em módulos quando necessário;
  
• Interfaces de Integração – para permitir a integração com outras aplicações. Pode ser uma interface de programação aplicacional (API) ou uma interface de acesso aos dados;
  
• Processos Suportados – lista de processos de negócio suportados pela aplicação;
  
• Entidades Geridas – lista de entidades informacionais que são criadas, lidas, actualizadas ou eliminadas pela aplicação (CRUD);
  
• Entidades Consultadas – lista de entidades informacionais que são apenas lidas pela aplicação (R).
  

Os sistemas de informação servem as funções das organizações a diferentes níveis [ver Laudon e Laudon]. As áreas funcionais são tipicamente Vendas e Marketing, Produção, Finanças, Contabilidade e Recursos Humanos; os níveis são: Estratégico, Gestão, Conhecimento e Operacional. Os sistemas de informação são classificados em diferentes tipos, dependendo do nível da organização que assistem:

• Sistemas de Processamento de Transacções (TPS – Transaction Processing Systems) – sistemas do nível operacional, que registam as transacções diárias necessárias aos processos de negócio;
  
• Sistemas de Trabalho de Conhecimento (KWS – Knowledge Work Systems) –sistemas de apoio a trabalhadores especializados em áreas de conhecimento, na criação e integração de novo conhecimento na organização;
  
• Sistemas de Informação de Gestão (MIS – Management Information Systems) –sistemas ao nível de gestão utilizados para funções de planeamento, controlo e decisão baseados em relatórios rotineiros de resumo ou excepção;
  
• Sistemas de Apoio à Decisão (DSS – Decision Support Systems) – sistemas ao nível de gestão que combinam dados e modelos analíticos ou ferramentas de análise de dados para apoiar as decisões não rotineiras;
  
• Sistemas de Apoio Executivo (ESS – Executive Support Systems) – sistemas ao nível estratégico concebidos para auxiliar nas decisões não rotineiras, utilizando técnicas avançadas de comunicação e representação gráfica.
  

ATSI 4/7 - Matriz de CRUD

A matriz de CRUD apresenta um cruzamento entre processos de negócio e entidades informacionais, ou seja, permite visualizar que dados são usados (e de que forma) em cada processo de negócio.

A imagem seguinte apresenta um exemplo de uma matriz de CRUD:

Pesquisar mais exemplos

ATSI 3/7 - Arquitectura de Informação

A arquitectura de informação é a descrição das entidades informacionais necessárias para a realização dos processos de negócio da organização. Esta arquitectura identifica e define a informação fundamental para o negócio de forma independente das aplicações que irão existir, formando a base que vai permitir a gestão correcta da informação.

Sugere-se a seguinte metodologia para a identificação e definição das entidades informacionais:

• Listagem conjunta de entradas e saídas de um grupo de processos;
  
• Agregação dos itens de informação por afinidade;
  
• Definição de entidades candidatas, com indicação do respectivo dono;
  
• Agregação ou separação de entidades candidatas;
  
• Ajuste do nível de detalhe das entidades e seus atributos, tendo em conta o objectivo da modelação;
  
• Definição das entidades informacionais;
  
• Verificação da coerência global das entidades e da relação entre as entidades e os processos de negócio.
  

As entidades informacionais são apresentadas da seguinte forma:

• Código Identificador – EI x, onde x é um número;
  
• Nome – descreve a designação da entidade;
  
• Dono da Entidade – quem cria a entidade;
  
• Gestor da Entidade – quem gere a maior parte do conteúdo da entidade;
  
• Descrição – genérica da entidade;
  
• Identificador – atributos que permitem identificar uma instância da entidade informacional;
  
• Atributos Contidos – descrição dos atributos de informação contidos na entidade. Cada atributo é sumariamente descrito.
  

Cada atributo das entidades tem, por omissão, grau de derivação: primitivo; dimensão grau de privacidade: pública; dimensão temporal: tempo presente.

ATSI 2/7 - Arquitectura de Processos de Negócio

A arquitectura dos processos de negócio inclui a definição e a descrição sucinta dos processos de negócio, juntamente com a definição e descrição dos actores neles envolvidos. Os processos de negócio são sequências de actividades que atravessam horizontalmente a organização e consomem recursos, produzindo valor para os clientes. Os actores são papéis desempenhados pelos intervenientes nos processos de negócio.

Capturar as actividades da organização através de uma visão orientada aos processos tem vantagens em relação a uma visão orientada às funções internas da organização. A principal vantagem é partir do ponto de vista dos clientes, identificando situações a melhorar e casos de redundância na gestão da informação. Esta vantagem justifica o maior esforço que é dispendido na modelação para não se perder o contacto com a realidade da organização.

Utilizar actores para fazer o levantamento de processos permite enriquecer a modelação produzida. Os actores do cliente devem definir os principais processos, enquanto que os restantes actores definem os restantes processos de apoio. Apesar disto, em cada processo, todos os actores são considerados igualmente importantes, i.e. não há distinção entre actores principais e secundários.

A vantagem de utilizar o actor como abstracção do utilizador e da unidade organizacional que participa no processo reflecte-se na maior adaptabilidade da modelação a alterações estruturais. Deste modo, a descrição de um processo mantém-se praticamente igual, mesmo que a unidade organizacional que o suporta mudar.

Tendo em conta estes aspectos, sugere-se a seguinte metodologia para construir a arquitectura de processos:

• Identificação e definição dos actores envolvidos na organização;
  
• Levantamento detalhado de processos para cada actor;
  
• Combinação das diferentes perspectivas dos actores, utilizando os objectivos dos processos como critério agregador;
  
• Ajuste do nível de detalhe, tendo em consideração o objectivo da modelação;
  
• Verificação da coerência global entre os processos.
  

Os processos de negócio devem ser apresentados da seguinte forma:

• Código Identificador – PN x, onde x é um número;
  
• Nome – descreve o objectivo do processo;
  
• Actores – envolvidos no processo;
  
• Entidades Externas – envolvidas no processo (opcional);
  
• Processos Precedentes – processos que têm obrigatoriamente que se realizar antes do processo (opcional);
  
• Descrição Sumária – descrição das actividades do processo e da participação dos actores;
  
• Entradas – informação consumida pelo processo;
  
• Saídas – informação produzida pelo processo.
  

Quer as entradas, quer as saídas são entidades informacionais, com indicação dos atributos utilizados (quando são um conjunto restrito) e indicação do tipo de acesso CRUD - Create, Read, Update, Delete - Criar, Ler, Actualizar, Apagar. No cruzamento com os processos de negócio, deve referir-se onde é que a disponibilidade, segurança e coerência têm requisitos especiais.

ATSI 1/7 - Introdução

O objectivo da Arquitectura Tecnológica de Sistemas de Informação (ATSI) de uma organização é definir um conjunto de sistemas de informação, não redundante, adequado à realidade da organização e com flexibilidade suficiente para permitir ajustes à evolução do modelo de negócio.

Para alinhar a arquitectura a propor com a realidade, deve começar-se por analisar a organização e identificar o cliente, definir uma visão e missão. Por outras palavras, é necessário definir o problema antes de propor uma solução.

Pode-se caracterizar o contexto da organização através do modelo das forças competitivas de Michael Porter que dá uma visão de indústria: clientes, fornecedores, novas entradas e produtos substitutos. É também relevante estudar a cadeia de valor que caracteriza as actividades e serviços prestados pela organização identificando as actividades principais e as actividades de suporte.

A definição da Arquitectura de Sistemas de Informação é estruturada, normalmente, em cinco etapas:

• Arquitectura de Processos de Negócio;
  
• Arquitectura de Informação;
  
• Arquitectura de Aplicações;
  
• Arquitectura Tecnológica;
  
• Plano de Implementação.
  

Os processos de negócio e as entidades informacionais formam a base para considerar as diferentes dimensões do problema. A arquitectura de processos descreve a abordagem seguida no levantamento de processos de negócio, descrevendo a metodologia, actores e entidades externas. A arquitectura de informação descreve a definição das entidades informacionais.

ATSI - Arquitectura de Sistemas de Informação

Vou publicar uma série de posts com excertos adaptados de um trabalho sobre Arquitectura de Sistemas de Informação que realizei no meu Mestrado com os colegas Inês Barreto, Marta Guerra e Gabriel Pestana.

O objetivo desta série de publicações é apresentar um resumo da disciplina de arquitecturas de sistemas de informação, que permite dar uma ideia de como começar a resolver problemas informáticos complexos em organizações.

As referências do trabalho são as seguintes:

[Fowler99] – Martin Fowler with Kendall Scott, UML Distilled - 2nd edition , Addison-Wesley, 1999

[Inmon93] – W.H. Inmon, Data Architecture - The Information Paradigm - 2nd edition, QED Technical Publishing Group, 1993

[Inmon96] – W.H. Inmon, Building the Data Warehouse - 2nd edition, John Wiley & Sons, 1996

[InmonZachmanGeiger97] – W.H. Inmon, John A. Zachman, Jonathan Geiger, Data Stores Data Warehousing and the Zachman Framework - Managing Enterprise Knowledge, McGraw Hill, 1997

[Laudon02] – Kenneth C. Laudon, Jane P. Laudon, Management Information Systems – 7th Edition, Prentice Hall, 2002

[Spewak93] – Steven Spewak, Steven Hill, Enterprise Architecture Planning, John Wiley & Sons, 1993

[ZIFA03] – Zachman Institute for Framework Advancement Website, 2003

Papa Francisco sobre as Mães

Para inspirar as mães...

Palavras do Papa Francisco
no final da recitação do Santo Rosário
na Basílica de Santa Maria Maior
4 de maio de 2013

Uma mãe ajuda os filhos a crescer e deseja que cresçam bem; por isso, educa-os a não cederem à preguiça — que deriva inclusive de um certo bem-estar — a não se abandonar a uma vida confortável, que se contenta simplesmente com os objectos. A mãe cuida dos filhos para que cresçam cada vez mais, cresçam fortes e se tornem capazes de assumir responsabilidades, de se comprometer na vida e de propender para grandes ideais.
(...)

Além disso, uma mãe pensa na saúde dos filhos, educando-os também para enfrentar as dificuldades da vida. Não se educa, não se cuida da saúde evitando os problemas, como se a vida fosse uma auto-estrada sem obstáculos. A mãe ajuda os filhos a ver com realismo os problemas da vida e a não se perder neles, mas a enfrentá-los com coragem, a não ser frágeis e a sabê-los superar, num equilíbrio sadio que uma mãe «sente» entre os âmbitos de segurança e as áreas de risco. E uma mãe sabe fazer isto! Não leva sempre o filho pelo caminho da segurança, porque desta forma o filho não pode crescer, mas também não o deixa unicamente na vereda do risco, porque é perigoso. Uma mãe sabe equilibrar as coisas. Uma vida sem desafios não existe, e um jovem ou uma jovem que não sabe enfrentá-los, pondo-se em jogo, é um jovem e uma jovem sem espinha dorsal!
(...)

Um último aspecto: uma boa mãe não só acompanha os filhos no crescimento, sem evitar os problemas e os desafios da vida; uma boa mãe ajuda também a tomar as decisões definitivas com liberdade. Isto não é fácil, mas uma mãe sabe fazê-lo. Mas o que significa liberdade? Sem dúvida, não é fazer tudo o que queremos, deixar-nos dominar pelas paixões, passar de uma experiência para outra sem discernimento, seguir as modas do tempo; liberdade não significa, por assim dizer, lançar da janela tudo o que não nos agrada. Não, a liberdade não é isto! A liberdade é-nos concedida para que saibamos fazer escolhas boas na vida! Como boa mãe, Maria educa-nos para sermos como Ela, capazes de fazer escolhas definitivas; escolhas definitivas, neste momento em que reina, por assim dizer, a filosofia do provisório. É muito difícil comprometer-se na vida de maneira definitiva. E Ela ajuda-nos a fazer escolhas definitivas com aquela liberdade integral e com a qual Ela mesma respondeu «sim» ao plano de Deus sobre a sua vida.

http://www.vatican.va/holy_father/francesco/speeches/2013/may/documents/papa-francesco_20130504_santo-rosario_po.html