Tuesday, September 25, 2012

Stories about IWA / Estórias sobre o IWA

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

I think by now everybody that follows Informix evolution knows and agrees that IWA (Informix Warehouse Accelerator) is a big step forward and one of the real market innovations. We know that many companies are doing something similar, but as usual, Informix does it better, simpler and easier.
Off course this is me talking and I may be accused of subjectiveness. But it's a pleasure to look at what others are saying.
Recently we've seen two analyst firms mentioning IWA and praise some of it's features. Some of the more positive points were:

  • The possibility to mix OLTP and BI workloads in the same infra-structure
  • The "no knobs" maintenance
  • The appeal to existing Informix customers
  • Tight integration with the native database optimizer
  • Performance
But you should read those papers yourself. They're spread all over the Intenet, but I'll leave two links for download here:

But this is not all... I suppose we all know that IBM takes basic investigation and development very serious. It studies hardware, software, physics etc.
IWA is based on a project that was born at the IBM Almaden labs. These projects are investigation projects that are not controlled by product management teams. If they reach a certain maturity than they may become products. Or parts of them may be incorporated into existing products.
Blink was one of those projects. It had specific targets and basic premises that lead to the development of something new. After that it was integrated with an existing product. And for those that think Informix is "dead" or that it's living in the IBM backstage, think again... This shows integration between Informix team and the more "raw investigation" at IBM.

But who would be best to explain what Blink is than one of it's creators? Let me introduce you Dr. Guy M Lohman. Let him tell you about it in this video:

And stay tuned... IWA is evolving and being constantly updated.

Versão Portuguesa:

Julgo que por esta altura toda a gente que segue a evolução do Informix concorda que o IWA (Informix Warehouse Accelerator) é um grande passo em frente e uma das efetivas inovações do mercado. Sabemos que várias empresas estão a fazer algo semelhante, mas como é hábito o Informix faz melhor, de forma mais simples e fácil.
Claro que isto sou eu a falar, e posso ser acusado de subjectividade. Mas é com prazer que vejo o que outros escrevem. Recentemente vimos duas firmas de analistas mencionar o IWA e elogiar algumas das suas características. Alguns dos pontos mais positivos foram:

  • A possibilidade de misturar perfis de utilização (OLTP e BI/DW) na mesma infraestrutura
  • A administração "automática"
  • Ser apelativo para clientes Informix atuais
  • Integração forte com o optimizador da base de dados
  • Rapidez
Mas deve ler esses documentos você mesmo. Estão espalhados pela Internet, mas deixo aqui links para fazer o download (Inglês).
Mas não é tudo... Suponho que todos sabemos que a IBM leva muito a sério a investigação de base e o seu desenvolvimento. Estuda hardware, software, física etc.

O IWA é baseado num projecto que nasceu nos laboratórios da IBM em Almaden. Estes projetos são projetos de investigação que não são controlados pela gestão de produtos. Se atingirem uma determinada maturidade podem tornar-se produtos. Ou parte deles podem ser incorporados em produtos já existentes.
Blink foi um desses projetos. Tinha objetivos e premissas específicos que levaram ao desenvolvimento de algo novo. Depois disso foi integrado num produto existente. E aqueles que pensam que o Informix "morreu" ou que vive nos bastidores da IBM é melhor reconsiderarem... Isto prova a integração entre a equipa Informix e a "investigação de base" da IBM.

Mas quem melhor para explicar o que é o Blink que um dos seus criadores? Permitam-me que apresente o Dr. Guy M Lohman. Deixe que ele lhe explique tudo neste vídeo:

E mantenha-se alerta... O IWA está a evoluir e a ser constantemente atualizado.

Saturday, September 22, 2012

Electronic entry of PMRs / Registo eletrónico de PMRs

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

The PMR opening...

I'm going to use an IBM announcement as an excuse to talk a bit about technical support. The announcement in question is that IBM is trying to get their customers to use a web based tool for opening PMRs (or Service Requests) for severity 2, 3 and 4 (higher means lower business impact, 1 being most critical, eventually a system down). The status of this change may vary with your geography, so if you still have any doubts after reading the information provided in the announcement and the links it includes, don't hesitate to contact IBM to clarify.

