For the past six months, I worked on a federal consulting project to transform data from a client’s legacy systems into a new centralized cloud repository. We chose MuleSoft as the integration and API platform to drive this transformation. After implementing my first MuleSoft project in the federal space, I jotted down a handful of takeaways to share with others embarking on new projects. Here are my top learnings:
1. Understand security
Leading up to this project, I spent almost seven years in the federal implementation space as a system implementor for a wide range of software. As is the nature with many federal projects, security and other non-functional requirements are a significant concern. However, these concerns (performance, availability, reliability, etc.s) evolve as the project progresses. Such an evolving system design is normal in the federal space due to the complexity of legacy systems and limited resources with full current system understanding.
Make sure you understand both your projects personally identifiable information (PII) footprint and its National Institute of Science and Technology (NIST) security categorization. Due to the federal security requirements of our client, we leveraged a FedRAMP-compliant environment to host the MuleSoft enterprise runtime. I needed to have conversations with multiple stakeholders to fully understand what our project security requirements were.
2. Demonstrate value throughout the project
For those who have implementing new technology changes before, you’ll understand how crucial it is to demonstrate value throughout a project. Even with this imperative, it’s likely that project requirements change, and which can present challenges. This often inconvenient reality plays to MuleSoft’s strengths. With MuleSoft’s three-tier API-led design, component-driven development, and modular flows, the midstream direction changes were not painful. MuleSoft’s loosely coupled APIs allow for changes in one area not to break functionality elsewhere. While requirement changes are generally a frustrating experience, my rework with MuleSoft allowed me to hone my MuleSoft skills and deliver a successful project to the client.
3. Learn and master batch processing
Batch processing is MuleSoft’s mechanism to asynchronously process larger-than-memory datasets. It does so by dividing the payload into predetermined subsets of records and queuing them for future processing. The batch process in MuleSoft consists of three phases: load and dispatch, process, and on complete. Since the software processes asynchronously, by default MuleSoft will use 16 threads to process the records in parallel. This functionality was critical to understand and utilize in our client’s use case, given the data volumes. Don’t leave this component unused.
4. Code commenting and peer review
Comment your code and use descriptive names. While this habit should be second nature in the federal space, timelines are often prioritized over completeness and it’s tempting to take shortcuts in an effort to alleviate deadline pressures. But there will come a time when the original developer will need to return to old code, or a new developer will need to understand the thought process behind a certain feature, which is when the notes may prove essential.
5. Form an inclusive team
A deliberately inclusive team is one way to remedy the normal experience of imposter syndrome and foster the collaboration necessary to thrive on a federal project. A healthy team culture of inclusion can empower all members to feel free to speak up without fear of negative repercussions. Individuals can ask questions without being concerned of the darting sideways glances and scoffs of “they doesn’t know that?” When team members feel safe, included, and open about what they don’t know, they can more rapidly address the knowledge gap, accomplish the task at hand, and all grow in knowledge and ability. On a federal project, with the usual challenges of navigating bureaucratic processes and collapsed timelines, a tight-knit team is imperative.
Even with aggressive project timelines, my team and I successfully migrated large quantities of data from legacy systems to the cloud. Hands-on development and actual federal project timelines and pressures are imperative to the advancement of one’s MuleSoft experience. Some of the key concepts to learn include batch processing and DataWeave transformations. A comfortable, open, and inclusive team will be critical through the challenges of federal client delivery. Whether you are in a purely functional or technical role, you can always find lessons learned over the duration of a project to implement on the next one — and I’m looking forward to putting those into practice for my next MuleSoft project.
For more help on starting your first MuleSoft project, check out our Developing your first API tutorial.
