Five Ways to Help IT Respond to Business Demands
It's no secret: businesses are making huge demands on their tech departments these days. And for good reason.
Markets are changing, customers are demanding self-service and personalization, partners are demanding self-service and speed, employees are demanding self-service and access to information.
Something has to change, and it mostly comes down to time. In the absence of any stunning advances in time warp technology that might enable the injection of a few extra minutes into the day, tech departments will need to find other ways move faster.
So what isn't changing? Security, uptime, business continuity, audit trails, and role-based access. All that great stuff remains as important as ever, but it takes a while to get right.
If we keep all of this, then what do we change to meet these needs demands from the business?
- Build interfaces
- Let others participate in success
- Self service
- Try things
See? This doesn't have to be difficult. Let's unpack these five points.
Nobody needs to know about the messy guts of your department's systems. Any large organization probably has multiple sources of truth and many naming conventions. Why saddle anybody building an app with that burden?
Putting a nice, clean, simple interface in front of all your systems means that you look good—to everyone: other departments building apps, partners, third parties. No matter what the state of your systems, you’re going to look marvelous and people will believe that you are easy to work with.
Let others participate in success
I have so many devices around me that my whole office shakes when I receive a message. And for every device, I have dozens of websites that I use. At this point, most technology departments need to gaze into the mirror and look into their own bloodshot eyes. You’re already busy doing what you do best (uptime, disaster recovery, identity, security). Why pretend that you also have the firepower to build apps for every device and web integration and platform and cloud and whatever else?
Gone are the days when we could control everything from back-end systems to the end-user experience, all within one group. The logical way to respond to this change is to embrace it. Somebody has expertise building smartwatch apps? Give them a hug. Embrace the fact that the expertise is out there—in other departments, in partners, in existing apps.
Together with these pockets of expertise, you can build wonderful apps that delight users. Everybody wins and gets free cake and even more hugs. The cake will probably need to be paid for, but the hugs should remain at no cost.
Much ink has been spilled on this topic. I won't reiterate all of the good arguments for automating what can be automated and not even attempting to automate what cannot be automated. I will just comment from personal experience that there is slack to be found in repeated tasks and rituals once they are automated.
Stop manually provisioning, supporting, and hand-holding. So much time is wasted doing what users would prefer to do themselves.
Allow employees to do as much as possible through self-service. Sure, you will still have role-based controls, multi-factor authentication, and all of that good stuff. But once identity has been established, enable people to take care of themselves. This applies equally to partners and customers.
Why burden your teams with supporting and handholding? Your people could be building amazing things that will propel the business to new heights and leave the competitors scratching their heads.
I briefly coached junior high basketball years ago. When I asked one of my players why he didn't shoot more often, he replied that he didn't know how to do it perfectly yet, so he might not make it. I pointed at the basket. If you don't throw the ball toward that orange hoop, you will never score.
Analysis paralysis is the second leading cause of death among IT projects at large companies.
Instead of waiting until that perfect set of requirements has been found, dipped in gold, burnished, and glowing with perfection, just get started. Build something good and iterate it into something great.
Interfaces (see point #1) enable you to prototype, develop, deploy, rinse, and repeat quickly because the app builders don’t need to inspect the guts of existing systems. They just need to trust that the API will respond to their request.
That, my friends, is what APIs do. Responding to requests is what gets them out of bed in the morning. It puts smiles on their faces and a bounce in their step.
And, like an encouraging coach, they should convince you to throw the ball. Let’s see what happens. You’ll score some points and learn to shoot even better. The only sure way to lose is to not shoot at all.
Having read the tongue-in-cheek reference to the second leading cause of death among IT projects, do you have any thoughts on what the first might be? Join the conversation on the Apigee Community.