The change is that currently you can open the service requests by phone. In the future that will be reserved for severity 1 issues. I haven't received any feedback on the announcement, but I can imagine there will be different reactions to this:

  1. Wow... So they want to save even more costs?
  2. What?!... I always use the web based tool
  3. What?!... So it means I must always have access to the web to open a problem?
  4. Why the difference between severity 1 and the others?
Well... I'm just guessing here... But let me make a few comments on these options before I dive deeper in the PMRs (Problem Management Record) and tech support in general

  1. Yes... You can be sure every company is trying to save costs. IBM is not an exception, and I'd be worried if it was. The question here is that the "cost" of having a couple of persons without specific product training, that just answer the phone and ask a set of pre-defined questions to the customer and enter the answers in some internal tool is probably very low. On the other hand, the "cost" (meaning bad impression) that derives from the bad interaction between these persons and a customer with a problem in his hands can be significant. Believe me. I've opened PMRs this way, and it's not a good experience. The person only purpose is to collect a minimum set of information (like product name, problem description, customer information, severity etc.) that will allow the opening of the service request and sending to a proper queue. It's a non-value added work. And if you have a serious problem, and on the other end of the line is someone asking you to spell "Informix" you won't like it. Furthermore, this can create some basic errors that may lead to bad queuing of the PMRs
  2. You always use the web based tool? Great... so do I. End of story :)
  3. Yes... it means you should always have an Internet connection. But that's mostly pervasive today... But if you don't have one, the phone channel will probably be accepted. But let's be honest... When was the last time that we did not have an Internet connection while working on IT?
  4. The difference would be that if you have a severity one PMR (possibly a system down) you need immediate feedback. Personally and let me stress "personally" I'd create the PMR using the electronic web based tool and then I'd call IBM to make sure it will reach an engineer as soon as possible
So, my point regarding the announcement is that it will not change my way of working, and I think it's a good idea.
I've been using the SR tool for some years and my experience tells me it's available, easy, quick and safe. The reasons why I feel this way are:
  1. Never caught it off-line
  2. It asks the essential, not a lot of useless information
  3. Since I have to authenticate it already knows the customer details
  4. It's flexible in the sense that I can upload files with relevant information
  5. It allows me to save the PMR in "draft" and come back later to complete and send it to IBM
  6. It always puts the PMR in the correct queue which guarantees fast feedback from a product specialist
I suppose people reading this may be thinking... "great... but I wouldn't expect less than that... After all I pay for support". True. I agree. But you should compare this to other database vendors for example, or to other software vendors. I've heard about stories that I wouldn't believe if they were not told to me by people I fully trust. I had people saying to me that using the equivalent tool from one competitor can take very long minutes, that they have to answer too many questions or choose lot's of different boxes etc. I can honestly say that we can comfortably open a SR in IBM in 5m (assuming we have gathered the data in advance, and that we're not uploading GBs of evidences).

Tech support in analysis

I'm sure we're able to find reports of bad technical assistance from IBM. And I suppose that it would be nearly impossible to be successful in 100% of the cases... But instead of basing my analysis on external reports from people I don't know, I prefer to base it on my own experience. And believe me, I open a lot of PMRs... I work mostly with Informix, but I've been involved in PMRs with other IBM products, and although the experience is not uniform, I'd say the end results are pretty good independently of the technology. The main difference I've found between different products would be that sometimes there is a bigger difference between different levels of support.
And in the case of Informix I must admit I may be privileged. We have a local resource doing L1 (first customer interaction) who is very good and experienced, and many times I discuss the issues previously with him. Assuming we're facing something new, he has to move the PMR to higher levels and then it's mostly business as usual, although I do have access to internal knowledge bases which may allow me to gather more useful information. But typically at this level I'm acting as a regular customer, interacting with people located around EMEA (Europe, Middle East and Africa).

As I mentioned before, I do open a lot of PMRs... In the last year or so I was involved in around 25. Most of them Informix. Before you start screaming that Informix must have a lot of issues let me explain a couple of points:

  1. Arguably, software is not cheap. And if a customer pays for support, if he has a reasonable doubt or if he hits what may look like a problem, I see no reason why not to open a PMR
  2. Many times a customer ask me a question and I may have an answer for them. But if they show me that a manual gives the incorrect information, a PMR should be raised to fix the manual even if the doubt is clarified
  3. If a customer has an issue, and that issue is caused by the OS or some external service (like DNS), if we have the feeling that Informix could be handling it better, I see no reason not to open a PMR and eventually ask for a FEA (Feature request).
  4. If a customer has an issue, but is able to workaround it, I see no reason not to open a PMR, even if the issue isn't urgent anymore due to the existence of a workaround
  5. A PMR is a natural way to interact with R&D (through technical support) so that some future improvements can be made. Specially for me, as an IBM employee, but also from a customer point of view, improving the product is in the best interests of all the customers and community members
