Stephen Brobst,CTO de Teradata : "la BI, un des seuls segments en croissance"
Publié par La rédaction le - mis à jour à
Echange avec Stephen Brobst, directeur technique de Teradata : les opportunités liées à la crise, Microsoft, Qliktek et Oracle.. Des analyses franches et sans concession.
Crise économique, communauté de développeurs, Microsoft, Qliktek, Oracle. Le directeur technique de Teradata Stephen Brobst livre son analyse du marché de la Business Intelligence Tous les éditeurs clament l'opportunité liée à la crise. Les entreprises auraient-elles encore autant d'argent pour investir en informatique ?
Dans la conjoncture de crise actuelle, les décideurs se doivent d'investir sur ce tout ce qui permet de gérer plus efficacement et de mieux analyser ce qui se passe dans les activités de l'entreprise. Cette tendance ne privilégie pas les dépenses en progiciels de type ERP, par exemple. En revanche, la BI s'impose car elle permet de mesurer le risque de comprendre et d'anticiper les situations.
D'ailleurs, l'exercice 2008 a été très bon pour Teradata, et excellent sur le secteur de la finance. La quasi-totalité des géants financiers compte parmi nos clients. Ceux qui ont saisi la BI et mesuré les impacts ont pu limiter les dégâts de la crise. D'ailleurs, la majorité des banques de premier rang ne sont pas tombées, et les banques de second rang ont plus souffert. Ainsi, notre client Bank of Americaa racheté Merryll Lynch (qui n'était pas un client Teradata). Néanmoins, restons prudents : la technologie ne reste qu'un facilitateur ["enabler"] et pas une solution unique à tous les problèmes.
Bien sûr, les négociations avec les clients sont devenues plus difficiles et plus longues. Mais globalement, la BI reste l'un des seuls segments qui enregistreront une réelle croissance en 2009, essentiellement dans le secteur financier. Toutefois, des secteurs comme l'Industrie étant beaucoup plus touchés par la baisse de la consommation sont obligés de ralentir tous les investissements.
Vous lancez aujourd'hui la communauté Teradata Developer Exchange sur les sujets BI. Coup marketing pour attirer les informaticiens ou vrai lieu d'échange entre développeurs ?
Nous lançons ce service conçu par des développeurs et pour des développeurs. Teradata Developer Exchange est clairement et exclusivement réservé aux développeurs, et aucun profil marketing de Teradata n'est autorisé à y participer. Ce réseau d'échange reste purement technique. Et tous les développeurs sont les bienvenus pour échanger et partager leurs idées, leurs codes. sur les multiples thématiques. Chacun peut y trouver des codes de programmes provenant de clients, de partenaires commerciaux ou d'experts Teradata. Chez Teradata, environ 50 personnes collaboreront régulièrement à cette communauté. Par ailleurs, nous essaierons de modérer au mieux les échanges. Ainsi, certains contributeurs pourront se voir attribuer le statut de "trusted contributor" [participant de confiance, ou fiable].
Que pensez-vous du retrait de Microsoft du CPM, avec sa solution PerformancePoint Server ?
Microsoft a fortement fait évoluer la concurrence et les prix en rendant la Bi accessible à plus d'entreprises. Toutefois, je préfère lorsqu'ils se concentrent sur ces aspects. Au départ, SQL Server était raillé et semblait très léger, sans parler des fonctions BI. Pourtant, aujourd'hui Microsoft est devenue un acteur sérieux des bases de données. Si les Reporting Services et Analytic Services sont intéressants, les tentatives de constructions cubes Olap se sont vite révélées catastrophiques, et pas seulement chez Microsoft. C'est donc une bonne nouvelle que Microsoft se concentre sur sa base de données, et noue des partenariats avec nous pour les bases de données de volume. Pour de très forts volumes de transaction, SQL Server peut se montrer un peu léger, mais convient pour nombre de PME. À chacun ses spécialités.
Quel est votre avis sur le petit challenger Qliktek qui parvient à faire parler de lui avec sa technologie In-Memory ?
Les démonstrations de Qliktek sont très impressionnantes, mais ces technologies rencontrent vite des limites lors de fortes montées en volume. D'ailleurs, les aspects les plus innovants reposent bien plus sur les interfaces ergonomiques et de présentation que sur la technologie In-Memory. D'ailleurs, l'équilibre et la répartition entre mémoire et stockage évoluent sans cesse. Et les disques flash [SSD] vont se démocratiser et donc devenir bien plus abordables. Une tendance qui estompera les comparatifs de performance entre accès en mémoire ou sur disque. D'ailleurs, il suffit d'installer sur ces disques flash les 20 % de données utilisées dans 80 % des cas par les entreprises pour gagner en performance. Selon moi, nous parviendrons à cette situation dans 18 mois à deux ans environ.
Votre prochain sérieux concurrent logciel+machine dédié au datawarehouse pourrait-il s'appeler Oracle/Sun ?
Tout d'abord, je pense que Spark est mort, et l'était déjà lors du rachat. Oracle finira de le tuer très rapidement pour favoriser des architectures de serveurs basés sur des architectures x86. Et bien entendu, Oracle multipliera les appliances applicatives sur serveurs x86.
Mainetnant, si vous demandez au marketing d'Oracle s'ils vont développer des solutions de datwarehouse comme les nôtres, ils répondront « Oui ! » sans hésiter. Si vous en discutez avec des informaticiens, le discours sera certainement différent. D'ailleurs, on peut le constater avec les offres Exadata Oracle/HP. Si ces architectures permettent de multiplier les entrées-sorties, elles ne permettent pas aux solutions Oracle de nous suivre sur les très hautes performances. Conçue dès l'origine pour les transactions OLTP, le SGBD d'Oracle ne peut rivaliser en souplesse et en performance.
Pour bien faire, il faudrait qu'Oracle revoie toute l'architecture de base de ses solutions, et cela s'avèrerait très délicat. Ce serait pourtant le seul moyen pour que le SGBD puisse gagner en performance et en partage. Quant aux NAC, load-balancing et autres qui n'interviennent que sur les couches hautes, c'est ce que nous autres Américains appelons « putting lipstick on a pig » (mettre du rouge à lèvres sur un cochon).