L’équipe de Visual Studio (Benoit Launay, responsable des outils chez Microsoft DPE) nous a invité à faire un WebCast sur notre technologie, fortement intégrée a Visual Studio.

J’ai donc choisi de présenter notre approche et d’illustrer comment nous travaillons pour réaliser des applications métiers. Vous me pardonnerez les quelques problèmes de son, mon pc n’est pas dans une forme olympique, et les animations des slides qui n’ont pas fonctionné non plus.

J’ai essayé de balayer l’approche en restant pragmatique, étant entendu que le délai est court, pour expliquer tout ce que notre technologie permet de faire et les bénéfices apportés. Ce que vous voyez ici en démo, est encore une démo sur Adventure Works; et oui, on ne se réinvente pas, c’est pratique d’avoir un schéma métier tout fait, et cela montre que le travail est rigoureusement le même que l’on travaille avec des nouveaux schémas ou avec des bases existantes. Enfin, presque une base existante, car l’ensemble des données a été migré de SQL Server dans Azure Storage, ce qui est une innovation en soit.

L’autre innovation majeure est que les applications qui sont développées sont nativement ajax et déjà compatibles avec la technologie HTML5, qui est une révolution du Web à venir. Aucun effort de développement particulier n’est à fournir pour avoir cette fluidité totale, c’est nativement built-in dans les applications.

J’ai également montré rapidement quelques exemples d’applications que nous avons réalisées. Notre solution est complètement opérationnelle et nous sommes capables de faire des applications métiers avec une agilité et une qualité qui n’ont pas d’équivalent sur le marché aujourdhui.

On a, en revanche, des progrès à faire en terme de communication. C’est ce que nous essayons de faire ici, notamment vis à vis des développeurs. Nous réfléchissons à quels sont les profils qui seront enthousiastes à notre approche, l’idée étant que la motivation doit être essentiellement fonctionnelle et non technique. La question de trouver les profils early adopter parmi les développeurs est loin d’être évidente, nous y travaillons, et même s’il y a déjà quelques équipes opérationnelles chez quelques clients.

S’il y a un message que j’ai envie de faire passer, c’est que je crois (les entrepreneurs ont quelques convictions étranges parfois...) que nous allons changer la façon de travailler pour une grosse partie des développeurs d’applications métiers web et mobile avec Visual Studio et Azure. Et comme ça va commencer par un petit nombre, vous êtes les bienvenus pour commencer à comprendre comment le faire, et si ça vous intéresse, de nous communiquer votre enthousiasme pour en être les prochains acteurs.

Merci encore à Benoit et à Marine pour leur accueil.

Le WebCast est disponible ici: https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=fr-FR&EventID=1032499925&CountryCode=FR

Comme j’avais refait la même vidéo de mon côté, pour palier aux problèmes de son éventuels, je la met en ligne également (il s’agit exactement la même présentation):

Le 20 mai dernier, nous avons participé à la journée BizSpark sur le Lean Startup, l’occasion pour nous de présenter 2 sessions sur le sujet.

Plus de 200 participants, des rencontres, des échanges constructifs sur le sujet.

Les slides de nos sessions sont ici et ici, et il y a un bon compte-rendu de la journée chez PIA ici.

Pour revenir à nos sessions, voici les messages que l’on souhaite faire passer.

Quelle place le développeur occupe-t-il dans la création de valeurs ?

Le développeur a le rôle fondamental d’orchestrer l’information entre l’utilisateur et la machine.

• Il doit analyser la situation, comprendre les besoins et les manques.
• Il doit concevoir les données, les traitements, les échanges, l’expérience utilisateur, l’ergonomie.
• Il doit penser à la sécurité, les performances, la montée en charge.

Doit-il pour autant écrire du code pour faire tout cela ? Le code est fragile, source de bugs, de rigidité, difficile à faire évoluer.

Notre vision est que le développeur doit être plus proche de la création de valeurs qu’il ne l’est aujourd’***. C’est le sens de l’histoire, de ne plus passer son temps à s’occuper des détails techniques:

• Il y a 20 ans, il était nécessaire d’écrire du code pour gérer finement la place des octets sur le disque.
• Il y a 10 ans, le développeur devait faire attention à gérer correctement la mémoire, et à bien désallouer toutes les ressources qu’il avait allouées précédemment.
• Aujourd’***, on ne s’occupe plus de savoir où sont les machines physiques, ni le lieu de stockage.

Et on prétend même qu’on n’a plus besoin d’écrire la moindre ligne de code spécifique pour afficher/transporter/stocker des données métiers.