Having said all this, I have to be clear about one thing: Many times the most important part of a PMR is the discussion with tech support and/or R&D. If you have a point, you should defend it. You must do it in a reasonable and rationale way, but you should do it. Remember: You like the product, you want it improved (either fixing bugs, or implementing new stuff) and most important you pay for support and subscription. That entitles you in other things to get support!

Two good examples
I don´t' want to fill the article with technical details, but I'd like to leave here two success stories with the technical support and R&D.

  • The nasty query
    Some time ago a customer identified that, what looked like a very simple query would be running for several days. We investigate the query plan, but meanwhile the query was re-written and it run in half an hour. But the new query was nothing like intuitive and we decided to check with tech support if the original behavior was acceptable. Meanwhile I asked an Oracle DBA from that customer to create the tables, load the data and test the query. The result was roughly the same... The query would be running for weeks (accordingly to the estimation of their product). This query would deserve an article by itself... But guess what: IBM R&D looked at the query, understood the problem, asked me to try it on a non released version that included some features that could help, and finally considered that it was a bug. 11.70.FC6 should have the fix!
    When I spoke again with the Oracle DBA and told him what we did, and asked him if he would consider enter a problem in Oracle he just laughed....
    So, without any drama, for a problem that was already solved, R&D decided to accept a bug and improve the product. That's good, and I'd say that's expectable, but it's not what you get from other vendors.
  • The useless message
    More recently a customer was seeing some messages in online log that mean something wrong was happening in the communication between the clients and the server. I don't want to go into big details, but basically the message was useless because it does not contain information that allows the customer to track down the issue. Again, a PMR was opened. Note that this was not causing measurable impact on their environment. I had an extensive chat with the technical support engineer and explained that the message as it was just causes anxiety on the customers since we're telling them that something is wrong, but not where or whom. In around a week R&D developed what we call a code fix (changes in the code that solve a problem) and after that customer is able to ask for a special build (patch like 11.50.xC7X? )
    Again, a simple change, that will bring help to customers on future versions (11.50.xC10 and 11.70.xC7).
    I bet that most vendors would just say "works as design"... or "we could consider a future change... insert a request in the features request database...". But here the answer was: "You're right! It's fixed. Do you need a patch?"
I could give you tens of examples like these. And if you're wondering how to make this possible, this is my subjective opinion:
  1. You need to have a clear understanding of the problem. A reproduction always helps, and a good evidence collection may be crucial
  2. You must be willing to defend your point of view with valid arguments.
  3. You'll have much better chances if the changes are simple to implement and if they don't change old behavior
  4. You should be able to express yourself clearly and be assertive
After all this, I'd like to say that I'm not always successful. I have my share of feature requests that are lingering around in the FEA database... But I can assure you that most of the times we're successful.

Versão Portuguesa:

Abertura de PMRs...

Vou utilizar um anúncio da IBM como pretexto para falar um pouco sobre o suporte técnico.
No anúncio em questão a IBM anuncia que os seus clientes devem usar uma ferramenta web para abrirem os PMRs (ou pedidos de serviço) de gravidade 2, 3 e 4 (mais alta significa menor impacto no negócio, sendo 1 a mais critica - eventualmente um sistema em baixo).
O estado desta mudança pode variar com a sua geografia, por isso se lhe restarem dúvidas depois de ler a informação do anúncio e os links nele contidos, não hesite em contactar a IBM para mais esclarecimentos.

A mudança em relação ao método atual é que de momento os pedidos de serviço podem ser feitos por telefone. No futuro isso será reservado aos casos de gravidade 1. Não recebi qualquer feedback relativo ao anúncio, mas posso imaginar que irão existir várias reações a isto:

  1. Wow... Então ainda querem reduzir mais custos?
  2. Hmmm?!... Eu uso sempre a ferramenta web...
  3. Hmmm?!... Então isso significa que terei de ter acesso Internet para abrir um problema?
  4. Qual a razão da diferença entre gravidade 1 e as restantes?
