Categorytecnologia

O que faz com que bons líderes sejam excelentes?

Li esse artigo e achei bem interessante compartilhar…

Por Stephen Orban, Head of Enterprise Strategy (link Original)

“É a falta de clareza que gera caos e frustração. Essas emoções são um veneno para qualquer objetivo existente”. –
Steve Maraboli

Líderes lideram de muitas maneiras diferentes. Alguns pelo medo, outros pelo exemplo, pelo carisma ou por meio de outras pessoas. E embora cada o estilo de cada líder seja um pouco diferente, a experiência me ensinou que algo nunca muda: é mais provável que as pessoas sigam alguém que elas compreendem.

As pessoas acreditam naquilo que são capazes de compreender. Quando se trata de gerenciamento de mudanças, as pessoas tipicamente se voltam para aquilo que estão acostumadas ( o status quo ) quando não’ entendem a direção na qual estão sendo orientadas. Os líderes podem resolver esse dilema fornecendo direções claras e concisas. A habilidade de fornecer clareza quanto aos objetivos é o que separa os grandes líderes dos bons.

Recentemente, escrevi que os executivos de tecnologia de hoje devem considerar-se diretores de gerenciamento de alterações (CCMOTM) ao liderarem a jornada para a nuvem em suas organizações. Além de gerenciar a fusão entre os negócios e a tecnologia, o CCMO também é responsável por fornecer clareza quanto aos objetivos. Isso significa ser capaz de articular a sua estratégia, saber como a sua equipe se encaixa nessa estratégia, onde há e onde não há flexibilidade, manter-se determinado e manter-se paciente.

As organizações migram para a nuvem por diferentes motivos : para economizar dinheiro, expandir globalmente, aprimorar a postura quanto à segurança ou ainda para melhorar a agilidade. Em minha experiência,descobri que as empresas começam a adotar a nuvem como uma plataforma em toda a organização ao perceber como ela os ajuda a dedicar mais recursos ao que importa aos negócios. Essas atividades são as que mais importam para os seus clientes e partes interessadas. E, a menos que você seja um provedor de infraestrutura, essas atividades não estão relacionadas ao gerenciamento de infraestrutura.

Sejam quais forem as suas motivações a curto ou longo prazo, recomendo que você as comunique e faça com que elas sejam mensuráveis. Articule suas motivações e objetivos claramente junto à sua equipe e às partes interessadas e faça com que todos sejam responsáveis por mover a agulha na direção certa.

No início do meu cargo de liderança, eu pensava – ingenuamente – que só porque eu era o chefe todos fariam o que eu dissesse. Eu aprendi da maneira difícil que, é claro, não é assim que a liderança funciona. Foi quando eu comecei a articular claramente o que era importante sobre a nossa estratégia que o comportamento da minha equipe começou a mudar. Antes de apresentar uma nova ideia ou objetivo à minha
equipe, eu tinha que considerar como todos se enquadravam na estratégia e como ela se relacionava aos negócios e à carreira de cada um. Em seguida, tinha que aproveitar todas as oportunidades para reforçar esses pontos.

Isso significava falar da estratégia em reuniões trimestrais, em blogs internos, durante sessões de planejamento de sprints e usar cada reunião como uma oportunidade de relacionar o trabalho que estava sendo discutido com a nossa estratégia. Às vezes parecia redundante, mas quanto maior a sua equipe, menor a probabilidade de que cada indivíduo tenha a oportunidade de ouvi-lo regularmente. Manter-se determinado e ser consistente com a sua comunicação é fundamental.

O medo do desconhecido é um dos pontos de atrito mais comuns em qualquer programa de gerenciamento de mudanças. Falarei sobre esse tema em um próximo post, onde abordarei a melhor prática “Educar a equipe” da jornada para a nuvem. Vale mencionar nesse contexto que uma excelente maneira como os líderes podem resolver esse atrito é fornecer clareza a todos na equipe sobre o que acontecerá com suas funções.

Deixar claro quais são as opções de cada um à luz da mudança de direção dará a eles um caminho claro para compreender como podem participar e, provavelmente, alguma tranquilidade. Quando eu era o CIO na Dow Jones, fornecemos treinamento a todos no departamento e também a oportunidade de migrar para novas funções na empresa. Deixamos claro que queríamos que todos fizessem parte da jornada, e às
vezes isso significava que eles precisariam assumir uma nova posição. Era do interesse de todos aproveitar a riqueza de conhecimento institucional que eles possuíam e, em muitos casos, esse conhecimento tornou-se ainda mais valioso quando direcionado a uma área ou disciplina diferente. É difícil substituir esse conhecimento, e eu diria que você deve esforçar-se ao máximo para mantê-lo.

Em praticamente qualquer estratégia que envolva mudanças, haverá alguns elementos ao quais você precisará ater-se firmemente e outros que podem ser mais sugestivos. Deixar claro para a sua equipe quais pertencem a cada grupo dá a todos a oportunidade de continuar ampliando os limites nas áreas adequadas e mostra que a organização ainda está disposta a aprender.

