July 2010 - Messages

Aspectize MSV = MVC + SOA + ORM + ESB
08 July 10 03:32 AM | Nico | avec no comments

Lors de notre élaboration de notre marketing stratégique, une question importante se pose sur notre catégorie; dans quelle catégorie voulons nous apparaître ?

La catégorie est essentielle parce qu'elle permet rapidement à nos interlocuteurs de nous positionner, et d'évaluer notre proposition de valeurs relativement aux autres outils de la même catégorie. Et c'est une question difficile, parce que notre approche est suffisamment différente pour que l'appartenance à l'une d'elle ne saute pas forcément aux yeux.

Aujourd'***, il nous est plus facile de dire dans quelle catégorie nous ne sommes pas. Par exemple, nous nous démarquons fortement des principales catégories des outils de développements:

 

• les Frameworks, qui proposent des API et pour lesquels il est nécessaire d'écrire du code pour les utiliser. Nous n'avons pas d'API (hormis le chargement des données qui nécessitent aujourd'*** d'écrire du code), et nous encourageons à écrire le moins possible de code. Nous réduisons significativement les API .Net à connaître pour développer une Application.
• les Générateurs de Code, qui proposent des outils de modélisation, mais dont la sortie est un code à intégrer dans une solution, complété par du code métier et compiler pour donner l'application finale. De ce point de vue, nous sommes plutôt un éliminateur de code.
• les AGL, qui propose des boites noires souvent fermées de plus haut niveau qui permettent de développer vite, mais qui vieillissent mal et s'intègrent mal avec l'existant. Nous sommes complètement intégrés à l'environnement .Net.
  
  

Si l'on se place du point de vue des briques qui constituent une Architecture d'Entreprise, on peut considérer les catégories suivantes, qui représentent à peu près les règles de l'art en la matière:

 

• les ORM, qui s'apparentent à des Framework ou des générateurs de code pour faciliter l'accès au stockage des données.
• les ESB, qui sont plutôt des middlewares, qui facilitent la mise en œuvre d'une SOA.
• les Framework MVC, qui sont le modèle le plus répandu pour réaliser l'IHM des applications.
  
  

Chacune de ces briques adressent bien des fonctionnalités de l'architecture, que nous adressons également, nous sommes donc un peu tout cela à la fois...

Et pourtant, quand on regarde comment Microsoft nous invite à réaliser ces différentes briques, on s'aperçoit qu'elles nécessitent beaucoup de code pour être implémentées. Cela vient principalement de l'approche orientée objet et du typage fort utilisé à tous les niveaux.

Notre vraie différence est d'avoir choisi une autre approche, ce qui nous permet d'éliminer l'essentiel du code à écrire, avec une séparation bien plus nette entre les différents éléments (vu qu'il n'y a plus de code pour les lier). Nous avons permis d'unifier toutes les briques de l'Architecture et de faire tout-en-un, beaucoup plus facilement.

Notre Modèle relationnel permet de définir les fonctions de mapping avec le stockage, ce qui offre les bénéfices d'un ORM, sans les inconvénients du mismatch entre le monde objet et relationnel. Meilleur mapping (pas de soucis pour les relations N-N par exemple), requêtage beaucoup plus facile (extraction de graphes et lazy loading trivial), support du n-tiers.

Nos Vues sont bindées dynamiquement sur le Modèle, ce qui correspond bien à la logique du MVC. Notre moteur de binding est en quelque sorte le C, le contrôleur universel, qu'il n'est pas nécessaire d'écrire, et avec lequel une logique déclarative suffit. Les vues sont des contrôles purs, il n'y aucun éléments du modèle qui intervient pour définir la vue, la définition du binding est externe à la vue. Cela permet une séparation définitive entre la présentation, au sens ergonomie et design, et le Modèle.

Notons au passage que le Modèle est bien le même que celui qui est utilisé pour le mapping avec le stockage et pour le binding avec les Vues. Et comme le binding est réalisé sur le client, vous disposez d'une Application Ajax native, et vous limitez les allers et retours avec le serveur à des échanges de données uniquement.

Nos Services sont découverts et appelés dynamiquement dans un contexte complètement distribué ce qui correspond bien aux fonctionnalités d'un ESB dans le monde .Net. Vu que l'ensemble du code est dans des Services, qui sont directement drivés par les besoins métiers, l'architecture SOA est naturellement réalisée sans avoir à écrire le moindre code technique.

Finalement, il reste bien un triptyque Modèle/Service/Vue, qui suffit à bénéficier de toutes les fonctionnalités d'une Architecture d'Entreprise: MVC, SOA, ORM et ESB.

Alors, est ce que la catégorie MSV reste à inventer ?

 

Classé sous : Architecture, Approche, Startup, Marketing

Mentoring Day
03 July 10 01:38 PM | Nico | avec no comments

Parmi les nombreux événements organisés par notre incubateur Paris Innovation, avait lieu vendredi dernier une session de Mentoring.

