Resumo

A computação em nuvem, particularmente com o modelo PaaS (platform as a service), é uma excelente oportunidade mas deve ser avaliada com cuidado. A promessas dos vendedores são exageradas, a complexidade das soluções está aumentando e vários riscos existem. De modo geral, é preciso ver como estratégicos os investimentos feitos em PaaS e nao apenas como uma soluçao para reduçao de custos. Algumas precauções devem ser tomadas, entre elas: começar com projetos de menor visibilidade e integrar competencias especializadas em cloud.

A onda da computação em nuvem continua forte com a chegada do mais novo irmão da família, o PaaS (platform as a service). Contudo, se o PaaS (a “nuvem” de modo geral) é uma excelente oportunidade, ele deve ser  considerado com bastante cuidado. O mercado tem atualmente duas caraterísticas marcantes. A primeira é a  falta de consolidação: vários atores estão na corrida com propostas e diferenciais muito heterogêneos. A segunda é a forte concorrência, levando, as vezes, a propostas e argumentos que beiram a ma fé. O problema disso é que os provedores, vendendo a nuvem pelo que ela não é, arriscam causar bastante decepção.

O propósito deste post pode ser resumido pelo David Linthicum (Infoworld)

“Cloud computing does not replace enterprise architecture. It does not provide “infinite scalability,” it does not “cost pennies a day,” you can’t “get there in an hour” — it won’t iron my shirts either. It’s exciting technology that holds the promise of providing more effective, efficient, and elastic computing platforms, but we’re taking this hype to silly levels these days, and my core concern is that the cloud may not be able to meet these overblown expectations. [..] the hype is almost out of control and misinformation is plentiful [..] It’s a new technology, but the same old hype cycle. [..] I still see many square cloud pegs going into round enterprise holes. Why? The hype drives the movement to cloud computing, but there is little thought as to the actual fit of the technology.” [2]

Gostaria assim de resumir alguns elementos a respeito das reais vantagens, riscos e mitos a respeito de PaaS. De modo geral o real valor de investimento em PaaS depende da situação da empresa, da infra-estrutura que ela ja possui, das suas necessidades atuais e futuras e dos recursos disponíveis. Gastos com  Paas (e em nuvem de modo geral) não devem ser considerados como um jeito de reduzir custos, mas sim como investimentos estratégicos.

Vantagens

Elasticidade e Flexibilidade

Talvez a caraterística mais interessante do PaaS seja a “elasticidade”, a capacidade da plataforma de se adaptar à nova carga em questão de minutos. Além disso, permite transformar um custo fixo em custo variável porque os provedores cobram em geral pela capacidade utilizada.

Além dos aspectos de infra-estrutura, a criação de aplicativos arquitetados em serviços desacoplados pode trazer uma agilidade sensivelmente maior no desenvolvimento ou na modificação de aplicativos, permitindo acompanhar melhor as necessidades de negócios.

Terceirização da plataforma

De fato, a terceirização da infra-estrutura e, além dela, da plataforma inteira onde rodam os aplicativos, pode ter sensíveis vantagens. A principal é o nível de serviço superior ao que pode ser alcançado “in house” e com custos menores. Mas como ja mencionado na introdução, tudo depende dos investimentos já feitos em infra- estrutura própria.

Diferenciais adicionais

Procurando diferenciais no mercado, alguns provedores de plataformas oferecem serviços ou capacidades diferenciadas e únicas que podem ser interessantes em certos tipos de aplicações. Por exemplo GigaSpace que oferece o “GigaSpaces XAP In-Memory Data Grid” – que promete acelerar drasticamente a performance do acesso a grandes quantidades de dados.

Mitos

(para não dizer mentiras)

Desenvolvimento em minutos.

Argumento número 1 de muitos provedores: a redução “drástica” do tempo de desenvolvimento. Alguns vão até afirmar “[..] eliminates the need for coding, data modeling and database querying “. Bullshit. Ter uma plataforma, mesmo integrando ferramentas de desenvolvimento e APIs, não impede ter que definir arquieturas, programar, intergar e testar.

