No two MuleSoft project engagements are the same. Software, people, environment, and task all factor into what makes or breaks a project. However, there are a few challenges that are universal across all types of projects, signaling a need for a careful hand. This blog will describe a few of the challenges I’ve seen across a variety of projects, why those indicate trouble, and what to do about them.
Before we dive straight into the content, let me explain a few terms I’ll be using:
Success Facet – This is a term I use to describe one of the aspects of a project that (if positive) contributes to the success of the initiative.
Adoption – Successfully implementing MuleSoft means little if no one uses it. This success facet tracks how much the business will be using MuleSoft.
Longevity – A high spike of initial adoption means little if the company gravitates back to its legacy development plan for future APIs. This lowers future engagements and can endanger existing MuleSoft applications if an executive decides to consolidate the IT footprint.
Reliability – This one is pretty self-explanatory. Unreliable applications are worse than non-existent applications.
Morale – Client morale has a larger impact on the above facets than you may initially assume. Obstacles or challenges faced by a team with low morale will have a significant negative impact. However, obstacles or challenges faced by a team with high morale will be overcome with little impact.
Challenge #1: Low Artifact Engagements
Talk the talk but don’t walk the walk. Who’s up for a marathon?
This challenge highly affects MuleSoft adoption. Artifacts are what keeps developers’ hands on the keyboard. They can be anything from an API implementation to a console application. When developing with a new software platform, most developers will look up a tutorial to help kickstart development. Project engagements that are purely set up with little to no ‘hands-on keyboard’ application development — like CloudHub, CI/CD, VPN, DLB, or Monitoring — will endanger future engagement with the MuleSoft platform due to developers’ unfamiliarity with the platform. Additionally, the development phase is a great time to discuss other opportunities to utilize MuleSoft without sounding like you’re trying to pitch something. Lastly, it can leave a bad taste in the client’s mouth if a consulting partner takes their money and leaves once the SOW is complete but leaves them effectively empty-handed and with little to no knowledge of the platform.
This challenge is one of the most difficult to handle as the solution has to be performed before the project starts. The only real way to mitigate the issue is by adding development artifacts. In the case this can’t be done before starting the project, see if you can get the client to agree to the development of an exemplar application that can serve to, at the least, guide future development.
Challenge #2: IT Teams Are Not in Control of Their Roadmap
Where do you see your department in 5 years?
This challenge highly affects adoption and longevity. Roadmaps are ephemeral things, here one day and gone the next budget meeting. What really matters isn’t necessarily the roadmap itself (or lack thereof) but who controls it. If IT teams are subject to the whims of other departments —whether those be larger organizations, the business side or the “higher-ups”— any new software implementation is at risk. The risk comes from those other entities not fully understanding the impacts of adopting an implementation platform like MuleSoft. This misunderstanding can lead to frustration and not giving the IT team enough time to refactor existing integrations over to the new platform. This results in low adoption rates and could affect longevity if the frustration hits a breaking point.
Often, this is a people problem and not easily solved, but you can help by creating a MuleSoft specific roadmap the IT team can follow. It doesn’t need to be detailed and time-boxed (in fact, you should avoid time-boxing work you won’t be doing) but having it come from a consulting agency the “higher-ups” hired can grant some confidence.
Challenge #3: Internal Team Jokes Around Too Much
Like these tidbits, sometimes humor is overstated.
This challenge affects morale. I know. Humor isn’t a bad thing. And for most cases, that’s true. But humor can mask a lot of undesirable behavior, making it easy to overlook. Humor can be used to harass, to gather information, and inflame rivalries. Humor can also alleviate workplace stress and bring a genuine smile to your face. It can also be used to hurt people, such as when joking about a particular developer’s speed. It’s sometimes difficult to know where that line is, especially when cultures mingle. There’s no fix for this, aside from being aware of your audience. Humor can endear you to the client, but you must be vigilant of what you’re joking about, who you’re joking with, and how they may understand it.
Challenge #4: High Subject Matter Expert (SME) Turnover
It’s like a game of musical chairs.
This challenge highly affects adoption, longevity, and morale. This challenge is a bit of a double-edged sword. It can be great for future work as the consultants kind of become the new SMEs. However, it’s extremely unhealthy for the client as a whole and should be treated with adequate care. Depending on the rate the client is filling in the gaps left by SMEs who have left the company, the effect on the listed success facets can vary. If hiring is high, adoption and longevity are more at risk than morale as new people bring in new predispositions, have to be taught MuleSoft standards, and learn about existing APIs. If hiring is low, adoption and morale are the affected facets, with morale taking the brunt of the hit. Adoption will suffer as the hiring deficit persists and manpower is stretched thin.
The only fix under our control is increasing the amount of written and recorded documentation. This includes information about the business processes, not just our APIs. It can also be beneficial to write a primer for new developers, to assist in reducing ramp-up time.
Challenge #5: Internal IT Teams Don’t Touch Development
That’s what we hired you for!
This challenge highly affects adoption. This is somewhat paired with challenge #1, but can occur even in a project where there’s a lot of development time. It may sound great due to the development work all being routed to a consulting agency, but with a lack of familiarity comes a lack of respect for the development time and process. This can build up to an unhealthy relationship between the client and consulting agency due to different consultants working at different speeds, project scopes being fully on the consultancy to develop, and an over reliance on the yearly budget to develop MuleSoft artifacts.
To alleviate this, paired programming is ideal though the most costly when considering man hours. In addition or replacement, a weekly or bi-weekly knowledge transfer session is advised. Consider recording these for future reference.
Challenge #6: IT Team is Unfamiliar with Monitoring Their Applications
But who monitors the monitors?
This challenge affects longevity and reliability. Site Reliability Engineering (SRE) has been a hot topic for a few years, and most big companies will have some sort of monitoring solution available. But just having some solution out there doesn’t solve the problem. If teams only look at the monitoring solution once something has gone wrong, what’s the point? Proactive alerts and monitoring should be the goal of a reliable IT department.
This solution comes through either establishing or utilizing a monitoring solution and also getting used to proactively checking for breaks or setting up reports to be sent regularly to the team.
If you find your team is trying to find solutions to overcome these challenges, please reach out. AVIO Consulting has several offerings to help businesses overcome many of the challenges mentioned throughout this blog.