Tendências de evolução aplicadas a TI

by arlima on 2 de maio de 2010

Altshuller e os pesquisadores da inovação sistemática, depois de estudarem milhões de patentes, conseguiram descobrir certas “regras” de evolução de sistemas técnicos. Como é isso ? Pegue uma patente e pergunte “quem deu origem a ela” e “a quem ela deu origem”. Depois procure padrões de evolução na respostas.

Estas 37 tendências nos permitem fazer “previsões” sobre o destino de qualquer sistema técnico.

Um exemplo de tendência simples de entender se chama “Redução do envolvimento humano”. Em milhares de sistemas alguma coisa começa a ser feita totalmente por um humano. Na sequência é feita por um humano + ferramenta, depois por um humano + ferramenta semi automatizada, depois por um humano + ferramenta automatizada e depois o humano deixa de fazer parte do processo. Fica somente a ferramenta automatizada.

Podemos ver isso acontecendo em sistemas de transporte. No começo era uma pessoa carregando outra, depois um condutor +  carruagem, depois um condutor + trem e agora, em alguns metrôs, por exemplo, somente o trem, sem maquinista. O homem sumiu do sistema.

Outro trend muito interessante se chama “Segmentação do objeto”. Neste caso vou começar com um exemplo: No início os teclados eram monolíticos. Depois apareceram teclados dobráveis, depois flexíveis (aqueles de silicone), agora temos teclados projetados a laser nas mesas ou telas (como no ipad) e em breve não teremos mais teclado pois vamos interagir com o computador por voz ou ondas cerebrais.

Bom, mas o que isso tem a ver com Tecnologia da Informação (além do exemplo do teclado) ? O primeiro exemplo de trend que mostrei neste post aponta um caminho ruim para os profissionais da área. Em breve eles não serão mais necessários na operação nos sistemas (apesar de ainda serem necessários na criação dos mesmos – por algum tempo). Estamos falando de self-healing, self-building, etc. Sistemas que se autocontroem, autoconsertam, automantem. Vemos isso acontecendo já em bancos de dados por exemplo. A profissão de DBA vai acabar em breve. O mesmo para administradores de servidores, desenvolvedores de software, etc…

Já com a segmentação de objetos podemos ver claramente uma migração de todos os “computadores” para a nuvem (campo). A computação em nuvem é uma coisa totalmente esperada e compreensível. Vão desaparecer totalmente todos objetos identificáveis em TI. Veja só. Eram mainframes, depois terminais, depois computadores isolados, depois em rede, depois “virtualizados” e depois “nuvem” – a noção de servidor desaparece.

Inovação sistemática é isso. Além de resolver problemas no presente, também mostra um pouco como vai ser o futuro. E olha que não sou eu falando. São mais de 3 milhões de patentes.

No meu próximo livro vou analisar mais trends e mostrar o que mais podemos antecipar.

Be Sociable, Share!