10 entreprises de Paris Innovation Bourse, étaient challengées par une quinzaine de mentors du réseau Paris Mentor. Paris Mentor est un réseau d'entrepreneurs et de managers de très haut niveau, qui consacrent une partie de leur temps à aider les entreprises innovantes, en leur transmettant des retours d'expérience sur des points précis et notamment stratégiques pour l'entreprise. Le mentor peut aussi servir de relais à l'entreprise, et lui ouvrir son réseau. La plupart des mentors ont ou ont eu des postes de hautes responsabilités dans des grandes entreprises, ou sont des entrepreneurs confirmés. Ils sont issus du monde industriel, du monde logiciel ou des médias numériques. Ils sont parfois business angels, avec des participations et/ou une présence dans les board de plusieurs startup. Ils connaissent bien le monde de l'entreprise et aussi des technologies.

 

Les sessions avaient lieu en 2 parties:

• un pitch de 5 minutes de chaque entreprise devant l'ensemble des Mentors
• 3 sessions de retours et d'échanges de 30 minutes, en petits groupes; nous étions en binôme avec BrightLoop, avec qui il était très intéressant d'échanger sur nos entreprises.

 

Pour le pitch, nous avons fait le choix de présenter l'essence et les bénéfices de notre approche, avec des slides illustrées, façon zen presentation. Cela sortait clairement du cadre des présentations classiques attendues dans ce genre d'exercice, qui ont un plan souvent destiné à des investisseurs, et relativement standard. Nous avons fait ce choix, parce que nous ne sommes pas en train de lever des fonds ni de nous adresser à des investisseurs et parce que nous espérons susciter enthousiasme et curiosité.

 

 

 

 

Ensuite, avaient lieux les sessions de retour, durant lesquelles nous avons eu droit à des retours enthousiaste ("ébahis" par notre présentation, cela fait plaisir), neutre ("je n'ai rien compris, car je ne connais pas du tout votre métier") et aussi un très négatif ("complètement à côté de la plaque"). Puis les conseils pratiques, comme quoi il faut être plus précis, sur la terminologie et qu'évidemment notre promesse est éculée, et nous devons être plus convaincant.

Outre les questions et remarques traditionnelles sur le fond, notre trésorerie, notre vision de l'écosystème, notre système de ventes, je crois que ce qui manque, en tout cas pour ceux du métier du logiciel, c'est notre catégorie. Nous avons d'ailleurs eu une discussion très intéressante qui nous a poussé à expliquer que nous étions le contrôleur universel du modèle MVC. Visiblement, cette précision a plu, je ne sais pas si nous l'intégrerons dans notre discours, c'est peut être une idée à creuser.

Plusieurs de nos interlocuteurs nous renvoient un signal qui témoigne une certaine curiosité, comme si le charme avait quelque peu opéré. Pour ceux qui ont connus une proximité avec de grands projets informatiques, l'histoire que nous racontons leur parle, elle fait écho par rapport à leurs vécus. Ils voient très bien les analogies que nous employons, même s'il manque le côté opérationnel. Comment peut s'intégrer une solution comme la nôtre dans un existant ? A quel niveau impacte-t-on l'organisation en place ? Quelles sont les entrées-sorties de notre logiciel ? Ce sont d'excellentes remarques, sur lesquelles nous devons affirmer notre discours, et surtout être capable de le formuler de façon claire et concise. Quand j'ai argumenté la non-présence de ces informations dans notre présentation (nous avons tout de même des éléments de réponses) par la faible durée du pitch, 5 minutes c'est très court, plusieurs intervenants m'ont répondus fort justement, que ce n'était pas une raison valable. 

Si nous avons choisi d'insister sur le Why, sur les raisons qui nous ont poussé à créer Aspectize, c'est parce que ces raisons-là sont déterminante dans notre projet, et qu'il nous parait intéressant de le dire. Le How était très succinctement exposé, peut être sur le caractère que l'on considère le plus différenciant (principe de Hollywood). S'il est extrêmement difficile de résumer le How en quelques minutes, nous sommes passés à côté du caractère différenciant, ce que nous ne sommes pas. Le What, quant à lui, n'a quasiment pas été évoqué, et le Cloud doit être mis en avant beaucoup plus tôt, car c'est la tendance actuelle du marché.

Etre capable de pitcher en 5 minutes, sur le Why/How/What de son entreprise est un exercice que se doit de réussir tout entrepreneur. Avec le feedback des mentors, nous avons des pistes très claires pour améliorer nos présentations, avec l'objectif de cibler les intérêts des décideurs. Petit à petit, nous perfectionnons notre discours, les éléments marketing se mettent en place. Lorsque ce discours sera alimenté par nos références, de véritables retours d'expérience réussie, je crois que nous commencerons à avoir un discours bien construit et qu'il sera le moment de faire beaucoup plus de bruit.

Je remercie en tout cas Paris Mentor et Paris Développement pour cette initiative, qui nous permet de progresser. En nous challengeant avec des décideurs de haut niveau, on ne peut que mieux se préparer au grand bain dans le business.

Classé sous : Entreprise, Approche, Startup, Marketing