Et pour être efficace dans ces taches, on a besoin d’outils.

• De même que l’on a besoin d’un compilateur pour traduire le code écrit en ce que comprend la machine.
• De même que l’on a besoin d’un Garbage Collector, pour gérer la mémoire comme il faut sans que l’on ne s’occupe de rien.
• De même que l’on a besoin d’une base de données, pour stocker les données sur le disque.
• On a besoin d’outils pour piloter la machine dans l’affichage, le transport, la communication, et nous sommes un de ceux-là.

Certains développeurs nous reprochent d’éliminer une partie de leur travail; oui, nous éliminons la partie stupide, répétitive, sans valeur, que la machine peut très bien faire toute seule. A condition toutefois de lui décrire ce qu’elle doit faire; c’est là où le développeur a sa valeur ajoutée. Avec sa capacité d’analyse, il peut décrire correctement à la machine ce qu’elle doit faire pour rendre le service à l’utilisateur.

Mais ce n’est pas un travail d’écriture de code, c’est un travail de description:

• c’est beaucoup plus facile à faire, cela demande moins d’efforts et moins de connaissances techniques.
• c’est beaucoup plus rapide à faire, cela demande beaucoup moins de temps.
• on fait moins d’erreurs, le résultat est beaucoup plus solide.
• et surtout, on peut modifier, effacer, recommencer, comme on le souhaite, sans remettre en cause l’existant, sans remettre en cause des journées de travail.

Et si la machine sait le faire, sans qu’un être humain ait besoin d’écrire du code, c’est que ce travail de codage n’a pas de valeur pour le produit, c’est du gâchis de temps, d’argent, d’énergie.

Un MVP en 3 jours, c’est possible !

Avec PIA, nous souhaitons montrer qu’un MVP est faisable avec un investissement minimum, dans l’esprit du Lean Startup.

Pour cela, il est préférable d’avoir une méthode et des outils.

Pour la méthode, PIA sait très bien le faire, et l’a très bien expliqué et montré:

• Donner du sens au produit, fédérer autour de l’usage.
• Cibler les utilisateurs, définir les profils, les attentes de l’innovation.
• Définir le contenu, l’architecture de l’information.
• Réaliser un prototype papier.

A partir du prototype papier, on est en mesure d’implémenter très rapidement. C’est là que notre outil entre en jeu:

• Décrire un premier modèle simple avec les données de l’application; le vocabulaire est le même que celui employé par le fonctionnel.
• Décrire les écrans; ce travail est facile, parce que le prototype papier nous dit exactement ce que l’on doit faire.
• Décrire le chargement; j’écris volontairement décrire et pas écrire, car il s’agit bien d’un travail descriptif, plus que du codage technique. Je ne sais pas où sont mes données, dans une base, dans un fichier, dans Azure Storage.

Enfin, déployer cette première version dans Azure, 3 clics de souris, 1 minute de travail.

En quelques heures, on a un premier jet qui fonctionne, que l’utilisateur peut utiliser et critiquer.

Et puisque la question a été posée, l’exemple montré sur scène représente 1/2 journée de travail pour le 1er jet, et 2h pour le 2ème; j’ai fait sur scène les modifications de développement, et il y a un travail d’intégration du design visuel, à réaliser avec une feuille de styles CSS.

En conclusion, pour revenir à l’esprit du Lean Startup, je dirais qu’on a essayé de montrer que le développeur peut et doit se rapprocher de l’utilisateur, éviter de se perdre dans des considérations techniques, qu’il faut pour cela des outils, et que l’approche est la suivante:

• L’utilisateur est au coeur du processus.
• On travaille en cycle court, très court, quelques heures suffisent pour réaliser des choses visibles et utilisables.
• L’application est toujours en état de marche, cela réduit les risques.
• Il est possible de changer les plans, le pivot est facile.

Nous aurons l’occasion d’y revenir avec des exemples concrets de réalisations.

En développement logiciel, le Minimum Viable Product (MVP) est la stratégie qui consiste à construire un produit qui a le minimum de fonctionnalités pour être déployé et exploité par les utilisateurs cibles.

Cette démarche, initiée par les gourous du Lean Startup, est généralement conseillée et appliquée à des startups qui ont vocation à développer des produits innovants. L’idée est simple:

