VISER LA PERFORMANCE EN MODE AGILE Part III (Team Empowerment)

Aucun d’entre nous n’est plus intelligent que l’ensemble d’entre nous.
Kenneth Blanchard

La formule de Norman Maier : E = Q x A.

Efficacité de la décision = Qualité de la solution x Adhésion.

L’empowerment est une des clefs fondamentales pour développer la performance des entreprises car il est axé sur la capacité à savoir engager les équipes pour les responsabiliser et susciter un travail collectif.  (Claire Leduc)

Comment faire ? 

Partager l’information : vision, mission et objectifs

• Partager un maximum d’informations concernant l'organisation et le service à l’ensemble des collaborateurs.

• Lorsqu’un manager/leader partage ses informations, ses bonnes et mauvaises nouvelles, il commence à gagner la confiance de ses collaborateurs et de son équipe.

• Le manque de clarté est néfaste à la responsabilisation des collaborateurs et au développement de leur motivation. 

Autonomiser en fixant des limites claires

• Il est primordial de fixer clairement les nouvelles règles du jeu, les nouvelles responsabilités étant précisées par un ensemble de limites clairement énoncées

• Au niveau individuel, le manager/leader et le collaborateur peuvent définir conjointement un ensemble d’objectifs et de projets destinés à donner le cadre de leur partenariat. 

• Les règles, Les limites et la structure ont paradoxalement besoin d’être clarifiées très précisément pour permettre plus de liberté d’action et d’initiative de la part des collaborateurs

Travailler et décider en équipe

• L’équipe devient l’organe de décision. Travailler et décider systématiquement en équipe permet un niveau de performance et des résultats au-delà des objectifs

• Le réflexe le plus fréquent du manager qui fait face à un problème à résoudre ? Chercher tout seul la meilleure solution pour ensuite au mieux la proposer, au pire l’imposer à son équipe par mail ou présentation ?

• Les idées du groupe auront toujours une longueur d’avance sur celles d’un leader ou d’un expert technique élaborées dans son coin

  • La formule de Norman Maier : E = Q x A.

• Efficacité de la décision = Qualité de la solution x Adhésion.

Activités clés et degrés d’empowerment

Source :https://www.amazon.com/Keys-Empowerment-Release-Astonishing-Results/dp/1576751600

Le résumé en détails : http://excellenceop.fr/empowerment-en-equipe-12

