Luís Vidigal Vogal do Conselho de Direcção do Instituto de Informática do Ministério das Finanças
“As ASI têm uma visão
holística e interdisciplinar”
A recessão económica dos últimos
anos e a evidência de um excesso
e/ou grande desaproveitamento
da base instalada de equipamentos
e sistemas de tecnologias de
informação (TI) veio alterar
profundamente o mercado e o
comportamento das organizações,
sobretudo no que respeita à
política de investimentos em TI.
esmo conscientes de que as TI são ferra-mentas indispensáveis para a sobrevivência e sucesso da organização, estas exigem hoje uma espécie de quadratura do círculo: fazer mais, melhor e mais rápido com o mesmo ou menos, gastando menos. Hoje, o desafio de todas as organizações consiste numa combinação que passa por reduzir custos, melhorar a eficiência, aumentar a eficácia, sem deixar de crescer o negócio. A Integração é a nova palavra de ordem e o conceito e modelo de Arquitectura de Sistemas de Informação (ASI) emerge, de novo, como a fór-mula mágica. De entre estes, destaca-se da ASI da autoria de John Zachman, também conhecida por modelo Zachman.
Luís Vidigal, presentemente vogal do Conselho de Direcção do Instituto de Informática do Ministério das Finanças, con-siderado o “pai” do Infocid, percursor do eGovernment em Portugal, é um dos maiores conhecedores e especialistas nacionais em arquitecturas de sistemas de informação. Nesta entrevista aos “Cadernos”, explica-nos a sua importân-cia e actualidade, designadamente, do modelo de Zachman. Afinal, o que é e em que consiste o modelo de Zachman? O modelo de Zachman tem a pretensão de enquadrar e classificar todas as ferramentas e documentos necessários à resolução de problemas complexos no âmbito dos sis-temas e tecnologias de informação, através de uma “plan-ta” a duas dimensões. Trata-se de uma generalização didáctica e metafórica aos sistemas e tecnologias de infor-mação dos métodos e práticas da arquitectura e engenharia tradicionais do meio físico, que no caso dos sistemas de informação ainda carecem de maturidade e rigor metodológico, uma vez que os seus métodos e técnicas ainda estão longe de ser estáveis, sistemáticos e
satis-M
fatórios. A arquitectura de Zachman visou introduzir 30perspectivas diferentes em relação ao mesmo sistema de informação, tornando as diferentes valências verdadeira-mente complementares e integradas para a viabilização do resultado global. O objectivo é formalizar e uniformizar a representação dos sistemas de informação, de modo a garantir, a integração dos diversos componentes de infor-mação da organização e facilitar a sua mudança e transfor-mação.
Quais são as suas principais características, funcionali-dades e metodologias?
A arquitectura de Zachman consiste num quadro de refe-rência a duas dimensões, constituída por cinco níveis na vertical que vão da representação simbólica à representação física, designadamente no que se refere ao âmbito, modelo de negócio, modelo do SI, modelo tecnológico e represen-tações detalhadas. Estes níveis são cruzados na horizontal com seis perspectivas de abordagem, nomeadamente dados (o quê), processos (como) e redes (onde), na versão original de 1987 e pessoas (quem), tempo (quando) e moti-vações (porquê) na extensão efectuada em 1992. Daqui resultam 30 caixas em matriz, capazes de enquadrar as fer-ramentas e documentos necessários à resolução de proble-mas complexos no âmbito dos sisteproble-mas e tecnologias de informação.
Do seu ponto de vista, qual é a sua importância hoje para os profissionais de Sistemas de Informação?
A história das metodologias relacionadas com os sistemas e tecnologias da informação estão cheias de avanços e recu-os, fortemente influenciados pelos enfoques fundamenta-listas em que cada um se colocou para abordar o mesmo
ascendentes (bottom-up), a necessidade de responder
rapi-damente ao mercado (time to market), as pressões
“prag-máticas” e os constrangimentos financeiros, entre outros motivos, conduziram à desvalorização do formalismo metodológico, capaz de responder hoje aos desígnios tão esperados da interoperabilidade semântica e tecnológica dos vários sistemas de informação que, entretanto, foram crescendo como cogumelos isolados.
A minha experiência situa-se sobretudo no interior das administrações públicas e da importância que as arquitec-turas dos sistemas de informação possuem para o proces-so de reforma do Estado, enquanto sistema complexo, com recurso às tecnologias de informação e comunicação. O que verifico é que cada vez as pressões vêm mais no senti-do de se comprar precipitadamente soluções sem primeiro se reflectir nos problemas que seria suposto resolver. As frustrações e os desencantos dos profissionais de sistemas de informação, são a demonstração da ausência de uma planta arquitectónica que coloque cada actor (profissional, gestor ou político) no seu lugar e no seu correspondente papel.
Porque é que a ASI de Zachman é considerada uma refe-rência no mercado e entre os utilizadores? Qual é a sua actualidade?
Zachman definiu a Arquitectura da Empresa como o conjun-to de representações necessárias à descrição de um Sistema/ Empresa (ou conjuntos de sistemas) com vista à sua con-strução, manutenção e evolução. Zachman influenciou deci-sivamente os modelos referenciais das administrações
públi-cas em todo o mundo, nomeadamente a FEA (Federal
Enterprise Architecture) dos EUA, o SAGA (Standards and Architectures for e-Government Applications) da Alemanha, o Interoperability Framework for the Common-wealth Government
da Austrália, o REACH - Public Services Broker da Irlanda, o
e-GIF (e-Government Interoperability Framework) do Reino
Unido, etc. Na 37a Conferência do ICA (
International Council for Information Technology in Government Administration) no
final do ano passado, várias delegações nacionais afirmaram convictamente que não valia a pena inventar novos referên-ciais para as arquitecturas dos sistemas de informação na administração pública, pois “quando nos referimos a
arqui-tecturas referimo-nos ao framework de Zachman”.
END = Class Of Business Objectives CYCLE = Class Of Business Cycles PEOPLE = Class Of Business Organizations NODE = Class Of Business Locations ENTITY = Class Of Business Entities PROCESS = Class Of Business Processes FUNCTIONING ENTREPRISE TECHNOLOGY MODEL (Physical) Builder Subcontractor DETAILED REPRESENTATIONS (Out-of-context) Owner BUSINESS MODEL (Conceptual) Planner SCOPE (Contextual) SYSTEM MODEL (Logical) Designer
e.g., Data e.g., Function e.g., Network e.g., Organization e.g., Schedule e.g., Strategy
e.g. Network Architecture
NODE = Addresses LINK = Protocols e.g., Data Definition
ENTITY = Field RELATION = Address
e.g., Program
I/O = Control Block
PROCESS = Lang. Statement
e.g. Security Architecture
PEOPLE = Identity WORK = Job
e.g., Rule Specification
ENDS = Sub-condition MEANS = Step e.g., Timing Definition
TIME = Interrupt Cycle = Machine Cycle e.g., Data Design E.g.,Presentation Archit. E.g., Control Structure
ENTITY = Table/Segm/etc RELATION = Key/Pointer/etc
NODE = Hardw/Syst Softw LINK = Line Specifications
PEOPLE = User WORK = Screen/Dev. Formats
TIME = Execute CYCLE = Component Cycle I/O = Data Elements/Sets
PROCESS=Computer Function
e.g., Techn. Architecture
e.g., System Design E.g.,Business Rule Model
ENDS = Condition MEANS = Action
e.g., Logical Data Model e.g., Applicat. Architecture e.g., Distributed Systems E.g.,Processing Structure Architecture
e.g., Human Interface Architecture
ENTITY = Data Entity RELATION=Data Relationship
I/O = Data Elements/Sets PROCESS =Applic. Functions
NODE = IS Function
LINK = Line Characterist.
PEOPLE = Role WORK = Deliverable
TIME =System Event CYCLE = Processing Cycle
E.g.,Business Rule Model
ENDS = Structural Assertion MEANS = Action Assertion
What
Data FunctionHow NetworkWhere PeopleWho TimeWhen MotivationWhy
List of Goals List of Things List of Processes List of Locations List of Organizations List of Cycles
e.g., Logistics Network
E.g.,Business Proc. Model E.g.,Work Flow Model E.g., Master Schedule e.g., Semantic Model
ENTITY = Business Entity RELATION =Busi. Relationship
I/O = Business Resources PROCES= Business Process
NODE = Business Location LINK = Business Linkage
PEOPLE = Organization Unit WORK = Work Product
TIME = Business Event CYCLE = Business Cycle
E.g.,Business Plan
ENDS = Business Objective MEANS = Business Strategy
ENTERPRISE ARCHITECTURE:
A FRAMEWORK™
Zachman Institute
for Framework Advancement
T H E Z A C H M A N F R A M E W O R K F O R E N T R E P R I S E A R C H I T E C T U R E
A existência destes referenciais tornam também mais claros e transparentes os relacionamentos entre as adminis-trações públicas e o mercado e constituem modelos de refe-rência para os requisitos a que devem obedecer as ferra-mentas de análise e modelação de processos que vão
surgindo no mercado das BPA (Business Process Analysis) e
das respectivas ferramentas arquitectónicas (ARIS, Casewise, MEGA, Metis, Popkin, ProVision, etc)
O que é que a diferencia de outras opções?
Constituiu talvez a primeira abordagem que não se fixou simplesmente na cascata descendente tradicional e que soube valorizar todas as perspectivas independentemente do nível hierárquico e funcional a que se referem (planifi-cador, dono, responsável pelo SI, responsável aplicacional
ou implementador) e às questões dos seis “W” a que cada
um tem de responder ao seu nível(What, hoW, Where, Who,
When e Why).
Imagine-se a construção de uma casa rústica ou de uma catedral, independentemente do seu tamanho e grau de complexidade. Ambas necessitam de projectos de
arquitec-tura baseados nos mesmos referenciais. Zachman tentou dar formalismo aos referenciais que suportam a arquitec-tura dos sistemas de informação, independentemente da sua escala e complexidade.
Onde está o seu valor acrescentado?
Trata-se de um esforço para definir e alinhar visões diferen-tes da mesma realidade, percebendo-se e valorizando-se as perspectivas em que cada um se coloca na matriz para representar o mesmo sistema de informação, ganhando-se elevados níveis de complementaridade e sinergia positiva. Compreender a natureza holística e interdisciplinar das arqui-tecturas do sistema de informação, desde as suas represen-tações mais simbólicas às mais tecnológicas, é sem dúvida o seu maior valor acrescentado.
E não tem limitações?...
Como todas as metodologias que pretendem dominar a complexidade formalizando e encerrando os resultados numa taxinomia fechada, corre-se o risco de “congelar” a realidade, aproximando-se mais dos sistemas mecânicos do que dos sistemas orgânicos e dinâmicos, característicos do mundo social em que se inserem e que visam servir. Esta será a sua maior limitação. Mais recentemente assiste-se a um realinhamento das arquitecturas para os processos,
SOA (Service-Oriented Architecture), questionando e dando
mais pragmatismo à cascata tradicional que vai do planea-mento, à análise, à concepção e à construção. As arquitec-turas orientadas aos processos focam sobretudo a mode-lação dos processos de negócio, a concepção e a
interli-gação dos workflows, etc., tornando mandatória a criação de
repositórios comuns de informação e a correspondente análise, modelação e partilha de dados.
Na sua opinião, a ASI de Zachman é aplicável ou especial-mente recomendável para qualquer tipo de organização? Sim. A universalidade, na sua aplicação, a casos e sectores bem distintos foi, sem dúvida, um dos propósitos de Zachman ao comparar os sistemas de informação, quais-quer que eles sejam, a edifícios que precisam ser planifica-dos com grande rigor interdisciplinar antes de ser construí-dos.
Existem algum tipo de condições que uma organização deve preencher para “receber” a ASI de Zachman?
Para que uma organização possa desencadear um processo de arquitectura é preciso que reconheça, antes de mais, a importância da interdisciplinaridade na resolução de prob-lemas. Tal como no meio físico um engenheiro ou um con-strutor civil deverão reconhecer a importância de um arqui-tecto para conceber e mapear o espaço, também no espaço simbólico que constituem os sistemas de informação dev-erão ser obrigatórias as respectivas arquitecturas prévias.
Uma organização que pretende aplicar o framework de
Zachman ou outro semelhante, é uma organização que val-oriza a cooperação e a interoperabilidade para chegar a resultados. Através deste quadro podem definir-se os negó-cios, os modelos, as regras, os elementos, os locais, os actores, as conexões, os programas, as redes, etc., ficando-se a saber que “cooperar não significa perder poder”.
Quem é Luís Vidigal
Luís Vidigal tem mais de 30 anos de experiência em Reforma Administrativa, especialmente através da utilização das Tecnologias de Informação e Comunicações. Presentemente vogal do Conselho de Direcção do Instituto de Informática do Ministério das Finanças. Reconhecido consultor nacional e internacional nas áreas de e-Government, foi subdirector Geral da Direcção Geral de Informática Tributária e Aduaneira entre 1998 e 2001 e subdirector Geral do Secretariado para a
Modernização Administrativa entre 1992 e 1998. Entre 1989 e 1998 foi fundador e coordenador executivo do INFOCID - Sistema
Interdepartamental de Informação ao Cidadão entre 1989 e 1998. De 1996 a 1999 fez ainda parte da equipa de Missão para a Sociedade da Informação. Para lá da sua actividade profissional, Luís Vidigal é conferencista em numerosos eventos no país e no estrangeiro sobre e-Government e sobre o uso das TIC na relação entre o Estado e a Sociedade. É ainda membro da Direcção e sócio fundador da Associação para a Promoção e Desenvolvimento da Sociedade da Informação (APDSI) e membro da Direcção de várias organizações e associações nacionais e internacionais.
Quem é John Zachman
John A. Zachman foi o criador do “framework for Enterprise Architecture” que recebeu larga aceitação em todo o mundo, como um quadro de referência integrador de representações descritivas de uma empresa. Ele não é apenas conhecido pelo seu trabalho sobre arquitecturas de empresa, mas também pelos seus contributos iniciais para o Business Systems Planning da IBM. Zachman está envolvido em estratégias e arquitectura de sistemas de informação desde 1970 e foi autor de vários artigos sobre estes temas. Foi conferencista e animador no mundo inteiro, em inúmeras sessões para executivos, equipas de planeamento e profissionais de informação em geral. Zachman encontra-se hoje reformado da IBM, onde foi funcionário durante 26 anos. Actualmente é Chief Executive Officer do Zachman Institute for Framework Advancement (ZIFA), uma organização dedicada ao desenvolvimento conceptual e à implementação das Arquitecturas de Empresa. É responsável pela empresa Zachman International, a partir da qual lecciona e dá consultoria. È membro da Direcção da Framework Software, do
Warehouse/Repository/Architecture/Development (WRAD) Users Group; do Advisory Board of the Data Administration Management Association (DAMA) International e do Advisory Board for the Data Resource Management Program da Universidade de Washington.
Bibliografia de Zachman
·
John A. Zachman, “A Framework for Information Systems Architecture”, IBM Systems Journal, Vol 26, No 3, 1987. IBM Publication;·
“Extending and Formalising the Framework for Information Systems Architecture”, J.F. Sowa and J.A. Zachman, IBM Systems Journal, Vol 31, No 3, 1992. IBM Publication;·
John Zachman, “Concepts of the Framework for Enterprise Architecture”, Zachman International, Los Angeles: CA (1996);·
John Zachman, “Enterprise Architecture and Legacy Systems”, Zachman International, Los Angeles: CA (1995);·
John Zachman, “The Challenge is Change: A Management Paper”, Zachman International, Los Angeles: CA (1995).Como é que caracterizaria a utilização da ASI de Zachman nas organizações portuguesas?
Para além das reflexões académicas e de algumas experiên-cias pontuais, Portugal, de um modo geral, ainda dá pouca importância às arquitecturas dos sistemas de informação, tal como ainda acontece com o desprezo a que ainda estão votadas as arquitecturas no nosso espaço urbano. No nosso caso, o Instituto de Informática, nos anos 70 e 80, foi sem dúvida uma instituição de referência particularmente preocupada com as metodologias de planeamento e análise de sistemas de informação, estando neste momento a retomar alguma da sua tradição nestes domínios, por força do papel que desempenha na Administração Pública por-tuguesa em geral e no Ministério das Finanças em particu-lar. Não conheço a situação das empresas portuguesas, mas no caso da Administração Pública ainda é muito fraco o investimento em arquitecturas de sistemas de informação e na criação e desenvolvimento de competências nesta área.
E nos outros países? Estamos mais ou menos avançados?... Antes de lhe responder directamente, deixe-me contextu-alizar a resposta. Em primeiro lugar, nunca, como hoje, se tornou tão necessária e até mesmo obrigatória a definição de arquitecturas. O mundo viveu nos últimos vinte anos uma desconexão tecnológica e informacional excessiva, a informática tornou-se mais pessoal do que institucional. E, apesar da revolução da Internet, o trabalho ainda não é cooperativo, os processos ainda não são suficientemente fluídos e desmaterializados, as organizações ainda não se reconhecem no seu espaço alargado junto de clientes, fornecedores e parceiros, que são capazes de partilhar o seu mesmo ambiente operacional.
O que verifico é que, apesar de estarem disponíveis algu-mas ferramentas facilitadoras, estes métodos não vêm em “caixas” e não se vendem em supermercados, pois trata-se sobretudo de promover novas atitudes de gestão. No nosso caso, em Portugal, julgo que não estará tão atrasado nestes domínios como noutros em que se requer uma perspectiva sistémica orientada a resultados. Não poderemos, contudo, confundir alguns modelos baseados em cascata de objec-tivos, que infelizmente nos conduzem a sistemas mera-mente mecânicos e cada vez mais burocratizados, com estas novas metodologias cada vez mais orgânicas e holísti-cas, que nos conduzem à qualidade, à excelência e à