Foco exclusivo no negocio

Pela mesma razão mencionada acima, o PaaS não evita de ter que escrever os aplicativos. Inclusive, PaaS eventualmente aumenta a complexidade e requer MAIS atenção ainda às questões de arquitetura corporativa tais como integração, segurança, transações.

Redução drástica dos custos

A computação em nuvem dificilmente é um jeito de reduzir os custos. Pelo menos não a curto prazo. Precisa migrar os aplicativos, eventualmente redefinir arquiteturas, etc. E isso requer gastos.

Riscos

Lock-in

Hoje, provedores de PaaS estão numa luta acirrada, cada um propondo plataformas baseadas nas tecnologias que ja tem e oferecendo suas próprias APIs. Os aplicativos desenvolvidos usando essas APIs não serão portáveis para outro provedor. Em comparação com Java EE por exemplo, que visa especificar APIs e serviços que devem ser implementados pelos provedores, é uma regressão. Embora a portabilidade (no sentido do Java EE) tenha sido no melhor dos casos imperfeita, o risco de “lock in” aumentou sensivelmente.

Complexidade

Com a nuvem, existem mais opções para desenvolver e disponibilizar aplicativos. A principio isso é bom, mas essas novas opções aumentam a complexidade dos sistemas de informação. Existem nuvens públicas, privadas ou soluções híbridas com parte dos aplicativos usados em SaaS, parte desenvolvida em Paas e outras ficando inhouse

Essa complexidade, e escolhas erradas, são um risco para projetos de PaaS. Tem até aparecido nos Estados Unidos a posição de “Cloud Architect”, com conhecimentos específicos- e diferentes de um “Software Architect”. Sendo a demanda por essas competências bem maior do que a oferta, é muito provável que muitos projetos conheçam problemas por terem sido mal desenhados ou mal planejados.

Descontinuidade

Provedores não são eternos. Podemos esperar que vários deles fechem ou que haja consolidação, ou casos de provedores menores sendo comprados. Obviamente, isso é um risco que nao pode ser negligenciado pelos clientes na hora de migrar ou desenvolver novas soluções.

Riscos jurídicos

Usar a nuvem (PaaS ou SaaS) é confiar a um terceiro a responsabilidade de garantir ao seu nível a segurança e a disponibilidade dos aplicativos e dados. É imprescindível amarrar os contratos para evitar problemas em casos de falhas dos sistemas (e sistemas, podem acreditar, falham).

Outro ponto importante, complexo e possível risco, é a questão internacional. Optar pela nuvem pode significar armazenar os seus dados com um provedor fora do Brasil – com a possibilidade de aplicação das leis locais, como por exemplo a quebra de sigilo em caso de ordem judicial. Além disso, a lei Brasileira proíbe que certas categorias de dados sejam armazenadas fora do território nacional.

Subestimação dos custos

A subestimação dos custos, em particular no que diz respeito à migração para a nuvem, pode causar o fracasso de projetos e muita decepção. Esta subestimação existe alias, por culpa de promessas comerciais exageradas por parte dos provedores. É um desperdício porque projetos que poderiam ter tido um bom retorno vão ser encerrados antes da hora.

Segurança

Segurança é um assunto amplo e complexo. E hoje, pouco conhecido pelos provedores e clientes. Muito resumidamente, a segurança na nuvem deve ser garantida em dois níveis. Primeiro pelos provedores e depois pelos desenvolvedores dos aplicativos. XaaS são baseadas no compartilhamento de recursos e é essencial que esses recursos sejam protegidos pelos provedores – inclusive da ação involuntária dos próprios clientes.

Performance

É um fato: a computação em nuvem esta crescendo mais rápido do que as redes que a suportam. Existe um risco grande a médio prazo que essas redes não agüentem a carga. É até provável que limitações apareçam nos planos propostos pelos provedores.