• Aller vite dans la mise en oeuvre pour avoir un produit opérationnel rapidement, avant de ne plus avoir de ressources.
• Aller à l’essentiel, en privilégiant d’abord les fonctionnalités qui ont le plus de valeur, et ne pas se disperser dans des fonctionnalités inutiles.
• Recueillir un feedback de la part des premiers utilisateurs pour savoir si on est sur la bonne voie et compléter ensuite le produit de façon incrémentale.
• Converger vers le produit qui recueillera les feedbacks positifs, vers le produit pour lesquels un utilisateur est prêt à payer.

Dans les projets, on avait l’habitude de faire une maquette ou un prototype pour valider ce à quoi devait ressembler une application; mais on jetait systématiquement la maquette à la poubelle, parce qu’elle n’était souvent pas faite dans les règles de l’art.

Avec le MVP, on est bien dans une considération de produit testable, mais pas jetable. Le premier jet est un produit qui rend une partie du service. Le feedback de l’utilisateur potentiel a beaucoup de valeur à ce stade, car il valide ou non l’idée du produit.

Cette démarche est bien adaptée à une logique de Startup, qui a besoin d’aller vite, avant de plus avoir de ressources, et de ne pas faire de dépenses inutiles. Comme souvent les Startup visent les early adopter, qui sont, en règle général, plus indulgent sur la complétude des produits, ce n’est pas grave de proposer un produit incomplet. Ce qui est important, c’est de montrer les fonctionnalités de base, et d’avoir un retour avant d’aller plus loin. Notre imagination nous pousse souvent à penser à beaucoup de fonctionnalités, alors que la mise en oeuvre révèle que cette imagination ne correspond pas toujours à quelque chose de valable. Le feedback utilisateur est là pour guider l’évolution du produit, pas à pas, vers quelque chose qui a une vraie valeur pour l’utilisateur.

Ce n’est pas tout à fait la même chose qu’une Beta, et ce sera souvent bien plus minimal que ce que vous pouvez imaginer pour votre produit. La version Beta est déjà le résultat d’un processus abouti, qui est en phase de consolidation. Le MVP se construit au fur et à mesure, avec les early adopters; on va d’abord rechercher l’expérience utilisateur pour construire le produit.

Cette idée peut aussi s’appliquer dans le contexte d’un projet d’entreprise plus mature. Après tout, certaines sociétés ont la volonté de continuer à fonctionner avec un esprit de Startup, et l’idée de faire converger un produit au fur et à mesure des besoins, est aussi au coeur de l’agilité. Un product owner doit penser à un MVP dans son cycle de développement. Ne pas gaspiller des ressources pour développer des fonctionnalités inutiles  - le fameux YAGNI - est au coeur du Lean et une préoccupation des agilistes.

Cette démarche nécessite de pouvoir mettre en oeuvre rapidement une idée, d’avoir un résultat visible tout de suite, pour construire petit à petit à partir du résultat. Elle est possible si vous pouvez mettre en production tôt, et si vous savez travailler en cycles courts pour mettre en production souvent.

Et c’est exactement comme cela que nous travaillons, et que nous pratiquons l’agilité; on fait pousser les applications par l’usage. Et c’est possible, parce que l’on écrit très peu de code; tout simplement parce plus vous êtes léger, plus vous êtes facile à bouger.

Il y a quelques mois, nous avons rencontré la société KBCrawl, éditeur d’une solution de veille.

Pour ceux qui ne savent pas ce qu’est un projet de veille, cela consiste à collecter des informations jugées stratégiques par l’entreprise sur les différents canaux d’informations Internet (blogs, réseaux sociaux, sites, flux de news, …). Le process de veille se déroule traditionnellement en 2 étapes: la collecte d’informations, et l’exploitation. Pour la collecte, on utilise un moteur, qui va surveiller les différentes sources d’informations choisies par les veilleurs de l’entreprise, et remonter les informations pertinentes. C’est là tout le savoir-faire de KBCrawl, éditeur spécialisé sur ce métier. L’exploitation, cela consiste à mettre à disposition cette information aux différents utilisateurs; toute l’information n’a pas la même valeur pour tout le monde. Il faut donc qualifier, classer, répertorier, indexer, organiser, modifier cette information, pour que chacun, en fonction de son profil, sa fonction, ses centres d’intérêt, trouve l’information pertinente. Pour cela, un portail Intranet, de type CMS, convient bien à ce genre d’usage. C’est ce que propose également KBCrawl dans son offre avec un portail basé sur une solution open source.

Sauf que, un des clients de KBCrawl, ne veut pas de la solution open source, et souhaite une solution sur-mesure. Que faire, quand les délais sont serrés, et qu’il y a un vrai projet de développement à réaliser ? C’est là où la complémentarité avec Aspectize s’est parfaitement trouvé. N’ayant pas le temps de former l’équipe de KBCrawl, nous décidons conjointement de réaliser le projet nous-mêmes.

