Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
Breaking a bit of tradition… there is a funny story in here but not until after I let you into my head for a second. Now, don’t be scared.
I've recently been doing some research on social computing. I'm not even close to being a "visionary" - that's Dan and Hub's job - so maybe I'm stuck in the myopic world of SOA. But when I hear web services, I think integration/SOA, but as I read more and more, it seems I'm in the minority. Most people hear web services and think Facebook, Twitter and a host of other things that are seemingly more about social computing than web services. Perhaps they are converging? I think I like that idea…
I [personally] care about businesses using technology in a way that takes the 'technology factor' out of it. It enrages me when I ask a question and the answer is phrased in terms of the technology used to solve the problem.
I recently had a rather humorous conversation with Continental -- I encountered a problem related to manipulating a reservation on their website. It was a (polite) 20 minute conversation where I insisted it was a reservation problem while she insisted it was a website problem. Why did it matter? Because she could help me with a reservation problem but not a web problem - even if the reservation was made via the web. I enjoyed the semantic disagreement because I knew that under the covers somewhere there was an IT vocabulary driving the interaction. (Totally aside, in the end, it turned out she could help me... she put me on hold, called the online department, and then came back online and said, "they are aware of the issue, try again in three weeks." Yes, I wish I was kidding.)
Anyway, earlier today I read David Linthicum's Real World SOA Blog post about United Airlines needing to look at their IT architecture. David held himself back from ranting about the airlines and focused on the unacceptable result of an IT failure. It's a good post... I think trauma, like the airline failure like he experienced, often makes us reach new heights of clarity on what's really important. What bothered him was that a "solveable" resiliency problem kept him stuck in Canada. But, I got the feeling there was also an underlying issue bothering him, that of corporate complacency around IT infrastructure's importance to business operations. Now if I was David, I would not have been upset as much about the unnecessary IT related delay as I would have been at the lack of concern United showed for the high value asset they have in David.
See, we all like to think we're special. However, in the case of airlines, some of us really are special. There have been multiple years where I've flown over 150,000 miles - that's flight miles. And while I don't keep track of my total flight expenses, it's quite possible I've spent as much as $50-75,000 on airline travel during a busy year. I've been flying extensively since 1997 - you do the math. Now, the airline can leave behind a bag from a family that spends $2,000 a year on a family vacation, but I find it insane that they would ever do it to flyers like David or me.
It's a controversial thing to say, but I'll say it anyway, “not all customers are created equal.”
I don't believe the IT architecture failure was the problem, as David said. Let's stop phrasing the answer in terms of the technology. The problem was a severe bad experience of United customers. It could have been solved by a more robust architecture (a technology), or with a better relationship (a technology-transparent solution). You’re crazy if you think you're going to have a relationship that doesn't have any bumps. If you fly, you'll eventually be delayed. What saves the relationship is, well, the relationship. And it's always better when you don't have to ask for an apology.
(SOA What?) Where am I going with this? Not 100% sure... but, let me point out three things to think about:
Let me clarify. I don't expect the CEO of Continental to call me and ask how my mom is doing (she's fine by the way), but I need more than a form letter apologizing for the delay. Chris Anderson, the editor at Wired.com and author of the book, The Long Tail, has an interesting take: He'll talk to any PR person that takes the time to write him a personal message based upon his interests. Anyone sending him "generic" newsletters/SPAM gets banned on first email.
Let's think about this… all he's asking for is a bit of personal attention in exchange for his valuable time. Seems like a fair trade to me. All I'm asking from the airlines is an acknowledgment that they made a mistake (note to Continental, the Newark baggage guy telling me, "oh, we took your bag off in Hong Kong because the plane was too heavy," is not what I had in mind). American Express apologized when I had to call three times to change my address - they read my record, knew it was the third time I called, and immediately apologized. It totally changed my experience of the interaction.
So it's not about "my personal information," it is about the "personal experience." And IT, SOA, Web Services, and Social Computing can make business more personal to everyone's benefit.
Well... where do you start? The second two points above are actionable. First, you need awareness of your customers, with flexibility around how they are segmented. In parallel, you need to understand your process - whether it's the process of taking off from an airport or changing a mailing address. Then, you need to merge those two and overlay them with a policy infrastructure so that the answer isn't "call back in three weeks." This isn't easy stuff... but you're going to have do it. Get ready.
View all posts from david bressler on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.