Bom... Estou apenas a lançar ideias... Mas deixe-me fazer alguns comentários a estas possibilidades antes de mergulhar na questão dos PMRs (Problem Management Record) e no suporte técnico em geral:

  1. Sim... Pode apostar que todas as empresas estão a tentar reduzir custos. A IBM não é uma exceção e eu estaria preocupado se fosse. A questão é que o "custo" de ter algumas pessoas sem formação específica em produtos, que apenas atendem telefones e fazem um conjunto pré-definido de perguntas, introduzindo as respostas numa ferramenta interna é provavelmente muito baixo.
    Por outro lado, o "custo" (entenda-se a má impressão causada) que deriva de uma má interação entre essas pessoas e um cliente com um problema em mãos pode ser significativo. Acredite em mim. Eu já abri PMRs por esta via e a experiência não é boa. O único propósito da pessoa é recolher um conjunto mínimo de informação (como o nome do produto, descrição do problema, informação de cliente, gravidade etc.) que irá permitir abrir o caso e colocá-lo na "fila" adequada. É um trabalho sem valor acrescentado. E se estiver com um problema em mãos e do outro lado da linha estiver alguém que lhe pede para soletrar "Informix" qual será a sua reacção? Para mais, isto facilmente pode criar alguns erros que podem levar a uma má classificação ou encaminhamento do pedido.
  2. Sempre usa a ferramenta web? Perfeito... eu também. Fim de assunto!:)
  3. Sim... significa que deverá ter sempre um acesso à Internet. Mas isso é quase omnipresente hoje em dia... No entanto, se tal não tiver disponível, o canal telefónico deverá ser aceite. Mas sejamos honestos... Quando foi a última vez que não tinha uma ligação à Internet enquanto estava a trabalhar em TI?
  4. A diferença será que se tiver um problema de gravidade 1 (possivelmente um sistema em baixo) necessita de resposta imediata. Pessoalmente, e deixe-me sublinhar "pessoalmente", eu abriria o PMR pela via eletrónica e depois ligaria para a IBM para garantir que o pedido chegaria a um técnico tão rápido quanto possível
Portanto, o meu ponto em relação ao anúncio é que não irá mudar muito a forma de trabalhar, e que me parece boa ideia.
Tenho usado a ferramenta de abertura de pedidos de serviço já há uns anos e, a minha experiência diz-me que é altamente disponível, fácil rápida e segura. As razões para sentir isto são:
  1. Nunca a encontrei indisponível
  2. Pergunta o essencial e não um conjunto de informação inútil
  3. Dado que nos temos de autentica, já sabe todos os detalhes do cliente
  4. É flexível no sentido que posso enviar ficheiros com informação relevante
  5. Permite-me gravar os PMRs como "rascunho" e voltar mais tarde para completar a informação e fazer o envio para a IBM
  6. Coloca sempre os pedidos na fila correta, o que garante uma resposta rápida por parte de um especialista do produto
Suponho que qualquer pessoa ao ler isto possa pensar... "certo... mas não esperaria menos que isso... Afinal eu pago pelo suporte!". Verdade. E eu concordo. Mas deverá comparar isto com o que outros fornecedores de bases de dados ou outros fornecedores de software disponibilizam. Ouvi histórias nas quais não acreditaria se não me tivessem sido relatadas por pessoas em quem confio totalmente. Houve quem me dissesse que a ferramenta equivalente de um competidor demora longos minutos para abrir um caso, que obriga a responder a muitas questões ou escolher muitas opções etc. Posso honestamente garantir  que conseguimos confortavelmente abrir um PM na IBM em 5m (assumindo que já recolhemos a informação antecipadamente e que não estamos a enviar GBs de evidências)

Suporte técnico em análise

