Departamento de Cincias e Tecnologias da Informao

Metodologia para a Implementao de Software as a Service Segundo a Anlise de Gesto de Benefcios

Antnio Jos Estevo Rodrigues

Dissertao submetida como requisito parcial para obteno do grau de Mestre em Cincias e Tecnologias da Informao

Orientador: Doutor Henrique ONeill, Professor Associado ISCTE-IUL

Setembro de 2009

Agradecimentos
No espao que me conferido, no queria deixar de dizer OBRIGADO a todos os que me apoiaram ao longo deste ltimos anos que agora culminam com esta dissertao. minha mulher Carla Rodrigues pelo apoio incondicional que sempre me deu, aos meus filhos Toms Rodrigues e Guilherme Rodrigues, que se viram privados do Pai nalgumas horas de brincadeira. Uma palavra especial para os meus Pais, graas educao de base que me proporcionaram, ajudaram tambm a construir esta dissertao. No queria deixar de agradecer aos meus colegas de emprego, pelo apoio a vrios nveis que me foi dado. Uma palavra de apreo para Professor Doutor Pedro Ramos, na qualidade de responsvel pelo Mestrado e para a incansvel Elisabete Raimundo. Por ultimo mas no menos importante ao Professor Doutor Henrique ONeill que no seu papel de orientador, me ajudou imenso. A todos OBRIGADO

Dedico este trabalho minha mulher e aos meus filhos

Resumo
As empresas e organizaes desde cedo tiveram como objectivo usar os sistemas de informao, para tornar os seus processos de negcio mais eficazes, potenciando esse facto, de forma a torna-lo um elemento diferenciador que lhes permitisse aumentar os nveis de competitividade. Desde o aparecimento dos mainframes at era da Internet, o protagonismo dos sistemas de informao revelou-se atravs de uma crescente dependncia com os processos de negcio. Proporcionando hoje ao cidado comum facilidades inimaginveis h poucos anos. Obviamente que por trs de todas estas funcionalidades existe um investimento associado no que diz respeito s tecnologias de informao (TI), que assume propores cada vez maiores. No actual momento de conteno, as empresas revem os seus modelos de funcionamento, tentando reduzir os custos sem que o mesmo seja sinnimo de uma reduo de funcionalidades disponveis. Durante os ltimos anos tm surgido novos modelos de funcionamento, Outsourcing ou Managed Services. Esta dissertao pretende efectuar uma reflexo sobre um conceito emergente que assenta no princpio em que o software disponibilizado como um servio, o qual pago consoante os nveis de consumo, este modelo denominado por SaaS (Software as a Service). Pretende-se tambm reflectir sobre o paradoxo que tem vindo a ser enraizado na rea das TI, em que os investimentos raramente correspondem aos benefcios expectveis. A histria das TI diz-nos que no existe uma soluo que se aplica a todos os casos, pelo que, o SaaS tambm no ser a excepo. Pretende-se com este trabalho contribuir com um modelo que ajude na opo por um conceito na sua fase emergente e em simultneo auxilie na sempre difcil relao investimentos e benefcios. Palavras-chave: Sistemas de Informao, Processos de Negcio, Software, Servio, Investimento

II

Abstract
Since early times, companies and organizations focused in using IT in such a way that would increase efficiency and therefore, also raise their competitive levels. Since the first appearance of the mainframe thru Internet age, IT main part as revealed itself due to a raising dependency with business process, providing to the common citizen unimaginable functionalities few years before. Obviously, behind all this new functionalities, there is a investment in IT which raises constantly. In todays financial crisis, companies review their operational models so that they may reduce costs without cutting back in IT investment and available functionalities. During last years new operational models have emerged such as Outsorcing or managed services. This dissertation pretends to reflect over an emerging concept that stands in the principle that software is deployed as a service which is paid in accordance with consumption levels and is referred as (software as a service). Is also intended to reflect over the paradox that has been growing in IT areas and that says investment rarely correspond to expectable benefices. It history teach us that there is no global solution and of course, SaaS is no exception. With this work, there will be an attempt to contribute with a model that helps creating a concept in an emerging phase and also helps in managing the always difficult relation between investment and return.

Keywords: Information Systems, Business Processes, Software, Service, Investment III

ndice
Agradecimentos ...................................................................................................................... I Resumo ................................................................................................................................. II Abstract ................................................................................................................................ III ndice ................................................................................................................................... IV ndice Figuras ...................................................................................................................... IX ndice Tabelas .....................................................................................................................XII Siglas ................................................................................................................................ XIV CAPTULO I ......................................................................................................................... 1 1. Introduo ...................................................................................................................... 1 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. Enquadramento ...................................................................................................... 2 Objectivos .............................................................................................................. 6 Motivaes ............................................................................................................ 7 Metodologia ........................................................................................................... 7 Problema ................................................................................................................ 7 Organizao da Dissertao................................................................................... 8 Resumo .................................................................................................................. 9

CAPTULO II ...................................................................................................................... 10 IV

2.

Estado da Arte ............................................................................................................. 10 2.1. Seco I................................................................................................................ 10 Sistemas Distribudos .................................................................................... 10 WEB Services ................................................................................................ 12 Definio de WEB Services ................................................................... 13

2.1.1. 2.1.2.

2.1.2.1. 2.1.3. 2.2.

SOA (Service-Oriented Architecture) ........................................................... 15

Seco II .............................................................................................................. 17 SaaS (Software as a Service) ......................................................................... 17 Contextualizao do SaaS (Software as a Service) ................................ 17 Definio do SaaS (Software as a Service) ............................................ 20 Adopo de Aplicaes e Servios SaaS (Software as a Service) ......... 22 Ecossistema SaaS ................................................................................... 25 Que tipo de Aplicaes se enquadra no conceito SaaS? ........................ 27 Ofertas de Aplicaes e Servios SaaS (Software as a Service) ............ 28

2.2.1.

2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.1.4. 2.2.1.5. 2.2.1.6.

Microsoft ............................................................................................................. 29 IBM ...................................................................................................................... 32 ORACLE ............................................................................................................. 33 AMAZON............................................................................................................ 37 2.3. Seco III ............................................................................................................. 39 Investimentos em SI/TI ................................................................................. 39 V

2.3.1.

2.3.2. 2.3.3.

Mtodos tradicionais de Avaliao dos investimentos em TI.................... 40 Gesto de Benefcios nova abordagem .......................................................... 42 Uma viso geral ao processo de Gesto de Benefcios .......................... 43

2.3.3.1. 2.3.4.

Investimentos nas componentes Infra-estruturais de TI ................................ 45 Investimentos Infra-estruturais, no modelo Gesto de Benefcios ......... 46 Investimentos Infra-estruturais, no modelo WEILL e BROADBENT .. 47

2.3.4.1. 2.3.4.2.

CAPTULO III .................................................................................................................... 50 3. Modelo Proposto ......................................................................................................... 50 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. (1) Identificar Necessidades ou Oportunidades ................................................... 51 (2) Anlise da Arquitectura (SI/TI) ..................................................................... 53 (3) Escolha da Opo mais Vantajosa ................................................................. 55 (4) Pilotar a Soluo ............................................................................................ 56 (5) Implementao ............................................................................................... 59 (6) Analise dos Resultados e Benefcios ............................................................. 60

CAPTULO IV .................................................................................................................... 62 4. Estudo de Caso ............................................................................................................ 62 4.1. (1 Fase) Contextualizao .................................................................................. 62 Porqu?: Porque razo se est a levar a cabo este investimento ................... 62 O qu?: Quais os benefcios que a organizao espera obter ........................ 64 Como? : Rede de benefcios .......................................................................... 64 VI

4.1.1. 4.1.2. 4.1.3.

4.2. 4.3.

(2 Fase) Anlise e Definio de Arquitectura .................................................... 65 (3 Fase) Opo mais Vantajosa .......................................................................... 69 (1) Indicadores Financeiros ........................................................................... 70 (2) Diferena de Resultados entre os Modelos .............................................. 72 (3) Poupanas no descontinuar da antiga Infra-Estrutura .............................. 73 (4) Optimizao dos Tempos de Transaces ............................................... 73 (5) Reduo no perodo de implementao ................................................... 73 (6) Aumento do nmero transaces efectuadas ........................................... 74 (7) Uma plataforma mais atractiva ................................................................ 74

4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. 4.3.6. 4.3.7. 4.4. 4.5. 4.6.

(4 Fase) Prova de Conceito ................................................................................ 75 (5 Fase) Implementao ..................................................................................... 76 (6 Fase) Anlise dos Resultados ......................................................................... 76

CAPTULO V ..................................................................................................................... 78 5. Concluses e Recomendaes ..................................................................................... 78 5.1. 5.2. 5.3. 5.4. 5.5. Comparao entre os modelos GO2SaaS e o actual ............................................ 78 Concluses Finais ................................................................................................ 80 Limitaes ........................................................................................................... 80 Recomendaes ................................................................................................... 81 Artigos Publicados ............................................................................................... 82

Bibliografia .......................................................................................................................... 83 VII

ANEXO A ........................................................................................................................... 86 ANEXO B ........................................................................................................................... 88

VIII

ndice Figuras
Figura 1-I - Relao Processos de Negcio/SI [Laudon 2005] ............................................. 2 Figura 1-II - Relao Processos de Negcio/SI ..................................................................... 3 Figura 1-III - Investimentos Negcio versus IT [US-DCBEA 2006] ................................... 5 Figura 2-I - Exemplo Arquitectura Cliente/Servidor........................................................... 11 Figura 2-II - Interaco Utilizador-Servidor ....................................................................... 13 Figura 2-III - Interaco Aplicao-Aplicao .................................................................... 13 Figura 2-IV - Exemplo Prtico do SOA .............................................................................. 16 Figura 2-V - Gastos em TI [IDC 2007a] ............................................................................. 18 Figura 2-VI - Tendncias dos Modelos [IDC 2003] ........................................................... 19 Figura 2-VII - Adopo de Aplicaes em SaaS ................................................................. 23 Figura 2-VIII - Factores desencorajadores do SaaS [IDC 2007b]....................................... 24 Figura 2-IX-Ecossistema SaaS [CARRARO 2006] ............................................................ 25 Figura 2-X - Evoluo de Arq. Dedicada para Multi-cliente .............................................. 26 Figura 2-XI - Exemplo de Arquitectura hbrida .................................................................. 27 Figura 2-XII - Aplicaes vs Aplicaes Perifricas [Moore 2002] ................................... 28 Figura 2-XIII - Evoluo do SaaS por Produto/Servio (Fonte:IDC 09/2009) ................... 28 Figura 2-XIV- Modelo S+S Microsoft ................................................................................ 30 Figura 2-XV - Plataforma Azure Services [Microsoft 2008b]............................................. 31

IX

Figura 2-XVI - Plataforma ORACLE SAAS [ORACLE 2008].......................................... 35 Figura 2-XVII - Processo de Gesto de Benefcios [WARD 2007] .................................... 43 Figura 2-XVIII - Justificao de Investimentos em Infra-Estrutura [WARD 2007] ........... 46 Figura 2-XIX - Portflio de Investimentos em TI [WEILL 1998] ...................................... 48 Figura 3-I - Modelo Proposto .............................................................................................. 50 Figura 3-II Rede de Benefcios adaptada [WARD 2007] ................................................ 53 Figura 3-III - Arquitectura de Integrao [CARRARO 2006] ............................................ 54 Figura 3-IV - Fases da Prova de Conceito ........................................................................... 57 Figura 3-V - Distribuio das Aplicaes ........................................................................... 59 Figura 3-VI - Mecanismos de Controlo............................................................................... 60 Figura 3-VII - Todas as fases confluem para a Analise de Resultados ............................... 61 Figura 4-I Quota de Mercado dos Atacantes e Incumbentes ..................................... 63 Figura 4-II - Receitas Esperadas com a introduo da PNA ............................................... 64 Figura 4-III - Rede de Benefcios do Projecto ..................................................................... 65 Figura 4-IV - Arquitectura genrica do SI........................................................................... 66 Figura 4-V - Fluxo de Informao entre o Banco e o Fornecedor de SaaS (F-SaaS) ......... 66 Figura 4-VI - Arquitectura de Integrao Implementada .................................................... 68 Figura 4-VII - Diferena dos VAL(s) entre o SaaS e o Modelo Tradicional ...................... 72 Figura 4-VIII - Diferena de Proveitos segundo o Modelo ................................................. 74 Figura 4-IX - Exemplos de Ecrs da Plataforma ................................................................. 74 X

Figura 4-X-Arquitectura do Piloto ...................................................................................... 75 Figura 4-XI-Arquitectura de Produo ................................................................................ 76 Figura 4-XII-Analise dos resultados por cada fase do modelo ........................................... 77 Figura 5-I-Modelo de Avaliao e Implementao dos Projectos ...................................... 78 Figura 5-II- Quadro comparativo entre Modelos ................................................................ 79 Figura 5-III - Conceitos .... as a Service .............................................................................. 81

XI

ndice Tabelas
Tabela 1-I Resumo Processos de Negcio versus Evoluo das Plataformas .................... 9 Tabela 2-I - Quadro Comparativo entre CORBA, JAVA RMI e WEB Service ................. 14 Tabela 2-II - Comparao Outsourcing,Managed Services e Utility .................................. 19 Tabela 2-III - Comparao Modelo SaaS/Tradicional ....................................................... 22 Tabela 2-IV - Servios disponibilizados Microsoft ............................................................. 30 Tabela 2-V - Servios disponibilizados IBM ...................................................................... 33 Tabela 2-VI - Servios disponibilizados ORACLE ............................................................ 36 Tabela 2-VII - Servios disponibilizados AMAZON ........................................................... 38 Tabela 2-VIII - Levantamento do processo de Avaliao dos investimentos em TI .......... 41 Tabela 2-IX - Gesto de Benefcios versus modelo "tradicional" [WARD 2007] .............. 43 Tabela 3-I - Tipos de Estratgias Propulsoras [WARD 2007] ............................................ 51 Tabela 3-II Objectivos SMART [OCG 2004] ..................................................................... 52 Tabela 3-III - Novo Business Case, Adaptado [WARD 2007]............................................ 56 Tabela 4-I - Tabela de Objectivos SMART ........................................................................ 63 Tabela 4-II - Fluxo de Informao em Detalhe ................................................................... 67 Tabela 4-III - Matriz Financeira .......................................................................................... 70 Tabela 4-IV - Indicadores Financeiros Modelo SaaS .......................................................... 71 XII

Tabela 4-V Indicadores Financeiros (Modelo Tradicional) ................................................ 72 Tabela 4-VI- Valores relativos antiga Infra-Estrutura ...................................................... 73

XIII

Siglas
CPD DCF EAI HTML HTTP HW IBM IDC ISV NPV PC PDA PME ROI SaaS SI SLA SMS SOA SOAP SW TI W3C WS WSD WSDL XML Centro Processamento de Dados Discounted Cash Flow Enterprise Application Integration HyperText Markup Language Hypertext Transfer Protocol Hardware International Business Machines International Data Corporation Independent Software Vendor Net Present Value Personal Computer Personal Digital Assistants Pequenas e Mdias Empresas Return On Investment Software As A Service Sistemas de Informao Service Level Agremment Short Message Service (Servio de Mensagens Curtas) Service-Oriented Architecture (Arquitectura Orientada a Servios) Simple Object Access Protocol Software Tecnologias de Informao World Wide Web Consortium WEB Services Web Service Description Web Service Definition Language XML (eXtensible Markup Language)

XIV

CAPTULO I
1. Introduo
O objectivo deste captulo contextualizar o tema da dissertao. Visa explicar que pelo facto das empresas encararem a disponibilidade do software como se de um outro servio se tratasse, poder ser o inicio de uma nova era, na curta histria das tecnologias de informao. Esta dissertao tende a servir como guio no sentido de orientar a deciso de escolher entre um modelo baseado no conceito SaaS (Software as a Service), versus o modelo tradicional.
Este novo conceito baseado no princpio de pay-per-use, permitindo que as

empresas e organizaes paguem o software como um servio. Deixando de lado as preocupaes do modelo tradicional, que passam pela aquisio de software, celebrao de contractos de manuteno do mesmo, compra de hardware associado, disponibilidade de uma equipa especializada para efectuar a gesto, no esquecendo obviamente factores como backup e eventuais cenrios de business continuity. O tema do SaaS no poder ser encarado nem como uma nova moda ou como uma nova verso de software, nem como uma poo mgica que vai resolver todos os problemas, principalmente os financeiros do modelo tradicional. Ter de ser encarado como um modelo de disponibilizao de software, que apresenta agora um grau de maturidade, onde seguro apostar como alternativa ou como complemento s tradicionais formas de desenvolvimento ou aquisio de software. O conceito SaaS, nasce fruto da necessidade que existe de diminuir custos, suportado numa evoluo tecnolgica que permite do ponto de vista de arquitectura de sistemas de informao poder-se evoluir para um modelo baseado em servios, fruto da evoluo das arquitecturas SOA (Service-Oriented Architecture).

1.1.

Enquadramento
Desde o inicio da histria da informtica as empresas e organizaes, viram nos

Sistemas de Informao (SI), uma forma de tornar mais geis e eficazes os seus Processos de Negcio (PN), sempre com a inteno de marcar a diferena face concorrncia.

Figura 1-I - Relao Processos de Negcio/SI [Laudon 2005]

A Figura 1-I acima representada pretende realar a interdependncia entre uma organizao e o seu SI. As mudanas na estratgia, regras e processos de negcio traduzem-se de uma forma directa em mudanas de hardware, software, bases de dados ou telecomunicaes. O contrrio tambm verdade quando existe uma evoluo tecnolgica, esta poder ser sinnimo de uma nova oportunidade de negcio. Exemplos deste facto so as inmeras empresas que aproveitando a era das dot.com, viram oportunidades que at ento no seriam possveis, destacam-se casos como a Google, Amazon ou eBay. Esta interdependncia entre negcios e tecnologias de informao tem-se revelado como saudvel proporcionando a evoluo de ambos.
Numa breve retrospectiva histrica cujo objectivo elucidar como os SI e os PN tm

evoludo em paralelo, a Figura 1-II servir como fio condutor.

Figura 1-II - Relao Processos de Negcio/SI

Recuando um pouco na histria das Tecnologias da Informao, em plena dcada de 60, o investimento em TI era reservado apenas s empresas e instituies com grande disponibilidade financeira. Os SI eram centralizados num nico computador denominado de mainframe e o seu funcionamento baseava-se essencialmente na execuo de trabalhos autnomos sem necessidade de interveno humano, vulgarmente denominados por trabalhos batch. A interaco com os utilizadores era reduzida, resumia-se ao acesso via terminal [Sommerville 2001]. luz do conhecimento actual as inovaes que os primeiros computadores trouxeram parecem quase ridculas, mas permitiu na altura a quem investiu em novas tecnologias melhorar os seus processos de negcio, conseguindo melhorias significativas no campo do processamento dos dados. Conferindo aos mesmos elevados nveis de rapidez e exactido nas operaes, dai as organizaes pertencentes rea financeira como a banca e os seguros, terem sido pioneiras na rea das TI. No inicio da dcada de 80 nasce uma nova era denominada de Cliente/Servidor, que vem claramente democratizar a informtica. Estavam criadas as condies para o aparecimento das chamadas aplicaes departamentais, a preos incomparavelmente inferiores quando comparados com o mainframe. Foi possvel atravs do nascimento do
modelo Cliente/Servidor, agilizar processos que at ento no eram considerados prioritrios ou pura e simplesmente no havia capacidade financeira para os informatizar. So exemplos 3

aplicaes de recursos humanos, aprovisionamento entre outras, que vai permitir uma evoluo significativa em termos de organizao interna de processos. o inicio do fim dos amontoados de papel. Outro marco de destaque nesta retrospectiva situa-se no fim da dcada de 80, quando,

