You have a problem. Whether you like it or not, you have one. Services are moving to the "cloud" more and more frequently these days and now you need to consume them. They are disparate and agnostic of each other, but their combination as a whole is what brings you value. You have Salesforce and Workday and some accounting system, and single-sign on controlled by your in-house ActiveDirectory server. You have lines-of-business with their own databases and APIs, and, shockingly, they don't know about each other even though you wrote them in-house. Different teams have developed different solutions to similar problems within your organization.
Maybe it does, maybe it doesn't. Either way the problem is still the same. Somehow, you need to integrate the data from across your organization in a way that makes it seamlessly accessible and available for use. Welcome to the world of enterprise integration.
You've checked the industry for players in this space, looked at reviews, consulted Gartners Magic Quadrant for leaders and now you've settled on MuleSoft. But where do you go from here? What should you be thinking about when adopting Mule? Maybe you just bought it and are still getting started. Here are some tips to help you become more successful, hopefully sooner rather than later.
1. Get Training
Don't skimp on this one. Send the entire team, ideally at the same time, or have MuleSoft send one of their trainers to you. The Anypoint Essentials class is the base minimum your development team will need to get started. To keep the team successful, make sure they're empowered to start on real work as soon as possible after the class.
Additional items to learn about especially if your developers are retraining as Java developers:
- Maven. This is a standard build tool used with Mule projects in Anypoint Studio. It's a mature open source product, and easily integrated with your continuous build environment.
- Java coding conventions, especially if your developers are coming from a .NET platform. C#, syntactically, is similar to Java, but there are several conventions which are different. While not expressly required, this is one of those "best practices" to follow.
- Continuous builds with something like Jenkins or Travis. Using a tool to automate your builds, expose when tests aren't passing to the development team, deploy to different environments easily will make everyone's life better.
- Use git. Github or Bitbucket are possible hosting solutions if you don't have or don't want to have an in-house repository. Git is the generally accepted source control tool for developers.
2. Get a Partner
The only way for your team to get experience is to do it. However, there are several opportunities to bring in a partner with their experience to help your team continue to accelerate past their training period. One of the best ways to do this is with a full or partial team from your partner embedded with your team, either on-site or remote. Remote can help you keep costs down, but having the remote members come in periodically is a big win for everyone. Having an experienced partner helping your team grow while delivering solutions in your integration space will be the single best way to get going quickly. Having a phase-out plan and clear, measurable goals and benchmarks will help manage this cost effectively.
Additionally, having a partner will give you experience to draw on when challenges arise. You'll still want to have a support contract with MuleSoft but your partner will be able and more accessible to assist. When even your partner is stumped or if a bug with Mule is found or suspected, that support contract will become useful. It's often easier for a partner who is working alongside your development team to help answer these kinds of questions, or to understand what MuleSoft support has offered, as they have the mental context of the problem and a history of what has been tried or not.
Shameless plug: hire Appnovation as your partner! We have the experience and knowledge to help you be successful long-term.
3. Understand Your Infrastructure
There is more than one way to skin a cat, as the saying goes, and so there is more than one way to deploy Mule. Considerations here will be licensing costs from MuleSoft, the complexity of your integrations and volume of data. MuleSoft has a cloud product which allows you to have Mule without having to worry about your infrastructure. This isn't always the best solution, especially if you have sensitive data over which you must keep strict control. An on-premise solution will be better in this case. Alternatively, it might be handy to have an on-premise solution for your development and QA process, but production is on Cloudhub.
Here are some things to consider, especially if you are deploying on-premise:
- Do you have a knowledgeable and experienced administrator for the platform where you intend to deploy Mule? My preference is a Linux distribution as you often get better performance, but a Microsoft Windows solution will work as well. Your administrator will need to be fairly knowledgeable about optimizing services on that platform.
- Do you have enough drive space? This one is often minimized, but the value of good logging and having plenty of data in those log files cannot be understated. Rolling log files of 50Mb in size would be a minimum in my opinion, but larger are often better as you can get more context over longer periods of time. Consider using log analysis tools and utilities and giving them to your developers as well as your support team, including at least read-access to your production environment as that will be where you need to spend more time triaging problems so you can replicate them in lower environments.
- If you don't already, setup a build and deploy pipeline. Automating your deployments will help reduce the human errors caused when you forget to edit a particular configuration file to add that new property just introduced in this new deployment.
4. Periodic Reviews
Getting a periodic review from your partner, a different partner or MuleSoft will help identify those areas of potential improvement which exist in all projects. Sometimes, being elbows-deep in the code, developers miss seeing some obvious wins to improve the code base. An architectural design review is a great way to get feedback on how you're doing. If you choose to use your partner, ask for someone who isn't working directly with you so you get a fresh set of eyes. Additionally, be sure to identify specific areas for consideration and what kinds of outcomes you are looking for. Communicate these when asking for a review. If you're just starting out using Mule, probably a three month review, then another six months later will help you stay on track with best practices and allow you to course-correct quickly if necessary.
5. Stay Current
Moving forward, try to stay as close to the current Mule release as possible. Improvements in their tooling, new features to simplify your development and bug fixes are all good reasons to stay current. Additionally, getting support for prior versions gets harder with each new release. The documentation can be more difficult to find, some tools were in beta at that release but are released with newer versions and different syntax, so that it becomes really hard to figure out certain kinds of problems. One example of this was the development of MUnit, the Mule Unit test framework. There are a lot of differences between the beta version for Mule 3.5 and the released version available now with Mule 3.7, most of them are breaking changes which will force you to redevelop those tests from the beta version. Additionally, finding any documentation on the beta syntax is very difficult. Staying current means being able to find documentation and support more quickly.
Need help with Mule? Want to use the best open technology on the market? Our MuleSoft experts are ready to create a custom and innovative solution using MuleSoft that will not only meet your needs now, but also be able to grow and change to meet your company's future needs.