Tenho a certeza que é possível encontrar relatos de má assistência técnica por parte da IBM. Julgo que seria impossível assegurar 100% de sucesso... Mas ao invés de basear uma análise nos relatos externos de pessoas que não conheço, prefiro basear-me na minha própria experiência. E garanto que eu abro bastantes PMRs... Trabalho essencialmente com Informix, mas já estive envolvido em PMRs com outros produtos da IBM, e apesar de a experiência não ser absolutamente uniforme, diria que o resultado final foi sempre bastante bom, independentemente da tecnologias. Talvez a principal diferença entre produtos tenha sido a diferença entre diferentes níveis de suporte. E no caso do Informix posso admitir que sou privilegiado. Temos um recurso local que trata do nível 1 (L1 ou a primeira interação com o cliente). E esse recurso é muito bom e experiente. Muitas vezes acabo por discutir os assuntos com ele mesmo antes da abertura dos casos. Mas admitindo que estamos a enfrentar algo novo,  ele terá de mover o PMR para os níveis de suporte acima e então sou mais um "cliente", isto apesar de ter acesso a algumas ferramentas internas que me permitem pesquisar alguma informação que pode ser importante. Mas no essencial assumo o papel do cliente e estou a lidar com alguém localizado na EMEA (Europe, Middle East adn Africa).

Como referi antes, eu abro realmente bastantes PMRs... No último ano estive envolvido em cerca de 25. Na sua maioria relacionados com Informix. Antes que alguém comece a gritar que o Informix deve ter muitos problemas, deixe-me esclarecer e deixar bem claro alguns pontos:

  1. É discutível, mas o software não será barato. E se um cliente paga pelo suporte, se tiver uma dúvida razoável ou se encontrar o que lhe parecer um problema, não vejo razão para não abrir um PMR
  2. Muitas vezes sou questionado por clientes e até posso conseguir esclarecer as dúvidas. Mas se me mostrar que o manual fornece informação errada, deve ser aberto um PMR para a sua correção, ainda que a dúvida tenha ficado esclarecida
  3. Se um cliente tem um problema, ainda que esse problema seja causado pelo sistema operativo ou outro serviço externo ao Informix (como o DNS), se pensamos que o Informix poderia lidar melhor com isso, não vejo razão para não abrir um PMR e eventualmente pedir uma melhoria (FEA ou Feature Request)
  4. Quando um cliente encontra um problema, mas consegue contorná-lo, não vejo porque não abrir um PMR, ainda que dada a existência de uma alternativa não o torne urgente
  5. Um PMR é uma forma natural de interagir com as equipas de desenvolvimento (através do suporte técnico), no sentido de tentar obter melhorias para o futuro. Isto é especialmente verdade para mim, sendo da IBM, mas julgo que também do ponto de vista de qualquer cliente, dado que melhorar o produto é do interesse de qualquer cliente e dos membros da comunidade
Tendo dito tudo isto, tenho de ser claro sobre algo: Muitas vezes a parte mais importante de um PMR é a discussão com o suporte técnico e/ou a equipa de desenvolvimento. Se considerar que tem razão sobre algo, deve estar disposto a defender esse ponto de vista. Isso deverá ser feito de forma razoável e racional, mas deve ser feito! Lembre-se: Gosta do produto, usa-o e provavelmente irá continuar a usá-lo, logo naturalmente deverá querer contribuir para a sua melhoria (seja pela correcção de bugs seja pela implementação de novas funcionalidades). E mais importante... Paga pelo suporte e subscrição. Isso habilita-o entre outras coisas a ter suporte.