Tim Berners-Lee que data desenvolvia a sua actividade no CERN (Conseil Europen pour la Recherche Nuclair) introduziu um conceito denominado World Wide Web, vulgarmente designado pelo diminutivo Web [Berners-Lee et al. 2006]. Teve o mrito de conseguir criar standards, que se revelaram as linhas mestras que permitiram transformar a Internet no fenmeno que actualmente: URI "Uniform Resource Identifier": Forma de enderear inequivocamente um documento ou objecto no espao Web [RFC3896 2005]; HTTP "Hypertext Transfer Protocol": Protocolo de aplicao responsvel pelo tratamento de pedidos/respostas entre cliente e servidor; HTML "HyperText Markup Language": Primeira linguagem, para formatar pginas Web; Estava criada a base, para a evoluo que se seguiu. Toda a riqueza das pginas WEB, rapidamente foi adoptada tambm para as aplicaes locais, fazendo nascer o conceito de aplicaes WEB Based, que se caracteriza por aplicaes residentes no servidor serem acedidas por um browser. E o mundo transformou-se. Nasce a era das dot.com, caracterizada pelo facto de todos quererem ver a sua marcar presente na Internet. O nmero de sites cresceu em exponencial, desde sites de carcter pessoal, comercial, humanitrios, governamentais e outros. Representou novas oportunidades de negcio, quer para as empresas que desenvolvem contedos, empresas responsveis pelo alojamento dos sites, quer para as empresas que j tinham a sua linha de negcio perfeitamente definida mas onde a presena na Internet foi vista como um novo canal de proximidade. Estamos novamente perante uma interaco muito forte entre os processos de negcio e os sistemas de informao. No caso do mainframe e das aplicaes Cliente/Servidor, assistiu-se a uma reformulao dos processos mais a nvel interno, do 4

ponto de vista de quem est do exterior pouco ou nada se apercebe da mudana. Com a presena na Internet, houve de facto a percepo que algo mudou, existe agora um vasto leque de servios, que podem ser acedidos independentemente da hora, local ou dia da semana.
Finalizada a viagem no tempo torna-se fcil concluir que os SI tm vindo a ganhar

protagonismo nas organizaes e a fazer crescer a interdependncia entre ambos, a capacidade das empresas levarem a cabo novas estratgias corporativas, ir estar directamente dependente da resposta que o seu SI ter ou no capacidade para o fazer [Laudon 2005]. A referida relao materializada num investimento cada vez maior em na rea dos SI e Tecnologias de informao (TI). Esta parcela tem vindo a aumentar ao longo dos ltimos anos, sem perspectivas de inverter a tendncia. Este facto coloca sobre os responsveis pelo SI/TI, uma quota-parte de responsabilidade acrescida, pressuposto que os avultados investimentos realizados estejam associados a aumentos de produtividade para as organizaes. A Figura 1-III representa um exemplo do evoluir do investimento em TI face ao investimento total.

Figura 1-III - Investimentos Negcio versus IT [US-DCBEA 2006]

Com o crescente investimento em TI, expectvel que os gestores e investidores se questionem: At que ponto que investimento realizado traduz um aumento na produtividade e obviamente nos resultados? A questo da produtividade versus investimento foi inicialmente levantada em plena dcada de 80, onde os investimentos ainda no assumiam as propores que tm actualmente. Robert Solow, prmio Nobel da Economia em 1987 afirmava ironicamente: You can see the computer age everywhere but not in the productivity statistics, esta afirmao viria a ficar conhecida como o paradoxo da produtividade. Ligeiramente mais tarde foi sucedido por outros autores como Diana Farrell [Farrell 2003], Michael Porter [Porter 2001] e John Ward [Ward 2007], que obviamente no colocam em causa o desenvolvimento das TI, nem o investimento que necessrio realizar. Mas alertam para a necessidade de chamar ateno para as empresas e organizaes que o simples facto de apostarem na nova economia, fazendo investimentos como nunca em TI por si s no seria sinnimo de sucesso. A aposta nas TI no pode ser considerado um fim, mas sim um meio poderosssimo que as empresas dispem para inovar e optimizar os seus processos. Isto porque a tecnologia cedo ou tarde ser copiada, agora o uso que se faz dela em prol do negcio, esse sim dever ser o elemento diferenciador.

1.2.

Objectivos
O objectivo deste trabalho conseguir esclarecer este novo conceito SaaS,

detalhando as arquitecturas em que o mesmo suportado, apresentando as vantagens e desvantagens relativamente a uma abordagem mais tradicional. Em simultneo propor uma metodologia baseada no processo de gesto de benefcios, que possa ser vista como instrumento vlido, no sentido de avaliar at que ponto que um investimento em SaaS traz de facto mais-valias para a empresa ou organizao.

1.3.

Motivaes
As motivaes para levar a cabo este tema surgem essencialmente do campo

profissional enquanto trabalhador na rea das TI. Ao longo dos anos tenho vindo a assistir ao crescimento da ideia que os investimentos em TI so um mal necessrio e no trazem consigo a produtividade esperada. Existem razes bvias que sustentam esses pressupostos destacam-se a existncia de projectos com um deficiente enquadramento entre as TI e o negcios. Outros casos em que a arquitectura no se compadece com os restantes elementos do SI e talvez a mais vulgar de todos, que uma deficiente gesto de benefcios do ponto de vista das TI. Outro factor motivador o acreditar que o SaaS marca um ponto de viragem, na mentalidade de quem gere as TI no ser um processo que ocorre de um dia para o outro, mas estou certo que as promissoras previses efectuadas por empresas como a IDC ou Gartner se vo concretizar.

1.4.

Metodologia
A presente dissertao foi conduzida, em trs etapas fundamentais: uma primeira

onde contextualizado o tema em si e respectivas ramificaes. Devidamente substanciados atravs do levantamento bibliogrfico, ser a base para que as etapas seguintes possam ser mais facilmente compreendidas. Na segunda etapa apresentada uma proposta de soluo baseada num modelo composto por uma vertente tecnolgica e organizativa, complementado por uma vertente econmica. A proposta confrontada face a um estudo de caso. Finalmente numa ltima etapa feita a discusso das concluses obtidas com o trabalho realizado.

1.5.

Problema
Esta dissertao pretende encontrar respostas para as seguintes questes:

Qual a metodologia que deve ser seguida, quando se equaciona enveredar para o conceito Software as a Service? Com a implementao desta metodologia haver mais-valias financeiras para quem venha a adopta-la? 7

1.6.

Organizao da Dissertao
A dissertao foi estruturada em cinco captulos: Introduo, Estado do Arte,

Proposta de modelo, Estudo de Caso e por fim um captulo dedicada a Concluses e Recomendaes. Neste primeiro captulo procede-se contextualizao do tema da dissertao, efectua-se o respectivo enquadramento tendo como base a evoluo dos SI e a forma como os processos de negcios tm acompanhado essa mesma evoluo. Como o SaaS pressupe uma componente econmica, foi realizado um levantamento forma como o SI, tem vindo a ganhar protagonismo nas organizaes, bem como levantada a questo do elevado investimento em TI, versus um aparente dfice de produtividade. O captulo 2 ser dividido em trs seces, a primeira destinada arquitectura, onde so detalhadas as componentes tcnicas como WEB Services (WS) e SOA. A segunda seco destinada a detalhar o SaaS, desde a definio, pontos fracos e pontos fortes, em que situao que se aconselha a sua utilizao, passando pela anlise de algumas ofertas de mercado. Na ltima seco foca-se a gesto de benefcios e pretende enquadrar as tendncias neste campo. Aps ter sido introduzido a componente terica, no captulo 3 pretende-se criar um modelo que responda, em que condies que se revela benfico uma aposta no conceito SaaS versus o modelo tradicional. Atravs da uma correcta gesto de benefcios, pretendese tambm sustentar a deciso para que tenha condies de sucesso. No captulo 4, apresenta-se um estudo de caso, que pretende colocar em prtica o modelo apresentado e detalhado no captulo 3. O captulo 5 reservado para as concluses e anlise de potncias cenrios de evoluo num futuro no muito distante.

1.7.

Resumo
A Tabela 1-I tem como objectivo efectuar um resumo da forma como os processos de

negcio se tm relacionado com a evoluo das arquitecturas de sistemas de informao.

Mainframe Cliente/Servidor Aplicaes Funcionavam essencialmente em modo batch, os utilizadores Processos de Negcio interagiam com o Computador atravs da utilizao de terminais sem capacidade de processamento departamentais permitem informatizar, reas de actuao como recursos humanos ou contabilidade, a preos consideravelmente mais baixos Baixa, devido ao facto de funcionar essencialmente no Dependncia com o Negcio batch nocturno, pouca interaco com os utilizadores e pouca visibilidade para o cliente Mdias, com o nascimento das aplicaes departamentais, os colaboradores comeam a usar o PC, nas actividades do dia-a-dia Arquitectura WEB Finalmente, as empresas viram-se para os clientes e torna-se possvel oferecer a estes novas funcionalidades, novos canais de interaco que potenciam a relao empresacliente Nunca o negcio esteve to dependente dos SI, um nmero elevado de empresas veria em risco o seu negcio, se por um acaso se visse privada do seu SI Evoluo do modelo Cliente/Servidor, para Constitudas por 2 ou mais camadas (N-TIER), SI, centralizado apenas num computador com papis bem definidos, quer do ponto de vista de HW como de SW, capazes de trocar informao entre si. um modelo baseado em WEB Services, baseado em standards, vai permitir interaco entre as aplicaes independentemente da plataforma onde so executadas ou da linguagem em que foram desenvolvidas Tabela 1-I Resumo Processos de Negcio versus Evoluo das Plataformas

Arquitectura

CAPTULO II
2. Estado da Arte
Como referido anteriormente, o conceito SaaS, assenta em princpios quase opostos ao desenvolvimento ou aquisio tradicional de software. O objectivo deste captulo realizar

um estudo bibliogrfico, que permita enquadrar devidamente este novo conceito, tanto do ponto de vista tecnolgico, como do ponto de vista econmico, assim o captulo est dividido em trs seces: Primeira Seco pretende ilustrar as componentes tecnolgicas que permitem nos dias de hoje pensar-se num conceito SaaS; Segunda Seco pretende retractar o SaaS de uma forma mais detalhada, bem como averiguar qual o posicionamento que a indstria das TI adoptou face a este novo conceito; A terceira Seco explora a componente econmica, num perodo particularmente difcil, os investimentos em TI, tm de ser geridos para que consigam ser materializados em benefcios, objectivo nem sempre alcanado. Pretende-se ilustrar o porqu, bem como apresentar mtodos alternativos que trazem consigo diferentes abordagens ao tema.

2.1.

Seco I
Esta seco tem como objectivo explicar como as arquitecturas de sistemas de

informao passaram de uma viso centrada no mainframe para uma viso cada vez mais distribuda. 2.1.1.

Sistemas Distribudos
Com o aparecimentos dos sistemas distribudos, acontece um fenmeno inimaginvel,

que o facto do processamento de dados, sair das portas do CPD (Centro Processamento de Dados), deixa de haver a noo que tudo tem que se centralizar num nico ponto. Esta arquitectura permite distribuir o processamento por camadas (tiers). A primeira noo de 10

sistemas distribudos aparece com as arquitecturas Cliente/Servidor. O processamento agora dividido por dois tipos de equipamento, a componente cliente responsvel pela entrada e validao de dados, a componente servidor tem a seu cargo operaes como, processar, armazenar e distribuir a informao [Laudon 2000].

Figura 2-I - Exemplo Arquitectura Cliente/Servidor

Um exemplo de uma arquitectura Cliente/Servidor, referida na Figura 2-I, este tipo de arquitectura dividido em duas camadas, cada uma com equipamento e funes perfeitamente definidas. Denominadas tambm por arquitecturas de duas camadas TWO-TIER, em modelos mais complexos, poder haver necessidade de existir um nmero maior de camadas, arquitecturas multi-camada N-TIER.

Com o desenvolvimento das arquitecturas de sistemas distribudos, evoluram para um novo patamar, que a definio de Coulouris [Coulouris et al. 1994] define como um conjunto de computadores autnomos interligados atravs de uma rede de computadores, equipados com software que permite a partilha de recursos do sistema, dos quais se destacam as seguintes caractersticas: Partilha de recursos: Um sistema distribudo permite a partilha de recursos de hardware e software, como discos, impressoras, ficheiros e compiladores, que esto associados a diferentes computadores de uma rede. Heterogeneidade: Possibilidade at ento vedada, de diferentes sistemas comunicar entre si, independentemente do fabricante do hardware ou software.

11

Concorrncia: Num sistema distribudo, vrios processos podem operar ao mesmo tempo em diferentes computadores na rede. Esses processos comunicam entre si, durante a sua operao normal.

Escalabilidade: Os sistemas distribudos so escalveis, no sentido de que a capacidade do sistema pode ser aumentada pelo acrscimo de novos recursos. Tolerncia falha: A disponibilidade de vrios computadores e o potencial de duplicar informaes significa que os sistemas distribudos podem ser tolerantes a eventuais problemas de hardware e software.

Transparncia: As diferentes formas como as componentes que constituem o sistema de informao interagem entre si, dever ser transparente do ponto de vista do utilizador final.
Apenas ser possvel, tirar partido dos sistemas distribudos, quando acompanhados

por uma evoluo no desenvolvimento de aplicaes distribudas, destacam-se o CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model) e JavaRMI (Java Remote Method Invocation). No entanto, por uma ou outra limitao, estas solues no atingiram o nvel de consenso, que a tecnologia Web Services, entretanto viria a atingir. Tornou-se numa excelente alternativa para a integrao de SI em ambientes heterogneos, pela sua simplicidade, versatilidade e abertura, fundamentais para a sua escolha como tecnologia preferencial de integrao. 2.1.2.

WEB Services
Se o inicio dos Sistemas Distribudos permitiu que o processamento deixasse as portas

do CPD para de alguma forma se estender pela empresa. Com o nascimento dos WEB

Services assiste-se possibilidade de estender o processamento Internet. Trata-se de uma mudana radical em termos de pensamento. Se nos recordarmos que no h muitos anos atrs todo o processamento era efectuado num computador religiosamente guardado numa sala especialmente concebida para o efeito. Versus a possibilidade de ter aplicaes internas a interagir com outras aplicaes residentes algures na nuvem (cloud). A Internet v o seu mbito ainda mais alargado, se j era possvel aceder via WEB a aplicaes, documentos, recursos multimdia entre outros, permitido atravs da utilizao dos WS, que as aplicaes comuniquem entre si. 12

Figura 2-II - Interaco Utilizador-Servidor

A Figura 2-II tem como objectivo ilustrar uma interaco tpica entre um utilizador e um site, onde realizada uma questo (request) a que o servidor de pginas responde. A Figura 2-III ilustra o comportamento quando a interaco realizada entre servidores.

Figura 2-III - Interaco Aplicao-Aplicao

Este tipo de comunicao deve-se ao facto dos WS terem como base standards que

permitem que as aplicaes possam interagir entre si, independentemente da linguagem em que foram desenvolvidos, ou da plataforma em que so executadas. Este facto explica o sucesso dos Web services. Para que os standards fossem uma realidade, houve necessidade que os servios de arquitectura da W3C (World Wide Web Consortium) publicassem documentos orientadores para o desenvolvimento dos WS.

2.1.2.1.

Definio de WEB Services

A W3C definiu WEB Services como sendo uma componente de software, com capacidade para suportar a interoperabilidade mquina-a-mquina, sobre uma rede, tem um interface cuja responsabilidade descrever o tipo de servios (WSDL), outros sistema podem interagir com os WS atravs da utilizao de mensagens SOAP, normalmente transmitida atravs de HTTP com uma serializao XML [W3C 2004]. 13

Os Web Services reflectem uma nova aproximao arquitectural orientada ao servio. O facto da arquitectura dos WS terem como base o uso de normas e protocolos abertos como: XML (eXtensible Markup Language); SOAP (Simple Object Access Protocol); UDDI (Universal Description, Discovery and Integration); WSDL (Web Service Definition Language); HTTP (Hypertext Transfer Protocol); Contraria a anteriores tendncias ao no estar associao a uma plataforma ou linguagem de programao, elementos que explicam a sua larga aceitao.
CORBA Formato dos Dados Protocolo de Transporte Descrio Interface Mecanismo Descoberta CDR IIOP CORBA IDL Naming Service JAVA RMI Serializao JRMP Java Interface JAVA RMI Registry WEB SERVICE XML http, SMTP, FTP, WSDL UDDI

Tabela 2-I - Quadro Comparativo entre CORBA, JAVA RMI e WEB Service

A Tabela 2-I ilustra as principais diferenas entre o CORBA, o Java RMI e os Web Services. Estes ltimos podem proporcionar uma vantagem competitiva sobre tecnologias concorrentes, tais como o RPC, o CORBA, o DCOM e o Java RMI, devido ao facto destas serem de difcil implementao ou utilizarem normas fechadas, no tendo ganho uma aceitao generalizada entre os fornecedores de software. Entre uma aplicao distribuda tradicional e uma aplicao constituda por Web Services no existem muitas diferenas, contudo o uso de protocolos normalizados e abertos, a forma como os dados so manipulados e a forma como as chamadas a mtodos remotos so realizadas tornam esta nova forma de desenvolver aplicaes distribudas um caso de sucesso [Cardoso 2008]. Vrias empresas esto a usar os WS como soluo para atingir uma maior interoperabilidade, uma reduo da dependncia em tecnologias proprietrias, uma flexibilizao dos sistemas e uma melhor capacidade de cooperao entre empresas. Alm disso, tambm permitem reduzir a complexidade das solues distribudas e diminuir os custos de desenvolvimento e integrao.

14

2.1.3.

SOA (Service-Oriented Architecture)

Service-Oriented Architecture (SOA), pode ser traduzido como arquitectura

orientada a servios, estamos perante um estilo de arquitectura, que assenta no princpio do servio. Fazendo uma comparao com um tradicional programa desenvolvido numa qualquer linguagem de programao, em que as sua funcionalidades se dividem em funes ou procedimentos que vo sendo chamadas consoante a lgica do programa. No SOA as funes so substitudas por servios, que tambm sero invocados consoante as necessidades. Estes servios so obviamente materializados em WEB Services, cujas vantagens foram referidas no ponto anterior (2.1.2). possvel encontrar variadssimas definies de SOA, em seguida sero apresentadas duas, a primeira que apresenta um carcter mais tcnico, a segunda mais enquadrada neste documento, que relaciona o SOA com os processos de negcio. 1. Uma definio mais tcnica define o SOA como sendo um tipo de sistema distribudo em que os agentes so servios. Um servio por sua vez materializado num software que executa um conjunto de tarefas bem definidas, que poder ser invocado de qualquer parte do sistema desde que sejam respeitadas as regras definidas ao nvel do interface bem como seja possvel a comunicao atravs de protocolos padro e formatos de dados [W3C 2003]. 2. SOA definido como uma Framework com capacidade de integrar os processos de negcios com a tecnologia da informao e infra-estruturas, atravs da chamada de componentes seguros e padronizados definidos como servios, que podem ser reutilizados e combinados de forma a responder s necessidades das empresas [BIEBERSTEIN et al 2006]. As arquitecturas SOA vm potenciar ainda mais a utilizao dos WEB Services, e ao mesmo tempo permitir que os processos de negcios sejam espelhados em servios que so orquestrados pelo SOA. Tal facto vai permitir conjugar resultados de diferentes origens, desde aplicaes desenhadas em (.NET) cuja fonte uma base de dados em MicrosoftSQL, como aplicaes vindas do mainframe cuja fonte poder ser uma base de dados IBMDB2, apresentando um resultado final certamente mais rico e integrado. Num passado no muito distante este tipo de operaes era segmentado em diferentes aplicaes consoante a 15

tecnologia. Alm de representar um constrangimento pelo facto de haver uma maior nmero de aplicaes para gerir, do ponto de vista de utilizador final o seu trabalho tambm fica mais dificultado pelo facto de ter que interagir com diferentes fontes de informao. O facto de as empresas terem ao seu dispor um maior dinamismo, vai-lhes permitir nveis de desenvolvimento de aplicaes mais rpidos, devido ao facto de os servios poderem e deverem ser reutilizados por diferentes aplicaes. Torna possvel aproximar os processos de negcio e as TI.

Figura 2-IV - Exemplo Prtico do SOA

Figura

2-IV

pretende

mostrar

conjugao

entre

WEB

ServicesSOAProcessos de Negcios. Como exemplo alguns processos do dia-a-dia, de uma qualquer instituio financeira, a camada mais baixa constituda pelos WEB Services que correspondem a componentes de SW com capacidade de recolher dados das mais variadssimas fontes, construdos em linguagens de programao com o COBOL, C, ou (.NET). A camada intermdia representada pelo SOA, que tm a capacidade de orquestrar os servios, quer nos que diz respeito aos pedidos, quer atravs da conjugao das respostas. Na ltima camada concentram-se os processos de negcio que foram desenhados tendo como base a possibilidade que o SOA oferece de articular as diferentes fontes, permitindo dar resposta aos clientes finais, independentemente da plataforma onde 16