VISER LA PERFORMANCE EN MODE AGILE Part II (Les principes de l'agile manifesto)

Les 12 principes de l'agile manifesto :  que vous travailliez en méthode Scrum, Kanban ou autre, il est important de ne pas les perdre de vue.

Satisfaire le client

En livrant rapidement et régulièrement des fonctionnalités

à grande valeur ajoutée.

Accueillir positivement les changements de besoins

Même tard dans le projet les processus agiles
exploitent le changement pour donner un avantage
compétitif au client.

Livrer fréquemment

Avec des cycles de quelques semaines à quelques mois et une
préférence pour les plus courts.

Des réunions journalières.

Les utilisateurs ou leurs représentants et les 
développeurs doivent travailler ensemble quotidiennement
tout au long du projet.

Réaliser les projets avec des personnes motivées. 
Fournissez-leur l’environnement et le soutien dont ils
ont besoin et faites-leur confiance pour atteindre les
objectifs fixés.

Privilégier le dialogue en face à face

La méthode la plus simple et la plus efficace pour 
transmettre de l’information à l'équipe de développement
et à l’intérieur de celle-ci est le dialogue en face à face.

Mesure d’avancement

Un logiciel opérationnel est la principale mesure d’avancement.

Un rythme de développement  soutenable. 

Ensemble, les commanditaires, les développeurs
et les utilisateurs devraient être capables de maintenir
indéfiniment un rythme constant.

La maîtrise technique et une bonne conception.

Une attention continue à l'excellence technique et
à une bonne conception renforce l’Agilité.

La simplicité

L’art de minimiser la quantité de travail inutile.

Des équipes auto-organisées.

Les meilleures architectures, spécifications et 
conceptions émergent d'équipes auto-organisées.

Devenir plus efficace

À intervalles réguliers, l'équipe réfléchit aux moyens
de devenir plus efficace, puis règle et modifie son
comportement en conséquence.

sources : http://agilemanifesto.org/ 

https://www.softfluent.fr/blog/expertise/2017/05/17/Les-12-principes-du-manifeste-agile

VISER LA PERFORMANCE EN MODE AGILE Part I (Le Rôle du facilitateur)

Satisfaire le client en délivrant régulièrement un logiciel opérationnel et à grande valeur ajoutée, favoriser la collaboration, l’excellence technique et la simplicité, en encouragent un rythme soutenable. l’ensemble étant sous-tendu par la mise en place d’une politique d’amélioration continue.

« favoriser, encourager et soutenir » sont donc les mots d’ordre du manager agile. il devient un facilitateur au service d’une équipe qui doit parvenir à s’auto-organiser.

Faciliter, cela consiste à aider un groupe, une ou des personnes, à apprendre, explorer, trouver des solutions, atteindre un consensus…

La posture de facilitateur vise à améliorer le fonctionnement d’un groupe pour garantir l’atteinte des objectifs. 

Plusieurs principes guident cette posture : le respect des contributions de chacun, que ce soit dans le monde des idées ou dans le monde des actions. 

Le manager quitte sa position « haute » de celui qui réfléchit et décide pour les autres au bénéfice d’une position « basse » qui aide les collaborateurs à réfléchir et décider.

Sources : 

http://www.managementvisuel.fr/manager-facilitateur-le-manager-du-21eme-siecle/

https://business.lesechos.fr/directions-ressources-humaines/management/gerer-et-motiver-son-equipe/quand-le-manager-devient-facilitateur-6232.php

La check-list Code Performance

La check-list Performance

Quelques points à vérifier :

• Les objets sont dupliqués uniquement lorsque cela est nécessaire. Si vous devez dupliquer des objets, envisagé de mettre en œuvre Clone et décider si le clonage profond est nécessaire.

• Pas de boucles d'attente avec des traitements lents -> favoriser des méthodes en asynchrone et les Threads. 

• Évitez les gros objets en mémoire ou utilisez la classe String pour contenir de gros documents qui devraient être manipulés avec de meilleurs outils. Par exemple utiliser StringBuilder/StringBuffer au lieu de String.

• Ne laissez pas le code de débogage dans le code de production.

• Évitez les System.out.println (); dans le code, -> enrouler les logs dans une déclaration de conditionnement booléen comme if(DEBUG) {...}

• "L'optimisation qui rend le code plus difficile à lire ne doit être implémentée que si un profiler ou un autre outil a indiqué que la fonctionnalité doit être optimisée. Ces types d'optimisations devraient être bien documentés et le code qui effectue la même tâche devrait être conservé". - UNKNOWN.

Quelques bonnes pratiques concernant l'utilisation des exceptions

Ne jamais ignorer une exception

//traitement susceptible de lever une exception

        }catch(Exception ex){

            ex.printStackTrace(); //il faut pas ignorer

        }

Ne pas utiliser la clause throws de manière exhaustive

public void funAction() throws A, B, C { // trop d'exceptions sur le throws
    //corps de la méthode
}

Les exceptions ne sont pas faites pour le contrôle de flux

