A big part of what BLDG-25 is known for is our UX expertise and our broad technical knowledge. This is the focal point of what people tend to see – but what’s operating on the back-end of our projects? Our knowledge of back-end tools that enable the front-end is just as valuable.
I work on back end systems. One of the things I frequently encounter is that not very many people understand what I do. To describe it further, I’m a back-end application developer. I work with business processes, relational databases, object modeling, and REST APIs, to describe a few things. If you understand some of those terms we have some things in common. If you don’t, and you operate a large organization, you probably need me, or someone like me.
A friend of mine who works in this back-end development space recently shared an interesting complaint. He was talking about product managers and he said something like, “as far as they’re concerned, what we do is ‘magic’.”
Although he was complaining, I kind of liked it. First, I do think it was largely accurate. And it reminded me of the third of Arthur C. Clarks three laws: “Any sufficiently advanced technology is indistinguishable from magic.”
Now I’m not saying that what I do is so advanced that no one else can understand it. Many people do. But I am saying that I have been so immersed in it, for so long, that many – even most – people don’t really understand what I do. To them it is, indeed, magic.
But it’s magic they rely on. They expect and demand it to work.
I’ve been in business systems for over four decades so I can promise that I have seen a lot of tools to support back-end data management efforts. The key component to a successful business system is that you have to have a good flow of information – from your customers through your order fulfillment processes, all the way through buying inventory, manufacturing systems, all of it.
Personally, I’ve experimented with a variety of approaches for connecting different enterprise applications together like Jitterbit, Mulesoft and more. But when it comes to EAI, I’ve never worked with a tool as convenient as Boomi.
What is Boomi?
Boomi is a low-code tool, a la Salesforce, with a graphical environment and drag-and-drop components. Dell acquired Boom in 2010 after it launched in 2007 – it primarily touts itself as offering iPaaS (integration platform as a service) solutions and tools for cloud-connected businesses. It can either be cloud-based or you can host it on your own server. Sometimes, that’s an important piece for applications behind firewalls that can’t be seen from the cloud. Ultimately, it’s a tool that provides really fantastic graphical abilities to transform data/a document into what and where you want it to go.
Biggest pro: reusability
Reusability of objects is something that people have talked about for a long time and it seldom lives up to its name. It’s perpetually been a disappointment for those of us in the field. Most tools offer “reusability” that we can fine-tune to the point where we want it but…it never seems to be easily replicable and re-used. It always feels like, well this portion and that portion are similar enough in what I want to achieve, but they’re different enough that I have to program the thing all over again. Boomi has done a stunning job of achieving a very high level of reusability.
Biggest con: naming nomenclature
Boomi thinks of things in terms of documents – so once you get data in there, it’s considered a document. You create a process, then Boomi takes your data and it considers it a document on the input side. It may manipulate them but there’s some resolution and a connector on the other side. For example, it may take a document from here and put it there. You can put data in as XML and get it out as JSON. Or a process can reorganize the structure of the document. This is the one part I found hard is how Boomi’s infrastructure offers a peculiar way of thinking about things. There’s the sense that once you get what they’re doing, you see the wisdom of it. You just have to have the “aha!” moment.