estes se encontram. No caso de uma instituio financeira actualmente possvel receber pedidos de diferentes canais, desde o tradicional balco de atendimento consulta atravs da Internet, ou PDA (Personal Digital Assistants). Neste exemplo est bem patente o reaproveitar de servios para diferentes fins, bem como o desenho dos processos de negcio, se torna independente do canal em que realizado o pedido, evitando assim duplicao de programas ou infra-estruturas.

2.2.

Seco II
Esta seco tem como objectivo detalhar o conceito SaaS, sobre diferentes pontos de

vista, desde a definio aplicabilidade, vantagens e desvantagens e por ultimo as ofertas de mercado. 2.2.1.

SaaS (Software as a Service)

Contextualizao do SaaS (Software as a Service)

2.2.1.1.

A IDC enquadra o conceito SaaS no modelo de utility computing. A definio de utility computing segue a linha de pensamento que tem vindo a ser descrita ao longo deste documento, em que a tendncia colocar os servios de TI, como se de um outro servio de tratasse, tal como se contracta a gua, a luz ou o telefone. Servios que em ingls se denominam de public utility ou simplesmente utility, dai o nascimento da expresso utility computing. Neste segmento alm do j referido SaaS, so usualmente includos conceitos como: Cloud Computing, Edge Computing e Green Computing Este conceito vem na sequncia de outros dois, mais antigos que so o Outsourcing e o Managed Services, cada um sua maneira, pretendem responder a um problema com que as empresas ou organizaes se deparam, que o custo elevado das TI. No que diz respeito ao presente, bem como as perspectivas futuras que no so nada animadoras, como poder ser verificado pela Figura 2-V, que tem como base o estudo [IDC 2007a], em que relevada uma tendncia preocupante. Que fez despertar todos os que esto relacionados com as TI, evidenciado que os custos do SW ou do HW no finalizam aps a sua aquisio, antes pelo contrrio. Como se pode ver pelo grfico os custos relacionados com a gesto e administrao do dia-a-dia de todo o parque informtico ocupam 17

propores cada vez maiores, adicionando os custos relacionados com a energia e sistemas de arrefecimento, legitimo questionar-se at que ponto rentvel para as empresas terem os seus prprios CPDs. O autor Nicholas Carr reforou este ponto num artigo intitulado The End of Corporate Computing, onde compara a actual gerao das TI com as empresas que no final do sculo XIX tinham os seus prprios geradores, que garantiam a produo de energia necessria para as suas linhas de produo [Carr 2005]. luz dos nossos dias este princpio pode parecer quase ridculo, a questo que se coloca, qual ser a opinio que as geraes futuras vo ter, das empresas que hoje optam por ter as suas prprias infraestruturas geradores de TI.

Figura 2-V - Gastos em TI [IDC 2007a]

Dai a razo de surgirem modelos em que os custos de infra-estrutura e gesto da mesma so transferidos para terceiros. A IDC, no seu estudo [IDC 2003], tem como objectivo comparar e revelar tendncias pelos modelos referidos.

18

Figura 2-VI - Tendncias dos Modelos [IDC 2003]

Atravs da anlise da Figura 2-VI, verifica-se que a resposta inicial ao problema dada sob a forma de servios tradicionais de outsourcing. Numa segunda fase e fruto do desenvolvimento tecnolgico e da maior maturidade de modelos tipo Service Provider e Hosting, regista-se uma evoluo no sentido dos Managed Services. No entanto, e apenas numa fase mais recente, que se verifica a possibilidade de gerir as TI num verdadeiro conceito de servio. A Tabela 2-II evidencia as diferenas entre os conceitos referidos.
1 Gerao: Outsourcing Controlo dos Funcionrios funcionrios de TI do cliente por parte do fornecedor Pertencente ao cliente Activos (Rede + TI) Pertencente ao cliente mas com tendncia para ser do fornecedor Nvel de partilha da Infra-estrutura Local de entrega dos servios Normalmente nas instalaes do cliente Entregue remotamente, atravs de um datacenter de terceiros Adaptados e definidos pelo cliente Adaptados e definidos pelo cliente Adaptados, definidos pelo cliente ou uniforme Adaptados, definidos pelo cliente ou standard Uniforme - baseado na utilizao Entregue remotamente, atravs de um datacenter de terceiros Uniforme Nenhum Parcial Total Pertencente ao fornecedor 2 Gerao: Managed 3 Gerao: Utility Computing Recurso aos funcionrios do fornecedor

Hosted Services Recurso aos funcionrios do fornecedor

SLAs

Preo

Tabela 2-II - Comparao Outsourcing,Managed Services e Utility

19

2.2.1.2.

Definio do SaaS (Software as a Service)

Quando as empresas ou organizaes, de forma a responderem a uma nova necessidade de negcio ou corrigir uma situao anmala, tm necessidade de ter disponvel um novo componente de software, tm agora um modelo denominado de SaaS, cuja base se diferencia do modelo tradicional. Trata-se de um modelo de disponibilizao de software, prefervel a utilizao do termos disponibilizao ao invs de distribuio, encontra-se em muita literatura o termo: distribuio de software ou em ingls software deployment, esta expresso poder ser confundida com as aplicaes que tm como misso distribuir novos pacotes ou actualizao de software para os PCs. Uma vez que o conceito de SaaS tem um mbito distinto, a chamada de ateno justifica-se. O SaaS torna disponvel um determinado pacote de software, sem que o mesmo esteja instalado nas instalaes da empresa, est alojado sim num prestador de servios, em que a Internet serve de meio, entre a entidade que prestadora do servio e a entidade que consumidora do mesmo. Estes so em traos gerais as caractersticas do SaaS, contudo a IDC atravs de uma publicao [IDC 2005], definiu as principais caractersticas: Disponibilizao por parte de um prestador de servios de um pacote de software, considerado comercial, portanto no adaptado a cada cliente, o objectivo tambm que seja dada a possibilidade de a entidade prestadora conseguir criar economias de escala, sendo assim possvel que o mesmo SW possa servir mais que um cliente. No seguimento do ponto anterior, do ponto de vista do prestador de servios, este vai seguir um modelo denominado um-para-muitos (one-to-many) baseada numa arquitectura multi-tenant, ao invs do modelo um-para-um (one-to-one). Todas as actividades de gesto do software, so realizadas de uma forma central, ao invs de da gesto em cada cliente, aos clientes permitido acederem remotamente s aplicaes atravs do uso da Internet. O conceito SaaS assemelha-se a um modelo anterior que no teve tanto sucesso, como se esperava aquando do seu aparecimento, denomina-se ASP (Application Service Providers). Os princpios so em tudo idnticos, ambos preconizam o facto de o software 20

ser fornecido com se de um servio se tratasse. legitimo colocar a seguinte questo: O que mudou para que se justifique o sucesso que est a ter desde j o SaaS? A resposta dada nos trs pontos que se seguem: Tem se verificado ao nvel das empresas de comunicaes, um aumento de largura de banda disponvel a preos atractivos, num modelo em que o meio de transporte se baseia na Internet, ter um bom acesso a um custo acessvel um ponto de partida na tomada de deciso. A variedade de servios hoje oferecida seguindo o conceito SaaS, grande em termos de quantidade pela variedade de servios oferecidos e rica tambm em termos qualitativos pelo facto das maiores empresas de informtica, no terem deixado passar mais esta oportunidade de negcio. Permite por um lado uma mltipla escolha, assim como confere ao conceito um maior grau de confiana, aliado ao facto do modelo assentar em bases tecnolgicas cada vez mais preocupadas com as questes de segurana, mais um passo para que as organizaes estejam dispostas a migrar dados crticos de negcio fora de suas instalaes. Adicionalmente outro ponto no menos importante e j referido anteriormente foi o aumento de custos para com os Data Centers. Pela definio em si do SaaS, elimina-se desde logo a necessidade que o cliente tem de efectuar um conjunto de investimentos a que estava habituado aquando do modelo tradicional, este claramente o factor que as empresas e organizaes que apostam no SaaS pretendem alcanar, mantm o mesmo nvel de servio e vm reduzidas as despesas com as TI. A Tabela 2-III pretende evidenciar de uma forma clara as diferenas entre o conceito SaaS e o modelo tradicional, que descrito em muita literatura com o nome de on-premises.

21

Modelo Tradicional Implementao Aquisio SW/HW Gesto continuada Gesto, Operao, Monitorizao, Resoluo de Incidentes Utilizao Utilizao do SW Aps o Setup da infra-estrutura, esta pode ser usada para a capacidade que foi dimensionada sem custos adicionais Outros Indisponibilidades no previstos, Licenas subutilizadas Continuidade de Negcio Custos altos para a instalao de centros negcio Tabela 2-III - Comparao Modelo SaaS/Tradicional de continuidade de Pagamento desnecessrio de Custos alto para o negcio em termos de falhas imprevistas Custos de Setup, altos necessidade de investimento em HW e SW logo de inicio Custos elevados, com equipas de administrao de sistemas e HelpDesk. Contractos de manuteno de HW e SW

Modelo SaaS Sem necessidades de investimento iniciais no que diz respeito a HW e SW Sem necessidades de custos

operacionais, quando muito custo inerentes gesto dos SLAs (Service Level Agreement) ou Acordo de Nvel de Servio O custo est com directamente o nvel de

relacionado utilizao

Este tipo de responsabilidades transferido para o parceiro, atravs do pagamento da utilizao

licenas em subutilizao

Deixa de ser necessrio um centro alternativo, visto que o SW no est nas instalaes

2.2.1.3.

Adopo de Aplicaes e Servios SaaS (Software as a Service)

O SaaS um conceito ainda emergente, est a ser adoptado essencialmente pelas PME (Pequenas e Mdias Empresas), a principal razo deste interesse assenta nos seguintes factores: As estruturas de TI so relativamente pequenas e simples, por isso so fceis de integrar ou substituir. Possibilidade de com este conceito, poderem ter acesso a determinado tipo de software, que devido sua capacidade financeira ou a falta dela, no seria possvel. Dificilmente uma PME ter capacidade financeira para efectuar um investimento inicial para aplicaes do tipo: SAP ou ORACLE, o SaaS poder ser a soluo para o acesso a componentes de software outrora inalcanveis. 22

Nas chamadas empresas grandes onde o factor econmico poder no ser um factor determinante para a escolha de um software, no sendo obviamente um elemento a descorar. A opo de se enveredar pelo conceito SaaS em algumas aplicaes pode-se justificar nos seguintes casos: Aplicaes Departamentais com nveis de acesso menores; Aplicaes de Futuro incerto; A histria das TI est recheada de projectos que tinham tudo para dar certo, com perspectivas de lucros enormes, mas que por uma ou outra razo, acabaram por ser um fracasso. Um exemplo recente o WAP (Wireless Application Protocol), em volta do qual se perspectivou um enorme potencial, e que no se concretizou. Perante a possibilidade de evitar um investimento inicial grande, para algo que ainda incerto, uma soluo SaaS, ser certamente uma opo a ter em conta e ter certamente grande aceitao. A Figura 2-VII representa dois estudos efectuados por empresas distintas com o intervalo no tempo de apenas um ano. Existem apenas pequenas diferenas principalmente na ordem em que aparecem as aplicaes, tm em comum o tipo de software que neste momento est a ser uma aposta.

Figura 2-VII - Adopo de Aplicaes em SaaS

23

Se por um lado se assiste a um conceito em pleno crescimento. No outro prato da balana esto factores que ainda conseguem ser elementos desencorajadores que inibem a opo pelo SaaS. Um dos factores que lidera a tabela das preocupaes [IDC 2007b], claramente a segurana, como dito anteriormente estamos perante uma nova realidade que rompe com as ideias em vigor. Ser natural este tipo de resistncia, principalmente em meios mais conservadores, um conceito onde a empresa ou organizao se expe claramente ao exterior. Outro ponto assinalado que merece reflexo, o pagamento continuado por utilizao, este conceito no dever ser visto como aplicvel a todas as realidades, obviamente que ter de haver sempre uma ponderao entre o modelo tradicional e este conceito ainda emergente. Sendo um dos objectivos deste trabalho ajudar na reflexo, elucidando quais os pontos a levar em conta aquando da deciso. Este tema ser desenvolvido no Capitulo III, mas desde j se depreende que a ponderao ter de ser feita entre as poupanas que este novo modelo permite, que se traduzem num determinado valor, versus o pagamento que ser efectuado pela utilizao do servio, que ter tambm ele um valor, desta equao cabe aos responsveis das empresas decidir qual a melhor opo para cada caso.

Figura 2-VIII - Factores desencorajadores do SaaS [IDC 2007b]

24

2.2.1.4.

Ecossistema SaaS

Pese embora o foco deste documento estar dirigido na perspectiva das empresas ou organizaes consumidoras do conceito SaaS. O mesmo no se esgota nesse ponto de vista, se existem entidades consumidoras, ter necessariamente que haver quem fornea o servio, onde obviamente tambm existe um conjunto de particularidades a ter em conta.

Figura 2-IX-Ecossistema SaaS [CARRARO 2006]

A Figura 2-IX, pretende ilustrar o ecossistema SaaS, segundo as camadas que o compem, assim como a forma como esto relacionadas: Hoster Clssicos: Esta camada representa as clssicas empresas de hosting, cujo desafio que tm evoluir tambm elas para o patamar superior e assim conseguirem rentabilizar infra-estruturas fsicas e equipas de TI, caso no seja esta a opo facilmente sero ultrapassados pelas inmeras ofertas que tm vindo a florescer nesta rea. Hoster SaaS: As empresas que se situam na camada de fornecedores de servios segundo o conceito SaaS, tm pela frente a tarefa de vencer neste conceito ainda emergente para tal so importantes: o Bons nveis de servios, medidos pelos SLA; o Bons nveis de segurana; Aposta em Arquitecturas de multi-cliente (multi-tenant), como representado na Figura 2-X, do ponto de vista do prestador de servios, existe toda a convenincia em evoluir 25

para arquitectura multi-cliente de forma a conseguir obter economias de escala, no exemplo representado ao consolidar os dados dos diferentes clientes (tenant), existe desde logo ganhos de: o Rentabilizao das infra-estruturas; o Poupana ao nvel do HW, que trs consigo poupana de espao, energia e administrao; o Poupana de licenciamento; Obviamente que as arquitecturas multi-cliente, nunca podero colocar em causa a integridade ou segurana dos dados, este tipo de arquitecturas devem ser totalmente transparentes do ponto de vista do consumidor

Figura 2-X - Evoluo de Arq. Dedicada para Multi-cliente

Agregadores: A camada intermdia existente entre os fornecedores de servidores e o consumidor final preenchida pelos agregadores, um conjunto de oportunidades que os ISVs (Independent Software Vendors) certamente vo aproveitar, atravs do desenvolvimento de componentes de software responsveis por integrar os sistemas de informao residentes e os servios que so disponibilizados segundo o conceito SaaS.

SaaS Consumidores: Por fim esta ultima camada que tem vindo a ser o alvo preferencial deste trabalho, constituda pelas empresas ou organizaes que decidem aderir ao conceito SaaS.

26

2.2.1.5.

Que tipo de Aplicaes se enquadra no conceito SaaS?

A questo que se coloca, passa pela identificao das aplicaes que actualmente integram o Sistema de Informao, aquelas que so potencialmente candidatas a evoluir para o conceito SaaS. As tendncias de evoluo apontam para solues hbridas [Moore 2002], ou seja aplicaes que vo continuar o seu ciclo de vida seguindo o modelo tradicional e aplicaes que so claramente candidatas a evoluir para o conceito SaaS.

Figura 2-XI - Exemplo de Arquitectura hbrida

A Figura 2-XI representa um exemplo de uma arquitectura hbrida constituda por aplicaes seguindo o conceito tradicional e o conceito SaaS. Que aplicaes devem estar em que quadrante, Geoffrey Moore, classifica as aplicaes em CORE, aquelas que so vitais para o negcio e essas devem ficar sobre a alada da empresa, por outro lado as aplicaes denominadas de PERIFRICAS, so igualmente importantes, mas o negcio poder sobreviver em caso de indisponibilidade das mesmas. Estas so candidatas a evoluir para o SaaS. Figura 2-XII, pretende esquematizar a diferena entre tipo de aplicaes preconizada por Moore.

27

Figura 2-XII - Aplicaes vs Aplicaes Perifricas [Moore 2002]

2.2.1.6.

Ofertas de Aplicaes e Servios SaaS (Software as a Service)

O SaaS est a ter uma aceitao por parte das empresas lderes nos vrios ramos da informtica que encararam este modelo de duas perspectivas: Primeira: uma oportunidade de negcio, possibilidade de alargar o seu mbito de actividade e rentabilizar infra-estruturas. Segunda: este novo conceito representa partida uma ameaa aos pacotes de software mais tradicionais.

Figura 2-XIII - Evoluo do SaaS por Produto/Servio (Fonte:IDC 09/2009)

28

A Figura 2-XIII permite-nos ter uma viso de presente e de futuro no que diz respeito diversidade de oferta e tambm do ponto de vista de volume de negcios. No difcil encontrar artigos, estudos ou afirmaes que comprovam a aposta que a indstria das TI est a fazer no SaaS, so transcritas trs citaes que ilustram o quanto esto atentas as empresas do sector: Uma nova forma de disponibilizar Software est a abanar as fundaes do mercado de TI. Os fornecedores tradicionais de Software devero estar muito atentos
McKinsey Quarterly, Maio de 2007

Gravem as minhas palavras, todos os nossos produtos estaro disponveis no modelo de SaaS dentro de muito poucos anos
SteveBallmer Abril de 2007

A Gartner prev que em 2011, 25% de todos os novos negcios de software sero disponibilizados no modelo de SaaS
Gartner, O seis grandes desafios do modelo de SaaS para os ISVs, Agosto de 2007

Em seguida sero descriminadas quais as iniciativas que esto a ser levadas a cabo por um leque restrito, mas representativo de empresas. Microsoft A Microsoft enquanto maior empresa de software do mundo, no poderia deixar de ter a sua viso do SaaS, a Microsoft optou por criar uma soluo que denomina de Software plus Services (S+S). Apontado como sendo o prximo passo lgico na evoluo da computao. A Microsoft pretende combinar a riqueza dos dois mundos, o software instalado localmente, que actualmente j consegue proporcionar uma enorme riqueza de funcionalidades, com os servios disponibilizados atravs do SaaS, por vezes apelidados de servios na nuvem pelo facto de estarem associados Internet. Conseguindo assim, entregar solues mais atractivas, para os consumidores, programadores e empresas [Microsoft 2008a]. A forma como estes dois mundos so conjugados, d lugar a um modelo hbrido, apenas possvel pelo facto de por um lado a Microsoft dotar as suas aplicaes locais de funcionalidades que permitem o acesso WEB. Independente do 29

equipamento, seja um telemvel ou um PC, por outro lado oferece um conjunto de servios que pretendem complementar a utilizao local.

Figura 2-XIV- Modelo S+S Microsoft

A Figura 2-XIV, pretende elucidar o Modelo Hbrido, preconizado pela Microsoft, de seguida so apresentados exemplos de servios disponibilizados.
Servio Descrio Aplicao de correio electrnico, disponvel on-line, baseada na plataforma Exchange-2007, permite que o acesso ao mail, seja Exchange Online efectuado de qualquer parte do mundo, esto tambm includas funcionalidades como contactos, calendrios, agendamento de tarefas, anti-spam http://www.microsoft.com/online/exchange-online.mspx Desde $10/ms por utilizador Custos

(Maro 2009)
Conjunto de ferramentas disponveis online, com o objectivo de Microsoft Exchange Hosted Services (EHS) ajudar as organizaes a defenderem-se de spam,malware, conseguir satisfazer nveis de reteno que so cada vez mais uma questo de compliance, encriptao de dados de forma a preservar a confidencialidade. http://www.microsoft.com/online/exchangehosted-services.mspx (Maro 2009) Ferramenta de colaborao, online baseada em SharePoint, permite Microsoft SharePoint Online gesto de contedos, criao de workflows, partilha de documentos, elaborao de sites de projectos ou outros temas de interesse comum http://www.microsoft.com/online/sharepoint-online.mspx (Maro 2009) Tabela 2-IV - Servios disponibilizados Microsoft Desde $7,25/ms por utilizador Desde $1,75/ms por utilizador

