This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
You & Your Comms APIs: Ignore Them No Longer!
Most of us have heard the phrase "software is eating the world," its driving point being that what used to be accomplished only on the other side of that warranty sticker can now be achieved on almost any compute device imaginable. We're free to solve our own problems if our preferred vendors can't solve them for us.
We, the customers, now have the advantage. But to reap this reward -- to gain this advantage -- we need to arm ourselves with the necessary tools. We have to become literate in the ways of software developers.
Keep On Pushing On
Notice I'm not saying we all need to turn ourselves into software developers. Each of us will "self-level" -- meaning, we'll find our own level of involvement in software. But this self-leveling can be dangerous; if you don't push yourself outside of your comfort zone, you might stop too early. And if you stop too early, you won't be able to help your organization truly to the best of your ability.
Yes, I'm saying that you, taking time and learning a new way of doing things, will help your company solve problems faster and cheaper. Please don't believe anyone who tells you that learning a completely new way of doing things, solving problems that you've been solving for years but now in a different way, is going to be easy! This will not be easy. You will not become a software developer by taking one course or attending one hackathon. If software development came that easy to you, you're probably already a software developer. This is going to be a long, hard journey into learning a complicated ecosystem.
But if it's going to be hard, frustrating, and people will want to quit... why should we do it? Why should we spend company resources and our personal time learning a new way of doing things?
The answer is simple. You should do this because you've always done this. You, as a career IT infrastructure engineer, have always been pushed to learn new ways of doing things, just as the ways of doing things has evolved!
All in the API
The only problem is that software development has been there the whole time, but most of us (myself included) purposely tried to stay as far away from that world as possible. I didn't want to learn how to write code, "I'm not a Web developer," I told myself.
I lived in networking infrastructure, then I worked on telephony infrastructure, then video infrastructure... are you seeing a pattern here? I convinced myself that I didn't need to know any programming languages because only people working on websites needed that sort of knowledge. But then, when a manager would ask for some metrics on our usage of something, and that metric wasn't tracked by the "out of the box" management software... I was sunk.
I was left with my only two options. I could call a meeting with our vendor and engage in the always-fun conversation of "how don't you have this built into the system!?" Or I could issue a request for proposals to partners of that vendor to tell me how they could solve my reporting problem, and 100 other problems that I didn't even know about, for the low, low price of are you kidding me! Inevitably, the answer always came back to the same thing, the vendor would tell us and the partner would tell us, the data we're looking for is available in an API.
Be a 'Have,' Not a 'Have-Not'
It took a long time, but finally it dawned on me that there are two types of infrastructure people -- the haves and the have-nots. The haves can write their own code, and they query their own infrastructure APIs to solve their own problems. As soon as I realized that I was a have-not, that I lacked the ability to solve an aspect of my job, I realized that I needed to take action for myself. This was a turning point for me.
This wasn't an edict brought down on me by management. This was a reflection of where I was in my career, and where I didn't want to be. The entire marketplace was telling us all that we needed to learn how to interact with APIs. I told myself that there is no downside to learning this skill. If the API hype was overblown, I'd still walk away from this effort with knowledge that I didn't have before and the ability to solve problems I was hoping others would solve for me.
This new skill easily translated into the ability to make better decisions. I could show, using metrics from APIs, cost-saving opportunities. Those opportunities were only brought to light because we could now look at the data.
Once you become a "have" inside your organization, more opportunities for you to be involved in big and exciting projects will start coming your way. You'll be brought to the table in those conversations not only as an expert in your field but also as someone who can speak to the API options. You'll be asked to make hard business decisions on buy vs. build, on standard vs. niche solutions.
By taking the path less traveled as the infrastructure person who can write code, you'll position yourself as a forward thinker who is open to disruptive change. By having the right people in those early conversations, you can help steer the company in the right direction by using your years of experience in your field, coupled with the knowledge of what's possible with an API.
So that's my message. Start by pushing yourself outside of your comfort zone and learn how to leverage the APIs of your own infrastructure by writing your own code. The journey you'll take is going to be frustrating, as learning anything new is, but once you've leveraged that information you've just collected you'll feel an excitement that only the "haves" have felt before. That excitement is that, with this new skill and willingness to learn, you can solve, you can integrate, you can guide your business better in this new API world.
I'll explain more, and share my experiences with software development, at Enterprise Connect 2018, where I'll be running the Monday, March 12, session, "Why You Should Embrace the API Movement." I'd also encourage you to participate in the pre-EC TADhack-mini, a great opportunity to work with communications APIs with lots of support and camaraderie, as I discovered last year:
I look forward to seeing you there!
Check out the full APIs & Embedded Communications track at Enterprise Connect 2018, March 12 to 15, in Orlando, Fla. And register now using the code NOJITTER to save an additional $200 off the Regular Rate or get a free Expo Plus pass.
The TADHack-mini hackathon is back in Orlando, Fla.,Saturday, March 10, and Sunday, March 11 --the weekend before Enterprise Connect 2018. TADHack brings together a rich diversity of people across the EC audience and the Orlando community, anyone from students to IT managers, from computer programmers to marketing folks. TADHack participants will collaborate on software projects that focus on using programmable communications to solve problems that matter to them, and the winners will be showcased at Enterprise Connect in the Monday afternoon session, “Hackathon Spotlight: ProgrammableCommunications is for Everyone.” Get more information and register here!