The Boomi Community is the hub of our relationship with our customers. It is where they find answers to their questions, learn how to get the most from the Boomi platform, and engage with peers to understand the best approaches to their integration challenges.
The heart of the Boomi Community is its members. Throughout the year, we recognize the most active and helpful individuals in this group. These leaders set the standard for how Community members can contribute and cultivate a rich conversation that helps everyone become better at integration.
We call these people our Community Champions. They are remarkable in their commitment to making the Community the best possible resource for integration professionals.
Our latest Community Champion is John Moore. Moore, like all Community Champions, is one of the most active participants in the Boomi Community. Contributors like Moore make the Boomi Community a vital resource for our customers to get the most from our low-code, cloud-native platform.
Like most integration professionals, Moore took a winding path to Boomi. He moved from a role as an IT hardware and software support supervisor into software programming before becoming an integration architect.
We recently spoke with Moore about his involvement in the Boomi Community, his professional development as an integration expert, and his advice for others about how to approach their integration projects.
How did you get started as an integration professional?
John Moore: I got into software development kind of late in the game. One of my first jobs was for a company that made traffic photo enforcement systems (equipment that takes a picture of your license if you run a red light or are speeding, etc.). I worked as the supervisor of our production and repair department, dealing with a lot of hardware repair and software configuration issues. Our whole support department was pretty much the IT department for systems in the field. Anything technical, except for developing the actual product, was handled in-house by my team.
At the time, I was also taking some software classes and learning how to program. As part of that, I participated in a mentor program with our director of software engineering. He was the reason I got into software development. He taught me how to program in Java.
Then I realized I didn’t want to do software development there because the technology wasn’t interesting anymore. That’s when I pursued other options and now have held various roles as a integration developer and architect.
What attracted you to integration?
John Moore: I think one of the things that makes integration so interesting is that you have to learn how to build software. You learn the basics of database interactions: read, write, update, and send a nice little error message, if necessary, to the client-side user.
In integration people rarely think about that. They’re dealing with data that doesn’t persist anywhere. It’s just about taking data out of a database and putting it somewhere or transforming it and putting it somewhere else.
Most people in the business don’t realize that there’s a software layer there. That’s interesting to me, because it’s still important. And when an integration breaks, everything downstream will probably not work.
So the person responsible for the integration really has to know how the source system works up to a certain extent, and how the destination works. If either side breaks, the business comes looking for you, the integration expert. They don’t know why something broke or why records are missing or why a record wasn’t updated. They just come looking for you and want an answer.
And that really involves digging into how the source system or the destination system works. I don’t think you can write a good integration without knowing those things. It’s like electronics repair because you have to know how everything around you is working in order to find your problem. For the traffic enforcement equipment we used at my former company, any integrations were custom coded. And it was a giant mess. That’s why something like Boomi is necessary.
How did you start using the Boomi integration platform?
John Moore: I moved on to a new job with a global corporate travel management company. We were working on a lot of point of transition (POT) processes, while another team worked exclusively with a NetSuite integration. So, as that team worked on point-of-arrival (POA) integrations, we were very quickly building POT integrations. The deadlines were very aggressive.
During that time, I learned how to use Boomi and became one of the end-to-end integration developers very quickly. And it was because of Boomi that I was able to do that.
And one of the good things about Boomi, especially when I started, was that the documentation was comparatively good. And, I love reading documentation. I like reading about technology more than developing it!
Why do you think documentation is so important for integration development?
John Moore: I’m kind of a documentation buff, and I try to encourage it within any team I’m on. Documentation is important — not always fun — but when it’s there, it proves that you have a good product. An API, for example, is not really an API without the documentation.
So Boomi documentation allowed me to rev up quickly. It also allowed me to retain certain information when I’d hit a snag developing a Boomi process, and I’d remember that I saw something about it in the docs. So, I’d reference it and know right where to look. This was all before the Boomi Community was what it is now.
What were your initial impressions of the Boomi platform?
John Moore: What I liked about Boomi right off the bat was that all the development takes place in the browser. Being able to do all the development in the browser is pretty neat. All the deployment and the administration menus, all the environment management is done in the same place. I really like that.
Also, the versioning of processes. That allows things to move quickly and have a central location where the team knows where to look. That’s helped speed up a lot of my work.
What is the biggest change from writing code to designing the architecture of integrations using Boomi?
John Moore: If you took classes today in college for software development or programming, you would not be taught how to take a simple requirements document and turn that into a product. None of that is covered. You don’t learn how to speak with a business person, find out what they need, and explain how the process will work.
Boomi kind of forces you to do that while making it easier to do. I do miss programming. But, when it comes to Boomi, if I see a team member writing a bunch of custom Groovy code or JavaScript, I usually find a way to do it with Boomi out of the box. So, as much fun as it might be to write a bunch of code that people down the line can’t read, there’s probably a way to do it better with Boomi.
What do you like most about working with Boomi?
John Moore: It forces me to be an engineer — more than a programmer or developer. Anybody can learn a programming language — come in and just spend seven hours implementing something that’s already designed.
But for integration architecture, it’s about the big picture. It’s easy to write code that works, but when you’re writing an integration at a higher level, you must think about what could happen if something fails. And something will fail when you’re dealing with a bunch of other systems.
So as an integration professional, you need to understand the design of the whole system. It forces you to think about what’s happening around the code, which is useful because programming languages change. There’s always the next new thing.
What advice can you give others who are grappling with integration challenges?
John Moore: If I could go back in time and talk to two-years-ago John, I would absolutely tell my team to constantly look for better ways to test integrations, test the processes — “be the test,” if you will. Find a better way to do it so these processes can be regression tested and things can be automated.
That’s something that just wasn’t on the radar during the busiest times at some of my jobs, when we were under pressure to move as fast as possible. And we kind of suffered through it. We got it ironed out, but it would have gone much more smoothly with a more methodical approach that included a structured testing process.
Our vision back then was to create a Boomi process that would test specific sub-processes, and it could be run on a schedule. Even if it menat manually testing and firing off a Boomi process to regression test an input file. When you have 70 integrations running, and every week someone in the business changes a field or something like that, it wastes a lot of time. So, if I were to go back in time, I would tell them to concentrate on that.
My favorite example is Coupa. When Coupa outputs an integration file, it’s pipe delimited. And they allow pipes to be entered in a free-form text field on the front end, which completely garbles the data format. So, you can just imagine what happens there with Boomi.
We ended up writing a script that literally switched on and off, checking every time a port opened and removing the pipe. It was a hack, but that clean-up script worked.
What other lessons have you learned about running integration projects?
John Moore: I would insist on heavy collaboration within the team and with the organization. Teams need to come up with their own idioms and conventions and stay consistent with them and enforce them. Even if it means how far apart on the canvas shapes are spread apart. It all comes down to readability and ease of use — especially when someone who didn’t write the process gets his or her hands on it.
As great as it is, Boomi in the wrong hands can create a big mess very quickly. A good tool can mess things up very fast.
Why do you think it’s important for Boomi users to be involved in the Community?
John Moore: When I started, the Boomi Community was very modest, but it has grown tremendously since then. Just having a forum, whether it’s on stack overflow or whatever, is so powerful. What is shared and discussed becomes documentation. It describes real-world scenarios.
Even if you have good documentation, you can’t capture all the real-world scenarios. And that’s where forums and knowledge-based articles come from, those real-world scenarios that people find challenging.
I know everybody on my integration teams use the Boomi Community every single day. Even as a so-call “expert” now, I still find lots of answers and help from the Community. And I’ve posted a lot of answers as well. Usually, it’s just about helping people get started using Boomi. Once they are oriented to the tool, they are usually off and running.
I some cases, members of the Community will just want you to solve their exact problem. I’m not a fan of that approach. It doesn’t offer as much opportunity for learning. I like to know what they’ve done so far, how they’ve tried to find the answer, and why they’re hitting a snag. Then people can jump in.
When someone asks for an answer, I like to respond with challenging counter-questions asking them what they have done so far. If you participate in the Boomi Community, make sure you’re paying attention to this. I’m hoping that people who just want an answer learn much bigger lessons from engaging with Community members. Then everybody wins because the answer is present, and you have another Boomi developer who’s better at using Boomi. That’s what I really like.
To learn more about Boomi’s low-code, cloud-based iPaaS technology, please book a demo today.