30

Ainda integrada no conceito de software-plus-services, a Microsoft lanou uma plataforma que pelo seu carcter inovador, ser caracterizada parte dos servios atrs referidos. Denominada por Azure Services Plataform pretende ser no apenas um produto ou um servio mas sim uma plataforma.

Figura 2-XV - Plataforma Azure Services [Microsoft 2008b]

Com esta inovao a Microsoft, consegue oferecer um conjunto de servios que o cliente pode compor de forma a satisfazer as suas necessidades, conjugando de uma forma integrada, os servios disponveis na plataforma, como verificado na Figura 2-XV, acima representada. Dando um exemplo que facilita a compreenso, imagine-se um projecto que necessita de uma camada de apresentao, tipicamente desenvolvida em (.NET) e como base um motor de base de dados tipicamente Microsoft-SQL, com estes requisitos um projecto deste tipo poder perfeitamente ser alojado na plataforma azure-services, que tem como componentes disponveis .NET Services onde pode ficar alojada a componente de apresentao, complementada com a camada de base de dados alojada SQL Services. A referida plataforma consegue com este exemplo que tem as componentes tpicas de uma aplicao dar resposta ao projecto, fazendo querer que tem condies para ser uma aposta para o futuro, a plataforma est neste momento numa fase de piloto e comercialmente ainda no est disponvel.

31

IBM A IBM por sua vez tambm se viu forada pelos prprios clientes a apresentar uma estratgia na vertente SaaS, tal como a Microsoft fez com o software-plus-services, tambm a IBM criou um nome para a sua estratgia que denomina de IBM Cloud Services, durante o lanamento da iniciativa em Outubro de 2008, sublinha-se a afirmao do vicepresidente Willy Chiu: "We are moving our clients, the industry and even IBM itself to have a mixture of data and applications that live in the data center and in the cloud A estratgia da IBM foi inspirada segundo os responsveis, nos desejos manifestados pelos clientes, em terem os dados, servios e aplicaes independentemente do local, suportada em tecnologias standards. Esta estratgia assenta sobre quatro eixos, que a IBM considera essenciais para conseguir corresponder aos anseios dos seus clientes: 1. Criao de um portflio de servios, desenvolvidos e oferecidos pela prpria IBM; 2. Auxiliar os ISVs a elaborar, construir e disponibilizar servios na nuvem (cloud); 3. Auxiliar os Clientes a efectuarem uma integrao entre os servios on-premises, com os servios disponveis segundo o SaaS; 4. Providenciar ambientes ou plataformas capazes de proporcionar s empresas, a estabilidade necessria para que a aposta nesta nova realidade seja uma certeza; A IBM est a efectuar uma aposta forte neste novo conceito ao ponto de ter no inicio do ano de 2009 disponveis 13 centros dedicados Cloud Computing Centers, acompanhados de 40 centros de inovao, espalhados pelo mundo inteiro. A Tabela 2-V inmera e caracteriza alguns dos servios disponibilizados.

32

Servio

Descrio Ainda em fase beta a BlueHouse pretende ser uma rede social social networking,

BlueHouse

com disponibilizao de ferramentas de colaborao como partilha de documentos, contactos, com o objectivo de juntar pessoas e grupos de diferentes origens http://www.bluehouse.lotus.com (Maro 2009) Ferramenta que permite a criao de conferncias via WEB, incluindo a partilha de

Lotus Sametime Unyte IBM Rational Policy Tester OnDemand IBM Rational AppScan OnDemand Remote Data Protection

documentos, apresentaes ou aplicaes atravs de uma ligao WEB . http://www.sametimeunyte.com (Maro 2009) Tem como objectivo reduzir os riscos das aplicaes que esto disponveis on-line, analisa os contedos a fim de verificar a qualidade e acessibilidade dos mesmos

Tem como objectivo reduzir os riscos com a segurana dos Sites, esta aplicao efectua uma anlise na estrutura do Site procura de falhas de segurana Disponibiliza ao Cliente a possibilidade de armazenar a informao vital para o negcio, garantindo que os dados esto em segurana e o negcios est salvaguardado Tabela 2-V - Servios disponibilizados IBM

ORACLE A ORACLE tambm no est a alheia ao SaaS, tal como os restantes fabricantes tambm foi pressionada pelos seus clientes a terem uma oferta. A resposta no tardou, foi dada atravs da concepo de um conjunto de servios integrados, a que foi dado o nome de Oracle SaaS Platform. A ORACLE teve como linhas orientadoras o ponto de vista de negcio em consonncia com o ponto de vista tcnico. Do ponto de vista de negcio, os impulsos so os seguintes: Concentrao no Negcio: No conceito SaaS como j referido o cliente deixa de ter as preocupaes de carcter mais operacional, como aquisio de software, instalar, configurar e dar suporte, deixa este tipo de tarefas para um prestador de servios. Permitindo ao cliente canalizar esforos, quer financeiros, quer de recursos humanos, para o seu negcio, onde tem que se preocupar em evidenciar-se da concorrncia. Integrao: Um dos pontos mais requeridos, a garantia que as aplicaes que esto no modelo SaaS, no sejam vistas como ilhas ou silos de informao, antes pelo contrrio, consigam interagir com as restantes aplicaes. 33

Gesto de Nveis de Servios: O estabelecimento de nveis de servios por norma conhecidos por SLA (Service Level Agremment). Funciona como garantia que os nveis de servio estabelecidos, entre os clientes e fornecedores de servio so definidos de forma clara e objectiva, com repercusses em caso de incumprimento.

Time-to-Market reduzido: Com este modelo, torna-se possvel agilizar o desenvolvimento das aplicaes, de forma a apresenta-las ao mercado o mais rpido possvel, em tempo de apertada concorrncia a forma como se introduz um novo produto ou a forma como se reage face a uma potencial ameaa, far certamente toda a diferena

Aumento dos Custos Controlado: Torna-se possvel iniciar com um custo relativamente baixo, face a uma necessidade que de inicio tambm ela tende a ser baixa e ir incrementando os custos de uma forma suave em paralelo com o crescimento das necessidades. Ao invs do modelo tradicional onde a fase inicial acompanhada por um investimento forte, que poder desde logo colocar em causa a sobrevivncia das empresas ou organizaes

Segurana: A componente segurana, obviamente a grande preocupao deste modelo, quer por imperativos legais, quer por questes de confiana, ningum ousa colocar em causa os registos dos seus clientes.

Do ponto de vista tcnico, os impulsos so os seguintes: Gesto: Torna-se vital ter uma boa capacidade de monitorizar como o sistema est a responder, sempre na perspectiva do cliente, o ponto de partida para uma monitorizao dos indicadores de disponibilidade, desempenho e utilizao de nvel de servio. Segurana e Privacidade: Como j referido no ponto anterior, uma das principais preocupaes prende-se com a segurana e gesto da identidade. A

infra-estrutura deve garantir que os dados esto realmente seguros e as credenciais usadas para acesso aos mesmos so credveis. Ferramentas de auditoria devem estar disponveis para monitorar o acesso e utilizao. Servios Partilhados e SOA: A disponibilizao de servios, com base num modelo SOA, permite ao prestador de servios. Disponibilizar aplicaes que podem ser reutilizadas ao invs de aplicaes monolticas. Permite um desenvolvimento mais 34

rpido das aplicaes, visto que podem ser construdas na base da conjugao de um conjunto de servios compostos de forma a satisfazer os requisitos da aplicao, ao invs de desenvolver a aplicao de raiz. Permite tambm aumentar os ndices de interoperabilidade com outras aplicaes, definir e medir tempos de resposta e disponibilidade de servios especficos. Multi-Inquilino (multi-tenancy): Poder haver a tendncia para o ISVs, terem uma nica infra-estrutura SaaS em arquitectura multi-tenancy, que a vo tentar rentabilizar ao mximo, partilhando-a pelos seus clientes (inquilinos). Torna-se importante realar que, embora existam vrias vantagens de utilizar toda a plataforma, a mesma pode ser usada segundo as necessidades do cliente. A Oracle permite assim que as empresas consigam um ambiente hbrido, constitudo pelas suas aplicaes (on-premises) com as aplicaes SaaS.

Figura 2-XVI - Plataforma ORACLE SAAS [ORACLE 2008]

A Figura 2-XVI, acima foi adaptada da original, tendo sido ligeiramente alterada no sentido de melhorar a compreenso da mesma, dividindo as componentes por funcionalidade. Em seguida apresentado um quadro, que tende a explicar com mais pormenor qual o papel de cada componente. 35

Servio

Descrio A camada Base de Dados, sem dvida alguma a pea principal da plataforma, as caractersticas descritas em seguida conferemlhe os requisitos necessrios para ser considerada uma ptima opo no modelo SaaS. A opo Real Appplication Cluster permite que a mesma base de dados esteja distribuda por vrios servidores, idntico a uma

Oracle Database

grelha. Outro factor em consonncia com o anterior o facto de a BD poder crescer em termos de Storage alocado de uma forma automtica graas ao Automated Storage Management, camada que fica entre a BD e o Storage que permite este dinamismo. O Active DataGuard for Disaster, permite sincronismos de BD a longas distancia (+200 milhas) e garante a recuperao aps um acidente, em segundos A facilidade Partinioning for Performance, permite a diviso de bases de dados de grandes dimenses melhorando os ndices de performance no acesso aos dados, bem como a gesto das mesmas Aps a camada de dados referida no ponto anterior, esta componente tem como responsabilidade providenciar um conjunto de WEBServices, que tm a responsabilidade de fazer a

Oracle Real Application Clusters for database grid Automated Storage Management for storage grid Active DataGuard for disaster recovery Partitioning for performance and manageability

Shared Services, SOA and Integration

ligao aos dados, como so feitos base de WEBServices, confere que os dados possam ser acedidos por qualquer tecnologia e qualquer fabricante, desde que respeite as regras implementadas Esta camada faz uso da anterior, para permitir s empresas a possibilidade de interaco com as suas aplicaes, tendo como

Customizable Business Processes

pano de fundo a utilizao de BPEL (Business Process Execution

Language).
Business Intelligence projectada para permitir relatrios, Real-time In-process Analytics grficos e anlises a serem embutidos nas aplicaes. Torna-se possvel SaaS Tabela 2-VI - Servios disponibilizados ORACLE disponibilizar estes recursos no contexto do

36

AMAZON A forma como a Amazon entra no mercado SaaS diferente das restantes j analisadas neste documento. Como sabido a Amazon no uma empresa cujo objectivo principal vender e desenvolver solues na rea das TI ao contrrio das anteriores. A oportunidade surge graas ao investimento que a Amazon realizou ao nvel dos data centers que tem espalhado pelo mundo, bem como devido ao facto de ter desenvolvido um conjunto de Web Services que permitiu efectuar a integrao entre as equipas de infraestrutura e as equipas de desenvolvimento. Quem saiu beneficiado numa primeira instncia foram as aplicaes disponibilizadas pela Amazon aos seus clientes tradicionais. Numa outra instncia surgiu a possibilidade de disponibilizar os servios desenvolvidos, como WEB Services, que em conjunto permitem a Amazon disponibilize uma plataforma capaz de responder aos clientes que pensem em avanar para uma soluo baseada no conceito SaaS.

Servio

Descrio um servio WEB, que permite distribuir uma mesma aplicao por N instncias diferentes, permitindo assim o correcto balanceamento e redundncia em caso de falha

Amazon EC2 A aplicao distribuda no conceito de servidor virtual, Amazon Elastic Compute Cloud independente do SO, a imagem armazenada no Amazon S3 e poder ser multiplicada por N, conforme as necessidades http://aws.amazon.com/ec2/ (05-01-2009) O objectivo do Amazon S3, disponibilizar na Internet, atravs de WEB Services, espao em disco (storage) Foram providenciados os mecanismos de segurana necessrio Amazon S3 Amazon Simple Storage Service Actualmente disponvel para os Estados Unidos e Europa, a quantidade de informao pode ir dos simples GB at quantidades superiores a 500 TB. A forma como so pagos para garantir que os dados so apenas acedidos por quem de direito

37

depende do volume de dados, transferncia e pedidos http://aws.amazon.com/s3/ (05-01-2009) O Amazon CloudFront um Web service, desenhado com o objectivo de fazer chegar dados ao cliente final. O facto de a Amazon dispor de uma rede global, permite que o contedo esteja geograficamente mais prximo do utilizador final Amazon CloudFront evitando assim questes de lentido e latncia. Este servio trabalha em sintonia com os restantes http://aws.amazon.com/cloudfront/ (05-01-2009) O Amazon SimpleDB um servio Web, cujo objectivo fornecer as funes nucleares de uma base de dados, desde indexao e consulta. Amazon SimpleDB Este servio funciona em estreita articulao com o Amazon S3 e o Amazon EC2, permitindo assim armazenar, processar e consultar conjuntos de dados na nuvem. http://aws.amazon.com/simpledb/ (05-01-2009) O Amazon SQS uma infra-estrutura que poder ser vista como um local seguro, onde podem ser trocadas mensagens entre componentes de diferentes computadores permitindo assim que os mesmos possam comunicar independentemente da tecnologia Amazon SQS Amazon Simple Query Service onde esto desenvolvidos A Amazon anuncia este servio como sendo escalvel, robusto e barato, por apenas um dlar possvel a um utilizar transmitir 500.000 mensagens http://aws.amazon.com/sqs/ (05-01-2009) Tabela 2-VII - Servios disponibilizados AMAZON

38

2.3.

Seco III
Esta seco tem como objectivo identificar as questes relacionadas com os

investimentos em TI. Identificando as lacunas das tradicionais formas de avaliar investimentos e benefcios, identificando duas diferentes abordagens ao tema. 2.3.1.

Investimentos em SI/TI
Como j referido no Capitulo I existe uma preocupao subjacente no que diz

respeito aos investimentos realizados na rea das TI. Por norma tm uma conotao negativa, cujo retorno no tem correspondido em termos de produtividade s expectativas. Algo que se tornou mais evidente aps o aumento desenfreado do investimento em TI (boom) verificado na dcada de 90, tambm conhecida pela era das dot.com. Deu azo inclusive a que surgisse o termo nova economia, como referido por John Ward [Word 2007]. Destaca-se um estudo realizado por Diana Farrell [Farrell 2003], cujo objectivo era identificar as razes que levaram a que os indicadores de produtividade e investimento em TI durante a dcada de 90 terem crescido em simultneo. Uma das hipteses era determinar se existe alguma relao entre as duas variveis referidas ou se estamos na presena de apenas uma coincidncia estatstica. No estudo concludo que o aumento da produtividade, se deveu em primeira instncia a um intensificar da competitividade, que obrigou os gestores a inovarem nos mtodos de gesto utilizados. Afinal as TI so importantes, mas no so a fonte primria de competitividade, logo a essncia da nova economia, associada a um maior crescimento da produtividade, est no ciclo: competio inovao crescimento da produtividade, e no nas TI por si s. Sem retirar mrito s TI, que durante os anos 90 foram instrumentos especialmente poderosos, permitiram desenvolver novas plataformas de negcio, novos canais Cliente Empresa. A grande vantagem apenas alcanada quando a adopo de novas TI, est associada s competncias especficas da empresa ou organizao, sendo esse o elemento diferenciador face concorrncia. Como alias referido por Diana Farrell firms must understand that IT alone is almost never a true differentiator. 39

Tambm Michael Porter [Porter 2001], numa reflexo sobre as estratgias e Internet, vem realar que as empresas tm que continuar a apostar nos seus tradicionais pontos fortes como so a aposta em produtos nicos, com um forte conhecimento dos mesmos, forte relacionamento com os clientes. Nesse contexto a Internet ter que ser vista como um meio de fortalecer as vantagens referidas. 2.3.2.

Mtodos tradicionais de Avaliao dos investimentos em TI

De forma a inverter a tendncia e de alguma forma provar que os investimentos em

TI trazem de facto um valor acrescentado para as empresas e organizaes. Tem havido uma preocupao em medir o sucesso dos investimentos realizados. A forma mais frequente de se efectuar a avaliao de um investimento em TI, atravs da realizao de um business case [ROSS 2002]. Em grade parte dos casos o mesmo realizado em torno do clculo do ROI (Return On Investment). A popularidade deste indicador de tal forma grande que por muitas vezes se confunde com o termo business case.

(1) O clculo do ROI (1) tem como um dos argumentos o retorno financeiro esperado aquando da realizao do investimento. Este retorno nos projectos de TI, muitas vezes traduzido atravs da reduo de custos que se obtm com a implementao de determinado projecto. O uso do ROI apesar da sua utilizao em grande escala tem partida uma lacuna, que o facto de no contemplar a varivel tempo. Poder no ser interessante do ponto de vista de quem investe, se o retorno tardio em termos temporais.

(2) Surgiu ento a necessidade de introduzir indicadores financeiros, onde a varivel tempo levado em conta. Como por exemplo o VAL (Valor Actual Liquido) (2), onde o cash flow (fluxo de caixa, diferena entre proveitos e custos) gerado espelhado ao longo do tempo de vida do investimento. Atravs da conjugao dos diferentes indicadores torna40

se possvel classificar os projectos do ponto de vista financeiro e atribuir-lhe assim uma prioridade de execuo dos mesmos. Esta forma de analisar os investimentos, apenas sobre a perspectiva financeira algo limitadora e d azo a que proliferam os projectos de menor custo, aqueles que so mais fragmentados e localizados em departamentos. Ao invs de uma viso mais empresarial, onde os projectos tm tendncia a ver o seu custo aumentado. A ineficcia dos mtodos tradicionais de avaliao dos investimentos comprovada atravs do estudo realizado pelo Lambert e Edwards [LAMBERT 2003], cujo objectivo foi identificar junto de cerca de 100 empresas, quais as consequncias de continuarem as apostas nos mtodos mais tradicionais na hora de ponderar os investimentos em TI. Na Tabela 2-VIII esto representados os resultados desse estudo. Sim
A avaliao dos Investimentos em TI importante para os gestores de negcio Existe um modelo efectivo de avaliao dos investimentos Os gestores de negcios esto envolvidos na avaliao dos investimentos em TI O processo de avaliao considera as alteraes realizadas no negcio Os responsveis pela tomada de deciso compreendem os business cases Qual a % de projectos, cujos benefcios justificaram o investimento 55% 22% 30% 10% 25% 27%

No
45% 78% 70% 90% 75% 73%

Tabela 2-VIII - Levantamento do processo de Avaliao dos investimentos em TI

O estudo revela algumas lacunas que de alguma forma explicam a opinio generalizada que se criou em relao aos investimentos em TI, dos quais se destaca: Um processo de avaliao ineficaz: um investimento no poder ser julgado apenas na ptica financeira. certo que existem benefcios que so tangveis aos quais se poder aplicar ndices financeiros. Todavia, existem tambm benefcios intangveis que no so de todo quantificveis. Como exemplos neste campo temos investimentos que trazem qualidade e bem-estar nos postos de trabalho ou iniciativas que transmitam tranquilidade aos colaboradores. Por outro lado existem projectos de carcter infraestrutural que so transversais a toda a empresa, cujo custos dos mesmos difcil de imputar, assim como o retorno dos mesmos tambm se torna muitas vezes difcil de calcular. 41

Falta de envolvimento entre os responsveis de TI e responsveis de negcio: Os responsveis de negcio, no colocam em causa a importncia dos investimentos realizados em TI, no entanto face ao avano rpido que se assiste nesta rea, torna-se difcil para quem no est por dentro acompanhar esta evoluo, comeando desde logo pela linguagem. Um estudo realizado pela iSociety [iSOCIETY 2003] identifica trs reas de separao: o Espacial: A separao comea desde logo, na separao fsica, a que remetida a equipa da rea das TI. Devido distncia tende a que cada grupo desenvolva hbitos de trabalho de forma isolada, longe da vista longe da mente. o Cultural: Pelo facto das equipas terem perfis diferentes, existe muito a cultura do ns e eles, revela um distanciamento no justificado quando se est na presena de colaboradores que deveriam trabalhar em prol de um objectivo comum. Outro factor a questo da linguagem, os gestores de negcio queixam-se que a equipa de TI tem uma linguagem prpria. o Estrutural: Questes estruturais, como a escolha de equipas em regime de Outsourcing para desempenhar determinadas actividades da rea de TI outro dos factores identificados.

2.3.3.

Gesto de Benefcios nova abordagem

