IT people have been talking about agility for two decades now. How to create what the enterprise needs faster is fine. (How that fits with “the answer is someone else’s software, learn to live with it” is a separate question.)

But really, what we should be delivering is enterprise agility: the ability of the business to flex, bend, adapt, seize the moment.

From an IT point of view, this can’t be reached by our traditional means. You’d be forever anticipating potential future use cases, most of which would be unnecessary.

So, to that end, a few architectural methods to increase agile business.

Let steps be waived, skipped, etc. Most of our systems are designed to do the exact opposite: everything must be filled in (in sequence). But many elements of great customer service work precisely the other way.

“No, I don’t want to give you my postal code” (so the store can figure out its reach). “No, I don’t want any optional extras” (on my insurance policy, or as an after-market service plan). “Just get me there by 7 PM” (rebooking a flight at an airline counter). These are far more typical of a day at the coal face.

Call centre interactions (like websites) are the worst for this. Everything is so heavily scripted getting what you came to do done is frustrating.

So unlock your systems. If we were using scrap paper and pens, the clerk could grab a sheet and pick up an address change request in the middle of providing some other service — and handle that later. Meanwhile, having asked about extras, and been told no, no slips for those would ever be created. The customer got speed and is happy.

Our solutions need to work that way. Maybe you get there through decomposition (pull up what you need), maybe through a skip button, but make it possible for employees to work the way your customers do.

Let your systems flow. Banks (to take one example) have systems for your bank accounts, systems for your credit cards, systems for mortgages and credit lines, and systems for your investments. These were created (or sourced) independently.

The customer moves and wants to update their address. Is that a one step operation — or does it have to be done over and over again? Is their self-managed RSP or TFSA that contains a mix of savings, GICs, stocks, and mutual funds an account, or several?

Even when it does all look seamless to the customer (one update) you can create ill will simply because the underlying piece parts update slowly. (I moved at the beginning of this month, and it took Apple’s iTunes Store four days to stop sending invoices with my old address after
I updated it — worse, I’d get old after new as different services invoiced me.)

Data needs to flow into systems. That means passing messages and ticking off the updates.

Flow with demand. In this era of infrastructure on demand, bought as a service, there’s no excuse for putting anyone through a demand crunch (all of us standing, waiting and waiting, while our debit cards get processed in the Christmas season, know what I’m talking about).

Again, parallel handlers and message passers are the answer. Big monoliths are not (and most of our systems are).

These are three starting points to up your enterprise’s ability to prosper. Delivering value from IT begins here.

Would you recommend this article?

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication. Click this link to send me a note →

Jim Love, Chief Content Officer, IT World Canada
Previous articleCloud Factory conference: beyond the buzz word
Next articleBe prepared: Keeping your Android alive when things get complicated
Bruce Stewart
Bruce Stewart is a 40 year veteran of IT management and above. He is an executive advisor serving CIOs and senior executives in areas of governance, strategy, complex architectural transitions, portfolio yield and value generation. - See more at: http://blogidol.ca/author/bastewart#sthash.irsVlPlk.dpuf