Na Dow Jones, tornamos a automação um requisito rígido para tudo o que fizemos no início da nossa jornada. Depois de tornar-nos suficientemente qualificados com nossas operações na nuvem, pudemos fazer casos de negócios financeiramente atrativos para migrar dezenas de datacenters para a AWS. Nesse momento, uma estratégia “levantar e mudar” era mais adequada para mover-nos na direção desses objetivos. Isso exigia alguma clareza quanto aos objetivos – tínhamos que comunicar isso várias vezes – para funcionar, mas uma vez que afrouxamos a restrição em relação à automação e aplicamos uma variedade de técnicas de migração, nosso progresso acelerou substancialmente.

A jornada para a nuvem de toda empresa vai encontrar alguns obstáculos no caminho. Gostaria de poder dizer que tudo vai ser perfeito e que o setor já descobriu como prescrever o que cada empresa deve fazer em cada
etapa. Na AWS, temos o compromisso de tornar-nos mais prescritivos com base no que vemos funcionar para os nossos clientes; porém, é improvável que todo o processo chegue a ter uma solução totalmente pronta. Descobri que é melhor tratar os obstáculos que você encontra no caminho como oportunidades de aprendizado, não castigar sua equipe por cometer erros (embora você não deva aceitar o mesmo erro duas vezes) e abordar prontamente ceticismo que vai contra o seu objetivo. Não deixe aqueles que estariam mais confortáveis permanecendo no status quo influenciarem o potencial da sua visão. Isso nem sempre é fácil, mas a sua paciência e perseverança serão compensadas.

Lembre-se, a prática faz a permanência. O que funcionou para você? Eu adoraria saber mais sobre isso.

Continue criando,
Stephen
@stephenorban

http://aws.amazon.com/enterprise/

Nota: oferecer suporte executivo é a primeira das sete melhores práticas sobre as quais estou escrevendo em minha nova série Jornada da nuvem corporativa. As outras seis são:informar a equipe, criar uma cultura de experimentação, atrair parceiros, criar um centro de excelência, implementar uma arquitetura híbrida e implementar uma política que prioriza a nuvem. Fique ligado para saber mais sobre estes assuntos.

How do you add swap to an EC2 instance?

When running an ec2 micro instance and you’ve been finding that the instance occasionally runs out of memory,  then you fix this problem adding swap or paging space to the instance.

Paging works by creating an area on your hard drive and using it for extra memory, this memory is much slower than normal memory, however much more of it is available.

To add this extra space to your instance you type:

If you need more than 1024 then change that to something higher.

To enable it by default after reboot, add this line to /etc/fstab:

Importando um certificado SSL

Você pode adquirir um Certificado SSL de uma certificadora como Verisign, Thawte, etc. Essas empresas oferecem excelentes documentações e instruções sobre como instalar o certificado em seu website.

Abaixo eu incluí um screenshot do processo de instalação do certificado no arquivo keystore.

Atenção! Podemos ter uma importação pura e simples de um certificado, onde somente a chave pública é enviada ao servidor; no exemplo abaixo, procedimento para a importação de um certificado emitido pelo SERASA:

Será requisitado que você entre com uma password… essa password será a chave privada da keystore; ele só servirá para abrir o certificado do SERASA (serasa.jks), onde contém a chave publica.

Após a password, ele mostrará qual chain root foi importada…

Observe que para finalizar, ele pergunta “Trust this certificate?”, responda “yes”.

Agora vamos listar a chave importada, ver se ficou legal (use a password usada acima).

Pronto, agora você tem uma Java Key Store para usar com seus certificados, enjoy!

Mark Shuttleworth quer dar um fim na ACPI na próxima geração de hardware

A ACPI é uma herança do final do século XX, quando chegou para suceder padrões mais limitados, como o APM, ou mais complicados de fazer funcionar (especialmente no Linux), como a especificação Plug and Play BIOS. Com a ACPI, passou a ser possível definir interfaces gerais (independentes de plataforma) para acesso a itens do sistema como a enumeração e configuração de hardware, o gerenciamento de energia (que antes ficava por conta do BIOS, e não do sistema operacional) e o monitoramento.

Mas Mark Shuttleworth, o fundador da Canonical, publicou sua preocupação com o fato de que – além de muitas vezes terem qualidade de software duvidosa – os firmwares dos fabricantes para suportar a ACPI podem, voluntariamente ou não, servir como vetor de ataque “invisível” à privacidade dos usuários, pela NSA e entidades assemelhadas.

A solução que ele aventa não é nada simples: convencer os fabricantes de hardware a disponibilizarem os drivers para suas inovações sempre na forma de código open source para uso no Linux, e mudar o padrão do firmware para um modelo declarativo, puramente descritivo, sem execução de código. (via lwn.net – “Shuttleworth: ACPI, firmware and your security [LWN.net]”)

Afinal, o que é o Modelo Canônico?

