Como paliativo ao meu problema de atualizações, vou tentar adotar uma estratégia mais imediatista. Estou usando o twitter para registrar progressos intermediários nas minhas pesquisas, experimentando uma abordagem de micro-blogging.
Inclui um gadget "Twitter" aí ao lado que trás os últimos posts no twitter (o howto peguei daqui).
Como beta inclui algumas impressões do livro do Ragsdale sobre o tópico de Multi Objective Linear Programming.
T++
0 comentários Marcadores: blogging, blogtest, Ethernal Beta
Pois é, ando meio sumido. Tive problemas de ordem técnico-acadêmica.
Bom, primeiro, a lâmpada da tela do meu note foi desta pra melhor. Até o técnico descobrir, encomendar a peça e executar o conserto se vao uns dez dias.
Como desgraças nunca vêm sozinhas (me lembro de uma citação do Corvo mais ou menos parecida), meu orientador finalmente decidiu a data de entrega da minha dissertação. Está perto. Bem no momento onde tive que me render ao apelo das lan-houses.
Fico agradecido a vocês que mantiveram meu contador do Motigo acima do zero. Na verdade este post é uma "prestação de contas" ao leitor Rogério sobre o post Padrões de Gerência de Configuração com Subversion 1.5 - Parte I: Conceitos. Ele pergunta sobre a continuidade da série de padrões de gerência de configuração.
Pretendo postar alguma coisa no meio da semana que vem, depois de entregar uma versão para revisão da minha dissertação para o meu orientador (segunda), talvez próxima quarta ou quinta (01/04 ou 02/04). Certamente a segunda parte da série de padrões de configuração está na frente.
Não gosto muito de prometer, afinal gerenciamento de expectativas é um problema a ser enfrentado. Mas lá vai um road map para os próximos assuntos que pretendo tratar no blog:
Até o momento estou focado na parte mais Corporativa da Arquitetura de Software. Então tem um assunto fantástico que descobri na administração para tentar avaliar uma série de possíveis arquiteturas de software. Aí vai então:
Espero com o tempo pôr alguns temas mais próximos da arquitetura de sistemas, como SOA, ESB, e de outras disciplinas da Engenharia de Software.
Então tá. Já estão me chutando da Lan House.
Até mais.
Não acredito que o tempo seja a verdadeira escala de medida do progresso. Apenas porquê temos hoje uma profusão de novas informações, novos métodos e novas promessas, não acredito que sejamos melhores do que os que nos precederam.
Não acredito num futuro brilhante como resultado unicamente baseado nas nossas ações do presente. Acredito no máximo num futuro razoável a enormes expensas de muito trabalho físico e cognitivo baseado na experiência pessoal de cada indivíduo. Compreendo que a estabilidade e a mudança devem ser reconhecidas e reconciliadas.
O que já é um ganho em si.
Apenas para mantermos nossos ganhos devemos nos esforçar para resistir à esmagadora força da entropia (no sentido de dispersão de energia). Sendo assim, o feedback é um mecanismo importante para a manutenção da concentração de energia do sistema para que este consiga sustentar um nível de trabalho aceitável, possibilitando o reconhecimento de uma cadeias de causa e efeito passíveis de uso na manutenção de ciclos virtuosos.
Isto foi o que me atraiu mais no advento do Scrum. Uma prática calcada na revisão constante de nossas ações passadas. Mas o Scrum não é nada mais que isso, é uma descrição de um mecanismo de feedback em um sistema.
Atualmente está ocorrendo uma caça às bruxas onde o Scrum é o bode expiatório da vez (Adopting the Whole Enchilada, Flacid Scrum e outras asneiras vindas a reboque do Decline and Fall of Agile).
Retrospectivas não são apenas pontos de replanejamentos per se. Tampouco são reuniões de terapia de grupo. São pontos ativos onde o feedback é usado para correção de rumo do método. É o ponto onde o relacionamento causal de nossos atos pode ser analisado e corrigido. É o reconhecimento do pensamento sistêmico como modo de se usar a dinâmica de sistemas em nosso proveito.
A despeito de toda uma indústria de consultorias e certificações criadas a seu redor, este é o valor de Scrum: sua simplicidade. Seu respeito a uma regra básica da física o torna um método elegante. Ponto.
Obviamente Scrum não é o suficiente. Para tirarmos proveito disto temos que ser criteriosos durante a retrospectiva. Isto não significa usar o bom senso, ou senso comum. O que quer que isso signifique acredito que não seja o ponto. Falo de honestidade intelectual. Não existe bala de prata.
Ser intelectualmente honesto não é uma tarefa fácil, reconfortante, ou que traga felicidade ou paz. Não foram nem uma nem duas vezes que idéias minhas foram refutadas (tanto justa como injustamente). O conhecimento da verdade, e principalmente de sua extensão, não é uma tarefa para fracos. Scrum não é o suficiente.
O que falta aos praticantes, agilistas convictos ou não, é pensamento crítico. Aproveitar os momentos de retrospectiva para REALMENTE fazer um ponto de inflexão. Onde podemos adotar uma série de técnicas fartamente documentadas na literatura de ciência da computação sistemas de informação e administração, submetê-las ao duro teste da prática e avaliá-las sem dogmatismo.
Durante a retrospectiva devemos entender que não há nada o que fizemos, absolutamente NADA, que seja realmente novo (não sou um fã de Nietzche). No decorrer de 40 anos de engenharia de software e de 10000 anos de outras engenharias, o que temos a fazer é olhar os que nos precederam, e isto não se restringe aos agilistas, nem tampouco ao RUP ou outra metodologia.
Não é uma questão de adoção do "bolo inteiro" é uma questão de adoção do que realmente podemos adaptar e empregar em um sistema sócio-técnico altamente dinâmico para que possamos retardar o avanço da entropia.
Atenção! Este post deve ser lido com a tecla SAP ativada. Caso não seja muito dado a sarcasmo ou ironia, por favor, nem tente.
Rebranding é o processo pelo qual um produto ou serviço desenvolvido sob uma marca, empresa ou linha de produtos é comercializada ou distribuída com uma nova identidade. Geralmente isto decorre de um reposicionamento de uma marca na tentativa de se descolar de conotações negativas da marca anterior.
Corretagem de seguros é uma profissão cheia de inconvenientes para o próprio e para o cliente. Corretores te ligam, marcam encontros em horários de estudo ou trabalho, insistem e ainda por cima pedem indicações suas. O cliente se faz de louco, não atende ou simplesmente manda o corretor longe.
Certa feita, fui chamado para uma entrevista numa multinacional em expansão agressiva no país (corporativês é o máximo). Ao chegar lá o recrutador foi falando sobre a empresa, foi falando sobre o produto, seguros, sobre a abrangência e tudo mais. Eu já imaginando "nossa, imagina a TI desses caras".
Com andamento, fiquei sabendo que não me chamaram para arquitetar algum sistema deles, mas para ser um life planner a um soldo de milhares de reais mais benefícios e comissões. Bom ainda estava interessado, pelo soldo, aí me veio a prescrição da vaga, era um corretor de seguros. Declinei e agradeci, não tenho perfil para trabalhar com humanos estranhos 100% do tempo (apesar de viver em reuniões, workshops e entrevistas).
Isso foi o rebranding em ação.
Há tempos a indústria de cosméticos vaseada em distribuição direta contava com Vendedoras Avon, Natura e Jequiti. O tempo transformou estas vendedoras em Representantes Avon, Natura e Jequiti. Por fim estas representantes se tornaram Consultoras Avon, Natura e Jequiti.
Mais um exemplo de rebranding.
Bom, a maior parte da minha carreira fui um consultor trabalhando em algumas empresas de consultoria de TI em Porto Alegre. Talvez se minha carreira tivesse tomado outro rumo não teria tido a variedade de experiências que adquiri. Já trabalhei em áreas diversas como DBA e administrador de servidores Linux, programador e arquiteto de software e como analista de sistemas e engenheiro de processos. Sempre tive sucesso em todas as áreas. Claro, fracassos se somam ao resultado final, mas o balanço até o momento é bem positivo.
Isso ocorre devido ao rebranding nas empresas de consultoria. Não é conduzido pelo departamento de marketing, e sim pelo departamento comercial. Um consultor se torna um profissional alocado via rebranding logo após o comercial questioná-lo: "Tem idéia de como se faz?". Temos aí um rebranding à la carte no ramo de outsourcing.
Antes que se perguntem, respondo: Não, nunca fui consultor Avon, Natura ou Jequiti.
O Reverse Rebranding e o Arquiteto de Software
Como falei anteriormente aqui, o mercado local de TI passou por um tempo de dificuldades na assimilação das tendências de mercado externas. Um dos problemas de assimilação foi justamente a posição de Arquiteto de Software. Outro foi justamente a vinculação da complexidade da TI atual à plataforma java, que em si, é apenas um reflexo da própria complexidade da indústria de tecnologia atual. Isso mesmo, Java é muito mais que uma linguagem.
Ouso dizer que são poucos os verdadeiros arquitetos de software que conheço. Não vou tratar o meu entendimento sobre arquitetura de software neste post. Isto dá muito pano pra manga. Vou resumir o meu ponto: Arquitetura de Software diz respeito à mitigação de riscos em sistemas sócio-técnicos.
Isto demanda uma abordagem amplamente interdisciplinar para resolução de problemas. Dêem uma olhada na lista de livros ao lado, acredito que sejam parte integrante do corpo de conhecimento técnico do arquiteto de software.
Na área de arquitetura de software ocorreu justamente o reverse rebranding. Haviam demandas novas (gerenciamento complexidade de TI) que deveriam ser solucionadas, no entanto ao invés da adaptação estrutural necessária, foi feito um rebranding do desenvolvedor sênior em arquiteto de software sem que os skills adequados sejam desenvolvidos para o atendimento de novas demandas. Afinal faz todo sentido descolar os aspectos deficientes de uma marca antiga e esperar que todos estes sejam atendidos apenas pelo que se imagina das conotações positivas da nova marca.
Um arquiteto de software não trabalha apenas com a integração do Spring e do Hibernate. Não é um piloto de API. Deve sobretudo entender o mecanismo interno desses e o mais importante deve desdobrar o funcionamento destes mecanismos sob as condições demandadas pelo sponsor como, por exemplo, escala, tempo de vida, manutenibilidade, integração e atendimento ao negócio que em si demanda grande conhecimento do domínio.
O arquiteto deve ter conhecimento em profundidade e amplitude sobre vários aspectos da TI, do protocolo de rede, ao funcionamento de frameworks, processos de desenvolvimento até o alinhamento estratégico da organização. Isto subsidia talvez o principal skill, na minha humilde opinião, do arquiteto de software: Pensamento Sistêmico. Ver as árvores e a floresta de acordo com a necessidade.
Como resultado do reverse rebranding, já vi vários erros cometidos por "arquitetos de software". Não erros decorrentes de deficiências em conhecimentos organizacionais, conhecimentos em soft-skills, como engenharia de requisitos ou relacionamento interpessoal (por si a maior reclamação do pessoal das organizações em relação a "arquitetos" intratáveis), mas conhecimentos em tecnologia, o famoso "baixo-nível":
Concluindo
O contratante deve tomar muito cuidado quando alguém oferecer um "arquiteto de software" ou um "arquiteto corporativo". Não digo que esta situação seja generalizada, apenas que já presenciei mais de uma vez a ocorrência de fenômenos semelhantes. Volto ao assunto de definição dos skills de um arquiteto no futuro.
2 comentários Marcadores: Arquitetura de Software, Business, Engenharia de Software, Mercado
O nosso país sempre esteve atrás das maiores tendências em TI. Talvez este gap esteja diminuindo agora com a internet. Mesmo assim temos nossos problemas ainda.
A ciência da computação passou por revoluções tão avalassadoras nos últimos 40 anos que faz com que as organizações tenham dificuldades em acompanhar não apenas a tecnologia mas o próprio mercado de TI (Quem não falou com o velho gerente de CPD que falava dos tempos do DATAFLEX, ADABAS, COBOL, ZIM e mesmo do Digitador).
Com um ciclo de mudanças nas subfunções da TI inferior a 5 anos novas carreiras e novas especializações surgem como Arquiteto de Informação, Analista IHC entre outros, como o Arquiteto de Software.
No desenvolvimento do nosso mercado local (Brasil e mais especificamente região sul), várias inovações da TI chegaram num determinado momento, mais ou menos a partir de 1996 - 1998. Entre elas a linguagem java em ambiente comercial, a adoção da arquitetura 3 camadas, o emprego da tecnologia TCP/IP e o uso deinterface Web.
Antes disso haviam plataformas proprietárias de diversos vendors, como a Oracle, a Borland, a Microsoft, e outras jabuticabas como o ZIM. Todas essencialmente duas camadas.
A gestão deste mix Tecnológico pelos departamentos de TI foi complicada. Um dos mitos que recorrentemente ouço é que toda essa complexidade é inerente à plataforma Java.
Durante a reserva de mercado na década de 80 ocorriam as guerras por padrões de plataformas corporativas, como CORBA, COM e DCOM, bem como as guerras de consolidação dos protocolos Internet. Coisas que o mercado local acompanhara apenas marginalmente. A grande maioria das empresas médias não têm acesso ao desenrolar das brigas por padrões (não é sua obrigação e nem seria de seu interesse) chegando a adotar padrões relativamente consolidados pelo mercado.
A encarnação atual de plataformas pode ser vista nos entreveros pela definição do padrão de HDTV no Brasil e nos padrões de discos óticos que substituirão o DVD, como o blu-ray.
0 comentários Marcadores: Business, Indústria de TI, Mercado
Grey Press by Dan S, inspired by PressRow. See more Blogger Templates
Distributed by eBlog Templates