“[..] global data center IP traffic will increase fourfold over the next five years. Overall data center IP traffic will grow 33 percent per year from 2010 to 2015. [..] Cloud computing is driving much of this growth, both from business and consumer usage [..] I suspect we’ll soon hit walls within many enterprises and ISPs, and perhaps limits will be placed on the amount of data that can move from place to place. Certainly, cable operators are suggesting they’ll do this, and cellular carriers and some DSL providers have already moved this way. I also see such restrictions imposed by cloud storage providers, including Box.net, Dropbox, Mozy, Carbonite, and even Amazon.com’s S3.” [2]

Referencias

[1] “Como PaaS pode gerar valor“,
[2] David Linthicum, Cloud Computing blog (vários posts),
[3] Edileuza Soares, 21/11/2011 “Quais são os riscos legais de cloud computing no Brasil?”
[4] “Improving PaaS Security: Get your Developers Involved“

Alguns dias atrás estava conversando com consultores em marketing e gestão e eles comentaram as dificuldades que os seus clientes enfrentam com os seus sistemas de informação e seus fornecedores. Apareceu muito claramente nessa conversa que a informação assimétrica é um fator essencial nesses problemas. Tipicamente, o cliente não tem informação  suficiente para validar a competencia de um fornecedor “ex ante”. Nem tem a competência para validar o trabalho feito “ex post”.

Quantas vezes um produto foi vendido sem atender corretamente as necessidades do cliente ? Quantos novos projetos não sucederam porque o vendedor prometeu mais do que era realista em termos de prazo ou custo ?

Essa situação de informação assimetrica já foi (esta sendo) estudada pelos economistas, tanto no quadro conceitual quanto na sua aplicação à terceirização de TI. Teria gostado de inventar algo a respeito, mas vou me limitar a resumir a literatura que achei a respeito (nem todas as matérias são muito recentes, porém ainda são perfeitamente válidas)

O problema esta longe de ser apenas teorico. Eu mesmo já sofri de fenômeno de “seleção adversa” descrito abaixo. Além disso, as conclusões que podem ser tiradas desses estudos influenciam diretamente o modelo de colaboração que consideramos como ideal, incluindo processo de desenvolvimento e aspectos contratuais.

A Teoria da Agencia: seleção adversa a risco moral

A questão da informação assimetrica é central à “teoria da agencia” que diz respeito a todas as situações onde um ator economico (o principal) contrata outro (o agente) para executar um trabalho.

Um primeiro fenômeno, chamado de seleção adversa, ocorre quando o principal, incerto quanto à real qualidade do agente, só aceita contratar com preços baixos, preços aos quais os fornecedores de alta qualidade não desejam vender. O segundo fenômeno, chamado de “risco moral” ocorre quando o agente adota comportamentos oportunistas para maximizar o seu próprio lucro e não o lucro do principal, aproveitando a dificuldade de controle por parte do mesmo.

Comportamentos oportunistas aparecem por causa de informação não revelada e também por causa de interesses divergentes dos atores. Teoricamente, o problema da agencia pode ser resolvido diminuindo a assimetria da informação e alinhando os objetivos do agente e do principal.

Aplicação à terceirização de TI

A terceirização é muito usada hoje em sistemas de TI, desde infra-estrutura até desenvolvimento de novos sistemas. Ao mesmo tempo, projetos de software continuam sendo arriscados. Projetos falham. Além disso, o outsourcing, mesmo que permita transferir o risco do projeto para o agente, cria novos riscos – riscos de agencia, relacionados à capacidade e motivação do agente para o sucesso do projeto [2].

Pois, podemos esperar que o principal e o agente tenham objetivos divergentes. Primeiro porque o lucro de um é um custo para o outro. Segundo porque principal e agente não tem o mesmo interesse no que diz respeito ao trade-off entre qualidade e respeito de prazos [1].

Além disso, mecanismos de controle e contratuais não necessariamente trazem uma solução para esses problemas. [2][3]