Tagged as: evolução, Inovação sistemática, tecnologia da informação, tendências

  • Rafael de Souza

    A tendência em TI faz todo o sentido, mas não entendo que profissões como DBA vão acabar. Acredito que cada DBA vai cuidar de mais bancos de dados (pois boa parte das tarefas serão automatizadas); entretanto ele terá de ser mais capacitado (pois precisará trabalhar com ferramentas cada vez mais complexas).

    Voltando ao exemplo das ferramentas: os primeiros operadores de máquinas encaixavam a peça e apertavam um botão. Hoje os "operadores" em uma linha supervisionam a produção e atuam em caso de erros, mas agora esses caras são engenheiros e não apenas operadores.

    • http://www.arlima.com.br arlima

      Olá Rafael. No limite, os sistemas (bancos de dados, etc) farão tudo sozinhos. As tendências de evolução não dizem quando, mas acredito que vai acontecer… Mas, certamente, surgirão novas necessidades … Como você falou, serão necessários administradores/engenheiros em algum outro patamar de abstração.

  • http://nervinformatica.com.br Ricardo Portilho Pro

    Grande Adriano !

    Além de ser seu fá desde o quiosque da Ambev, sou (de certa forma) DBA hoje, e concordo com você que esta profissão irá acabar em breve. Assim como aconteceu com o sysadmin, que era elite e tornou-se commodity.

    O DBA que aumenta DATAFILEs, ou verifica coleta de estatísticas de tabelas e planos de execução de comandos SQLs já acabou nas versões de RDBMSs atuais, mas alguns DBAs não perceberam.

    Já os DBAs (aí é preferível Arquiteto de Dados) que migram de banco W para X, atualizam de versão Y para X, implanta o aplicativo N corretamente para determinada indústria, continuará existindo.

    Os profissionais sem extrema especialização serão absorvidos pelo submercado das grandes empresas administradoras da nuvem.

    Parabéns pelos Posts, leio todos.

    Abraço !

    • http://www.arlima.com.br arlima

      É isso aí Portilho. Ao que parece você se tornou um dos maiores Arquitetos de Dados Oracle do Brasil (ou do mundo ?) e tem moral para falar do assunto. Abraço

  • Rodrigo Fernandes

    Oi Adriano,

    Em primeiro lugar, parabéns pelo blog, ele já está entre os poucos que eu acompanho diariamente.

    Bem, já nos tempos de graduação, há mais de 10 anos, eu me lembro de discutir com colegas a respeito da possibilidade de que o desenvolvimento de software se tornasse uma espécie de Lego e que os especialistas na nossa área se tornassem menos necessários.

    Hoje eu vejo que em certo aspecto isso se realizou. Ex.: hoje é possível desenvolver um aplicativo e rodá-lo na cloud do Google ou do Salesforce e ter uma infra-estrutura de classe mundial completamente abstraída e barata.

    Por outro lado, o trabalho do desenvolvedor de software se tornou muito mais complexo. Tomando um horizonte de tempo mais longo, um bom desenvolvedor Java/.Net/etc precisa ter uma formação bem mais sólida que um programador da época do Cobol. O programador hoje tem mais "poder", ele pode fazer muito mais do que antes – mas eu não diria que em termos de programação, a vida tenha ficado muito mais fácil do que era antes.

    Agora a minha pergunta… :)

    Recentemente fazendo uma pesquisa com os meus clientes usando a metodologia Outcome Driven Innovation (vocês a usam no livro, certo?), eu vi claramente que as métricas que eu preciso cuidar mais estão mais relacionadas à análise e especificação do software do que ao desenvolvimento do sistema em si. Algo na linha, "o software vocês desenvolvem de forma satisfatória, mas acho que poderiam se envolver mais na elaboração do sistema". Veja que a questão não é o velho "você precisa entender o meu negócio", é mais "eu tenho um problema, gostaria que você me ajudasse mais a criar a solução para ele e não apenas levantar os requisitos da solução que eu tenho em mente – e que pode não ser a melhor".

    Na linha do seu artigo e dos meus comentários, você acredita que o futuro do negócio de desenvolvimento de software estará muito mais na elaboração de uma boa solução – que efetivamente resolve o problema que o cliente tem – do que na competência de desenvolvimento de software propriamente dito?

    um abraço,

    Rodrigo Fernandes

    • http://www.arlima.com.br arlima

      Olá Rodrigo. Obrigado pelos elogios.

      O acredito no seguinte:
      - Deve ser possível estratificar os programadores tal que 20% deles dão 80% dos resultados (Pareto). Ou seja, bons programadores ainda causam um grande impacto no desenvolvimento de sistemas. Por isso nossa dificuldade em imaginarmos que eles vão sumir.
      - A função de programador vai sim sumir com o tempo (assim como diversas outras funções operacionais sumiram).
      - Cada vez mais vai surgir a função de "designer de soluções". Pessoas que sabem pegar peças (os legos dos seus exemplos) e conectá-las para atender a necessidades de negócio (tarefas e medidas).

      Ou seja, o futuro me parece estar mais na criação de boas soluções e não no desenvolvimento de software como conhecemos hoje.

      Sobre o ODI, sou fã. Modificamos um pouco para encaixar no framework do Innovatrix, mas a base é a do Anthony.

      Abraço
      Adriano

  • http://www.aboutfamouspeople.info Michael

    Recentemente fazendo uma pesquisa com os meus clientes usando a metodologia Outcome Driven Innovation (vocês a usam no livro, certo?), eu vi claramente que as métricas que eu preciso cuidar mais estão mais relacionadas à análise e especificação do software do que ao desenvolvimento do sistema em si. Algo na linha, “o software vocês desenvolvem de forma satisfatória, mas acho que poderiam se envolver mais na elaboração do sistema”. Veja que a questão não é o velho “você precisa entender o meu negócio”, é mais “eu tenho um problema, gostaria que você me ajudasse mais a criar a solução para ele e não apenas levantar os requisitos da solução que eu tenho em mente – e que pode não ser a melhor”.
    +1

  • Rodrigo

    Adriano,

    Você concorda que o JTBD de uma empresa de software é automatizar processos de negócio?

    um abraço,

    Rodrigo

    • http://www.arlima.com.br arlima

      Olá Rodrigo. Quem tem JTBD é sempre o cliente. A empresa tem como função atender ao JTBD. Em um artigo bem legal do Christensen ele diz que o JTBD primário de qualquer empresa é gerar valor. Desta forma, a função da empresa de software deve ser ajudar o cliente a gerar valor utilizando software. Perceba que não estou falando em automatizar tudo, ou substituir tudo por software (pois muitas vezes isto pode destruir valor).
      Abraço !
      Adriano

  • Pingback: Tendências de evolução aplicadas a TI

Previous post:

Next post: