If you follow this blog, you know that I mostly write about fintech, marketing, product management and customer experience.
IT architecture is a new topic. I was prompted to write about it after witnessing a series of chaotic happenings with modern SMAC architecture during the last few months.
For the uninitiated, SMAC stands for Social-Mobile-Analytics-Cloud. SMAC applications are typically built using cloud hosting, app stores, web services and APIs.
I encounter the following building blocks of SMAC in my everyday life:
Everyday SMAC Building Blocks
Cloud Hosting: My company’s website, including this blog that you’re reading, are hosted by HostGator, a leading hosting services provider.
App Stores: GTM360’s mobile apps are published on Google Play Store.
Web Service: Every time I publish a new blog post, a web service called Twitter Feed automatically tweets a link of the post to my Twitter feed along with the first 100 characters. Every time somebody likes, retweets or replies to my tweets, another web service called IFTTT adds them to a Twitter List called skr-engagers.
Third Party APIs: This blog is published using WordPress. The world’s leading blogging platform uses an array of APIs to perform various functions like validating the blog to third party plugins like Disqus (comments) and Akismet (spam protection).
SMAC architecture helps non-technical people do stuff they otherwise can’t dream about. For instance:
- This blog exists only because of cloud hosting.
- It’s thanks to the visibility provided by Play Store that our mobile app LBTR360 could attract the attention of Computerworld, which named the app to its list of Top 10 Android apps in the to-do list category.
SMAC architecture also helps technical people cut down time-to-market of new applications by letting them deliver new functionality readily using preexisting web services (and open source code) instead of developing them from scratch. As Fortune says:
Fewer companies are releasing bloated, monolithic apps that take months or even years to revise. Instead, they are breaking them up into individual components or “microservices” that handle specific processes. For example, a bank might create one authentication system for creating accounts or for verifying a person’s identity that is used across all of its systems and apps. In theory, this lets organizations update software more quickly.
With that out of the way, let me describe the kind of chaos I witnessed with SMAC systems in the recent past.
#1. Failure of ‘Set and Forget’
Most SMAC services are designed to work on the “set and forget” principle. Most of the time, they deliver on that promise.
The chaos begins when they break that promise.
Like Twitter Feed did. I recently noticed that the tweets posted by Twitter Feed didn’t contain the link to the post (although they did display the 100-character text). Because the web service had been working on “set and forget” mode ever since I installed it over five years ago, I’d totally forgotten how to configure it! I’d been wondering how to fix this problem. But, lo and behold, while I was trying to take a screengrab of one of the problematic tweets to use in this post, I noticed that the last three tweets do have a bit.ly link!
Problem solved. Without me doing anything about it.
Unfortunately, not all problems get solved automatically.
#2. Premature Death
Many web services acquire huge distribution by word-of-mouth. Then, they suddenly die because they’re built without a business model and can’t afford the mounting hosting charges e.g. aforementioned Twitter Feed and IFTTT recipe. This leaves thousands of applications built on top of them in the lurch e.g. auto-tweeting and skr-engagers list. Now, I need to look for another auto-tweeting service for my blog and find some other way to update ‘skr-engagers’ whenever someone likes, retweets or replies to my tweets.
#3. Frequent UI Changes
We’ve all been through perplexing moments when familiar software suddenly looks strange, with screens, links and buttons vanishing into thin air. This happened with Windows Vista a few years ago. It happens with virtually every SAAS software nowadays.
It’s easy to spout philosophical statements like “change is the only constant” and all that, but the chaos caused by frequent changes to user interfaces shouldn’t be underestimated, especially if the software is used by large teams and / or time-poor executives.
#4. Too Many Moving Parts
SMAC applications tend to use open source code, third-party APIs, and so on. Corporate systems are highly reliant on app store passwords, API keys and more.
This has introduced a lot of moving parts in IT landscapes. Since wide circulation of credentials leaves the system open to attack from multiple threat vectors, the security best practice is to restrict their circulation. But the people who do know this information needn’t be permanent employees in today’s world of distributed development teams – they could be contractors or supplier employees as well.
As a result, it has become quite hard and time-consuming to recover from a defect or attack, whether they’re caused by a poorly trained employee or disgruntled team member. As the aforementioned Fortune article notes:
The downside is that a company’s chief information officer might not have a centralized view into all of these different projects. If an app falls down on the job, it’s tough to pinpoint the cause.
I can testify to this from first hand experience:
An ecommerce customer’s employee deleted a few duplicate records in the database without knowing that this housekeeping best practice would cripple the open source search function used by the software. As a result, the website came crashing down.
Had the system been developed and hosted internally, it would have only taken a few minutes to troubleshoot the problem and restore the website.
However, the website had used many building blocks of SMAC architecture and the only person who knew all the passwords and keys was no longer working for the company.
Luckily, the present development team was able to locate him and secure his help to fix the problem.
All’s well that ends well but it took four days to resolve a five minute issue. Needless to say, the company suffered a significant loss of revenues and severe damage to its reputation due to this outage.
#5. Excessive Hype
The last, and perhaps the most serious, source of chaos happens because SMAC hype has overtaken reality by leaps and bounds.
Hype is no stranger to the IT industry. However, in the case of SMAC architecture, it’s gone a bit too far and is causing a ton of operational risks.
I got a glimpse of this when I recently visited a healthcare center in my neighborhood. I was asked to fill a registration form. I told the receptionist that I’d already registered with them during my previous visit. He told me that they’d lost all customer data when their server crashed two months before without any backups.
When I asked him if form-filling will become an ongoing affair, he assured me that they won’t have any problem in the future because they’d “shifted everything the cloud”. Obviously, he assumed that the cloud service provider would take care of backups and make the data available 24/7/364.
Big mistake.
If ever you forgot it’s *your* job to backup your cloud data, @HostGator will remind you.
I hope the CIO of this company knows better. But I strongly doubt it. Because it’s not just this random healthcare center.
Australian ATM networks recently went down because their cloud service provider suffered an outage. According to Finextra, there was no backup. Apparently, the leading banks to whom the ATM network belonged thought it was the responsibility of the cloud service provider to take the backup. And the cloud service provider countered by saying the hosting plan purchased by the banks didn’t include a backup.
When such things happen even to seasoned technology users like banks, you know that the “cloud gets rid of all infrastructure worries” hype has gone a bit too far.
Just to be clear, it’s not my intention to discourage enterprises from implementing new SMAC systems or migrating their legacy systems to SMAC architectures.
I’ve highlighted the topic of chaos only to underscore the need to plan for measures to mitigate the risk caused by it while embarking upon SMAC implementations and migrations.
And I’m not alone. Yvette Cameron, Gartner Research Director, offers similar advice on the right!