L’expression de besoin est très sommaire, exprimée par 15 slides, tout ce qu’on adore. A partir de là, nous allons construire au fil de l’eau la solution, avec des cycles extrêmement courts, un feedback permanent du client, qui a parfaitement jouer le jeu, et une réactivité très forte de notre part. Et tout cela est possible, parce que nous écrivons très peu de code.

• Ecrire peu de code permet d’être réactif.
• Etre réactif permet de livrer en continu.
• Livrer en continu permet d’avoir du feedback.
• Avoir du feedback permet de mieux cibler les besoins des utilisateurs.

Au total, on a réalisé une application spécifique en un temps record, et surtout avec un minimum de code, et c’est vraiment cela qui permet d’être agile. Et au passage, on s’est intégré au moteur Exalead, le moteur d’indexation choisi pour la solution, ainsi qu’au système d’authentification du client.

En général, lorsque l’on montre l’application, et que l’on explique ce qu’on a fait, nos interlocuteurs sont assez impressionnés.

Alors, si vous aussi vous souhaitez en savoir plus, venez assister à la conférence que nous co-animons avec KBCrawl le Mardi 5 Avril à 9h30, au CNIT de La Defense.

C’est gratuit, vous pouvez vous inscrire ici.

Une petite discussion à la soirée bière – très sympathique – d’Alt.net de mardi, nous a menés des propriétés automatiques du C# 3.0 à qu’est-ce que la science puis à l’analyse non standard… mais je m’égare.

Revenons au C# et à l’objet de la discussion : y a-t-il une caractéristique d’un langage qui a de l’importance ? C.-à-d. une caractéristique qui permettrait d’être meilleur informaticien, d’écrire un meilleur code, un code qui dénoue le problème métier plus efficacement, avec moins de bugs et plus de souplesse ?

Personnellement je pense que non ! Et, dans la limite des langages que j’ai pratiqués, mon argument est le suivant : de l’assembleur au JavaScript en passant par le Fortran et le C, sans oublier le C++, le C# ainsi que VB6, VB.net et VBS, bien que je trouve que l’un se démarque, et c’est le JavaScript, ils se ressemblent tous : des « si », des « tant que », des variables et des valeurs, des points virgules et des accolades, du « case sensitif » ou pas… bref ils se différencient sur des détails alors que le problème est ailleurs. Qu’en pensez-vous ?

Aspectize est présent aux TechDays sur le stand de Bizspark.

Venez nous rendre visite sur le stand C02, nous aurons l’occasion de faire des démonstrations agiles, et notamment sur la plate-forme Azure.

Vous avez des interrogations pour migrer vers Azure ? Venez voir comment assurer la totale réversibilité des applications entre un environnement OnPremises et la plate-forme Azure, afin de vous laisser la liberté de passer d’un monde à l’autre et inversement.

Vous avez des réticences parce que la plate-forme Azure constitue un nouvel environnement qu’il faut apprendre ? Venez voir comment réduire la courbe d’apprentissage en permettant à vos développeurs de construire vos applications sans effort particulier pour la plate-forme Azure.

Vous avez des hésitations sur le meilleur choix de gestion de données dans Azure ? Venez voir comment gérer les données de façon complètement transparente, entre SQL Server, SQL Azure et Azure Storage, afin de vous permettre une cohabitation sereine entre ces différents systèmes, et de bénéficier du meilleur prix.

Vous avez des doutes sur la capacité de la plate-forme à vous permettre d’être agiles ? Venez voir comment déployer instantanément une application dans Azure, comment gérer facilement les différentes versions.

Ou bien vous en avez tout simplement assez des projets qui coutent trop cher, et qui ne sont jamais livrés à dans les délais prévus ? Venez voir comment mettre à disposition une application dès le premier jour du projet, et diminuer de façon drastique les couts de développement.

Bref, si êtes curieux de découvrir une solution innovante pour faire des applications .Net Azure plus facilement, vous êtes les bienvenus.

Scientipole Initiative est un organisme de soutien des entreprises innovantes. Le soutien se matéralise sous plusieurs formes:
- Financière, avec des prêts d’honneur aux entrepreneurs
- Conseil, avec des missions d’accompagnement sur des problèmatiques juridiques, financières, commerciales, marketing...

Après une expertise menée par un expert qui étudie le business plan de l’entreprise, une commission d’une dizaine d’experts a validé l'attribution d’un prêt d’honneur aux fondateurs de la société.