Processos Ageis

Um papel muito interessante [1] cita metodos de desenvolvimento ágeis (XP, Scrum) como um jeito de reduzir a assimetria de informação entre o agente e o principal.

Promovendo uma estreita colaboração do cliente e do desenvolvedor e até a presença permanente do cliente na equipe de desenvolvimento, ajuda o principal a saber como o agente conduz o seu trabalho. Com entregas frequentes, permite também um melhor compartilhamento do real status do projeto – o que é de alto valor para o principal.

Teria ainda muita coisa esta para dizer. Questões de riscos de projetos de software, de volatilidade dos requisitos e tecnologias, de custos de transação. Espero ter a ocasão de completar este post ulteriormente.

Referencias:

[1] Information Systems Development Methods and Reducing Information Asymmetry: a Way to Decrease Project Escalation in Outsourcing ?, Arttu Kataja & Tuure Tuunanen.

[2] Vendor Related Risks in IT Development: A Chronology of an Outsourced Project Failure; Joseph Natovich; Technology Analysis & Strategic Management

[3] Control in Internal and Outsourced Systems Development Projects; Amrit Tiwana, Mark Keil

[4] Principal Agent Theory and its Application to Analyze Outsourcing of Software Development; Patrick Keil

A primeira dessas fases, de suma importancia para uma “software house” como a Sofshore, é a inception. Resumido, o objetivo dessa fase é acordar um escopo e validar a viabilidade economica do projeto.

“The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project.

• Establishing the project’s software scope
• Discriminating the critical use cases of the system
• Estimating the overall cost and schedule” [5]

Essa fase é absolutamente essencial para gerenciar as expectativas dos participantes do projeto. E em particular as expectativas dos participantes externos. Gerenciar, no caso, criando inclusive a certeza razoável que as expectativas serão atingidas.

Inception e Agile

Scrum ou XP simplesmente desconhecem essa fase. E com razão: no que diz estritamente  respeito ao desenvolvimento de software, não é necessária.

Por outro lado, agilistas renomeados defendem também o uso de uma etapa inicial. Alistrair Cockburn escreve:

“RUP starts with an “inception phase”, in which the sponsors and lead developers come to understand what problem they are trying to solve, how they intend to solve it, what a successful outcome might look like. They then start carving up the work into smaller pieces to design and deploy incrementally. All of that is good. Many Scrum teams (starting with even Scrum instructors) start by listing features and putting them on the backlog. That is not good.” [6]

“Software development projects (most projects, frankly) are “group cognition” exercises[..] meaning that everyone is busy trying to make sense of what is happening and what should be happening. “Where are we? Where should we be going? How should we get there?’” [6]

De fato, projetos tem quase sempre interessados “externos”. No caso de uma software house, esses interessados são até centrais: são so clientes usuários e donos do sistema a ser desenvolvido.

“Some people will say that this approach isn’t agile, that your stakeholders should by the only ones to prioritize requirements. Yes, I agree with that, but I also recognize that there are a wide range of stakeholders, including operations people and enterprise architects who are interested in the technical viability of your approach.” [3]

Para esclarecer, inception não é identico ao “Sprint 0″ as vezes usado. Peter Schuh define o “Scrum 0″ da seguinte forma:

“An iteration zero does not deliver any functionality to the customer. Instead, the project team focuses on the simple processes that will be required for the adoption and use of most agile practices. From a programming point of view the features delivered in an iteration zero may include:

• Source control system installed and operational
• [...]” [8]

“The process of pre-planning has been described in numerous books and articles about Scrum and agile. [..]

Inception e PMBOK

Apenas para completar, e embora usemos o PMBOK como referencia mais do que como norma, tem uma correspondencia muito boa entre a criação de um documento de visão e o “project chartering”:

“Develop project charter is the process of developing a document that formally authorizes a project or a phase and documenting initial requirements.

It [Project Charter] established a partnership between the performing organization and the requesting organization (or customer [..]).