Antes de mais nada, Modelo Canônico é uma questão de semântica. Em se falando de SOA, o Modelo Canônico tem se tornado uma grande fonte de dúvidas e confusões. Na realidade, a solução SOA precisa incluir um amplo interesse do conjunto de design, refletindo informação das melhores práticas de arquitetura a fim de escalonar o suporte totalmente, consistente e acesso reutilizável da informação.

Mas antes de falar sobre canônico, vamos voltar em um tópico mais “básico” que acredito ser a origem de parte do problema: a Modelagem. É muito comum encontrar problemas de modelagem mas, tratando-se de serviço, a correção destes problemas torna-se um pouco mais complexa. Tal correção não pode ser encarada como um “simples” refactoring. Ao alterar o contrato de um serviço, todos os seus consumidores podem ser afetados, vai ser um “Deus nos acuda”. Uma vez que a alteração na interface dos serviços é complexa, sua modelagem merece atenção redobrada! Para isso é necessário trabalhar juntamente com a área de negócio, buscando sempre utilizar os mesmos termos para que a nomenclatura dos serviços tenha significado para a área de negócio.

Uma vez que os serviços e operações (ou capacidades) foram modelados, os parâmetros das operações precisam ser modelados. Esta modelagem NÃO deve levar em conta a nomenclatura dos sistemas já existentes e sim manter o mesmo critério adotado na modelagem dos serviços. Neste ponto o Modelo Canônico entra na equação, atuando como uma linguagem universal entre os sistemas envolvidos, facilitando o entendimento dos parâmetros dos serviços.

Então, respondendo a pergunta do título, uma definição simples de Modelo Canônico seria modelo de dados universal utilizado pela camada SOA.

Uma terminologia consistente é um bom ponto de partida na concepção de serviços mas isso por si mesmo não é suficiente. Você deve também ter um entendimento claro da forma como a informação do negócio é estruturada. Os parâmetros de entrada e saída, isto é as mensagens, são geralmente muito mais complexas do que dos únicos tipos de dados. Eles representam as definições complexas das entidades e os relacionamentos entre eles. O tempo de desenvolvimento e qualidade dos projetos SOA podem ser muito melhorados se arquitetos SOA alcançam o modelo canônico no designing dos formatos de dados expostos e modelos de serviços. O alinhamento resultante do processo, serviço/mensagem e modelos de dados aceleram o design, alcançam orientação normativa para a modelagem de dados e evita transformações desnecessárias.

Modelagem sempre é um assunto indigesto, pesado. Digo isso porque leva um tempo para ser digerido, assimilado, e isso só é alcançado através de exercícios, ou seja, só se aprende fazer fazendo! Mas existem algumas ‘dicas’ que podem ajudar a encurtar este caminho.

A parte mais dificil e complexa na modelagem do Modelo Canônico é a ‘normalização semântica’, então vamos deixa-la para o próximo post, começando pela parte técnica:

  • Como estamos falando em SOA e a maioria das implementações utiliza SOAP, a implementação do Modelo Canônico é em XML Schema;

  • Deve ser definida um padrão de nomenclatura. Normalmente é utilizado como em java, UpperCamelCase para os tipos (complexType) e lowerCamelCase para campos (element);

  • Como as entidades do Modelo Canônico são reutilizadas por várias operações, não é possível definir a obrigatoriedade dos campos (elementos). Por este motivo todos os campos devem ser opcionais utilizando o atributo minOccurs="0"e não devem possuir nenhum tipo de restrição, como limite de tamanho;

  • Utilize element para representar os campos, não attributes;

  • Não utilize referência cíclica, mais conhecida como relacionamento bi-direcional. Por exemplo: se a entidade Cliente possui um relacionamento com a entidade ContaCorrente não deve ser criado um relacionamento da entidadeContaCorrente para Cliente. Isso pode gerar problemas de performance e incompatibilidade em alguns clients / ferramentas;

Depois da parte técnica, existem alguns tópicos relacionados a modelagem:

  • Evite criar relacionamentos entre entidades muito independentes. Este tipo de composição pode ser feito na interface do serviço;

  • Eventualmente uma associação é identificada, porém não é necessário que tais informações sejam estruturadas. Neste caso a desnormalização pode ser usada. Por exemplo: a entidade Endereço possui todos os campos do entedereço estruturados, porém para a entidade Nota Fiscal esta normalização não é necessária, podendo ser um único campo texto;

  • Em alguns casos similares ao exemplo acima o tipo de informação de uma determinada entidade muda de acordo com o contexto. Por exemplo para o contexto de faturamento o Cliente possui algumas informações e para o contexto de CRM possui outros. Neste caso a entidade Cliente pode ser ‘quebrada’ de acordo com o domínio;

Modelagem é um assunto complexo e subjetivo. E ainda existem outras considerações a respeito da modelagem de Modelo Canônico.

© 2018 Ziben IT Solutions

Theme by Anders NorénUp ↑