CIO Codex E-book
Uma introdução clara ao CIO Codex Framework, com os pilares essenciais para transformar TI em valor. Ideal para ter a visão geral do framework.
Nessa matéria da CIO Online algumas boas dicas quando da parceria com startups:
https://www.cio.com/article/412993/5-pitfalls-to-avoid-when-partnering-with-startups.html
Acredito que esse tipo de parceria será cada dia mais natural daqui para frente!
Confesso que nunca trabalhei para uma startup (então não tenho o profundo conhecimento de como é essa cultura no dia a dia sob a perspectiva interna), mas ao longo dos últimos anos atuei ao lado de algumas sob a ótica de parceria, algo que permite capturar insights muito interessantes de como pensam e operam.
E inegavelmente existem diferenças "filosóficas" significativas, quando se compara com empresas grandes, tradicionais (com "porte" e já estabelecidas).
E acho que essas diferenças acabam sendo naturais pela própria concepção de cada qual:
Empresas tradicionais
- Possuem um "legado" já estabelecidos.
- Expectativas quanto aos seus resultados mais claras e rigidamente governadas pelo mercado e shareholders.
- Limitação (de certa forma) do apetite ao risco e a predisposição a tentativa e falha.
- Em geral atuam em mercado já estabelecidos e regulados, o que impõe ainda mais limitantes.
Startups
- Em sua grande maioria nascem com a visão de tentar e eventualmente falhar o mais rapidamente possível (e assim tentar novamente o quanto antes).
- Buscam aumentar rapidamente sua base de clientes apostando no potencial de monetização futura (por vezes não se preocupando com o resultado/eficiência operacional no curto prazo).
- De largada o mercado e shareholders possuem expectativas e rigidez mais brandas quanto ao resultado de curto prazo.
- Atuam em um outro patamar (bem mais alto) de apetite ao risco, afinal, em muitos casos o propósito delas é explorar oportunidades que são um risco por si só.
- Atuam muitas vezes em nichos de mercado, se valendo de brechas da regulação ou mesmo funcionando como "agentes" dos próprios reguladores que as tratam como um mecanismo de aumento da competitividade do mercado.
Quando se considera as mudanças no mercado, com a redução da liquidez e do capital barato, entendo que as expectativas de resultados positivo se tornam cada vez mais antecipadas, assim como deve se reduzir em alguma escala a predisposição ao risco de falhar, o que deve então reduzir o gap cultural/conceitual entre empresas tradicionais e startups.
Como desenvolver uma cultura de DevSecOps?
Esse é o tipo de conceito que não tem mais volta em IT: acho impossível pensar em evoluir na qualidade e produtividade dos times sem avançar na prática do DevSecOps!
Obviamente que DevSecOps sozinho não faz milagre, ele anda em conjunto com outras práticas, como SRE, ITOps como um todo, FinOps, além do mais novo da turma, o AIOps.
Pelo menos eu creio que seja o caçula – ao menos que já tenha surgido uma nova tendência depois dessa.
Mas de qualquer forma, deixo aqui um ponto adicional que costumo comentar com frequência: é curioso que dentro do contexto de transformação digital, foi visível o avanço da adoção de Agile no mercado como um todo, ao mesmo tempo que o DevSecOps não teve o mesmo nível de avanço de adoção.
Já escutei diversas "teorias" distintas tentando explicar esse "fenômeno".
Aqui um artigo muito bom da Red Hat abordando esse tema dentro do contexto atual das empresas:
https://enterprisersproject.com/article/2022/11/how-establish-devops-culture
Me recordo de ter visto muitas análises de mercado indicando os rumos esperados para a indústria de tecnologia como um todo, o que inclui sempre aspectos do mercado de Cloud.
Dentre os muitos tópicos, um que passou a se mostrar cada vez mais presente foi o de especialização das plataformas de cloud por indústria dos seus cliente.
E não é que a tendência de "especialização das Clouds por indústria" é real?
Até agora tinha visto a oferta da IBM e não sabia que a MS também tinha a dela.
Até que vi esse artigo da própria Microsoft comentando sobre essa iniciativa deles:
https://learn.microsoft.com/en-us/industry/financial-services/overview
Embora vale salientar que cada vendor parece ter seguido por caminhos bem distintos nas suas proposições.
A IBM me parece ter criado mecanismos específicos para algumas necessidades mais específicas das instituições financeiras, com destaque para segurança (creio que mais na linha de diferenciação em IaaS e PaaS).
Já a MS, pela lista aqui, seguiu na linha de empacotar especializações de caráter mais "funcional" do que ela já tinha como oferta SaaS "financial services".
Admiro e acredito que seja basicamente inevitável o progresso e a realização pessoal de todos que se propõem a fazer esse esforço extra!
E eu acho muito curiosa a dicotomia cada vez maior nisso:
- Por um lado, as oportunidades de aprendizado são cada dia mais acessíveis, afinal, não falta informação e formação gratuita e de qualidade espalhada pela Internet ao alcance de todos.
- Ao mesmo tempo, apesar de estar facilmente acessível, continua demandando o investimento de algo cada dia mais valioso (pois é um recurso cada dia mais escasso): o tempo e a atenção das pessoas.
Aprender de verdade exige dedicação!
Seria tudo muito mais fácil se pudéssemos aprender as coisas na mesma velocidade com que encontramos e baixamos materiais na Internet, bem no estilo Matrix, para aqueles que se lembram desse filme.
Mas acho que se tudo fosse tão fácil, se não existisse o fator empenho pessoal, muito da vida perderia o sentido, pois haveria menos mérito e incentivos para aqueles que se dedicam a aprender e a buscar a excelência naquilo que amam fazer.
Movimentação bem interessante do mercado, em mais um avanço do WhatsApp para se tornar cada dia mais relevante para os usuários.
Mais detalhes nessa matéria da StartSe:
https://www.startse.com/artigos/pedir-uber-pelo-whatsapp/
Racional do Uber: "é um passo em busca do comportamento do usuário"
Nos últimos anos acho que já vimos diversas indústrias distintas oferecendo serviços e adotando o WhatsApp como peça fundamental da sua estratégia de canais digitais.
Parece que o Uber é mais uma das indústrias, depois do banking, insurance, retail e tantas outras.
Enquanto banking, lembro de ter visto muitas preocupações com o WhatsApp quanto a ser comoditizado/intermediado ou mesmo perder o controle direto da usabilidade e do canal de interação direta com o cliente em si (questões que tem lá o seu fundamento e merecem ser devidamente avaliadas por cada organização).
Mas por outro lado: o apelo, a facilidade e alcance (creio que único) de BILHÕES de usuários que fazem uso diário e intensivo do WhatsApp no seu dia a dia, simplesmente não tem como ser ignorado (e o Uber é mais um exemplo disso)!
Cada dia mais artigos, das mais diversas fontes, falando sobre o "crise" da Cloud, a partir de números que mostram uma eventual desaceleração do crescimento desse mercado.
De qualquer forma, olhando tendências de mercado, acho que ainda não chegamos no momento da maturação, muito menos saturação do mercado.
Na verdade vejo o mercado crescendo, ainda que não com a mesma pujança de antes, mas ainda assim com um crescimento que parece ser bastante saudável.
Fora isso, ainda tem muito a ser inventado, muitos serviços serem comoditizados, padrões a serem compatibilizados, além das discussões geopolíticas de sovereign cloud" a serem melhor regulamentadas.
Aqui uma matéria muito rica da McKinsey sobre estratégias e alternativas para mitigar os riscos de escalada dos custos com Cloud:
De qualquer forma, sob a ótica estruturada de custos, dos 5 pontos dessa matéria da McKinsey, acho que o melhor conhecido, mas ao mesmo tempo mais complexo em ser alcançado (ao menos para quem vem de plataformas legadas pré-existentes), é o 3, que fala da elasticidade.
Adequar plataformas de forma que elas possam passar a fazer uso desse benefício da cloud definitivamente não é trivial!
Como bem dizia o famoso Deming: "o que não se mede não se gerencia".
Ou seja, para que haja uma gestão efetiva, se mostra absolutamente essencial que existam indicadores suficientes para que seja possível interpretar qual a direção, sentido e velocidade com que a organização está operando.
Isso vale para a organização como um todo, mas também para cada área da mesma, o que inclui a Tecnologia.
Sou um ardoroso defensor da governança e da gestão baseada em dados, mas não como um mero mecanismo para controle, mas sim um mecanismo para impulsionar o IT Transformation.
Em um mundo cada vez mais ágil e digital, a IT precisa igualmente da sua transformação.
E a transformação de IT não é apenas "técnica", mas também no seu modelo operacional, tudo isso guiado por indicadores e métricas diretamente relacionados com os objetivos do business!
Dentro desse contexto, achei esse webinar do Gartner muito interessante:
https://webinar.gartner.com/434249/agenda/session/1025037
Vale a pena assistir e considerar as ideias de indicadores a serem considerados dentro de uma visão executiva.
Qual o supercomputador mais potente em operação hoje:
Segundo essa matéria da DigitalWorld é um americano:
Tive a curiosidade de procurar na Internet qual a diferença de poder de processamento entre um Super Computador e um Mainframe.
Não encontrei muitas tabelas comparativas, pelo nada na linha do que encontramos facilmente de benchmarks de processadores Intel, AMD ou ARM.
O mais próximo disso que achei foi em um site falando que um Mainframe chega até 100 MIPS e um Super Computador chega até 900 MIPS (presumo que sejam MIPS por segundo).
Se for mesmo nessa linha, em que um Super Computador processa algo na casa de 10x mais do que um Mainframe top de linha, dá então para se ter uma noção de se trata de MUITO poder de processamento, afinal um Mainframe roda um banco grande, o que permite atender algumas dezenas de milhões de clientes e processos internos.
Então me parece inevitável perguntar: o que tanto essas organizações que operam esses Super Computadores monstruosos processam de tão pesado o dia todo?
O primeiro da lista, por exemplo, com mais do que o dobro do poder de processamento do segundo colocado. O que o Departamento de Energia dos Estados Unidos processa nele a ponto de demandar tamanho poder?
Para tentar dar uma ordem de grandeza, fazendo uma conta de padeiro os, 1,1 ExaFlops dele equivalem a cerca de 100.000 Consoles XBox One X (12 TeraFlops cada). Imagina isso rodando todo o dia, quanto cálculo é possível fazer!
Excelente matéria da CIO Online sobre Enterprise Architecture:
Aqui está uma disciplina que considero fundamental para se garantir a estabilidade de IT e seus ativos no médio e longo prazo.
Enterprise Architecture não pode ser colocada em segundo plano!
Acho muito interessante o desafio que EA em se manter relevante e presente nos processos de IT e das organizações como um todo, especialmente com toda a movimentação do mercado de uma visão water/iterfall para o Agile.
Pela própria natureza do waterfall, encaixar a disciplina de EA nas etapas de desenho e os check-points ao longo do desenvolvimento e testes era algo bem natural e basicamente não havia discussão a esse respeito.
Já quando veio o Agile, acho que (ao menos por um tempo) foi como se os times encararam (erroneamente) que o processo de desenvolvimento passou a ser livre e os times/squads eram independentes, ou "autogeridos".
E em muitos casos essa independência e autogestão foi interpretada como uma desconexão com a estratégia de arquitetura de IT.
Mas como tudo no mundo, o pêndulo da história parece estar se estabilizando, e a cada dia fica mais claro que não é prudente deixar o visioning da saúde arquitetônica de sistemas críticos (e para os quais se espera uma vida útil longa) sob a gestão exclusiva das squads, as quais usualmente possuem um horizonte de análise e preocupação de algumas poucas sprint (curto prazo).
Tem alguns vídeos do Tom Gilb onde ele fala sobre isso de uma forma super clara. Vale procurar no YouTube.
Mais uma vez sobre o tema de automação, aqui uma matéria da Gartner com alguns insights legais, embora me parecem mais na linha do "simple automation" e não o "intelligent automation":
https://www.gartner.com/en/articles/10-automation-mistakes-to-avoid
Destaco 4 que me parecem as mais relevantes:
02 – Automatização sem participação (ou orientação) de IT: as automatizações geral algo muito parecido com SW e merece os mesmos cuidados de visão arquitetônica, evolução e sustentação, sendo assim, acho que nada mais prudente do que garantir os cuidados adequados ao longo de todo ciclo de vida.
05 – Não testar adequadamente: na mesma linha do item acima, SW não testado adequadamente tem potencial para trazer consequências terríveis (e em alta escala) então, é importante manter o mesmo rigor aqui.
07 – Automatizar ipsis lipsis: em primeiro lugar, ao se automatizar já surge o desafio de efetivamente entender o que de fato é feito por quem e seguindo quais regras. Dado que essa análise se faz necessária, por que não aproveitar e rever a eficiência do processo em si?
10 – Não dar atenção à gestão de mudança: aqui acho que a questão se mostra ainda mais crítica do que quando na implementação de SW tradicional, pois automatizar em geral significa eliminar tarefas manuais originalmente efetuadas por pessoas. Pessoas merecem atenção, orientação e oportunidades!