Projects are authorized by someone external to the project such as a sponsor, [..].  Projects are initiated due to internal business needs or external influences. Chartering a project links the project to the strategy and ongoing work of the organization” [2]

——————–

Referências

[1] Scott Ambler, Mark Lins, “Disciplined Agile Delivery: An introduction”, 2011 - IBM

[2] “PMBOK Guide” 4th Edition, 2008 PMI – Project Management Institute

[3] Scott Ambler , ”Scaling Agile with Risk-Based Milestones”

[4] Jeff Anderson, “Looking at Why Agile Works Tells You How To Make It Scale“, 5/12/2011

[5] Rational Unified Process, Version 2002.05.00

[6] Alistrair Cockburn,  ”Using RUP to fix Scrum”

[7] Mike Cottmeyer, “Progressive Estimation and Tollgates“, 17/01/2009

[8] Peter Schuh, “Iteration 0“, 03/09/2008

[9] Yahoo Group “scrumdevelopment”, “Re: Sprint Zero“, 22/09/2008

A idéia por trás de processos híbridos é que ágil é bom, mas não é suficiente.

“However, mainstream agile methods don’t provide enough guidance for the typical enterprise. Mature implementations of agile recognize a basic need in enterprises for a level of rigor that core agile methods dismiss as not required, such as governance, architectural planning, and modeling.” [1]

Fases

A primeira “hibridação” importante que fizemos é o uso de fases. Reconhecemos que projetos passam por fases por vários motivos: governança, gestão dos riscos e evolução no tempo da natureza das operações conduzidas.

“The primary concern seems to be that phase implies a serial approach, something many agilists believe to be foul and evil.  Yet the reality is that projects do in fact proceed in a serial manner.  There are some project initiation activities at the start.  Then there are construction iterations/sprints one after the other in yes, a serial manner.  Then there is an effort to deploy/release your solution into production.  This is clearly “serial in the large”.” [5]

Governança

Primeiro, projetos precisam de governança. Projetos são geralmente desenvolvidos para atores externos, que precisam decidir, registrar decisões em artefatos que fazem sentido ao seu nivel. Projetos existem em um âmbito econômico que requer que sejam definidos e monitorados escopo, prazo e recursos.

A norma ISO 38500, referente à governança de TI e focada em principios para o uso eficiente e aceitavel de TI, diz:

“Expenditure on IT can represent a significant proportion of an organization’s expenditure of financial and human resources. However, a return on this investment is often not realized fully and the adverse effects on organizations can be significant.

The main reasons for these negative outcomes are the emphasis on the technical, financial and scheduling aspects of IT activities rather than emphasis on the whole business context of IT use.” [6]

Fases, milestones e artefatos servem assim de “adaptador” entre o mundo corporativo no qual se inserem os projetos e o processo de desenvolvimento, que precisa de uma iteratividade maior.

Como escreve o Scott Ambler:

“[..] explicit milestones [..] reduce project risk and increase external visibility of key issues to support appropriate governance activities by senior management.” [1]

“Holding these sorts of milestone reviews improves your IT governance efforts by giving senior management valuable visibility at the level that they actually need” [3]

O PMBOK descreve o mesmo principio, embora de jeito genérico:

“Project phases are divisions within a project where extra control is needed to effectively manage the completion of a major deliverable. [..] Regardless of the number of phases comprising a project, all phases have similar characteristics: [..] * The work has a distinct focus that differs from an other phase. This oten involves different organizations and different skill sets.” [2]

“The phase structure provides a formal basis for control. Each phase is formally initiated to specify what is allowed and expected for that phase. A management review is often held to reach a decision to start the activities of a phase. [..] A project phase is generally concluded and formally closed with the review of the deliverables to determine completeness and acceptance.” [2]

Usamos as fases do UP porque os 4 grandes “milestones” que ele define e em particular os dois primeiros respondem de jeito pragmático a duas perguntas essenciais: devemos construir esse sistema ? (inception) e somos capazes de construir esse sistema ? (elaboration).