Torna-se urgente a criao de um processo de avaliao dos investimentos

realizados na rea das TI, que consiga dar resposta tanto a gestores de negcio, como responsveis de TI. A resposta tem vindo a ser dada por um programa levado a cabo pelo Information System Research Center (ISRC) pertencente Cranfield School Management, o programa tem vindo a ser consolidado entre os anos 2004 e 2007, atravs da implementao do mesmo em organizaes localizadas na Europa, Estados Unidos e China. Sero identificadas as caractersticas principais do modelo, bem como o que o distingue da forma tradicional de avaliar investimento. Esta abordagem gira em torno de um novo conceito de gesto de benefcios, caracterizada como sendo, um processo de organizao e gesto cujo objectivo assegurar que o potencial do investimento em TI efectivamente alcanado [WARD 2007]. O quadro abaixo identifica desde logo a diferena de abordagem que necessrio incutir, 42

quando se pretende evoluir de um mtodo tradicional, para um novo mtodo de gesto de benefcios. Por vezes pequenos gestos como uma denominao mais consensual para o nome de um projecto ou iniciativa, um levantamento de necessidades ou opinies transversais empresa, faz com que haja um maior nvel de participao e interesse nos projectos prximos.
De Para

Foco na Tecnologia Focados nas despesas - Perca de ligao com

as necessidades de negcio

Foco no Beneficio Focados em Business Case Integrao

com as linhas orientadoras do negcio

Gestor de negcios como espectador Stakeholders sujeitos a Plano de implementao para TI

Gestor de negcio envolvido Stakeholders envolvidos em Plano para a Gesto da Mudana

Tabela 2-IX - Gesto de Benefcios versus modelo "tradicional" [WARD 2007]

2.3.3.1.

Uma viso geral ao processo de Gesto de Benefcios

O processo de gesto de benefcios constitudo por um conjunto de ferramentas e tcnicas de diferentes reas, desde a gesto de projectos gesto da qualidade.

Figura 2-XVII - Processo de Gesto de Benefcios [WARD 2007]

43

(1) Identificar e Estruturar os Benefcios: Baseado no alinhamento estratgico entre as TI e o negcio, os objectivos do primeiro ponto so: Estabelecer objectivos onde as partes estejam de acordo, no que diz respeito ao investimento garantir que est associado pelo menos a um factor impulsionador de mudana na organizao; Estabelecer todos os potenciais ganhos, que se podem obter, atravs da concretizao dos objectivos do investimento; Estabelecer responsveis dos benefcios e garantir que os mesmos podem ser medidos, de forma a averiguar a realizao dos mesmos; Identificar alguma questo organizacional ou de algum grupo integrante no processo que de alguma forma possa colocar em causa o sucesso do projecto; (2) Plano de realizao dos Benefcios: O principal propsito deste ponto a elaborao de um plano de benefcios e um business case para o investimento: Uma descrio completa de cada benefcio; Formas de medir para cada benefcios e sempre que possvel a realizao de uma expectativa materializada em valores; Definio da rede de dependncias;

(3) Execuo do plano de Benefcios: O objectivo deste ponto garantir que as aces programadas efectivamente acontecem conforme planeadas. Poder ser necessrio estabelecer metas intercalares vulgarmente denominados de milestones (pontos chaves), tornando assim mais fcil o controle e acompanhamento do progresso no seu todo. Com este tipo de abordagem evitam-se as surpresas de fim de projecto, no que diz respeito a derrapagens em termos financeiros ou temporais. Algo frequente nos projectos de TI, em que o resultado final nem sempre corresponde s expectativas do negcio. (4) Reviso e evoluo dos resultados: Um dos factores diferenciadores entre as empresas que apresentam maiores nveis de sucesso na gesto das TI, precisamente a forma como so geridos os investimentos aps a concluso dos projectos. Um estudo 44

[WARD et al. 1996] que visou avaliar a forma como as empresas geriam os benefcios de SI/TI, demonstrou que apenas 26% das empresas, analisam os seus projectos aps o trmino dos mesmos a fim de verificarem, at que ponto que o resultado corresponde ao esperado, pontos a ter em conta: Determinar e confirmar se os benefcios planeados foram de facto alcanados Identificar quais os benefcios que no foram alcanados, decidir quais as medidas de contingncia; Perceber as razes, que levam a que determinados benefcios tendem a falhar e retirar as respectivas lies para o futuro; Perceber como que se poder melhorar a gesto de benefcios, de uma forma transversal a toda a empresa; (5) Benefcios Adicionais: Este ponto na sequncia do anterior, consiste num olhar crtico realizado aps cada projecto, investimento ou mudana no negcio e verificar at que ponto no se est na presena de uma oportunidade ou de um benefcio que entretanto foi desencadeado. semelhana do ponto (1), ser necessrio analisar em conjunto com o negcio e decidir se o processo no se reinicia agora na procura de outro benefcio. 2.3.4.

Investimentos nas componentes Infra-estruturais de TI

Como tem sido nesta seco, os investimentos realizados em TI, geram sua volta

expectativas no que diz respeito ao retorno em forma de benefcios. Estes podem e devem ser quantificados atravs da realizao de um business case que dever ser o mais fiel possvel para que a tomada de deciso no que diz respeito ao financiamento desses investimentos, seja a mais acertada possvel. No caso de aplicaes ou projectos, que visam atingir um conjunto de objectivos bem, definidos, torna-se mais fcil, quantificar os ganhos e com eles elaborar um ou mais modelos que sero a base do business case. Quando estamos perante investimentos em infra-estruturas TI, raramente os podem estar associados a um nico objectivo especfico o que torna muito mais difcil quantificar o retorno. Alm disso, os benefcios de muitos investimentos em infra-estruturas so intangveis, comum serem descritos como 45

melhorias de segurana, proporcionar uma maior agilidade ou aumentar a eficincia. Estas so descries que parecem ser difceis, se no impossveis de quantificar. A lgica usada quase intuitiva, se fizermos esses investimentos, as coisas sero melhores, face a este cenrio, torna-se difcil que exista uma aposta em projectos de infra-estrutura, caso sejam analisados atravs dos tradicionais instrumentos financeiros, esto desde logo condenados a no serem mais que uma proposta, em seguida so descritas duas abordagens cujo objectivo demonstrar que os investimentos realizados em componentes de infraestrutura, podem tambm representar benefcios tangveis e assim serem alvos de uma apreciao mais justa [SYMONS 2008].

2.3.4.1.

Investimentos Infra-estruturais, no modelo Gesto de Benefcios

A primeira abordagem est enquadrada no modelo apresentado no ponto (2.3.3 Gesto de Benefcios nova abordagem)

Figura 2-XVIII - Justificao de Investimentos em Infra-Estrutura [WARD 2007]

A analise dos investimentos em infra-estruturas, exige um tratamento diferente em relao aos restantes projectos, dando origem a esta aproximao, das quais se desta os pontos analisados em seguida:

46

Reduo dos Custos: Com a introduo de novas tecnologias, ser objectivo das equipas de TI, aproveitar sempre que possvel proceder a evolues ou transferncias de forma a conseguirem uma reduo de custos, que poder desde logo ser visto como um benefcio quantificvel

Crescimento no volume de negcios: Nem sempre o crescimento do volume de negcios, tem uma correspondncia directa com o investimento necessrio nas componentes de infra-estrutura, o objectivo a atingir que se consiga crescer custa de uma gesto optimizada dos recursos, passando sempre que possvel por cenrios de consolidao, estes factores so claramente benefcios que podem ser associados infra-estrutura.

Instalao de Novas Aplicaes: Fazer corresponder, os ganhos obtidos com as aplicaes, s componentes infra-estruturais que possibilitam a existncia da aplicao em si

Criao de Novas forma de Trabalhar: Possibilidade de associar infra-estrutura benefcios pelo facto, dos colaboradores terem sua disposio ferramentas que fazem aumentar os seus ndices de produtividades. Nestes casos so exemplos questes relacionadas com a mobilidade ou a disponibilizao de ferramentas de colaborao.

Criao de Novas Oportunidades: Adopo de novas tecnologias, que servem de base criao de novos processos de negcio.

2.3.4.2.

Investimentos Infra-estruturais, no modelo WEILL e BROADBENT

No caso do modelo [WEILL 2008], defende que os investimentos em TI devem ser enquadrados num portflio de investimentos, cujo objectivo que todos os investimentos estejam l representados. O referido portflio por sua vez dividido por quatro tipo de investimentos, cada um deles com as suas caractersticas e objectivos tpicos como ilustrado na Figura 2-XIX.

47

Figura 2-XIX - Portflio de Investimentos em TI [WEILL 1998]

Torna-se necessrio detalhar as caractersticas de cada tipo de investimento, de forma a facilitar a compreenso do modelo: Informacional: Gerir e controlar uma empresa exige o acesso informao de uma forma consolidada e sistematizada. sem dvida uma ajuda vital para a correcta tomada de decises. As aplicaes capazes de o fazer so hoje denominadas como business intelligence, este tipo de ferramentas necessitam obviamente de ser alimentadas pela componentes infra-estruturas e transaccional. O grande objectivo passa por conseguir produzir uma informao melhor num espao de tempo cada vez menor. Estratgico: A evoluo estratgica quase um jogo que as empresas de determinado segmento praticam. O objectivo apresentar produtos revolucionrios no mercado, que sabido partida que sero alvo de cpia pela concorrncia, cabe empresa que teve o mrito de ser a primeira retirar desse facto o mximo proveito Transaccional: Um dos principais focos das TI foi permitir automatismos que conseguissem produzir mais rpido a um preo cada vez menor. Esse objectivo continua presente, este patamar procura constantemente a optimizao das transaces para que o negcio consiga apresentar nveis de servio cada vez melhores Infra-Estrutura: Como referido anteriormente os investimentos em infra-estrutura pela sua natureza so os mas difceis de avaliar porque so:

48

o Intangveis: Expressos muitas vezes no seu aspecto qualitativo, o objectivo criar forma de quantificar os aspectos que partida so inquantificveis: Ligao de benefcios intangveis a resultados tangveis, tentando quantificar essa mesma ligao, exemplo deste aspecto poder ser a decomposio de uma determinada aplicao cujos objectivos so quantificveis, nas componentes que a compem, desde servios, a bases de dados, passando por mtodos de autenticao, monitorizao, backup, atribuindo valores proporcionais a cada um destes elementos. Os benefcios podem ser quantificveis quanto ao seu impacto na empresa, exemplo deste aspecto poder ser a segurana, se no forem tomadas as medidas mais correctas e a empresa ficar exposta a um ataque, quais as repercusses, quanto que a empresa deixa de facturar se o seu SI no estiver operacional durante um perodo de tempo. Perspectiva Futura: Determinados componentes, tm partida um investimento inicial elevado, em que o mesmo s justificado quando a sua utilizao atinge os 50%, exemplo disso so: o Investimentos em Discos, em que as equipas responsveis, tm que ter sempre uma margem de potencial crescimento de utilizao o Investimentos em equipamentos de comunicaes, que se adquire desde logo com uma margem de crescimento

49

CAPTULO III
3. Modelo Proposto
O objectivo deste terceiro captulo propor um modelo (Framework) denominado de GO2SaaS, que consiga responder s incertezas de um conceito ainda emergente e por outro lado seja capaz de melhorar a relao investimento e benefcio. Consolidando as componentes tcnicas do conceito SaaS, alertando para aspectos que se prendem desde a seleco relao com o parceiro fornecedor de servio. Com as componentes financeiras, que vo desde o correcto enquadramento com o negcio, passando pela realizao de um novo business case terminando com a natural anlise de resultados.

Figura 3-I - Modelo Proposto

50

Em seguida so descriminadas as fases que constituem o modelo GO2SaaS, apresentado na Figura 3-I.

3.1.

(1) Identificar Necessidades ou Oportunidades

Como tem sido notrio, existe uma preocupao constante com o investimento que

necessrio realizar para que se possa levar a cabo um determinado projecto, o termo investimento pressupe desde logo um retorno positivo face ao capital investido. objectivo da primeira fase, efectuar o enquadramento do projecto face ao negcio e respectivo investimento, tem como base a resposta s questes: Porqu?: Porque razo se est a levar a cabo este investimento; O qu?: Quais os benefcios que a organizao espera obter; Como?: Como que a combinao das alteraes de negcio e alteraes das TI podem atingir esses benefcios; A conjugao do resultado obtido em cada pergunta vai contribuir para a construo de uma rede de benefcios, elementos preponderante ao longo de toda a vida do projecto. Porqu?: Identificao dos elementos propulsores do Negcio ou Organizao Com a resposta ao porqu do projecto, pretende-se definir quais os business drivers, este termos amplamente usado neste tipo de literatura, poder ser traduzido como estratgias propulsoras para o negcio. Os business drivers podem ter como base vrias fontes, a Tabela

3-I agrupa-as quanto sua natureza.

Relacionada com evolues no campo das TI, como exemplo um projecto que Infra-estrutura leve a cabo uma infra-estrutura que permita maior mobilidade aos colaboradores Projectos que visam proporcionarem que a empresa trabalhe segundo uma Contexto directiva imanada de um rgo supervisor, como exemplo o Banco de Portugal para as empresas ou organizaes do sector financeiro Projectos que visam atingir determinado fim, como reduo de custos, Orientadas ao Resultado integrao de um conjunto de funcionalidades para que seja possvel disponibilizar um novo servio Tabela 3-I - Tipos de Estratgias Propulsoras [WARD 2007]

51

Para completar a resposta ao porqu, necessrio que haja uma definio clara e consensual acordada por todos os intervenientes no processo, de quais os objectivos a atingir [WARD 2007].
Os objectivos atrs referidos, devero obedecer aos requisitos apresentados na Tabela

3-II, conhecidos por objectivos SMART devido conjugao das iniciais das cinco caractersticas que os mesmos devem ter, quando escritas em ingls.
Definio clara a precisa das metas a atingir, para que possa ser entendido por todas as partes envolvidas no projecto Possvel de ser medido, de forma a aferir se no fim do projecto o objectivo foi alcanado Estabelecimento de metas realistas que possam de facto ser atingidas no contexto em que o projecto se desenvolve Abordar questes que so importantes Definio de um tempo limite, no qual o projecto se desenvolve Tabela 3-II Objectivos SMART [OCG 2004]

(S) Especfico

(M) Mensurvel

(A) Atingvel (R) Relevantes (T) Tempo Delimitado

O qu?: Benefcios do ponto de vista do negcio (vantagens empresariais) Aps delimitar os objectivos, devidamente suportados por um investimento, torna-se

possvel conjugar como os benefcios em termos de negcio a serem atingidos. Entende-se por benefcio de negcio, uma vantagem que a empresa no seu todo, ou um grupo especfico, poder retirar aps a concluso do projecto [WARD 2007]. Como referido no ponto (2.3.1 Investimentos em SI/TI), os projectos e consequentes investimentos no se podem esgotar no ponto de vista das TI, eles tm que representar uma mais-valia no ponto de vista da afirmao da organizao
Como?: Criao da Rede de Benefcios Depois de definidos os business drivers assim como os benefcios do ponto de vista do negcio, necessrio proceder identificao dos factores facilitadores da mudana, bem como as mudanas esperadas ao negcio.

52

Figura 3-II Rede de Benefcios adaptada [WARD 2007]

A rede de benefcios tem o condo de conseguir agregar e relacionar, no apenas os actores do projecto, mas tambm os objectivos a serem alcanados e os benefcios esperados, no perdendo de vista os bussiness drivers que tiveram na sua origem. Ser um documento para seguir durante a vida do projecto, assumindo vital importncia na ltima fase, onde ser confrontado com os resultados realmente obtidos.

3.2.

(2) Anlise da Arquitectura (SI/TI)

Quando uma empresa ou organizao, coloca como hiptese, a utilizao de

aplicaes atravs do conceito SaaS. Algo no seu sistema de informao, tem que mudar e existem passos que tm que ser dados para que se possa atingir uma integrao entre os sistemas residentes e os sistemas da nuvem. No existe uma receita a ser seguida, cada caso tem especificidades prprias, contudo como ilustrado na Figura 3-III h um conjunto de preocupaes comuns que no podem, nem devem ser esquecidas.

53

Figura 3-III - Arquitectura de Integrao [CARRARO 2006]

A Figura 3-III foca o ponto onde sistema de informao residente interage com o sistema de informao do fornecedor de servios. O detalhe (zoom) da componente integrao, na qual ressalta trs aspectos:

Gesto de Identidade e Acessos: Implementao de mecanismos de autenticao e autorizao, que permitam regular quem acede aos dados e de que forma que o faz. Sempre com um objectivo em mente, o facto de existir necessidade de aceder a um dado que est geograficamente externo empresa, dever ser transparente para os processos de negcio. Gesto de Dados: Por gesto de dados entende-se tudo o que est relacionado com o acesso aos mesmos, estes podem estar sobre a forma de bases de dados relacionais ou sobre a forma de ficheiros (flat files). No acesso aos dados dever ser privilegiada a utilizao de WEBServices, desta forma torna-se transparente para as aplicaes qual o repositrio de dados a ser utilizado. Outros pontos relacionados com os dados e que tm que ser tidos em conta so: Estratgias de Migrao: A forma como so migrados os dados das aplicaes que sero alvo de mudana, todas as aplicaes tm um histrico a passagem dos dados 54

 um ponto importante e nunca dever ser esquecido. Poder haver a tentao de migrar apenas os dados actuais, deixando os dados histricos na antiga infraestrutura, seria um erro, pois o facto de se manter as plataformas antigas representa custos. Estratgias de Backup/Reposio (restore): A forma como realizado o backup (salvaguarda dos dados), no que diz respeito periodicidade e reteno, no esquecendo o tempo necessrio para efectuar uma reposio. Regulao: Assegurar todos os requisitos legais so cumpridos, medio de nveis de servios (SLA), providenciar auditorias de preferncia efectuadas por empresas da especialidade a fim de assegurar a consistncia do sistema no seu todo. Meta-Data: Dita as regras de transformao e adaptao, necessrias para que dois sistemas diferentes possam comunicar.

3.3.

(3) Escolha da Opo mais Vantajosa

objectivo desta fase introduzir uma nova forma de analisar a componente

financeira de um projecto, neste caso validar uma possvel opo pelo SaaS. A questo profunda e este trabalho no tem a pretenso de a resolver na sua totalidade. Mas a soluo poder passar por contabilizar correctamente os gastos e os ganhos, algo que no possvel com tradicionais business cases, baseados em frmulas tipo ROI (Return On Investment). Ao invs propem-se seguir um mtodo onde se coloca numa matriz adaptada matriz de [WARD 2007], representada na Tabela 3-III. Todas as variveis so importantes numa deciso de cariz financeiro, no apenas as componentes que so quantificveis, mas tambm no menos importante, so as mensurveis e observveis, cada uma delas analisada da perspectiva de: Fazer coisas NOVAS, SaaS versus Modelo Tradicional, deixar de fazer coisas ANTIGAS.

55

Grau de Explicitao

Fazer coisas NOVAS

SaaS versus Modelo Tradicional

Deixar de fazer coisas ANTIGAS

Financeira

Atravs da aplicao de uma relao custo / preo ou uma outra frmula financeira, torna-se possvel quantificar um benefcio Existncia de elementos de prova suficientes para que se torne possvel efectuar uma previso, de quanto ser o benefcio resultante das mudanas Prev-se aplicar uma forma de medir o desempenho. Mas no possvel estimar de quanto que sero as melhorias, no fim da implementao das mudanas Por ter uma dose de subjectividade grande o mais difcil, utiliza-se critrios

Quantificveis

Mensurveis

Observveis

acordados, por indivduos ou grupos especficos, que com base na sua experincia, vo decidir at que ponto o objectivo foi realizado Tabela 3-III - Novo Business Case, Adaptado [WARD 2007]

3.4.

(4) Pilotar a Soluo

Esta fase tem como objectivo levar a cabo uma prova de conceito, para que a

soluo a implementar possa ser posta em prtica. No de todo aconselhvel que se evolua para um conceito ainda em fase emergente, sem que antes a soluo passe por uma fase de teste. A exemplo do que se pratica nos projectos de desenvolvimento de novas aplicaes, tambm nestes caso a implementao de um prottipo, permite que a empresa ou organizao ganhe confiana e assim possa evoluir para uma adopo em pleno da soluo. O conceito SaaS tem subjacente por definio uma relao com uma outra entidade,
por mais conceituado que seja o fornecedor escolhido, existem precaues que tm de ser tomadas desde logo na prova de conceito, a Figura 3-IV, pretende evidenciar as etapas a percorrer.