Dois bons exemplos
Não quero encher o artigo com detalhes técnicos, mas gostaria de deixar aqui duas histórias de sucesso de interação com o suporte e equipa de desenvolvimento.

  • A query perversa
    Há algum tempo atrás um cliente identificou aquilo que parecia uma query muito simples, mas que no entanto iria ficar a correr por vários dias
    Investigámos o plano de execução, mas entretanto a query foi re-escrita e correu em meia-hora. Mas a nova query era tudo menos intuitiva e decidimos verificar com o suporte técnico se o comportamento inicial estava correto e se não haveria nada a fazer.
    Neste intervalo de tempo pedi a um DBA de Oracle do mesmo cliente que criasse as duas tabelas envolvidas, carregasse os dados e analisasse o resultado e plano de execução. O resultado era sensivelmente o mesmo... A query de acordo com a estimativa fornecida pela base de dados iria estar a correr durante semanas (note-se que a estimativa em si ia variando). Esta query merecia um artigo por si só.... Mas o que se passou com o suporte da IBM? Olharam para a query, compreenderam o problema, pediram-me que tentasse a execução numa versão ainda não disponível, dado que havia novas funcionalidades que poderiam fazer diferença (não adiantou) e finalmente considerara que era um bug. A versão 11.70.FC6 deverá conter a correção.
    Quando voltei a falar com o DBA Oracle e lhe contei a história da IBM, perguntei-lhe se considerava abrir um problema na Oracle... Apenas se riu...
    Ou seja, sem grandes dramas, para um problema que na realidade já não existia, o desenvolvimento decidiu aceitar um bug e melhorar o produto. É bom e diria que é o desejável, mas não é o que se obtém com outros fornecedores.
  • A mensagem inútil
    Mais recentemente um cliente estava a encontrar algumas mensagens no online.log que indicavam que algo de errado estava a ocorrer na comunicação entre o servidor de base de dados e algum cliente. Não querendo entrar em grandes detalhes, entendemos que a mensagem era inútil dado que não continha detalhes que permitissem ao cliente investigar e depois rsolver a questão. Novamente foi aberto um PMR. Note-se que isto não estava a provocar nenhum impacto sensível no ambiente do cliente. Não havia queixas de erros ou problemas de performance.
    Tive uma extensa conversa com o técnico de suporte e expliquei que tal como estava, a mensagem apenas causava desconforto no cliente (pois fica a saber que algo de errado estava a ocorrer), mas que não permitia uma investigação sobre o assunto por falta de detalhes. Em cerca de uma semana o desenvolvimento desenvolveu o que chamamos um code fix (alteração no código) e depois disso o cliente pode pedir um special build (patch como 11.50.xC7X?)
    Mais uma vez foi uma alteração simples, que irá trazer benefícios e ajudar os clientes com versões futuras (11.50.xC10 e 11.70.xC7)
    Julgo que a maioria dos fornecedores concluiria algo como "trabalha como planeado... Insira um pedido de melhoria na nossa base de dados....". Mas aqui a resposta foi: "Tem razão. Está corrigido. Quer um patch?"
Podia dar dezenas de exemplos como estes. E se está interessado em saber como tornar isto possível, eias a minha opinião subjetiva:
  1. Tem de ter um entendimento claro do problema. Uma reprodução do mesmo ajuda sempre e uma boa recolha de evidências pode ser crucial
  2. Tem de estar disposto a defender o seu ponto de vista.usando claro argumentos válidos
  3. Terá maiss possibilidades de sucesso se as alterações necessárias não forem demasiado complexas se não modificarem comportamentos antigos por omissão
  4. Deve saber exprimir-se claramente ser assertivo
Depois de tudo isto, gostaria de dizer que obviamente nem sempre tenho sucesso. Tenho a minha quota de pedidos de melhorias que estarão a ganhar bolor na base de dados de melhorias... Mas posso assegurar que na maioria dos casos conseguimos ter sucesso.

Wednesday, September 19, 2012

V11.10 EOS / Fim de supporte V11.10

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

Recently there were posts, twits and news about the end of support of Informix V11.1. The official announcement was made a year ago. In some foruns there were some discussions recently about the end of marketing and end of support policies by IBM. I do understand that this kind of announcements may cause some customer irritation, but this is clearly a good opportunity to clarify some aspects.
Typically the EOS (End Of Support) of version N is announced after version N+2 is generally available. Depending of the release schedules this typically means around 5 to 6 years of support. If you compare with the hardware renovation cycles this software support life cycle is greater or equal. And if we take a look at this particular case, the dates were:

  1. July 2007, v11.1 was made available
  2. May 2008, v11.5 was made available
  3. October 2010, v11.7 was made available
  4. September 2011, v11.1 end of support was announced
  5. September 2012, v11.1 effectively enters end of support
The only point worth noting was the short time between v11.1 and v11.5. Normally the time between two major consecutive versions round two years but it was shorter in this case.
This helps to explain why v11.1 was probably less used than V11.5. I heard about around two or three customers who may still be on this version in my country. Most are currently on v11.5. Nevertheless this was a great mark in Informix history because it included many of the major features and was a big leap forward. This version was code named Cheetah and was one of the most talked about Informix versions.
I wonder if you still remember these videos:

"It's about being the hunter, not the prey"...
And by the way, music by Al di Meola, a famous Spanish guitar player, called "Perpetual Emotion" (first video, and I accept information about the second one)

But returning to serious issues... Customers do hate upgrades and end of support announcements. Why? Well, I must say I never run any survey, but it looks apparently evident: If it works, don't break it. And we all know Informix works... and works... and keeps working.... without bothering anybody. But what looks like a wise business decision may turn out to be a bad deal. Here's why:

  1. You may end up tied to old hardware and OS versions, because to upgrade these you may be in a non-supported and/or non-tested environment
  2. The longer you take to upgrade your software, the bigger will be the knowledge gap
  3. Upgrading can be seen as a challenge to your staff. And it's a motivating factor. Who wants to work in a place that looks like an attic?
  4. Being stuck with older versions means giving up of a lot of new features that can improve the way you use the software, and safe you time
  5. Upgrading Informix is simple.... it really is!
  6. Upgrading Informix is safe. Specially with newer versions
And since I'm into videos today I don't want to miss the opportunity to link to this informative video from Tom Rieger about Informix upgrades:

So, please don't get stuck with an old version, even such a great and historic one as V11.1, a.k.a. Cheetah!

Note from the author: The musics for the second video are "Rain" from the soundtrack of "Spirit - Stallion of the cimarron" and the Van Helsing theme!

Versão Portuguesa:

Apareceram recentemente artigos, twits e notícias sobre o fim de suporte da V11.1 do Informix. O anúncio oficial foi feito há um ano atrás. Em alguns foruns houve também algumas discussões sobre as políticas de fim de marketing e fim de suporte da IBM. Eu entendo que este tipo de anúncio pode causar alguma irritação nos clientes, mas esta é claramente uma boa oportunidade de clarificar alguns aspectos.
Habitualmente o EOS (fim de suporte) de uma versão N é anunciado após a versão N+2 estar disponível para o público. Dependendo do calendário de releases isto tipicamente significa cerca de 5 a 6 anos de suporte. Se comparar-mos isto com os ciclos de renovação de hardware, este ciclo de suporte de software é maior ou igual. E se olharmos para este caso em particular as datas foram:

  1. Julho 2007, a v11.1 foi disponibilizada
  2. Maio 2008, a v11.5 foi disponibilizada
  3. Outubro 2010, a v11.7 foi disponibilizada
  4. Setembro 2011, foi anunciado o fim de suporte da v11.1
  5. Setembro 2012, a v11.1 irá efectivamente ficar sem suporte
O único ponto digno de nota foi o curto espaço de tempo entre as v11.1 e v11.5. Normalmente o intervalo entre duas versões principais consecutivas ronda os dois anos, mas foi mais curto neste caso.
Isto ajuda a explicar porque é que a V11.1 foi provavelmente menos usada que a V11.5. Julgo ter ouvido falar em dois ou três clientes no meu País que estarão ainda nesta versão. A maioria está actualmente na v11.5. Mas em todo o caso, esta versão foi um grande marco na história do Informix porque incluíu muitas das principais funcionalidades e foi um grande salto em frente. Esta versão teve o nome de código Cheetah e foi uma das versões mais badaladas do Informix.
Será que se lembra destes vídeos:

"It's about being the hunter, not the prey"...
E já agora, música de Al di Meola, um famoso guitarrista Espanhol, chamada "Perpetual Emotion"(primeiro video e aceito informações sobre o segundo)

Mas voltando aos assuntos mais sérios... Os clientes detestam upgrades e anúncios de fim de suporte. Porquê? Bom, nunca efectuei nenhum inquérito, mas parece evidente: "Se funciona, não estragues". E nós sabemos que o Informix funciona.... e funciona.... e continua a funcionar. sem aborrecer ninguém. Mas aquilo que pode parecer uma boa decisão, pode tornar-se num mau negócio. Eis porquê:

  1. Pode ficar agarrado a uma máquina antiga ou versão se sistema operativo desactualizado, porque uma mudança pode deixá-lo num ambinete não suportado ou não testado
  2. Quanto mais tempo adiar uma actualização de software maior será o atraso de conhecimento a recuperar
  3. Actualizações podem ser vistas como um desafio para o pessoal técnico. E isto é um fator de motivação. Quem quer trabalhar num local que mais pareça um sótão?
  4. Ficar preso a uma versão antiga implica prescindir de uma série de novas funcionalidades que pode melhorar a forma como usa o software e poupar-lhe tempo
  5. Actualizar o Informix é simples... É mesmo simples!
  6. Actualizar o Informix é seguro.... Especialmente com as versões mais recentes