Cadência

Vale ressaltar que a existencia de fases não implica que o processo seja organizado em cascata. Iterações podem existir (e existem) dentro das fases. E fases podem ser repetidas ao longo de um projeto. Além disso, ter uma validação formal do resultado de uma fase não dispensa de re-avaliar regularmente o cumprimento de objetivos durante o resto do projeto.

Jeff Anderson apresenta bem esse conceito:

“Stage gates are the familiar command-and-control waterfall tool of choice of to ensure high quality and stable delivery. Work cannot proceed until the entire batch is deemed to be of sufficient quality to proceed to the next stage. [..] The problem with stage gates is that they actually reduce the amount of quality reviews and inspection done for projects that really require it” [4]

“The answer to this is favoring cadence over a state gate approach. A cadence is a regularly occurring event, and is at the heart of the iterative model inherent to agile methodologies like scrum and extreme programming” [4]

Arquitetura

Outra grande razão de termos fases é a gestão dos riscos e a importância da arquitetura. Milestones no final das fases servem assim para verificar, antes de começar o “grosso” do desenvolvimento, que o escopo geral é bem definido e que o projeto está tecnicamente são.

Teremos a oportunidade de voltar nesses pontos nos próximos posts.

———————-

Referências

[1] “Disciplined Agile Delivery: An introduction”, 2011 Scott Ambler, Mark Lins – IBM Software

[2] “PMBOK Guide” 4th Edition, 2008 PMI – Project Management Institute

[3] “Scaling Agile with Risk-Based Milestones “, Scott Ambler

[4] “Looking at Why Agile Works Tells You How To Make It Scale“, Jeff Anderson, 5/12/2011

[5] “Why are there phases?”, Scott Ambler, Disciplined Agile Delivery, 8/2/2012

[6] ISO/IEC 38500 “Corporate governance of information technology”, 2008

Ao longo dos projetos temos construído um conjunto coerente de conhecimento baseado em nossa experiencia e em modelos reconhecidos pela profissão:

• Processos já existentes e bem definidos, Scrum e RUP (Rational Unified Process),
• Modelos de maturidade de processo, CMMI-DEV (Capacity Maturity Model Integration for Development) e MPS.br (Melhoria de Processo do Software Brasileiro)
• O padrão internacional em gerencia de projeto, o PMBOK (Project Management Body of Knowledge)

Temos definido assim um processo próprio, “Scrup” (Scrum + RUP), visando ser ágil, centrado na arquitetura e maduro.

Ágil porque reconhecemos a importancia e o valor dos principios do manifesto ágil. Trabalhamos para criar software de valor para os clientes, gerenciar as mudanças, melhorar a comunicação e atingirmos a excelencia técnica.

Centrado na arquitetura porque a arquiitetura de um sistema é a pedra angular do seu sucesso. Por menor que seja o projeto, por melhor que seja o processo, não há sucesso sem uma arquitetura bem definida.

Maduro no sentido dos modelos citados acima. Pretendemos satisfazer minimamente os critérios definidos por esses modelos tal como o GPR13 do MPS.br “O escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado”.

Nos próximos posts apresentaremos esse processo em mais detalhes:

• Como priorizamos a arquitetura (que é implicita no Scrum, embora apareça nos principios ágeis)
• A implicação no processo de ter fases além de iterações (sprints, para usar a terminologia do Scrum).
• Quais elementos (artefatos, workflows) selecionamos nos dois processos de base para satisfazer os critérios do MPS.br
• Como articulamos sprints, fases e artefatos com o resto da organização (clientes externos e internos) com interfaces claras.

Um investimento muito pesado para pequenas empresas. E ainda para ter um sistema básico, com funcionalidades limitadas.