Nous sommes ravis de cette décision, qui, au delà des aspects purement financiers qui font toujours du bien, nous permet également d’intégrer un réseau d’experts et d’entreprises innovantes, et d’obtenir ainsi une nouvelle marque de confiance sur notre développement.

Dans le précédent billet, nous avons introduit la notion de complexité cérémoniale en la définissant comme une complexité inutile qui naît de l’amalgame incontrôlé entre code technique et code métier. Cette fois nous allons voir comment l’approche Architecture en tant que service nous aide à éliminer cette complexité cérémoniale du système d’information.

Architecture en tant que service

Un système d’information est composé de divers aspects techniques et métier : données, traitements, interfaces utilisateur, stockage, communication, robustesse, performance…

Deux facteurs sont à l’origine de la croissance explosive de la complexité dans les systèmes d’information : d’abord les dépendances entre technique et métier ainsi que les dépendances à l’intérieur des aspects métier. Ensuite la quantité de code et d’artifices techniques qui sont introduits pour essayer de maîtriser ces dépendances.

Aujourd’hui, on ne peut que constater l’échec récurrent des outils, des infrastructures, des design pattern et des méthodologies mises en œuvre pour maîtriser cette croissance incontrôlée de complexité. Ils échouent car ils introduisent du code : du code pour séparer les aspects techniques des aspects métiers, du code pour communiquer, du code pour l’accès aux données… Parfois ce code est généré automatiquement, souvent il est codé à la main, mais il est toujours fragile et source de friction, il entraîne manque de souplesse, dépassements des délais, dérives des coûts, déceptions.

L’architecture en tant que service (Architecture as a service, AaaS) est une nouvelle approche et un ensemble d’outils, conçus pour éliminer la complexité cérémoniale, permettant souplesse et alignement des systèmes d’informations sur les besoins du métier.

L’architecture en tant que service atteint ce but en réutilisant le réutilisable, à savoir le code technique ; en séparant le code technique du code spécifique métier ; en éliminant le code sans valeur ; et en imposant une structure cohérente au processus de développement. Elle peut ainsi être considérée comme la première approche systématique et lean du développement logiciel.

Le code technique est nécessaire pour gérer la robustesse, la souplesse, les performances, pour lire, écrire, afficher et échanger les données. Au lieu de l’écrire, l’architecture en tant que service utilise un moteur technique pour traiter ces besoins invariants.

Le code métier qui sert à traiter, valider et automatiser les processus métier est le seul code qu’on doive écrire. En revanche, l’intégration du code technique avec le code métier n’a nul besoin d’être codée et peut être obtenue par une approche bien plus souple.

Contrairement aux infrastructures et approches traditionnelles qui proposent un API et qui invitent à coder, le moteur technique AaaS alimenté par la conception métier, fournit ses services de façon déclarative.

Dans un prochain billet nous parlerons du rôle de la conception (des données, de l’expérience utilisateur et des communications) du point de vue AaaS.

En vous souhaitant moins de code et plus de réussite pour 2011.

In the last post we introduced the idea of ceremonial complexity by defining it as avoidable complexity that emerges essentially from uncontrolled mangling of technical code with business oriented code, this time we will briefly see how Architecture as a Service helps eliminate ceremonial complexity from an Information System.

Architecture as a service

Information systems are composed of different business oriented and technical aspects, such as Data, Code and User interaction, Storage, Communication, Robustness, Performance…

Two factors are at the origin of explosive growth of complexity in information systems: first the number of dependencies between and within each of these aspects, second the amount of code and technical diversities that are introduced to handle them.

Today almost all tools, frameworks, design patterns and methodologies that attempt to tackle the problem of uncontrolled growth of complexity fail. They fail, by introducing code; code for separating different technological and business related aspects, code for communication, code for data access… sometimes this code is generated, often hand coded, but always fragile and change adverse and entails lack of flexibility, missed deadlines and disappointment.

Architecture as a service is a novel approach and set of tools, designed to contain software complexity and thus enables flexible alignment of the information system on business requirements.

Architecture as a service meets its goal by reusing the reusable i.e. technical code, separating the separable i.e. reusable technical code from custom business oriented code and design, by eliminating valueless code, and by enforcing a consistent structure to the development process and thus can be considered as the first systematic and lean approach to software development.

Technical code is required for taking care of robustness, flexibility, performance… but also for reading, writing, displaying, exchanging… data.

Architecture as a service enforces the reuse of a technical runtime for invariant technical requirements.