E como estou voltado para os vídeos hoje, não quero passar a oportunidade de recomendar um vídeo do Tom Riger sobre actualizações de Informix:

Portanto, por favor não fique agarrado a uma versão antiga, mesmo que seja uma com tanta história como a V11.1, também conhecida como Cheetah!

Nota do autor: As músicas do segundo video são "Rain" do filme de animação "Spirit - the stallion of the cimarron" e o tema do filme Van Helsing!

Sunday, September 16, 2012

IOD 2012

This article is written in English and Portuguese
Este artigo está escrito em Inglês e Português

English version:

It's official. I'm ashamed... around 3 months without a post. I can find good reasons, but that's unacceptable in  any case. As usual I'm not running out of ideas, just time. It's possible you'll see a sequence of non technical posts, but don't worry (if you like the tech stuff). It's just that the technical stuff takes longer to write and there have been very serious news around the non technical arena.
So, this is the first "other stuff" post. Just a note to remind everybody that IBM is promoting another round of the IOD (Information On Demand) conference that have been taking place for a number of years. It will be held in Las Vegas (also known as Sin City?) on 21-25 October. Why would you care? Obviously because there's an Informix and Tools track (and naturally you can find a lot of other sessions related to anything about Information Management).

Taking a look at the list of sessions, the topics are more or less what we'd expect but there are a few surprises:

  • Informix Warehouse Accelerator
  • Open Admin Tool
  • Informix 11.7 features
  • Roadmap
  • Replication
  • Time series, Spatial and other extensions
  • Embedding
  • Application development and modernization
  • One session about a project integrating Informix with BPM (Business Process Management) from IBM
  • Compression
  • Integration with Cognos from a business partner (ERP)
You can find more on the conference website (http://www-01.ibm.com/software/data/2012-conference/). And if you want to combine decent weather, good content, nice companion and the change to win a jackpot, where else would you go? Here's a situation where the phrase "what happens in Vegas stays in Vegas" does not apply!

Versão Portuguesa:

É oficial. Estou envergonhado.... cerca de 3 meses sem um artigo. Consigo encontrar boas razões, mas é inaceitável em qualquer caso. Como é hábito não estou a ficar sem ideias, mas apenas sem tempo. É possível que venha agora uma sequência de artigos de cariz não técnico, mas não se preocupe (se gosta de artigos técnicos). Isto deve-se ao facto de que os técnicos demoram mais tempo a escrever e por terem aparecido uma série de notícias muito importantes em torno dos temas não técnicos.
Assim este será o primeiro artigo "sobre outras coisas". Apenas uma nota para lembrar toda a gente que a IBM está a promover mais uma realização da conferência IOD (Information On Demand) que tem realizado nos últimos anos. Terá lugar em Las Vegas (também conhecida como Sin City ou cidade do pecado) de 21 a 25 de Outubro. Porque será isto importante? Naturalmente porque existe um conjunto de sessões dedicadas ao tema "Informix and tools" (e claro que pode encontrar uma série de outras sessões relacionadas com tudo o que diga respeito a Information Management)

Olhando para a lista de sessões, vemos que os temas são mais ou menos os que se esperavam, mas há algumas surpresas:
  • Informix Warehouse Accelerator
  • Open Admin Tool
  • Funcionalidades do Informix 11.7
  • Roadmap
  • Replicação
  • Time series, Spatial e outras extensões
  • Inclusão de Informix em aplicações
  • Desenvolvimento e modernização de aplicações
  • Uma sessão sobre um projecto que integrou Informix com  BPM (Business Process Management) da IBM
  • Compressão
  • Integração com Cognos de um parceiro (ERP)
Pode saber mais no endereço da conferência ( http://www-01.ibm.com/software/data/2012-conference/ ). E se quiser combinar clima decente, bom conteúdo, boa companhia e a hipótese de acertar num jackpot onde haveria de ir? Aqui está uma situação onde não se aplica a frase "o que acontece em Vegas fica em Vegas"!