Em compensação, e parece ser pouco conhecido, o software livre pode ser uma solução. Quando se fala em software livre, a primeira características mencionada é sempre a ausencia de custo de licenciamento. Mas não devemos esquecer que a principal característica de software livre é de poder ser modificado e extendido. Assim, entre outras modalidades de uso, softwares livres podem ser usados como base para sistemas customizados. Partindo de um sistema próximo do necessário basta integrar, acrescentar ou até remover funcionalidades, sem ter que desenvolver o sistema completo.

Um bom exemplo disso é o softphone para Android que a Hellou disponibilizou para os seus clientes no Android Market. A Hellou precisava de um sistema  com algumas funcionalidades bem específicas, tais como um assistente de configuração próprio. O desenvolvimento “from scratch” de tal sistema teria sido inviavel. Mas, usando um produto já existente com propriedades próximas ao necessário, um mês foi suficiente para adaptar às necessidades específicas do cliente.

Por fim devemos mencionar que existem alguns pre-requisitos para esta solução ser viavel. A existencia de um software livre de qualidade para ser usado como base é a mais óbvia. Outro ponto importante é que modificar um sistema é sempre mais difícil do que criar um novo. Como sempre em software, ter um parceiro de muita experiencia é uma condição sine qua non.

Pressionada pela concorrencia, precisando aumentar sua produtividade e buscando diferenciais, nenhuma empresa, pequena ou grande, vive sem software.

Contudo, muitos empresários e executivos ainda não realizaram a profundidade e a amplitude desse fenômeno. Profundidade porque não se trata mais da importância de apenas usar sistemas tais como ERPs e sim danecessidade de oferecer serviços baseados em software, das empresas integrarem sistemas até se tornarem eventualmente empresas de TI. E Amplitude porque esse movimento atinge todas as empresas, tanto as PMEs quanto as grandes.

Duas matérias recentes, “Now Every Company Is A Software Company” [1] e “Why Software Is Eating The World” [2] ilustram bem essa evolução:

My own theory is that we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy. [..] More and more major businesses and industries are being run on software and delivered as online services [2]

Today, the world’s largest bookseller, Amazon, is a software company .. Today’s dominant music companies are software companies, too: Apple’s iTunes, Spotify and Pandora .. Disney— Disney!—had to buy Pixar, a software company, to remain relevant in animated movies [..] Software is also eating much of the value chain of industries that are widely viewed as primarily existing in the physical world. In today’s cars, software runs the engines, controls safety features, entertains passengers, guides drivers to destinations and connects each car to mobile, satellite and GPS networks [2]

Regardless of industry  your company is now a software company, and pretending that it’s not spells serious peril [1]

Não é apenas uma visão macro-economica das têndencias a longo prazo. Podemos citar dois exemplos de clientes do segundo semestre da Sofshore. 

Uma agencia de turismo de São Paulo precisou integrar seus sistemas com grandes provedores internacionais para ampliar a oferta de serviços no seu site.  Substituindo atendentes por sistemas técnicamente complexos, está de fato se tornando uma empresa de TI.

Uma assessoria imobiliária acompanhando o processo de venda de imoveis, pela sua posição central entre os atores (construtoras, bancos e compradores) é na prática um “hub” agregando serviços a fluxos de dados. Nesse caso também, oferecendo serviços baseados em software próprios, essa assessoria pode vir a se tornar uma empresa de TI automatizando e integrando seus sistemas com outras partes.

Forçando apenas um pouco: sua empresa também é uma empresa de TI, você apenas ainda não realizou. Na hora das retrospectivas e projetos para o próximo ano, é importante o administrador de empresa refletir a respeito dessa nova realidade. 

Integrar a TI na estratégia da empresa é claramente, um desafio para empresas pequenas e medias.  Em geral PMEs não tem CIO dedicado e essa função cabe ao administrador da empresa, que tem muitas outras responsabilidades e prioridades. 

Uma resposta possivel a esse desafio é contratar um parceiro tecnológico. Porém, essa contratação pode ser apenas deslocar o problema – se não criar um problema adicional. 

Mas esse será o assunto do nosso próximo post

Mas o blog da Sofshore esta de volta