Business oriented code for automating, computing or validating business related processes and data is the only code that should be developed.

What is definitely not needed is code for integrating technical with business oriented aspects this can be handled with a more flexible approach than coding.

Unlike traditional frameworks or runtimes that propose an API and hence request coding, an AaaS runtime, fueled by design, delivers its facilities through declarative binding.

In our next post we will talk about the role of design (Data, Communications, UX) from an AaaS perspective, stay tuned…

La notion de complexité est bien étudiée et documentée en informatique, mais ce n’est pas celle qui fait souffrir l’industrie du développement logiciel. Ainsi pour notre part, nous distinguons deux sortes de complexités : la complexité naturelle et la complexité cérémoniale.

La complexité algorithmique et la complexité inhérente à un processus métier relèvent de la complexité naturelle. La complexité naturelle se contrôle. Elle peut être documentée, maîtrisée et communiquée.

La complexité cérémoniale, quant à elle, s’immisce insidieusement dans le système, instruction après instruction, jour après jour. Complexité inutile, elle provient essentiellement de l’amalgame incontrôlé entre code technique et code métier, mais aussi du défaut de structure et d’uniformité dans le système.

Aujourd’hui, le développement des systèmes d’information est empoisonné par cette complexité cérémoniale qui cause échecs et gaspillages. Pourtant, cette complexité cérémoniale pourrait être éliminée.

Autant la notion de complexité est un sujet académique bien étudié, autant la notion d’architecture en informatique est floue et s’articule différemment selon les projets informatiques.

En électronique ou en ingénierie civile, l’architecture existe dans le produit, mais que ce soit un pont, un barrage ou un microprocesseur, cette architecture ne peut pas être séparée du produit. On pourra toujours en extraire une vision d’ensemble décrivant ses éléments et leurs relations, il s’agira d’un plan, pas d’une des pièces du produit : la structure est inséparable de la matière.

Inversement, dans le cas de l’ingénierie des systèmes d’information, le produit final étant lui-même immatériel, l’architecture peut être non seulement séparée du produit, mais si on fait abstraction des spécificités métiers, elle peut même être développée et livrée séparément : c’est l’objet de l’approche « architecture en tant que service ».

En effet, les besoins techniques sont des besoins invariants et donc prévisibles. Leurs cycles de vie suivent les cycles technologiques et non métier. Tout le code dont on a besoin pour lire, écrire, distribuer, échanger et afficher des données est du code technique et peut ainsi être développé et livré séparément du code métier.

Ainsi l’architecture peut être vue comme un service logiciel en lui-même : un exécutable technique conçu, développé, testé et débugué, contenant du code technique invariant nécessaire pour « faire pousser » des systèmes d’information.

Cette architecture en tant que service (« Architecture as a service ») soustrait la complexité cérémoniale du système d’information en lui imposant structure et uniformité et en éliminant le code technique fragile, sans valeur et source de friction.

Dans un prochain billet nous vous présenterons plus en détail la méthode, le rôle de la conception et les outils de développement à utiliser pour éliminer la complexité cérémoniale de vos systèmes d’informations.

If you search for the meaning of architecture or complexity you will come up with a large spectrum of definitions, articles and analysis… Each field or author will be likely to give a particular meaning to these words and software engineering is no exception.

In the following paragraphs we will describe our standpoint on architecture and complexity in the context of engineering information systems.

It’s our understanding that architecture and complexity balance each other; more architecture is less complexity and less architecture is more complexity.

There are two sorts of complexity: natural complexity and ceremonial complexity.

Natural complexity can be controlled; Algorithmic complexity is natural complexity; complexity that is inherent to a business process is natural complexity. Natural complexity can be documented, learned, mastered and communicated.

Ceremonial complexity on the other hand is complexity that creeps into the system instruction by instruction, day after day. Ceremonial complexity - unnecessary complexity - emerges essentially from uncontrolled mangling of technical code with business oriented code, but also from lack of structure and uniformity in the system.

Today the entire complexity that haunts the development of information systems and causes failure and waist is ceremonial complexity; complexity that can be eliminated, eliminated by architecture.

Architecture in civil engineering or electronics is present in the manufactured product, be it a bridge, a dam or a microprocessor and cannot be produced apart… At best it can be abstracted out as a big picture of the product describing its parts and their relations thus being more of a plan than constituent of the product.

Due to the abstract nature of information and software, architecture, in the context of engineering information systems, can be both a plan and a product; furthermore it can be abstracted away of all business considerations.