56

Figura 3-IV - Fases da Prova de Conceito

Identificao da Aplicao: O primeiro passo a identificao da aplicao eleita e neste caso colocam-se duas hipteses: Aplicao Nova: No caso de aplicao ser nova, tem que existir o cuidado, de no criar dependncias do ponto de vista de processos de negcio, at que no tenha confiana quer na aplicao, quer no prprio conceito. Aplicao j existente: Neste caso temos uma aplicao a funcionar nas instalaes da empresa segundo a forma tradicional (on-premises), que se pretende evoluir para o conceito SaaS, a escolha dever recair por uma aplicao perifrica, utilizada por um nmero reduzido de colaboradores. Como estamos perante a primeira experiencia, tem que se ter em conta que o risco poder ser elevado, tem que ser garantido que o impacto para o negcio baixo. De preferncia deve-se optar por efectuar um paralelo caso haja condies, desta forma alm de se garantir que no existe qualquer impacto para o negcio, tem tambm a vantagem de se conseguir comparar indicadores. Implementao do Prottipo: Aps a escolha da aplicao, dever ser efectuado a implementao do prottipo que consiste na utilizao da aplicao eleita, segundo o conceito SaaS. Avaliao do Prottipo: A avaliao do prottipo dever ser efectuada segundo os seguintes pontos:

57

Integrao: Identificar e testar nveis de integrao com as aplicaes residentes, dever ser medido o nvel e facilidade de integrao com o actual sistema de informao.

Nveis de Servio: Uma das componentes mais importantes, quando existe uma relao entre entidades, so os nveis de servio acordados entre ambos, materializados em SLA(s). Como tal devem ser introduzidos mecanismos que permitam entidade cliente conseguir aferir at que ponto que esto ou no a ser cumpridos os nveis acordados, a melhor fase para o fazer desde logo na prova de conceito. Assim devem-se recolher indicadores de uma forma constante para medir qual o comportamento da aplicao, de preferncia em situaes de actividade elevada.

Auditoria: Como referido na fase onde foi aflorada as questes de auditoria, pressuposto que a aplicao e respectivos dados estejam ao abrigo de mecanismos de autenticao e autorizao acordados. Pretende-se neste verificar at que ponto que os ditos mecanismos so eficazes, assim aconselhvel a contratao que uma empresa da especialidade que ir tentar descobrir as vulnerabilidades do sistema no seu todo.

Gesto de Incidentes: Entende-se por gesto de incidentes, colocar prova a forma expedita ou no como a empresa prestadora de servios gere os incidentes relacionados com a aplicao. Os problemas e incidentes iro sempre existir importante conhecer como que o prestador de servios est organizado para os resolver.

Tarefas de Gesto: Por tarefas de gesto, entende-se um conjunto de tarefas mais especializadas, como seja o repor de uma base de dados ou a criao de um ndice importante perceber qual a capacidade do prestador de servio para responder a este tido de tarefas. Prev-se que entre as actividades Implementao do Prottipo e a Avaliao do

Prottipo, ocorram ajustes, portanto as tarefas atrs mencionadas entraram num ciclo, que apenas ser finalizado quando todos os indicadores tiverem parecer positivo, segue-se a ultima actividade da prova de conceito. Produo do Relatrio da Prova de Conceito: Dever ser produzido um relatrio, que dever ter o acordo de ambas as partes, no mesmo dever constar todos os dados relevantes ocorridos, sejam eles de carcter positivo ou negativo.

58

3.5.

(5) Implementao
Aps os resultados obtidos na fase de piloto, a prxima etapa ser a implementao,

para tal torna-se importante ter uma viso das aplicaes, tendo em conta a potencialidade que tm para evoluir para o conceito SaaS. Assim sugere-se que as aplicaes sejam perfiladas num quadro idntico ao representado na Figura 3-V. O objectivo criar uma estratgia (roadmap) a curto mdio prazo para as aplicaes que suportam os processos de negcio.

Figura 3-V - Distribuio das Aplicaes

As aplicaes consideradas CORE, so a base do negcio, aquelas atravs das quais a empresa ou organizao pretende marcar a sua diferena no seu campo de actuao. Vivemos num mundo em constante mudana, como tal preconiza-se que as aplicaes consideradas intocveis passem tambm elas por um processo de anlise de uma forma peridica. As aplicaes em Anlise so aquelas que potencialmente podem evoluir a candidatas para o conceito SaaS. Por sua vez as aplicaes Candidatas sero todas as aplicaes j identificadas para evolurem apenas aguardam oportunidade. Por fim as aplicaes SaaS so todas aquelas aplicaes que j se encontram segundo esse conceito. O rtulo atribudo a cada aplicao no dever ser considerado inaltervel, como exemplificado na Figura 3-V, existem factores que podem desencadear a passagem entre quadrantes. 59

Aps definido o plano de evolues, a mesma linha de preocupao at agora preconizada, dever ser mantida. As aplicaes devem evoluir de forma faseada e segura permitindo empresa cliente do SaaS, reforar os seus mecanismos de controlo, tal como j identificado em fase de piloto, o conjunto de tarefas descrita na Figura 3-VI, tm que ser realizadas de uma forma contnua apenas desta forma se garante um controle efectivo perante o servio prestado. Obviamente que os nveis de regulao podero oscilar mediante o nvel de confiana oferecido pelo parceiro, com a certeza porm que nunca podero desaparecer.

Figura 3-VI - Mecanismos de Controlo

3.6.

(6) Analise dos Resultados e Benefcios

O objectivo da ltima fase do modelo, efectuar uma anlise dos resultados obtidos,

embora em todas as fases devem ser implementados mecanismos de controlo de forma a evitar derrapagens. Numa implementao tipo SaaS, apenas possvel efectuar um balano aps a soluo implementada ter atingido um grau de confiana elevado. Nunca perdendo de vista que um dos pontos positivos deste modelo a possibilidade de descontinuar solues antigas.

60

Figura 3-VII - Todas as fases confluem para a Analise de Resultados

Como ilustrado na Figura 3-VII, esta ultima fase recolhe os outputs das restantes e analisa os resultados de forma a retirar concluses, sempre na ptica da identificao dos pontos considerados negativos, pontos positivos, quais as aces de melhoria e identificao dos prximos passos.

61

CAPTULO IV
4. Estudo de Caso
O objectivo deste quarto captulo efectuar a anlise de um projecto conduzido luz do modelo GO2SaaS proposto no Capitulo III. O cenrio de estudo desenrola-se numa instituio bancria privada, integrada no sistema financeiro Portugus, doravante denominada por

Banco, em seguida so apresentados alguns elementos, de forma a contextualizar a entidade em causa: Em termos de ranking financeiro, est entre os primeiros 5 maiores Bancos Portugueses, com presena assdua no PSI 20; Detm cerca de 900 Balces espalhados por todo o pas; Existe uma aposta em canais alternativos, como o caso da presena na Internet, onde permitido aos clientes efectuarem a quase totalidade dos servios bancrios. Embora com alguma perca de protagonismo nos ltimos anos a Banca Telefnica, continua a ser um canal alternativo a ter em conta; Tem vrias presenas no estrangeiro, onde se destaca; Espanha, Angola, E.U.A e Macau; Composta por aproximadamente 6000 Empregados, distribudos pelos vrios servios do Banco; Est vocacionada para o pblico em geral, oferecendo um vasto leque de produtos financeiros, quer do ponto de vista de investimento, como do ponto de vista do crdito;

4.1.

(1 Fase) Contextualizao
O pressuposto desta primeira fase efectuar o enquadramento do projecto, do ponto

de vista de negcio, bem como do ponto de vista tcnico. 4.1.1.

Porqu?: Porque razo se est a levar a cabo este investimento

As instituies financeiras, so catalogadas de Atacantes ou Incumbentes

conforme Figura 4-I, consoante as receitas de corretagem geradas pelos clientes investem 62

no mercado bolsista. As mais tradicionais viram-se ultrapassadas pelos bancos mais jovens que apostaram forte na conquista deste segmento de clientes. Fizeram-no atravs de plataformas de apoio ao investimento muito eficazes e de fcil utilizao, principalmente pelo facto de serem acedidas via Internet. O Banco alvo de estudo, tambm foi categorizado como Incumbente, o que significa estar a perder oportunidades de negcio, correndo o risco de perca de clientes e consequente diminuio de receitas.

Figura 4-I Quota de Mercado dos Atacantes e Incumbentes

A resposta dada atravs da criao de uma Plataforma de Negociao de Aces (PNA) munida de um conjunto de funcionalidades mpares, que seja capaz de inverter a situao. A estratgia propulsora (business drivers) claramente a orientada a atingir determinados resultados, atravs da implementao de uma nova componente de TI. O prximo passo a caracterizao dos objectivos do projecto segundo o mtodo SMART (definido na Tabela 3-II).
Desenvolvimento de uma Plataforma de Negociao de Aces (PNA), que permita melhores nveis de: Funcionalidade, Usabilidade e Visualizao Aumento de 25% em cada um dos trs prximos anos, nas receitas geradas com a negociao de aces Pretende-se que a PNA, seja classificada como plataforma de referncia a nvel nacional O facto de assentar sobre o conceito SaaS, representa uma nova realidade que trs consigo cuidados especiais ao nvel da segurana Prazo de Implementao da nova PNA: nunca superior a 1 Ano. Em termos de negcio 3 anos, consecutivos para crescer no segmento Tabela 4-I - Tabela de Objectivos SMART

(S) Especfico

(M) Mensurvel

(A) Atingvel

(R) Relevantes

(T) Tempo Delimitado

63

4.1.2.

O qu?: Quais os benefcios que a organizao espera obter

Com a nova plataforma, existe no apenas a inteno de colocar o Banco, entre os

lderes do segmento, como tambm aumentar os proveitos resultantes da corretagem, conforme

Figura 4-II. O objectivo no passa por aumentar as taxas de corretagem, passa sim por
aumentar os ndices de transaces.

Figura 4-II - Receitas Esperadas com a introduo da PNA

4.1.3.

Como? : Rede de benefcios

Depois de definidos os business drivers assim como os benefcios do ponto de vista do

negcio, necessrio proceder identificao dos factores facilitadores da mudana, bem como as mudanas esperadas ao negcio.

64

Figura 4-III - Rede de Benefcios do Projecto

A rede de benefcios, tem o condo de conseguir agregar e relacionar todos os elementos envolvidos, com a particularidade de o fazer atravs de um quadro facilmente perceptvel por todos os elementos envolvidos no projecto. Desde as componentes mais tcnicas at ao ponto de vista mais virado para o negcio e as vantagens financeiras.

4.2.

(2 Fase) Anlise e Definio de Arquitectura

O objectivo da segunda fase do modelo, definir a arquitectura a ser seguida, no

pressuposto que a linha se orientao o SaaS. A Figura 4-IV que resulta de um levantamento efectuado ao SI do Banco pretende ser uma representao genrica, no era objectivo identificar todos os componentes do SI mas apenas transmitir uma viso conceptual. Da anlise efectuada, permite concluir a existncia de uma componente central, denominada por mainframe e a componente de sistemas distribudos, constitudos por servidores de mdio porte. Os servidores esto agrupados de forma a fornecerem um servio autnomo e so orquestrados pela presena de um EAI (Enterprise Application Integration), que permite a interaco entre os diferentes servios. O facto de o Banco j ter uma arquitectura orientada a servios (SOA) partida um bom indicador.

65

Figura 4-IV - Arquitectura genrica do SI

A Figura 4-V, pretende ilustrar o fluxo de informao existente entre o utilizador o Banco e o Fornecedor de servios referido como: F-SaaS

Figura 4-V - Fluxo de Informao entre o Banco e o Fornecedor de SaaS (F-SaaS)

A Tabela 4-II, explica em detalhe cada um dos fluxos enumerados na Figura 4-V 66

Nmero de Aco

Explicao Login do Cliente na plataforma Banco-ONLINE, Esta plataforma tem a capacidade de se

(1)

adaptar aos perfis dos Clientes, aps o Login bem sucedido, o contedo das pginas constitudo segundo o perfil do cliente que acabou de entrar Em seguida so apresentados as Opo de navegao das Pginas No exemplo que est a ser detalhado o Cliente, seleccionou uma opo, cuja resposta est

(2)

(3)

inserido num servio prestado pelo Fornecedor de SaaS (F-SaaS). Quando esta aco acontece o F-SaaS contacto atravs de um pedido (request) O F-SaaS confrontado com o pedido, tem necessidade de efectuar validaes a dois nveis.

(4)

Tem necessidade de saber se estamos na presena de uma sesso vlida, bem como saber qual o perfil de utilizador So devolvidos dados relativos sesso estabelecida, entre eles a chave de sesso, que

(5)

gerada atravs de um algoritmo previamente estabelecido entre as duas entidades. Bem como o perfil do utilizador. No so fornecidas quaisquer informaes relativas identificao do utilizador, bem como informaes de carcter financeiro

(6) (7)

A pgina composta com os dados financeiros, segundo a opo escolhida pelo cliente A pgina disponibilizada ao Cliente, enquadrada na sesso, para ele as aces efectuadas entre a realizao do pedido e a resposta so completamente transparentes Todo o processo registo em LOGS, de forma a aferir-se tempo de resposta, registo de aces A sesso terminada Tabela 4-II - Fluxo de Informao em Detalhe

(8) (9)

A Figura 4-VI identifica a arquitectura de integrao implementada, onde descriminado em detalhe a forma como os dois sistemas interagem entre si, segundo as perspectivas: Gesto de Identidades e Acessos: Como referido anteriormente no existem dados dos clientes a serem trocados, de qualquer forma foi exigido um nvel de segurana confortvel. Foi criado um processo onde para que a comunicao possa ser estabelecida tm que ser verificados os seguintes parmetros: o Sesso Vlida: Cada sesso tem um cdigo associado que permite aferir se uma sesso vlida ou uma sesso simulada, permite assim que garantir que apenas so desencadeados pedidos da plataforma BANCO-Net.

67

o Endereo Seguro: Existe uma tabela com os endereos dos servidores autorizados a estabelecer comunicao, garante-se desta forma que no existe intromisso. o Limite de Sesso: Todas as sesses tm um limite de tempo, que verificado no sentido de no perdurarem no tempo sesses, quando o utilizador termina a sesso de forma abrupta. Gesto de Dados: Aps garantir que a sesso valida, estabelecido um canal seguro entre as duas entidades, existe a preocupao adicional de adicionar a cada pacote de dados uma chave (hash), que permite validar a que os dados no foram alterados na sua fase de transporte. Meta Data: Conjuntos de definies que permitem s entidades envolvidas efectuarem as validaes. Regulao: Conjunto de registo, que ir permitir aferir nveis de desempenho, segurana e auditoria.

Figura 4-VI - Arquitectura de Integrao Implementada

Todas as solues de arquitectura tm de ter a aprovao por parte de dois grupos no Banco caracterizados da seguinte forma: 68

ARB Architecture Review Board: Grupo constitudo por especialistas de vrias reas de actividades: Arquitectura, Sistemas, Comunicaes, Segurana, Base de Dados e Armazenamento de dados, cuja principal preocupao a validao do ponto de vista tcnico.

GTA Grupo de Trabalho de Arquitectura: Grupo constitudos por especialistas das reas de projectos, onde a preocupao centra-se nas relaes das aplicaes entre si e a contextualizao com o negcio.
A arquitectura apresentada foi aprovada, na condio de incluso de uma chave (hash)

de controlo com encriptao por chave privada para garantir autenticidade da origem, na primeira verso apresentada esse ponto no era considerado. Outra recomendao foi a realizao de auditorias, em fase de piloto e posteriormente em ambiente de Produo.

4.3.

(3 Fase) Opo mais Vantajosa

O objectivo da terceira fase do modelo garantir que se escolhe a melhor opo, no

que diz respeito principalmente ao campo financeiro. Com base nas elaes retiradas das fases anteriores do modelo. Existem condies para se efectuar uma consulta ao mercado na procura de potenciais parceiros. No estudo efectuado apenas foi identificado um fornecedor com capacidade de resposta ao cenrio proposto. Apesar de haver apenas um concorrente o mesmo teve que se apresentar com as credencias necessrias, de forma a transmitir confiana na parceria, destacam-se os seguintes aspectos: No existe nenhum outro fornecedor com este tipo de contedo adicional diferenciador, e em portugus; Presena em Espanha e Portugal (www.negocios.pt); Responsvel pela implementao e gesto do portal de referncia em Espanha (www.bolsamania.com); Excelente carteira de referncias, bancos como: Santander, Bankinter, Openbank, Sabadell, BBVA, La Caixa, Uno-e, Caja Madrid entre outros; Fornecedor preferencial na recomendao da Reuters; A matriz representada atravs da Tabela 4-III, pretende consolidar os pontos importantes no que diz respeito tomada de deciso, como referido no captulo anterior, 69

esta matriz pretende inovar no que diz respeito forma como se analisa um investimento referente a um projecto de TI. Os valores indicados na tabela so o resumo dos clculos efectuados nos Anexos A e B.

Grau de Explicitao

Fazer coisas NOVAS (1) Indicadores Financeiros demonstrao que a aposta no projecto positiva: VAL Total: 2.817.845 EACF Total: 679.558,97

Modelo SaaS versus Modelo Tradicional (2) Diferena de Resultados entre os Modelos: Atravs da anlise dos indicadores financeiros, indica que a opo SaaS mais vantajosa do ponto de vista econmico: VAL (SaaS): 2.817.845 EACF (SaaS): 679.559 VAL (M.T) : 960.358 EACF (M.T): 231.603

Deixar de fazer coisas ANTIGAS (3) Poupanas no descontinuar da antiga Infra-Estrutura: Com descontinuar da actual soluo reduz-se o custo de infra-estrutura em aproximadamente de 108.000, que nos seis anos que esto a ser considerados representas uma diminuio de 657.203

Financeira

Quantificveis

Mensurveis

Observveis

(4) Optimizao dos Tempos de Transaces: Tempo associado a cada transaco mais baixo, devido ao maior nvel de integrao (6) Aumento do nmero transaces efectuadas (7) Uma plataforma mais atractiva: aspecto visual mais atractivo e com um nmero de funcionalidades superior

(5) Reduo no perodo de implementao: Devido ao facto de se ter optado pelo SaaS, foi conseguida uma antecipao de 12 meses

Tabela 4-III - Matriz Financeira

4.3.1.

(1) Indicadores Financeiros

A Tabela 4-IV, permite-nos calcular os indicadores financeiros, que vo determinar

a viabilidade do projecto, os indicadores levados em conta foram: VAL Valor Actual Liquido, ndice bastante utilizado devido ao facto de levar em conta os anos de vida do projecto, tanto do ponto de vista de investimento, como do ponto de vista de custos;

70

EACF O EACF (Equivalent Annual Cash Flow) trata-se de um indicador de avaliao de projectos que permite comparar projectos com diferentes vidas teis, uma vez que apura o VAL e actualiza-o a uma taxa de desconto calculada com base no nmero de anos do projecto;

ROI - Return Of Investment, este indicador traduz a relao dos proveitos gerados pelo projecto, face aos investimentos realizados; PAYBACK Tempo necessrio para que o projecto gere receitas capazes de colmatar o investimento realizado, ou seja o tempo necessrio para atingir o ponto de breakeven;
Os indicadores financeiros ROI e PAYBACK, no permitem ter uma viso do factor

tempo do projecto ao contrrio dos outros indicadores referidos. Para o seu clculo foi pressuposto que o investimento era realizado todo numa fase inicial, o que no corresponde realidade. Os investimentos em TI so diludos ao longo da vida dos projectos.
Pressupostos Taxa de actualizao VAL N Anos do Projecto

11,7% 6

Ano 1 Custos F-SaaS Proveitos de Negcio VA Impactos Positivos VA Impactos Negativos (F-SaaS) Funo desconto (actualizao do VAL) VAL Anual (F-SaaS) VAL do Projecto EACF EACF (Projecto) ROI PAYBACK (Anos) 3,13 1,45 17.122,55 100.000,00 29.000,00 29.000,00 100.000,00 1,00 71.000,00

Ano 2 230.000,00 316.000,00 282.900,63 205.908,68 0,90 76.991,94

Ano 3 262.000,00 782.000,00 626.758,75 209.988,23 0,80 416.770,53