while(true){
//faire quelque chose
if(condition d'arrêt)
throw new FinDeLaBoucleException(); // ne pas utiliser les exceptions pour controler le flux
}

Attention au return dans un bloc finally !

public int methode(){
try{
return 3;
}finally{
return 4; // pas de return dans un block finally
}
}

Eviter le catch Error ou Throwable

try {

} catch (Error e) { // pas de catch Error ou Throwable
System.out.println("Une erreur est survenue : " + e);
}

Road to the Cloud (3) : Monolith Vs Microservices Applications (1)

Road to the Cloud (3) : Monolith Vs Microservices Applications

Monolithic architecture (monolithic architecture pattern)

"une seule brique avec tout les services ... et un seul WAR"

Avantages :

- Simple

- La scalabilité est obtenue à travers un cluster / load balancer

Inconvenants : 

- Le code source devient énorme a travers le temps donc difficile a lire et a comprendre ... le développement devient lent, l’environnement de développement aussi.
- Comme l'application devient énorme l’intégration continue doit être moins fréquente car il faut compilé et déployé tout le code.
- La scalabilité devient difficile car elle peut ce faire uniquement en verticale donc achat des serveurs plus performants.
- A long terme l'entreprise va être forcé à utiliser les mêmes technologies car puisque l'application devient énorme le coût du changement de technologie devient grand.

Microservices architecture (microservices architecture pattern)

"plusieurs briques indépendantes avec un système de communication entre eux ... plusieurs WARs"

Avantages :

- Une scalabilité horizontale et verticale (déploiement sur un ou plusieurs serveurs/JVMs.)
- Facile à comprendre et à gérer car chaque partie du code est presque indépendante.
- Le développement devient plus rapide car l'utilisation de l’environnement de développement et déploiements/tests deviendrons plus rapides.
- Chaque application peut être développé/amélioré et déployé indépendamment des autres.
- Les problèmes rencontrés en "run-time" sur une brique n'affecterons pas tout le système donc ça augmente la disponibilité.
- L'obligation de garder la même technologie au fil du temps n'est plus d'actualité.

Inconvenants :

- Nécessite une bonne coordination entre les équipes qui travaillent sur différentes briques.
- Il faut développer et gérer un système de communication entre les briques.
- Des scénarios de tests plus complexe.
- La transformation des transactions distribuées en use cases est assez difficile.
- Complexité de gérer et déployé des briques avec peut être différentes technologies.


Une solution pour l'existant

Pour les applications existantes qui souffrent de problèmes de scalabilité et lenteur ce qu"on peut retenir c'est que à un moment le coût de la scalabilité verticale va explosé (upgrade des serveurs pour gérer la demande qui augmente avec le "computing everywere" ...)


La solution est de faire sortir la ou les briques qui consomment le plus de ressources a fin de pouvoir les déployées séparément.

La séparation doit se faire au niveau du code aussi a fin de pouvoir l'améliorer et changer les technologies utilisées pour augmenter la performance.

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Intégration continue avec Jenkins / Maven / JUnit / JMeter / PMD

Le pourquoi: Assurer l’intégration, la performance, et la qualité du code avec les outils suivants : 

Jenkins (un "fork" open source de hudson / outil d'intégration continue).
JUnit (tests unitaires).
JMeter (test de charges).
PMD (la définition de nombreux règles qui assurent la qualité de code).

Maven (La gestion des dépendances et automatisation de la production).

A chaque "build" l'application est compilée, analysée ,testée (JUnit), déployée et re-testée (JMeter).

Les résultats des analyses sont disponible juste après :

PMD :

JMeter :

JUnit :

Maven permet d'automatiser le tout en définissant un ou plusieurs fichiers POM (pom.xml) qui contient le nom du projet, le numéro de version, les dépendances vers d'autres projets, les bibliothèques nécessaires à la compilation, les noms des contributeurs etc.

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.test</groupId>
<artifactId>spring</artifactId>
<version>0.0.2-SNAPSHOT</version>
<packaging>war</packaging>
<name>test</name>

<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.1.6.RELEASE</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>WebContent\WEB-INF\web.xml</webXml>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat6-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<url>http://localhost:8090/manager</url>
<server>TomcatServer</server>
<path>/SpringMavenCLITest</path>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<targetJdk>1.6</targetJdk>
<linkXref>false</linkXref>
<failOnViolation>false</failOnViolation>
<failurePriority>1</failurePriority>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
<goal>cpd-check</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.lazerycode.jmeter</groupId>
<artifactId>jmeter-maven-plugin</artifactId>
<version>1.10.1</version>
<executions>
<execution>
<id>jmeter-tests</id>
<phase>verify</phase>
<goals>
<goal>jmeter</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.11</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit47</artifactId>
<version>2.12</version>
</dependency>
</dependencies>
<configuration>
<includes>
<include>**/*.class</include>
</includes>
</configuration>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>2.3</version>
</plugin>

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>3.0.1</version>
<configuration>
<linkXRef>false</linkXRef>
<targetJdk>1.6</targetJdk>
<rulesets>
<ruleset>/rulesets/basic.xml</ruleset>
</rulesets>
</configuration>
</plugin>
</plugins>
</reporting>

</project>

 Pour finir il faut configurer jenkins pour démarrer notre intégration continue.

Road to the Cloud (2) : Twelve-Factor Applications

Road to the Cloud (2) : Twelve-Factor APP

Le "Twelve-Factor App" est un ensemble de design patterns qui déterminent si une application à une architecture "cloud-native" donc architecturalement destiné à profité des avantages que propose le cloud c-a-d rapidité robustesse et scalabilité.

Codebase

Un dépôt centralisé et unique avec gestion de version et multiples déploiement (plusieurs versions peuvent être déployées au même temps).


Dependencies

La gestion des dépendances via un outil approprié ex: Maven, NPM ...

Config

La configuration, ou tout ce qui est susceptible de différer entre
des environnements de déploiement est injecté via des variables d'environnement au niveau du système d'exploitation.

Backing services

Les services de sauvegarde (ex : base de données ...) doivent être considérés comme ressources attachées et consommées dans tous les environnements de la même façon.

Build, release, run

Les processus "Build/release/run" doivent être séparés et indépendants.

Processes

L'application doit s'exécuté comme un ou plusieurs "stateless process" qui ne partagent absolument rien entre eux. toute relation possible doit être externalisée (ex cache, base de données).

Port binding

L'application doit être "self-contained" (tout les composants nécessaires doivent être packagés/emballés dans même installation)  et expose tous ces services via "port binding".

Concurrency

Les processus doivent être "mis à l’échelle" horizontalement à fin de résoudre les problèmes de concurrences.

Disposability

La robustesse est garanti à travers des processus qui redémarre rapidement et se termine correctement.

Dev/prod parity

Les environnements Dev, Pré Prod  et Production doivent être très proche voir similaire.

Logs

Au lieu de gérer des fichiers logs, il faut gérer les logs autant qu'événements stocker centralement pour indexation et analyse.

Admin processes

Les tâches administratives ou de gestions, tels que les migrations de bases de données, sont exécutés en tant que processus ponctuels "one-off" dans des environnements identiques.

Road to the Cloud (1) : NoSQL / Hibernate OGM (Object/Grid Mapper)

Road to the Cloud (1) : NoSQL / Hibernate OGM (Object/Grid Mapper)

Le 2015-02-27 a connu le lancement de la version stable du framework Hibernate pour les bases de données NoSQL appelé Hibernate OGM le but est de porté la facilité de développement JPA au monde NoSQL ainsi les développeurs familiarisés avec JPA n'aurons aucun problème à changer de cape.

Le pourquoi : une scalabilité horizontale et évolutivité.

- Un schéma flexible capable d'accepter les changements plus facilement (Evolution).

- Un système facilement distribué sur plusieurs serveurs. (le besoin supplémentaire en stockage ou en montée en charge se traduit simplement par l’ajout de nouveaux serveurs).

Donc si vous visez de porter votre application vers le cloud et d'avoir des milliers d'utilisateurs (Données) a moindre coût le choix du NoSQL est obligatoire.

L'architecture Hibernate OGM permet l'utilisation des requêtes JP-QL en les transformant en requêtes DataStore donc le développeur n'aura pas a écrire des requête NoSQL, donc même réutiliser l'existant.

La définition des beans avec annotations JPA/EJB3 reste la même sauf l'introduction de hibernate search qui pourra aussi être un autre moyen de recherche.

Exemple de requête JP-QL simple : 

                EntityManager emSearch = emf.createEntityManager();
Query query = emSearch.createQuery("from Data d where d.name like :name")
.setParameter("name", "XXX%");

Exemples de requête DataStore Ex: MongoDB: 

- Update du montant :
db.Data.update({ "_id" : NumberLong(351) },{ "$set" : { "montant" : "1" } },false, false )

- Delete par ID :
db.Data.remove({ "_id" : NumberLong(143) })

- Recherche Par ID : 
db.Data.find({ "_id" : NumberLong(143) })


- Insert des données :
db.Data.insert({"_id" : NumberLong(131300),"montant" : "0.16364626911022928101857587535050697624683380126953125","description" : "Description2134956245","name" : "Name170565634","date" : ISODate("2015-04-17T10:36:46.583Z"),"parent_id" : NumberLong(13118),"rows" : [NumberLong(13123),NumberLong(13122),NumberLong(13125),NumberLong(13124),NumberLong(13127),NumberLong(13126),NumberLong(13129),NumberLong(13128),NumberLong(13119),NumberLong(13121),NumberLong(13120)]})

- Recherche par champs Name :
db.Data.find({ '$query' : { "name" : "Name-414524582" ,  "_id" : NumberLong(13) }})

- Recherche ID >13 et ID < 130  :
db.Data.find({ '$query' : { "_id" : { $gt: NumberLong(13), $lt: NumberLong(130) } }})

- Recherche par objet incorporé :
db.Data.find({"location.y" : "Y-400967006"} )

Les bases de données suivantes sont supportées : couchDb, mongodb, ehcache, infinispan, neo4j.

Pour l'exemple nous allons utilisé la base données MongoDB :

- Installation MongoDB : http://docs.mongodb.org/manual/installation/

Pour la visualisation les données le plugin eclipse MonjaDB :

- Installation MonjaDB : http://marketplace.eclipse.org/content/monjadb

Le Fichier Persistence.xml : 

Télécharger l'exemple : Test APP

Websphere Application Server ( WAS 8.5 ) : Probléme d'upload (multipart/form-data)

L'erreur : FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Async operation timed out


Problème des timeouts (FileUpload) :

- Pour tester sur tomcat il faut changer les paramètres suivants car ils sont semblables aux paramètres WAS :
      
connectionUploadTimeout="XXXX" disableUploadTimeout="false"  connectionTimeout="XXX"
- Pour WAS il faut augmenter le Read timeout. (180)

Lien : Documentation WAS

Google App Engine(Google Cloud SQL) /ZK/Spring/Hibernate Integration (1)

Demo : doukkani.appspot.com

Google App Engine est une plateforme de conception et d'hébergement d'applications web basée sur les serveurs de Google.

Google Cloud SQL En octobre 2011, Google aperçus une base de données SQL sans entretien, qui supporte JDBC et DB-API². Ce service vous permet de créer, configurer et utiliser des bases de données relationnelles avec les applications App Engine. Moteur de base de données MySQL version 5.1.59 est la taille et la base de données ne doit pas être supérieure à 10 Go ³.

Contexte technologique Le service Google App Engine vient concurrencer ceux d'Amazon nommé Amazon Web Services (AWS) et de Microsoft nommé Windows Azure. Ce sont des lots de services applicatifs qui permettent à une application web de stocker des données et d'exécuter du code sur leurs serveurs respectifs.

Beaucoup d'analystes techniques avaient prédit l'arrivée de Google dans ce créneau. « Google finally realizes it needs to be the web platform » a écrit Mike Masnick, qui publie le blog Techdirt⁴. Source WikiPedia

Scrum : le mécanisme d’inspection et d’adaptation

 

j'ai pris le temps de lire le guide scrum de Ken Schwaber et Jeff Sutherland d'ou j'ai retenu les principes suivants :

Scrum comporte trois activités en ce qui concerne le mécanisme d’inspection et d’adaptation :

1- il y a la mêlée quotidienne (Daily Scrum), qui permet de vérifier l’avancement en regard à l’atteinte du but pour le sprint et d’adapter ce qu’il y a à
faire de manière à optimiser la valeur produite au jour le jour.( Adaptation, optimisation ).

2- La réunion de planification du sprint (Sprint Planning Meeting) et la réunion de revue du sprint (Sprint ReviewMeeting) sont utilisées pour valider l’état d’avancement quant à l’objectif de la livraison courante et pour faire les adaptations qui optimiseront le processus de réalisation du prochain sprint. ( inspection ).

3- La rétrospective du sprint (Sprint Retrospective) permet de passer en revue le sprint qui vient de se terminer et de déterminer les changements à apporter pour que le prochain sprint soit plus productif, enrichissant et agréable pour
toute l’équipe. ( inspection et adaptation ).

Integration Continue : Hudson vs Jenkins CI?

Link : http://java.dzone.com/articles/hudson-vs-jenkins-ci

La formation initiale BPM/jBPM/jBPM5

BPM predictions for 2012

What are BPM predictions for 2012 as we stand on the verge of the new year?

There will be a new focus on the technology stack versus the BPM point solution. BPM has such a diverse following that only a solution that works for many can have wide acceptance across business and technology folks.

By  Chris Taylor

Link :BPM predictions 2012

jBPM5 Vs Activiti5

VS

Come on guys/girls/CTOs/CEO/Architects/Developers! there is no battle between jBPM5 and Activiti5. If you are here because you are looking for the right option, I will give you some recommendations to choose one rather than the other. I will not make a detailed comparison between features, instead I will make a more project to project overall comparison (Write me back if you want a feature to feature comparison). I’m not a Red Hat / JBoss or Alfresco employee, so I will express my personal opinion about these two projects and why I decide to write and participate in jBPM5/Drools as a community member.
In this post I will highlight some points about these two projects. However the conclusion is that you can choose either jBPM5 or Activiti5 and they will improve and change the way that you are used to developing applications.

The main similarities between this two projects are:

• BPMN2 process modeling and execution environment
• They are both BPM Systems (implementing the BPM discipline)
• Open Source – ASL (Apache Software Licence)ed
• Both were originally developed by JBoss (it’s not a secret that Activiti5 is jBPM4 design and jBPM5 is Drools Flow code base)
• Maturity, both were written from the scratch and both started about 2 years and a half ago.
• Human Task Life Cycle Management. The only difference between jBPM5 and Activiti5 is that jBPM5 implements the WebService-HumanTask standard to describe the Human Task Management Life Cycle. If you are interested to know about this standard and the advantages of adopting it, you can read the introduction chapter of the WS-HT specification here.
• Both projects uses different flavors of the  Oryx editor for modeling BPMN2 processes. jBPM 5 uses a fork for the Open Source project maintained by Intalio. Activiti5 used a different branch maintained by Signavio.

Now, which are the main differences between them?

• The companies / The business model
• The project leaders / Community
• The goals of the projects
• Future / which one should I choose?

Based on these four points and on your personal/company requirements, you can make a long-term decision about which is the best project for you to adopt.

Disclaimer: if you are a java developer learning new technologies, doing your first applications or trying to understand a BPMS, you can take advantage of this comparison. It’s important to notice that knowing both projects will help you to improve your skills, learn best practices, architectural designs, a new way of developing applications, a cool discipline and a bunch of cool stuff. Go ahead and pick one, when you learn the concepts behind one of them, in order to adopt the other, you have to learn a new API, adapt some concepts and learn wider ones.

The companies / the business behind the projects

Both projects are distributed under the ASL (Apache Software License), from the licensing perspective it is exactly the same. You can use both of them without restrictions. Once again, if you are a developer learning something new, both of them will fit perfectly. If you don’t have too much BPM expertise, both of them will look alike.

My community perception about Red Hat and, as far as I know, the Red Hat/JBoss business is about services, the money comes from selling services and support. If you are thinking about spending your money on Red Hat, you can buy support for the SOA Platform Stack. However, until now you cannot buy support strictly for jBPM. This is probably a great advantage, which means that if you buy support from Red Hat, you will get support for the full stack of middleware. Red Hat is specialized in providing that service.

I worked with Alfresco’s CMS and understood how its community works and the business around CMS, but I’m still confused about their business plans for Activiti5. As a company, they can embed the Activiti5 runtime inside the CMS project as they did with jBPM3, or they can sell services about the BPM System solution.  In the official web page(www.activiti.org), they don’t mention anything about Alfresco selling Activiti5 services. I’m not sure if Alfresco is planning to provide them in the near future.

The project leaders and the community

It’s well known that all the community members who know JBPM4.x history move to Activiti5 based on the similarity of the code base and configurations. So the jBPM 4.x community is the same as in Activiti5.

New adopters are asking a lot of questions about jBPM5 and Activiti5.

The jBPM5 community will be probably populated by jBPM 3.x users that want to have the official support from Red Hat/JBoss plus the new ones that understand the great advantages of using a BPM System on top of a Rule Engine. The Drools Flow community and those who use  it, can easily migrate their application to use the new jBPM5 dependencies. Community migration efforts are already being done and a tool for migration is being developed for those jBPM 3.x users.

You can find some useful links about jBPM5 here:

http://blog.athico.com/2011/01/recent-jbpm-5-blogs-articles-videos-and.html

Please feel free to write me back if you have a specific topic or a set of topics that you want to read about. I really enjoy writing about jBPM5 and Drools, but comparisons are fun too!

Right now, jBPM5 is an independent project separated from Drools but highly integrated with the rule engine. The project leader, Kris Verlaenen, is doing a great job trying to get a first stable release at the end of this month.
On the Activiti5 side both Tom Baeyens and Joram Barrez are doing an excellent job trying to get attention and adoption from their re-branded BPMS.

*add whatever you want here 

Project’s Goals

As far as I know, they have very different perspectives and goals. The Activiti5 team is fighting for adoption, while the jBPM5 team is struggling for improving concepts, giving us a new twist, great features and flexibility.

There is no way to say that one is better than the other when they have different goals in their roadmaps. If you are fighting for adoption, you will focus on conferences, tooling and integration. The project roadmap for adoption has short period releases and stable deliverables.

If your project roadmap includes features that were never developed, long period releases will probably be required. From my point of view Drools Flow was an innovative project built from the scratch to show that the interaction between a rule engine with a BPMS gives richer features and a great degree of flexibility to model real situations.

Right now, jBPM5 is a more ordinary project. A lot of the work that is being done now is about  tooling and demos to show common usage. jBPM5 will look very good in the next few months, after the first stable release.

Future / Which one should I choose?

There is no simple answer. If you are looking for a simple lightweight BPMS both are good. If this is your first experience with a BPMS, no matter what you choose, you will be happy and you will have trouble with both.

If you want to join a community to contribute to these projects both are good. I can’t give an opinion about the Alfresco community, because I’m not so involved but it looks like an active community. From the jBPM5 perspective you will find a pretty active community as well. Right now, as a result of mixing Drools and jBPM3 communities, you will see strong activity in the Forums and in the IRC channel.

The important question here that you may ask to yourself is:

Am I choosing a BPMS for the next couple of years or is it just for a little project?
If the answer of this question is:

• I’m just starting OR I will create a simple web app that shows the basic features OR the application will not be used by a large amount of users OR the application will not be critical for the organization OR we don’t have complex business processes and we don’t have complex business situations, both projects will work well.
• I need to build a middle-sized application that uses business process extensively, this business processes are not so complex (no more than 20 activities each, without too much exceptional branches) and the application is not critical for the company, both projects will work well.
• I need to build a new architecture that gives me the ultimate flexibility to express complex/ real life business scenarios AND I understand the power of a Rule Engine AND I understand the advantages of using it in conjunction with a BPMS (handling in an unified way my business logic and my business processes, using the same APIs, being as declarative as possible), you really need to try jBPM5!  This is not the common case, usually only advanced users that already developed more than one BPM application, notice this kind of advantages. If you don’t know how to leverage the power of a rule engine, both projects will give you the same amount of features. If you analyze the common features of a BPMS, there is no clear advantage between both projects. When you start to understand the power and advantages of the Rule Engine or when you really need a Rule Engine working together with a BPMS,x you clearly know what to choose for the next two years.

Conclusion

As I mention in the post introduction:
You can choose jBPM5 or Activiti5, both will teach you and let you implement the BPM discipline main stages. Both are Open Source and ASL licenced.
If you are not only thinking in adopting a new technology and you already face some BPM implementation with jBPM3/jBPM4 or the old OSWorkflow you probably notice and know the advantages of using a Rule Engine in conjunction with the BPMS. If you are at that point please take a look at jBPM5 and the Drools integration, you will probably be amazed. If you want to take a look at a running application designed using the concept of Rule Engine and BPMS together you can take a look at the following posts. Notice that Drools + jBPM5 offers you a full platform for declarative application programming.  Adding important features like the advantages of a CEP engine(Drools Fusion) and a Centralized Repository for all your business assets (Drools Guvnor).

copyright http://salaboy.com/