Technical requirements are invariant, thus predictable, their life cycle follows technological life cycle. All code needed for reading, writing, dispatching, exchanging and displaying data is technical code and thus can be developed and delivered separately.

Architecture, as we see it, is a software service by itself; a technical runtime designed, developed, tested and debugged, containing boiler plate technical code needed for growing information systems.

Architecture as a service contains software complexity by enforcing structure and uniformity and by eliminating valueless, fragile, change adverse, technical code.

In following posts we will describe the role of design and code from an AaaS perspective and show, by introducing new tools, how to use piecemeal design and development to grow your Information Systems out of applications each containing data, services and user interface elements.

AaaS bridging the gap between PaaS and SaaS.

Le MUG Lyon, est une association qui a pour objectif d’animer des sessions sur les technologies Microsoft (MUG signifie Microsoft User Group). Elle a démarré l’été dernier, à l’initiative de Rémi Moriceau, un ancien de Winwise, qui s’occupe désormais de l’enseignement à Epitech Lyon.

Et Remi nous propose de participer à la prochaine session, le 25 Novembre. Nous répondons avec plaisir à son invitation.

La session aura lieu en 2 parties, avec le programme suivant:

• 1ère partie de 19h30 à 20h30

  L’orienté objet : erreur historique ou voie à poursuivre ?

  • Pourquoi ce titre ?
  • Crise logiciel : mythe ou réalité ?
  • L’orienté objet quelques définitions
  • Du rigide au souple : une histoire accélérée de l’informatique

• 2ème partie de 20h30 à 21h30

  Architecture as a Service (AaaS)

  • Une nouvelle approche pour le développement des SI
  • Les différentes formes de complexités
  • Architecture et complexité
  • Le rôle de la conception
  • Les différentes sortes de binding
  • Les outils

Toutes les informations utiles sont disponibles sur le site de l’association.

Les plus perspicaces auront remarqué que cette manifestation se déroule le même jour que le MDDay parisien, à laquelle nous participons également. Et de la même manière que nous faisons des miracles en matière de développement, nous serons bien présent aux 2 événements le même jour dans 2 villes différentes ;-)

Nous avons l'honneur d'être partenaire de la journée MDDay.

Comme son nom l'indique, MDDay est une journée consacrée au Model Driven.

Au programme, essentiellement des présentations autour des bonnes pratiques et des outils en vigueur. La majorité des intervenants sont des éditeurs de logiciels, et les témoignages clients sont nombreux. En tout cas, il y aura du beau monde, et surement des débats passionnants.

De notre côté, nous seront présents sur le stand de Microsoft (notre présence donnera un peu plus de poids à .Net, car, même si l’évènement a lieu chez MS, la majorité des intervenants vont parler Java), et nous essaierons de montrer que le MD, ca sert surtout à éliminer du code ! il y a quelques mois, j'avais tenté d'expliquer en quoi notre approche se rapprochait du Model Driven, surtout dans l'esprit du Modèle Exécutable, qui permet justement d'éliminer le code, au lieu de le générer, ce qui nous parait avoir beaucoup plus de valeur et faire sens en matière d’agilité.

Et on va pouvoir montrer des vraies applications qui tournent, avec des vrais modèles et des morceaux de code-ni-écrit-ni-généré dedans ;-)

L’évènement a lieu le Jeudi 25 Novembre, chez Microsoft, et pour s’inscrire, c’est par ici.

Notre page partenaire est là.

Après une année passée chez Paris Développement, nous quittons l’incubateur pour intégrer la pépinière de l’Essec Ventures.

Nous retenons de cette année:

• la logistique: les locaux, le mobilier, les services, c’est bête à dire, mais un fax et une photocopieuse sont toujours utiles.
• les animations nombreuses de l’association Paris Développement: ventes, marketing, RH, financement, networking, juridique, propriété industrielle, les sujets présentés sont nombreux et variés. Les interlocuteurs ont tous une expertise sur leur domaine, et sont aussi là pour faire du business. La formule est bonne, puisque certains sont d’ailleurs devenus nos fournisseurs.
• L’accompagnement: mené par les chefs de projets, un point mensuel permet de définir l’avancement sur la R&D, le business, le financement, et tout ce qui touche au développement de la société. C’est très enrichissant d’avoir un moment d’échange sur la stratégie, avec des personnes externes de l’entreprise, qui ont un regard différent, une expérience à partager.
• le réseau: c’est sans doute là, que la dimension d’incubateur est la plus importante. Intégrer un réseau, avec des connexions multiples; start-up, business angels, mentors, financiers, experts, c’est toute une communauté qui échange, et des mises en relation toujours très intéressantes. Plusieurs de nos prospects sont directement issus de ces mises en relation.

