One of our prospects evaluating IZ Analyzer, who is currently using MuleSoft SonarQube Plugin, wondered how we are different. For the benefit of everyone, here is a quick comparison:

1️⃣ Rule Language

MuleSoft SonarQube plugin uses XPATH. XPath expressions can be longer and more complex due to the structure of XML documents, which can be hierarchical and nested, and partly due to the syntax of XPath itself. This can make it more difficult to work with if you’re not familiar with XML.

IZ Analyzer uses Groovy, which has a syntax based on Java: one of the most widely used programming languages in the world.

2️⃣ Dynamic rule deployment

MuleSoft SonarQube plugin stores all rules in a .xml file relative to SonarQube’s extensions directory. This places a constraint on the new rules which require SonarQube server to be restarted. IZ Analyzer on the other hand can promote rules dynamically without the need to restart the server.

3️⃣ Anypoint Studio Integration

MuleSoft SonarQube plugin’s biggest drawback is inability to alert developer during development phase. Since there is no integration with Anypoint Studio or any other IDE for that matter, developers have to wait till the CICD process publishes the results to SonarQube server resulting in slower development cycles. Without real-time assistance on fixing issues, developers have to juggle between SonarQube server reports and Anypoint Studio to identify and fix issues.

IZ Analyzer can be easily plugged into Anypoint Studio which helps enforce rules even before the code is deployed, saving precious time during development cycles.

4️⃣ Auto fix

Isn’t it equally important to fix the issues the right way while identifying them? If Developer committed a mistake, it is highly probable that he/she may not be aware of the best practice. Traditionally, code reviewer identifies the issue and passes the buck back to the developer to fix it. Developer then has to refer to coding best practices (if available in the organization) or come up with a solution as per his/her limited knowledge.

We realized this issue and built an Auto fix feature to automatically provide a fix to an issue. Code reviewer/Architect, who created the rule earlier, can also specify a fix linked to the rule. This way Auto fix ensures that the Developer isn’t re-inventing the wheel, not wasting time to come up with a solution and more importantly applying a fix that’s already vetted by the Architect as per organization’s best practices.

5️⃣ No support for non XML files

MuleSoft SonarQube plugin can only analyze XML files which creates a huge problem for projects containing APIs built on RAML/OAS or property files. In the API-led world, this may lead to security leaks causing significant impact to the delivery cost and timeline.

As we designed and built IZ Analyzer from ground up, we realized this key requirement and supported analysis of all types of files in Mule or API projects.

6️⃣ Limited built-in rules

MuleSoft SonarQube plugin comes with a very few built in rules (around 25 as we write) to scan Mule projects. This requires significant effort to build more rules to cover all best practices. If you are unfamiliar with XPATH, the effort just compounds.

In contrast, IZ Analyzer has 160+ built in rules for MuleSoft projects and 50+ for API projects. Even if it takes 2 hours to build and test one rule, we are talking about 420+ hours or 53+ days or $50,000+ cost. This presumes one is aware of best practices which normally isn’t the case with customers with small teams.

7️⃣ Custom rules editor

MuleSoft SonarQube plugin doesn’t come with a custom rules editor. Developers/Architects need to rely on XML editors to build and test rules. This not only requires more time to build the rules, but also makes it difficult to test and promote them to the server in real-time, without multiple server restarts.

IZ Analyzer comes with a dedicated rules editor integrated with Anypoint Studio. Development, Testing and Deployment of these rules is a breeze.

8️⃣ Access control

In real world, a Technical Lead or an Architect defines coding standards, best practices and should be the person to define the rules. A developer should only have read-only access to these rules. MuleSoft SonarQube plugin, with lack of access control, doesn’t offer role based permissions.

IZ Analyzer offers granular access control for different types of users.

9️⃣ Enterprise support

MuleSoft SonarQube plugin in an open-source community developed tool last updated 2 years ago. It is not supported by MuleSoft contrary to it’s name. This is a huge risk for any customer working on critical projects.

IZ Analyzer is enterprise-grade with frequent updates and innovative features. We provide enterprise support with clearly defined service levels and response times.

🔟 Initial vs total cost

This is often an overlooked aspect. Nothing in this world is free. If a product is available for free, it invariably comes with hidden development and maintenance costs. Just the tangible costs to develop, test and support free tools alone will result in $100,000+ in hidden costs. Whereas, we built IZ Analyzer using our decades of experience with MuleSoft customers, understanding their pain points, consolidating frequently used best practices, thoroughly testing the features in live deployments over the past 3+ years and adding many innovative features to significantly reduce the costs for MuleSoft customers. We have many MuleSoft customers, including some in the Fortune 100 list, successfully using the product.

We pride ourselves in saving 80%+ direct costs for customers plus a lot more in indirect costs. Unbelievable – give us a chance to prove it.