Ano 4 294.000,00 1.343.000,00 963.643,72 210.954,02 0,72 752.689,69

Ano 5 227.000,00 1.474.000,00 946.857,87 145.818,68 0,64 801.039,18

Ano 6 259.000,00 1.722.000,00 990.301,15 148.947,73 0,58 841.353,41

2.817.844,76 18.567,58 100.509,49 181.520,66 193.180,75 202.903,04

679.558,97

Tabela 4-IV - Indicadores Financeiros Modelo SaaS

71

4.3.2.

(2) Diferena de Resultados entre os Modelos

O facto de se ter optado por um conceito SaaS, no implica que no se avalie o projecto

do ponto de vista tradicional e se apure os respectivos indicadores. A Tabela 4-V pretende

ilustrar a anlise efectuada tendo como hiptese o modelo tradicional.

Ano 1 Custos Modelo Tradicional Proveitos de Negcio VA Impactos Positivos VA Impactos Negativos (M.Tradicional) Funo desconto (actualizao do VAL) VAL Anual (F-SaaS) VAL do Projecto EACF EACF (Projecto) ROI * PAYBACK (Anos) * 1,14 2,80 161.108,39 125.010,51 668.048,62 0,00 0,00 668.048,62 1,00 668.048,62 Ano 2 608.014,74 29.000,00 25.962,40 544.328,32 0,90 518.365,92 Ano 3 110.731,08 316.000,00 253.268,24 88.748,95 0,80 164.519,30 Ano 4 113.337,64 782.000,00 561.109,00 81.323,24 0,72 479.785,76 Ano 5 170.399,77 1.343.000,00 862.707,00 109.460,22 0,64 753.246,78 Ano 6 171.205,86 1.474.000,00 847.679,38 98.458,40 0,58 749.220,98

960.358,28 39.675,91 115.706,42 181.655,01 180.684,13

231.602,57

Tabela 4-V Indicadores Financeiros (Modelo Tradicional)

Atravs da Figura 4-VII, observa-se a diferena do ponto de vista econmico, entre os dois modelos, que de facto comprova ser o SaaS uma opo financeiramente atraente.

Figura 4-VII - Diferena dos VAL(s) entre o SaaS e o Modelo Tradicional

72

4.3.3.

(3) Poupanas no descontinuar da antiga Infra-Estrutura

Nos projectos de TI, raramente se leva em linha de conta as infra-estruturas que so

substitudas, deve-se assegurar que as novas solues descontinuam de facto as anteriores, apenas desta forma se poder abater financeiramente e dever ser uma varivel importante na avaliao dos investimentos. O exemplo dado atravs da Tabela 4-VI, onde se verifica que o valor apurado no de forma alguma desprezvel.

Anos Custos Projecto Custos Infra-Estrutura Ambiente de Produo Ambiente de Qualificao Ambiente de Disaster Recover Custos Energticos

Ano 1 107.199 65.555 26.534 24.654 14.367 41.645

Ano 2 107.278 65.555 26.534 24.654 14.367 41.723

Ano 3 107.357 65.555 26.534 24.654 14.367 41.803

Ano 4 107.439 65.555 26.534 24.654 14.367 41.884

Ano 5 113.922 68.875 28.058 25.844 14.973 45.047

Ano 6 114.007 68.875 28.058 25.844 14.973 45.132

Total 657.203 399.968 162.251 150.303 87.415 257.234

Tabela 4-VI- Valores relativos antiga Infra-Estrutura

4.3.4.

(4) Optimizao dos Tempos de Transaces

Devido ao facto desta nova plataforma ter nveis de integrao superiores, permitir que

os tempos gastos em cada transaco desam em mdia 20%, o que alm de facilitar as operaes no ponto de vista do utilizador final, vai diminuir tambm a carga ao nvel do sistema de informao.

4.3.5.

(5) Reduo no perodo de implementao

O facto de se ter optado por uma soluo SaaS, permitiu diminuir o tempo de

implementao. Permitiu a antecipao da plataforma mais cedo que consequentemente antecipa receitas e diminui os riscos inerentes ao desenvolvimento da plataforma de raiz.

73

Figura 4-VIII - Diferena de Proveitos segundo o Modelo

Como se pode confirmar pela Figura 4-VIII, os proveitos de negcio em termos de proveitos so idnticos, analisando na perspectiva do SaaS existe uma antecipao no que diz respeito s receitas. 4.3.6.

(6) Aumento do nmero transaces efectuadas

A expectativa em relao nova plataforma que consiga atrair um maior nvel de

utilizao, principalmente nos clientes que por norma investem no mercado bolsista. As primeiras reaces ainda num universo restrito deixaram boas indicaes no que diz respeito aceitao. 4.3.7.

(7) Uma plataforma mais atractiva

A nova plataforma alm de um conjunto de novas funcionalidade tem tambm um

aspecto visual atraente, que obviamente ser um elemento que cativa os investidores.

Figura 4-IX - Exemplos de Ecrs da Plataforma

74

4.4.

(4 Fase) Prova de Conceito

Na quarta fase do modelo garantiu-se que a soluo validada atravs da realizao

de um piloto. A infra-estrutura do Banco divida por ambientes, explicados em detalhe no Anexo B. Qualquer aplicao antes de evoluir para o ambiente de Produo testada em ambiente de Qualificao, foi neste ambiente que o piloto foi realizado. Permite que se possa validar a soluo no colocando em causa a estabilidade exigida no ambiente de Produo, a arquitectura representada na Figura 4-X, expressa no apenas o ambiente de Qualificao mas projecta igualmente o ambiente de Produo.

Figura 4-X-Arquitectura do Piloto

Aps a implementao da infra-estrutura, houve um perodo de integrao com os diferentes sistemas do Banco, como referido no ponto relativo arquitectura, o facto de existir um EAI facilitou as tarefas de integrao. Em seguida foi elaborado um caderno de testes, cujo objectivo simular as aces tpicas de um cliente com perfil de investidor, dessa forma foi possvel aferir os nveis de servio e capacidade de resposta do fornecedor a incidentes ocorridos. Torna-se importante destacar a importncia que o factor segurana teve na elaborao da arquitectura. Mesmo sabendo partida que no existiro troca de informao financeira dos clientes, foi pedida a realizao de uma auditoria infra-estrutura a uma empresa da especialidade. Com o objectivo de explorar potenciais vulnerabilidades na soluo, apenas se considerou a infra-estrutura segura aps terem sido efectuados alguns ajustes aconselhados pelo resultado da auditoria.

75

4.5.

(5 Fase) Implementao
A fase de implementao, j se vai desenvolver no ambiente de Produo, existe a

necessidade de replicar os passos relativos implementao, anteriormente dados no ambiente de Qualificao, o facto de o processo j estar interiorizado facilita o processo de instalao em Produo.

Figura 4-XI-Arquitectura de Produo

Aps concluda a implementao a entrada em Produo efectuou-se com as devidas cautelas, uma infra-estrutura deste tipo no deve ser imediatamente exposta a um nmero elevado de clientes. Desta forma definiu-se um universo de utilizadores inicialmente reduzido e confinado aos empregados que so simultaneamente clientes que permitiu validar a soluo segundo os passos identificados na Figura 4-XI. Aps uma entrada em Produo de forma controlado, ganhou-se confiana na infra-estrutura ao ponto de colocar ao dispor do pblico em geral.

4.6.

(6 Fase) Anlise dos Resultados

Na ltima fase do modelo, compilou-se os resultados obtidos em cada uma das

anteriores etapas do modelo, como identificado na Figura 4-XII. Em jeito de resumo podese efectuar uma anlise sobre os pontos que estiveram na origem da construo do modelo: 76

No ponto de vista do conceito SaaS, revelou-se eficaz nos pontos considerados fortes, que so o preo e a rapidez de implementao. Mostrou-se ao mesmo tempo uma soluo robusta, o facto de estar no ambiente de Produo em pleno funcionamento sem defraudar as expectativas, so a melhor prova que se poderia exigir.

No ponto de vista de gesto de benefcios, amplamente evidenciado nos pontos anteriores, permitiu ter uma viso mais abrangente, sem o foco apenas no aspecto financeiro.

Figura 4-XII-Analise dos resultados por cada fase do modelo

77

CAPTULO V
5. Concluses e Recomendaes
Neste captulo encerra-se esta dissertao, acreditando que os objectivos inicialmente propostos foram alcanados. Houve uma preocupao sempre presente que foi a conciliao de um conceito na sua fase emergente denominado de SaaS com a perspectiva financeira que lhe est associado. Alargou-se desta forma o mbito da dissertao que dever ser proveitosa para quem procura uma abordagem mais tcnica, bem como algum mais preocupado com a rea financeira. Como valor acrescentado desta dissertao, houve a ousadia de propor um modelo que tem como pretenso ser uma ajuda para as empresas ou organizaes que colocam a hiptese de evoluir para um conceito baseado em SaaS.

5.1.

Comparao entre os modelos GO2SaaS e o actual

O modelo proposto foi colocado prova, atravs da sua aplicao num projecto real

desenvolvido numa instituio financeira Portuguesa, que por norma gere os seus projectos seguindo o modelo retratado na Figura 5-I.

Figura 5-I-Modelo de Avaliao e Implementao dos Projectos

A comparao entre o modelo actualmente em vigor versus o modelo proposto (GO2SaaS), permitiu construir o quadro ilustrado na Figura 5-II. 78

Figura 5-II- Quadro comparativo entre Modelos

Da comparao efectuada, salienta-se os seguintes pontos: Fase 1: No Banco j existe uma preocupao de enquadrar os projectos de TI com o negcio. Todavia, a inexistncia de uma rede de benefcios, no permite estabelecer uma relao entre as melhorias introduzidas com o novo projecto e os consequentes benefcios para o negcio; Fase 2: Do ponto de vista de Arquitectura no existem alteraes significativas entre os modelos. O modelo proposto tem a vantagem de criar um conjunto de regras e enquadramentos que devem ser seguidos em projectos onde o SaaS esteja presente. Fase 3: No que diz respeito ao clculo dos benefcios, apenas se est a analisar do ponto de vista dos benefcios quantificveis de negcio. Como foi notrio ao longo do documento existem outros benefcios a ter em conta. Mesmo no campo dos benefcios quantificveis no tido em conta o eliminar da actual infra-estrutura que representa uma diminuio de custos. Neste ponto foi claramente uma mais-valia a interpretao dos dados segundo o modelo, permitiu ver cenrios antes ignorados. Fase 4: Pelo facto do SaaS ser um conceito ainda novo, no havia uma metodologia a ser seguida neste tipo de projectos. Os passos seguintes devem ser considerados uma referncia para o futuro. Fase 5: No existem alteraes significativas no processo de implementao, o que no existe e poder ser implementado a classificao das aplicaes por quadrante. Fase 6: No existe uma fase final, que efectue a anlise dos resultados. Neste ponto houve claramente um ganho que este modelo introduziu no projecto.

79

5.2.

Concluses Finais
Como concluses finais desta dissertao, foi permitido provar atravs do estudo as

consideraes efectuadas sobre o conceito SaaS, com a ajuda da figura conclui-se: Os custos totais do SaaS, so mais baixos quando comparados com o modelo tradicional; Os custos de investimento do SaaS so consideravelmente mais baixos; O perodo de implementao mais reduzido;

Outro ponto no menos importante o facto da plataforma sobre o conceito SaaS, estar a dar uma resposta positiva aos inmeros requisitos dirios o que prova que um conceito estvel que pode ser usado com confiana. No futurologia mas sim bem presente. Do ponto de vista da gesto de benefcios, tambm foi evidente que a viso proposta d luz a pontos que nas vises mais tradicionais so esquecidos e que ajudam a fortalecer as ideias das TI serem apenas sinnimo de despesismo. Seguindo uma correcta gesto de benefcios consegue-se provar a relao entre as TI e os benefcios para o negcio, assim como demonstrar que os proveitos de negcio gerados atravs de uma nova aplicao, podem no ser os nicos benefcios a serem contabilizados.

5.3.

Limitaes
Neste longo trabalho nem todos os aspectos foram lineares, do ponto de vista

pessoal houve a necessidade de gerir da melhor forma possvel a vida pessoal, profissional 80

e acadmica. No que confere realizao da dissertao, houve inesperadas dificuldades para identificar os custos relacionados com a energia e ar condicionado e foi de todo impossvel calcular os valores relacionados com o espao ocupado.

5.4.

Recomendaes
Outros conceitos esto tambm na sua fase emergente como indicado na Figura

5-III, tendo em comum o conceito servio. Ser certamente uma realidade nos prximos anos e vai colocar em causa muitos conceitos, mesmos os mais conservadores.

Figura 5-III - Conceitos .... as a Service

Como recomendao para trabalhos futuros, quem sabe um futuro doutoramento. Na ptica dos grupos empresariais, constitudos por vrias empresas, teriam todo o interesse em concentrar numa nica empresa o fornecimento de servios na rea das TI. As restantes empresa colocam-se na ptica de consumidoras, permitindo em limite abdicar das infra-estruturas e equipas de TI. O facto de as empresas pertencerem ao mesmo grupo, facilita questes que ainda so um entrave neste contexto, como segurana ou confidencialidade.

81

5.5.

Artigos Publicados
Durante a fase de desenvolvimento da dissertao, em conjunto com o orientador

Professor Doutor Henrique ONeill, consideramos benfico a submisso de artigos relacionados com o trabalho em curso: SaaS Software as a Service, compreender e escolher a abordagem correcta na implementao - Conferncia da Associao Portuguesa de Sistemas de Informao (CAPSI 2009), artigo a apresentar no dia 30-Outubro-2009. Saas Software as a Services, Linhas orientadoras - IADIS Conferncia IberoAmericana WWW/Internet (CIAWI 2009), artigo aceite como short paper, devido proximidade temporal entre as duas conferncias, optamos por participar apenas na CAPSI.

82

Bibliografia

[Amaral e Varajo 2000]

AMARAL, Luis e VARAJO, Joo. Planeamento de Sistemas de Informao, FCA Editora, Fevereiro-2000

[Berners-Lee et al. 2006]

BERNERS-LEE, Tim e GDEL Kurt e TURING Alan. Thinking on The Web, WILEY-INTERSCIENCE, 2006

[BIEBERSTEIN et al 2006]

12. Bieberstein, N., Bose, S., Fiammante, M., Jones, K., and Shah, R. 2006. Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap. Pearson Education, Upper Saddle River, NJ, p. 215.

[Cardoso 2008]

CARDOSO, Jorge. Programao de Sistemas Distribudos em Java, FCA, 2008 CARR, Nicholas. The End of Corporate Computing MITSloan Management Review, Vol.46 n3, SPRING 2005 CARRARO, Gianpaolo, Software As a Service: Architecture Strategies for Catching the Long Tail, Architecture Strategy Team http://blogs.msdn.com/gianpaolo, 2006

[CARR 2005]

[CARRARO 2006]

[Coulouris et al. 1994]

COULOURIS,

George

DOOLIMORE,

Jean

KINDBERG, Tim.

Distributed Systems Concepts and

Design, 3 ed., Addison-Wesley, 2000 [DELONE 2003] DELONE, W. H. e McLEAN, E.R. The DeLone and McLeane model of information system success: A ten year update, Jornal of Management Information Systems [FARREL 2003] FARREL, Diana. The Real New Economy Harvard Business Review, 2003 [Forrester 2006] Forrester The State Of Enterprise Software Adoption In 83

Europe, Janeiro-2006 [Fowler et al. 2002] FOWLER, Martin e RICE, David e FOEMMEL, Matthew e HIEATT , Edward e MEE, Robert e STAFFORD, Randy. Patterns of Enterprise Application Architecture, Addison Wesley, Novembro-2002 [IDC 2003] Utility Computing: A Look at Demand-Side Needs for OnDemand Computing Services, Maro-2003
[IDC 2005]

TRAUDT, Erin e KONARY, Amy. Software as a Service Taxonomy and Research Guide, IDC, 2005

[IDC 2007a]

Virtualization and Multicore Innovations Disrupt the Worldwide Server Market, Maro-2007

[IDC 2007b]

Worldwide Software on Demand 20072011 Forecast: A Preliminary Look at Delivery Model Performance

[iSOCIETY 2003]

iSociety Getting By, Not Getting On, London: Work Foundation LAMBERT, R. e EDWARDS, C. A survey of IS/IT project appraisal, IS Group Cranfield School of Management, 2003

[LAMBERT 2003]

[Laudon 2005]

LAUDON,

Kennet

LAUDON

Jane.

Management

Information Systems: Managing the Digital Firm, 9 ed., New York, Prentice Hall, Outubro-2005 [Microsoft 2008a] Microsoft-Ray Ozzie, Software-Plus-Services: Full Story, http://www.microsoft.com/softwareplusservices/softwareplus-services-full-story.aspx , Dezembro-2008 [Microsoft 2008b] http://www.microsoft.com/softwareplusservices/softwareplus-services-strategy.aspx?product=azure, Maro-2009 [OCG 2004] OCG, Office of Government Commerce, Project Initiation Guidelines, www.ocg.gov.uk 2004 [ORACLE 2007] ORACLE SaaS Platform: Building On-Demand

Applications, Oracle With Paper, Junho-2007 [ORACLE 2008] ORACLE SaaS Platform: Building On-Demand

Applications, Oracle With Paper, Setembro-2008 [Porter 2001] PORTER, Michael. Strategy and The Internet, Harvard 84

Business Review, Maro-2001 [ROSS 2002] ROSS, J. W. e BEATH, C. M. Beyond the business case: New approaches to IT investment, MIT Sloan Management Review, 2002 [Serrano et al. 2004] SERRANO, Antnio e CALDEIRA, Mrio e GUERREIRO, Antnio. Gesto de Sistemas e Tecnologias de Informao, FCA, Abril-2004 [Sommerville 2001] SOMMERVILLE, I., Software Engineering, 6 ed., Pearson Education Limited, 2001 [SYMONS 2008] SYMONS, Craig. Justifying And Funding Infrastructure Investments, Fevereiro 2008 [W3C 2003] [W3C 2004] http://www.w3.org/TR/2003/WD-ws-arch-20030514/ World Wide Web Consortium, Web Services Architecture, http://www.w3.org/TR/2004/NOTE-ws-arch-20040211 Fevereiro-2004 [Ward 2007] WARD, John e DANIEL, Elizabeth. Benefits Management Delivering Value from IS & IT Investments, WILEY, Maio2007 [WEILL 1998] WEILL, Peter e BROADBENT, Marianne. Leveraging the New Infrastructure: How market leaders capitalize on IT, Harvard Business School Press, 1998 ,

85

ANEXO A
O objectivo deste Anexo A, detalhar as caractersticas dos servidores referidos nos clculos. O Banco divide os servidores em trs tipos, denominados por: Small: Servidor cuja capacidade de processamos pode ser expansvel a dois processadores fsicos, independentemente do numero de cores. Neste perfil enquadramse os servidores WEB que no exigem capacidades de processamos elevados, no necessitando tambm de ligaes a unidades de disco externas. Medium: Servidor cuja capacidade de processamos pode ser expansvel at quatro processadores fsicos, independentemente do numero de cores. Neste perfil encaixam os servidores de bases de dados, onde existem uma capacidade de processamento elevada, bem como necessidade de espao em disco tambm elevadas, por essa razo existe a necessidade de ligao a uma unidade de discos externa. Large: Servidor cuja capacidade de processamos pode ser expansvel a oito processadores fsicos, independentemente do numero de cores. Devido sua imensa capacidade, quer no ponto de vista de processamento, quer na capacidade de ligao a unidades de disco externas. Apenas se usa para bases de dados muito exigentes e fulcrais para o negcio. A Figura A-I, tem como objectivo dar imagem da arquitectura de referncia implementada no Banco no que diz respeito aos sistemas distribudos, d uma viso de posicionamento dos diferentes elementos atrs citados: Servidores WEB, Servidores de Base de Dados, Unidades de Disco

86

Figura A-I - Arquitectura de Referencia para Sistemas Distribudos

As tabelas apresentadas em seguida descrevem as principais caractersticas, tendo em conta o tipo de Servidor.
Caractersticas por tipo de Servidor Tipo Servidor Small Modelo System x3550 M2 Disco (2) 146GB 15K rpm 6Gbps SAS HS HDD 2.5 (2) 146 GB 10K-rpm SAS Hot-Swap HDD 2.5 Memria (2) 2048 MB 1Rx4 Dimm(s) (2) 8192 MB Dimm(s) CPU (2) 2.93GHz Quad-Core Intel Xeon X5570 (4) 2.40GHz Intel Quad Core Xeon E7440 (2) Brocade 8Gb FC Single-port HBA for IBM System x Placas de Fibre Channel