Puisque la période d’incubation est limitée à un an – nous serions bien restés, mais il faut aussi laisser la place aux autres – je ne peux qu’encourager les start-up de tout poil à postuler, vous ne serez pas déçus (à l’exception du café, seul point noir au tableau, la machine en libre service fait du mauvais café, et nous avons investi dans une machine Nespresso dès le premier jour).

Et maintenant, nous changeons d’environnement.

Tout d’abord le quartier; moins de textile, plus de banquiers, nous sommes en plein cœur de la Défense.

Les locaux sont tout neufs, le CNIT a refait peau neuve, et ce n’est pas désagréable de se trouver dans un lieu comme ça:

La proximité de l’ESSEC Business School en fait un environnement incontestablement plus orienté business.

Organisés en Open Space, et non plus en bureau fermé, l’ambiance de travail sera surement différente.

Enfin, le réseau, d’autres partenaires, d’autres relations à découvrir.

La vidéo du Tutorial

Design du Schéma

Nous allons ajouter les Entités qui contiennent les images des produits. Les images sont contenues dans la table ProductPhoto, qui est associée à la table Product avec la table ProductProductPhoto.

Dans Visual Studio, ouvrez le Schéma AdventureWorks.Entities. Ouvrez le Server Explorer. Avec la touche Ctrl enfoncée, sélectionnez les 2 tables ProductPhoto et ProductProductPhoto et dropez les dans le Schéma.
Une nouvelle Entité et une Relation sont créées dans le Schéma. Comme la table ProductProductPhoto a une ForeignKet vers la table Product, la relation est automatiquement créée avec l’Entité Product du schéma. La relation est une relation 0-N/0-N, mais il n’y a qu’une seule photo par Product. L’image du produit est dans la colonne LargePhoto, qui est de type ByteArray. Sauvez le Schéma.

Ecriture du code de chargement de l’image

Nous allons ajouter une commande pour charger l’image à partir de la base de données.

Byte[] LoadProductPhoto(int productId);

byte[] IADWService.LoadProductPhoto(int productId)
{
    IDataManager dm = EntityManager.FromDataBaseService("DataAccessAdventureWorks");
    List<ProductPhoto> productPhotos = dm.GetAssociated<ProductPhoto, ProductProductPhoto>(productId);
    if (productPhotos.Count > 0)
    {
        return productPhotos[0].LargePhoto;
    }
    return new Byte[0];
}

Ajout du contrôle pour afficher l’image

<tr>
    <td align="right" style="width:200px">Photo:</td>
    <td style="width:200px" ><div aas:name="ProductImage" class="AspectizeImage"></div></td>
</tr>

Binding de l’image

Nous allons maintenant bindé notre contrôle. Ce binding est un peu particulier, car nous n’allons pas bindé de propriétés du controles sur les données du DataSet, mais utiliser directement le binding de la commande sur un événement du contrôle.

Dans BindingStudio, ouvrez la vue ADWProduct. Ajoutez un Binding sur le contrôle ADWProduct.ProductImage.
Ce contrôle n’a pas de propriétés bindables pour afficher l’image, mais un évènement OnNeedImage. Cet évènement est dynamique, c’est à dire qu’il est levé lorsque le paramètre de la commande bindée change de valeur. Bindez cet événement sur notre commande serveur. Le retour de la commande n’est pas bindé dans le DataSet.
Bindez le paramètre sur l’identifiant du product qui est sélectionné. Sauvez la configuration.

Si nous lançons notre application, nous constatons bien que le controle image affiche la photo du produit.

A chaque sélection de produit, l’image associée est affichée.

Comprenons la cinématique d’échange:

- lorsque l’on sélectionne un Product, le productId prend la valeur du Product sélectionné.

- l’événement dynamique est levé, car le paramètre de la commande a changé de valeur.

- le contrôle Image fabrique une url avec le nom de la commande et le paramètre productId

- le browser appelle l’url, dont le type de retour est un mime type image

- le serveur appelle la commande avec le paramètre productId et renvoie le ByteArray qui représente l’image du produit

- le browser affiche le contenu sous forme d’image

Les échanges entre client et serveur sont minimes, seul le contenu de l’image est échangé, quand nécessaire.

Nous avons affiché une image, sans création de fichier temporaire sur le serveur, en bindant directement un contrôle sur une commande server.

La suite au prochain épisode.