Medium

System x3850 M2 (7233)

Tabela A-I - Caractersticas por Tipo de Servidor

Gastos Energticos por tipo de Servidor Tipo Servidor Small Medium Voltagem 220V 220V Amperes 1,7 A 2,9 A Consumo Mnimo 225 W 449 W Consumo Mdio 373 W 625 W Consumo Mximo 780 W 1600 W

Tabela A-II - Gastos Energticos

Gastos de Arrefecimento por tipo de Servidor Tipo Servidor Small Medium Consumo Mnimo 768 BTU/Hr 1532 BTU/Hr Consumo Mdio 1272 BTU/Hr 2132 BTU/Hr Consumo Mximo 2661 BTU/Hr 5459 BTU/Hr

Tabela A-III - Gastos de Arrefecimento

87

ANEXO B
O objectivo deste Anexo B descriminar um conjunto de tabelas vitais no clculo dos custos. A
Custos de Hardware, Licenciamento e Gesto
Itens Windows Standard Windows Enterprise SQL Enterprise Serv. Tipo Web (Produo) - Apenas HW Serv. Tipo Web (Produo) - Gesto Serv. Tipo Web (Qualificao) Apenas HW Serv. Tipo Web (Qualificao) Gesto Serv. Tipo Web (DR) - Apenas HW Serv. Tipo Web (DR) - Gesto Serv. Tipo BD (Produo) - Apenas HW Serv. Tipo BD (Produo) - Gesto Instancia BD (Produo) Serv. Tipo BD (Qualificao) - Apenas HW Serv. Tipo BD (Qualificao) - Gesto Instancia BD (Qualificao) Serv. Tipo BD (DR) - Apenas HW Serv. Tipo BD (DR) - Gesto Instancia BD (DR) Gastos Energticos Servidor Tipo WEB Gastos Energticos Servidor Tipo BD Gastos Arrefecimento Servidor Tipo WEB Gastos Arrefecimento Servidor Tipo BD C. Unit. 1 Ano 208,00 795,00 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 263,42 520,45 263,37 520,39 C. Unit. 2 Ano 208,00 795,00 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 268,69 530,86 268,64 530,80 C. Unit. 3 Ano 218,40 834,75 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 274,06 541,47 274,01 541,42 C. Unit. 4 Ano 218,40 834,75 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 279,55 552,30 279,49 552,25 C. Unit. 5 Ano 229,32 876,49 3.035,27 645,75 4.351,05 645,75 3.948,89 645,75 4.351,05 3.260,95 5.251,31 2.909,68 2.560,95 4.724,84 2.621,50 2.560,95 5.251,31 2.909,68 285,14 563,35 285,08 563,29 C. Unit. 6 Ano 229,32 876,49 3.035,27 645,75 4.351,05 645,75 3.948,89 645,75 4.351,05 3.260,95 5.251,31 2.909,68 2.560,95 4.724,84 2.621,50 2.560,95 5.251,31 2.909,68 290,84 574,62 290,78 574,56

Tabela B-I descreve os custos de Hardware, Licenciamento e Gesto os valores apresentados referem-se realidade do Banco estes custos no devem ser considerados custos de referencia para o pblico em geral. Torna-se importante explicar cada um dos itens: Custos de Hardware: Entende-se por custos de HW o valor pago pelos servidores, segundo o seu perfil, o custo diludo ao longo dos quatro anos de vida do mesmo; 88

Custos de Gesto: Entende-se por custos de gesto os custos associados manuteno, gesto de sistema operativo, gesto de backups, tambm este custo distribudo ao longo dos quatro anos de vida do respectivo servidor. Os custos de gesto diferem segundo o papel desempenhado, por exemplo um servidor WEB, tem um custo diferente de um servidor de Base de Dados;

Custos de Licenciamento: Custo que a Microsoft cobra pela utilizao do software, este custo sofre um acrscimo de 5% do segundo para o terceiro ano; Na

Custos de Hardware, Licenciamento e Gesto

Itens Windows Standard Windows Enterprise SQL Enterprise Serv. Tipo Web (Produo) - Apenas HW Serv. Tipo Web (Produo) - Gesto Serv. Tipo Web (Qualificao) Apenas HW Serv. Tipo Web (Qualificao) Gesto Serv. Tipo Web (DR) - Apenas HW Serv. Tipo Web (DR) - Gesto Serv. Tipo BD (Produo) - Apenas HW Serv. Tipo BD (Produo) - Gesto Instancia BD (Produo) Serv. Tipo BD (Qualificao) - Apenas HW Serv. Tipo BD (Qualificao) - Gesto Instancia BD (Qualificao) Serv. Tipo BD (DR) - Apenas HW Serv. Tipo BD (DR) - Gesto Instancia BD (DR) Gastos Energticos Servidor Tipo WEB Gastos Energticos Servidor Tipo BD Gastos Arrefecimento Servidor Tipo WEB Gastos Arrefecimento Servidor Tipo BD C. Unit. 1 Ano 208,00 795,00 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 263,42 520,45 263,37 520,39 C. Unit. 2 Ano 208,00 795,00 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 268,69 530,86 268,64 530,80 C. Unit. 3 Ano 218,40 834,75 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 274,06 541,47 274,01 541,42 C. Unit. 4 Ano 218,40 834,75 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 279,55 552,30 279,49 552,25 C. Unit. 5 Ano 229,32 876,49 3.035,27 645,75 4.351,05 645,75 3.948,89 645,75 4.351,05 3.260,95 5.251,31 2.909,68 2.560,95 4.724,84 2.621,50 2.560,95 5.251,31 2.909,68 285,14 563,35 285,08 563,29 C. Unit. 6 Ano 229,32 876,49 3.035,27 645,75 4.351,05 645,75 3.948,89 645,75 4.351,05 3.260,95 5.251,31 2.909,68 2.560,95 4.724,84 2.621,50 2.560,95 5.251,31 2.909,68 290,84 574,62 290,78 574,56

Tabela B-I, so efectuadas referncias a termos como Produo e Qualificao, so nomes dados aos diferentes ambientes que existem no Banco e que a Figura B-I ilustra e enquadra quanto aos objectivos de cada um. 89

Figura B-I - Ambientes de Desenvolvimento, Qualificao, Produo e DR

Custos de Hardware, Licenciamento e Gesto

Itens Windows Standard Windows Enterprise SQL Enterprise Serv. Tipo Web (Produo) - Apenas HW Serv. Tipo Web (Produo) - Gesto Serv. Tipo Web (Qualificao) Apenas HW Serv. Tipo Web (Qualificao) Gesto Serv. Tipo Web (DR) - Apenas HW Serv. Tipo Web (DR) - Gesto Serv. Tipo BD (Produo) - Apenas HW Serv. Tipo BD (Produo) - Gesto Instancia BD (Produo) Serv. Tipo BD (Qualificao) - Apenas HW Serv. Tipo BD (Qualificao) - Gesto Instancia BD (Qualificao) Serv. Tipo BD (DR) - Apenas HW Serv. Tipo BD (DR) - Gesto Instancia BD (DR) Gastos Energticos Servidor Tipo WEB Gastos Energticos Servidor Tipo BD Gastos Arrefecimento Servidor Tipo WEB Gastos Arrefecimento Servidor Tipo BD C. Unit. 1 Ano 208,00 795,00 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 263,42 520,45 263,37 520,39 C. Unit. 2 Ano 208,00 795,00 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 268,69 530,86 268,64 530,80 C. Unit. 3 Ano 218,40 834,75 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 274,06 541,47 274,01 541,42 C. Unit. 4 Ano 218,40 834,75 2.890,73 615,00 3.955,50 615,00 3.589,90 615,00 3.955,50 3.105,67 4.773,92 2.771,12 2.439,00 4.295,31 2.496,66 2.439,00 4.773,92 2.771,12 279,55 552,30 279,49 552,25 C. Unit. 5 Ano 229,32 876,49 3.035,27 645,75 4.351,05 645,75 3.948,89 645,75 4.351,05 3.260,95 5.251,31 2.909,68 2.560,95 4.724,84 2.621,50 2.560,95 5.251,31 2.909,68 285,14 563,35 285,08 563,29 C. Unit. 6 Ano 229,32 876,49 3.035,27 645,75 4.351,05 645,75 3.948,89 645,75 4.351,05 3.260,95 5.251,31 2.909,68 2.560,95 4.724,84 2.621,50 2.560,95 5.251,31 2.909,68 290,84 574,62 290,78 574,56

90

Tabela B-I - Custos de Hardware, Licenciamento e Gesto

Os custos relacionados com os consumos energticos e de arrefecimento, tm vindo a tomar propores cada vez maiores, ao ponto de serem tambm eles factores de preocupao. A Tabela B-II, identifica os custos de referncia para o KW/h, unidade que expressa o consumo energtico, o seu preenchimento foi possvel atravs da consulta do Site da Entidade Reguladora dos Servios Energticos (http://www.erse.pt/pt), realizada em Agosto-2009. Existem tambm referncias ao BTU (British Thermal Unit) identifica a necessidade que cada equipamento tem no que diz respeito ao arrefecimento, essa necessidade traduz-se tambm ela num gasto energtico por parte dos equipamentos de ar condicionado. Para que se consiga efectuar o clculo exige a necessidade de converter BTU em kWh, a relao entre as duas unidades medidas dada pela seguinte equao:

Custos do KWH de Referencia

Custos Energticos Custo (kWh) Custos Energticos Converso de BTU/H para KW/H (1BTU 0.293071 Wh) Gastos Arrefecimento Servidor Tipo WEB Gastos Arrefecimento Servidor Tipo BD 0,04190 0,04490 0,08210 Perodo Baixa Utilizao Perodo Mdia Utilizao Perodo Mxima Utilizao

0,22508 0,44898

0,37279 0,62483

0,77986 1,59987

Tabela B-II - Custos do KWH de Referencia

A Tabela B-III, faz o resumo dos gastos anuais de consumo energtico e de arrefecimento, tendo como base os valores das diferentes tabelas dos anexos A e B. No que diz respeito utilizao, foram considerados trs perodos: Perodo de Baixa utilizao: Das 00:00 s 08:00, onde os servidores tm um processamento muito baixo e por consequncia o seu consumo baixa; Perodo de Mdia utilizao: Das 16:00 s 24:00, onde os servidores tm um processamento mdio e por consequncia o seu consumo mantm mdio; 91

Perodo de Mxima utilizao: Das 08:00 s 18:00, onde os servidores tm um processamento muito alto e por consequncia o seu consumo tambm elevado;

Resumo
Custos Energticos Perfil Utilizao Consumo (Mim:8h Med:8h Max:8h) Gastos Energticos Servidor Tipo WEB Gastos Energticos Servidor Tipo BD Custos Energticos Servidor Tipo WEB Custos Energticos Servidor Tipo BD Arrefecimento (Mim:8h Med:8h Max:8h) Gastos Energticos Servidor Tipo WEB Gastos Energticos Servidor Tipo BD Custos Energticos Servidor Tipo WEB Custos Energticos Servidor Tipo BD Consumo (Anual) Custos Energticos Servidor Tipo WEB Custos Energticos Servidor Tipo BD Gastos Arrefecimento Servidor Tipo WEB Gastos Arrefecimento Servidor Tipo BD 27,52830 54,93425 27,53791 54,93239 48,90328 81,94250 48,87527 81,91987 186,99096 383,57120 186,95786 383,54113 263,42254 520,44795 263,37104 520,39339 1,801 3,592 0,07545 0,15050 2,982 4,999 0,13390 0,22444 6,239 12,799 0,51221 1,05080 1,800 3,592 0,07542 0,15050 2,984 5,000 0,13398 0,22450 6,240 12,800 0,51230 1,05088 Perodo Baixa Utilizao Perodo Mdia Utilizao Perodo Mxima Utilizao Total

Tabela B-III Resumo

A Tabela B-IV, faz uso das anteriores tabelas de forma a conseguir determinar os custos relacionados com opo desenvolvimento segundo o modelo tradicional.
Anos Custos Projecto Custos Setup-Projectos Custos Infra-Estrutura Ambiente de Produo Servidores HW WEB (3x) Base Dados (2x) Gesto Servidores WEB (3x) Base Dados (2x) Licenas Licenas de Windows Licenas de SQL Storage Espao estrutura + InfraAno 1 668.049 62.634 97.050 42.718 8.056 1.845 6.211 24.185 11.866 12.319 7.995 2.214,00 5.781,46 Ano 2 608.015 0 99.482 43.691 8.056 1.845 6.211 24.185 11.866 12.319 7.995 2.214,00 5.781,46 Ano 3 110.731 0 102.028 44.776 8.056 1.845 6.211 24.185 11.866 12.319 8.106 2.324,70 5.781,46 4.427,76 4.427,76 Ano 4 113.338 0 104.461 45.749 8.056 1.845 6.211 24.185 11.866 12.319 8.106 2.324,70 5.781,46 5.400,76 5.400,76 Ano 5 170.400 0 111.345 49.087 8.459 1.937 6.522 26.465 13.053 13.412 8.511 2.440,94 6.070,53 5.650,76 5.650,76 Ano 6 171.206 0 111.970 49.337 8.459 1.937 6.522 26.465 13.053 13.412 8.511 2.440,94 6.070,53 5.900,76 5.900,76 Total 1.841.738 62.634 626.337 275.357 49.144 11.255 37.889 149.673 73.572 76.100 49.226 13.959 35.267 27.315 27.314,56

2.480,76 3.453,76 2.480,76 3.453,76

92

Ambiente de Qualificao Servidores HW WEB (2x) Base Dados (2x) Gesto Servidores WEB (2x) Base Dados (2x) Licenas Licenas de Windows Licenas de SQL Storage Espao + Infraestrutura Ambiente de Disaster Recover Servidores HW WEB (1x) Base Dados (1x) Gesto Servidores WEB (1x) Base Dados (1x) Licenas Licenas de Windows Licenas de SQL Storage Espao estrutura + Infra-

33.403 6.108 1.230 4.878 18.267 7.180 11.087 7.787 2.006,00 5.781,46

33.889 6.108 1.230 4.878 18.267 7.180 11.087 7.787 2.006,00 5.781,46

34.376 6.108 1.230 4.878 18.267 7.180 11.087 7.787 2.006,00 5.781,46 2.213,88 2.213,88 22.876 3.054 615 2.439 11.501 3.955 7.545 3.894 1.003,00 2.890,73 4.427,76 4.427,76 8.703 3.810 1.644,23 2.165,78 3.262 1.096,15 2.165,78 1.631 548,08 1.082,89

34.863 6.108 1.230 4.878 18.267 7.180 11.087 7.787 2.006,00 5.781,46 2.700,38 2.700,38 23.849 3.054 615 2.439 11.501 3.955 7.545 3.894 1.003,00 2.890,73 5.400,76 5.400,76 8.877 3.886 1.677,11 2.209,10 3.327 1.118,08 2.209,10 1.664 559,04 1.104,55

36.995 6.413 1.292 5.122 19.969 7.898 12.071 7.787 2.006,00 5.781,46 2.825,38 2.825,38 25.263 3.207 646 2.561 12.512 4.351 8.161 3.894 1.003,00 2.890,73 5.650,76 5.650,76 9.055 3.964 1.710,65 2.253,28 3.394 1.140,44 2.253,28 1.697 570,22 1.126,64

37.120 6.413 1.292 5.122 19.969 7.898 12.071 7.787 2.006,00 5.781,46 2.950,38 2.950,38 25.513 3.207 646 2.561 12.512 4.351 8.161 3.894 1.003,00 2.890,73 5.900,76 5.900,76 9.236 4.043 1.744,87 2.298,35 3.462 1.163,25 2.298,35 1.731 581,62 1.149,17

210.647 37.259 7.503 29.756 113.006 44.515 68.492 46.725 12.036 34.689 13.657 13.657 140.333 18.629 3.752 14.878 71.026 24.524 46.502 23.362 6.018 17.344 27.315 27.315 52.767 23.101 9.969 13.132 19.778 6.646 13.132 9.889 3.323 6.566

1.240,38 1.726,88 1.240,38 20.929 3.054 615 2.439 11.501 3.955 7.545 3.894 1.003,00 2.890,73 1.726,88 21.902 3.054 615 2.439 11.501 3.955 7.545 3.894 1.003,00 2.890,73

2.480,76 3.453,76 2.480,76 8.365 3.662 1.580,38 2.081,68 3.135 1.053,59 2.081,68 1.568 526,79 1.040,84 3.453,76 8.532 3.735 1.611,99 2.123,32 3.198 1.074,66 2.123,32 1.599 537,33 1.061,66

Custos Energticos Ambiente de Produo Server WEB (3x) Server BD (2x) Ambiente de Qualificao Server WEB (2x) Server BD (2x) Ambiente de DR Server WEB (1x) Server BD (1x)

500.000 500.000 0 0 50.000 50.000 1.100.000 Custos Desenvolvimento Os custos de Desenvolvimento pressupem um tempo de concluso da plataforma nunca inferior a um ano. O Banco no tem experiencia no desenvolvimento deste tipo de aplicaes, todo o processo tem que ser desenvolvido de raiz, por essa razo os custos so elevados.

Alm do Desenvolvimento inicial, que em termos contabilsticos dilui-se nos dois primeiros anos, esto previstas tambm no quinto e sexto ano de vida algumas adaptaes tpicas de uma aplicao com quatro anos de vida.

Tabela B-IV- Custos do Modelo Tradicional

93

Custos Adaptao (F-SaaS) Adaptao (Banco) Royalties (F-SaaS) Total:

Ano 1 50.000 50.000

Ano 2 50.000 50.000 130.000

Ano 3 50.000 50.000 162.000 262.000

Ano 4 50.000 50.000 194.000 294.000

Ano 5

Ano 6

227.000 227.000

259.000 259.000

100.000

230.000

Tabela B-V - Custos Modelo SaaS

Pressupostos Taxa de actualizao VAL N Anos do Projecto

11,7% 6

Ano 1 Custos F-SaaS Proveitos de Negcio VA Impactos Positivos VA Impactos Negativos (F-SaaS) Funo desconto (actualizao do VAL) VAL Anual (F-SaaS) VAL do Projecto EACF EACF (Projecto) ROI * PAYBACK (Anos) * 3,13 1,45 17.122,55 100.000,00 29.000,00 29.000,00 100.000,00 1,00 71.000,00

Ano 2 230.000,00 316.000,00 282.900,63 205.908,68 0,90 76.991,94

Ano 3 262.000,00 782.000,00 626.758,75 209.988,23 0,80 416.770,53

Ano 4 294.000,00 1.343.000,00 963.643,72 210.954,02 0,72 752.689,69

Ano 5 227.000,00 1.474.000,00 946.857,87 145.818,68 0,64 801.039,18

Ano 6 259.000,00 1.722.000,00 990.301,15 148.947,73 0,58 841.353,41

2.817.844,76 18.567,58 100.509,49 181.520,66 193.180,75 202.903,04

679.558,97

Tabela B- VI- Indicadores financeiros para o modelo SaaS

Ano 1 Custos Modelo Tradicional Proveitos de Negcio VA Impactos Positivos VA Impactos Negativos (M.Tradicional) Funo desconto (actualizao do VAL) VAL Anual (F-SaaS) VAL do Projecto EACF EACF (Projecto) ROI * PAYBACK (Anos) * 1,14 2,80 161.108,39 125.010,51 668.048,62 0,00 0,00 668.048,62 1,00 668.048,62 Ano 2 608.014,74 29.000,00 25.962,40 544.328,32 0,90 518.365,92 Ano 3 110.731,08 316.000,00 253.268,24 88.748,95 0,80 164.519,30 Ano 4 113.337,64 782.000,00 561.109,00 81.323,24 0,72 479.785,76 Ano 5 Ano 6

170.399,77 171.205,86 1.474.000,00 1.343.000,00 862.707,00 847.679,38 109.460,22 0,64 753.246,78 98.458,40 0,58 749.220,98

960.358,28 39.675,91 115.706,42 181.655,01 180.684,13

231.602,57

Tabela B- VII- Indicadores financeiros para o modelo Tradicional

94