I started off this blog post by typing “Is Amazon Taking Over the World?” and it turns out there is quite a bit of debate on this.  Some analysts say yes, others say no.  But one thing these articles all get wrong is the entire context of what Amazon seems to be doing.  My analysis?  Yeah, they’re taking over…but not how analysts seem to think.

Most of the articles seem to be talking about how online retailers are causing brick and mortar stores to become extinct.  This DOES appear to be happening, but this is not the greatest threat.  For example, everyone is making a big deal about the recent Amazon purchase of Wholefoods.  “Oh no!” Everyone says, “Now Amazon is going to destroy super markets.  Now I’ll only be able to buy bread, milk, and eggs by having them directly delivered to my doorstep via drone!”  No, I don’t think Amazon actually cares about food delivery.  Or books.  Or any of the other products they sell.  The real money is in their cloud platform, Amazon Web Services.  Amazon doesn’t care about selling you products directly, they want to be EVERY OTHER business’s back end.

There are so many small businesses out there that are hamstrung in the IT services and logistics department.  They simply aren’t large enough to have IT staff.  They probably don’t deal in volumes large enough to warrant shipping contracts that provide the same value as “Free Two Day Shipping.”  But Amazon is going to sell them that capability.  Soon small businesses will be able to handle all of their back office operations via amazon.  Consumers will be able to purchase their products from far away and have them show up at their door step at no additional cost.  All these articles reference some future battle between Amazon and Walmart, likening it to a battle of the titans.  Big box stores have spent the last 25 years pricing mom and pop out of business, leveraging their size and infrastructure to do so.  It won’t be Amazon directly that destroys Walmart, it will be thousands and thousands of small businesses who are able to compete again.

I don’t mean to sound Anti-Amazon here.  If anything, it’s admiration, in how they’ve positioned themselves to corner the cloud market.  They’re already not the ONLY cloud player, with Microsoft’s Azure cloud offering.  I think in Microsoft’s case, they’re currently a bit too focused on the front end with Office, Skype for Business, OneDrive, but I also expect more players to emerge to challenge Amazon in this space.

Thoughts on Micro-services: GE Predix

The Russinovich blog on Azure Microservices did a good job at outlining the concept, but I wanted to take a little time to put on my company hat and talk about GE Predix.

Over the last few years, General Electric has been undergoing pretty rapid change.  They’ve shed themselves of their financial services business, spinning off the retail banking division as it’s own independent company Synchrony  Financial and sold everything else to Wells Fargo.  They’ve also divested their consumer appliances business last year and recently divested their Oil & Gas division to Baker Hughes.  So what’s going on?  Well, the stated goal is they want to be a top software company in the world by 2020 and their plan to get there is to dominate what they call the “industrial internet” with a service known as Predix.

At a high level, Predix is a framework that consists of a portfolio of microservices available in an “App Store” of sorts that are specifically tailored for industrial applications.  The advantage to Predix is there is great emphasis on data and analytics as well as robust security which stems from the fact the platform was designed from the ground up to work together.  There’s nothing particularly groundbreaking here about the technology, but the idea is to leverage their already sizable installed base in the “operations technology” space where there is currently very little competition.

Everyone’s looking to be the next disruptor.  The next big thing.  Often though, it’s not merely envisioning the next great technology, but also being in the right place at the right time.  There’s a degree of randomness to it.  I’m reminded of the huge failure of the Apple Newton which was released almost a decade prior to the Palm Pilot.  IBM’s OS/2 losing out to Windows 95.  Arstechnica did a great write up on how and why that battle shook out, great to read over your morning coffee some morning.  The iPod wasn’t the first portable MP3 player by any stretch, but certainly the most popular.  Heading back to the late 70s/early 80s where you had the shift from time sharing mainframes to PCs.  That’s disruptive.  And in the last example, ironic, that in cloud computing and “as a service” offerings, we’ve come full circle.

But there is no denying the impact the “cloud” has been making as of late and it’s a bit of a wake up call for an infrastructure oriented IT professional, now due to the proliferation of application, platform, and even infrastructure as a service options available.  In my particular situation a lot of my current day to day involves assisting business partners with migrating their applications over to EC2/RDS instances in Amazon’s cloud.  This has been going on for the last few years, but has really been building up a head of steam in recent months.  This was the chief driver for my entering into the EA MPS program.  True there will always be jobs for knowledgeable IT infrastructure people, but they are becoming increasingly pidgin holed as it becomes cheaper for organization to purchase these services from third parties.   I’m betting it will be easier for someone with a strong technical background to learn the business side of things, rather then the converse.

“I’ve come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you’re thirty-five is against the natural order of things.”

-Douglas Adams, The Salmon of Doubt

There was a great set of readings on cloud in this lesson, I especially enjoyed the anti-cloud pieces.  Not because I myself am anti-cloud per say, I’m only just turning 35 this November so I don’t yet have the animosity some of my more senior colleagues harbor for it, but because the cloud simply is NOT the magic bullet, the solution for everything.  And the subscription model is NOT always cheaper.  I’m going to go through the Gartner Top 10 SaaS Myths article and talk about about those points and why I agree.

Myth 03: It’s Cheaper – Probably the big one, right?  Cost is king, after all.  But in the case of cloud, not always is this true.  For example, in our portfolio we have some applications which I will describe as “very legacy” (to be charitable).  These applications have dependencies on older, EOL operating systems and often run on hardware that may be a decade out of vendor support.  You may recognize this has a horrible situation, but these applications exist in that odd state where they are both too critical to the business to decommission, yet not important enough to spend any money to maintain or upgrade.  And yet, in the zeal for migrating everything without a hardware dongle over to cloud, application owners were SHOCKED to find out that they were now incurring charges for these systems which previously were “FREE.”  You and I might see this as simply paying down that technical debt, but I know the appearance of these bills broke the heads of quite a few folks from the business side of the shop.  Another thing that has happened a bit with some of our newer systems, some of the savings have been eaten up by mismanagement of cloud resources.   For example, I can look in any random AWS S3 bucket and see in some cases several hundred gigs of orphaned volumes.  Sure, it’s only a few cents a GB/month in charges, but in the aggregate we’re talking a sizable amount.

Myth 10: It’s All Integrated – Now, I know the Gartner article is specifically speaking to ERP systems as a service and I’m speaking more generally, but it’s not good to EVER assume integrations.  I know of several cases where an application has been migrated to AWS, but the web front end and database is still running on prem.  Depending on the type of integration, I would say existing in a cloud is even tougher.  For example, I know of one integration between an ERP system and shipping PCs in a warehouse that is set up like this:  ERP system running on Windows, hosted internally in data center in Georgia has script which every hour exports shipping data as a CSV file into a SAMBA share on a Unix box in a Data Center in Cincinnati.  The shipping PCs, again, running Windows, map to this share and the FedEx shipping software is configured to pull the data from the CSV file and print labels.  It’s kludge as hell.  But it works. (The backstory to WHY it’s set up this way is because the shipping PCs used to reach directly to a file share for the data, but these PCs were managed by FedEx and the shippers liked to surf some of the more questionable sections of the Internet in their downtime, which caused a rather nasty piece of software to crawl into and take down several domain controllers one Friday afternoon.)  And since it works, there is zero interest in fixing it.  But now it’s causing some issues with the pressure to move everything to the cloud.  Again, can’t avoid paying that technical debt forever.

Despite these edge cases that I’m sure any company who has existed for more than a few years will have, the cloud model is certainly the future.

For context, I’ve spent my entire career on the IT side of the shop and in my sixth and final semester of the EA MPS program, it’s been my experience that students in the program with an IT background are in the minority.  This has been valuable to me, because in a lot of ways, it’s a microcosm of my professional experience:  a LOT of my day to day revolves around convincing non-technical people to spend money on something that they don’t see any value in.  (It’s even tougher than you may expect, because my projects focus mainly on infrastructure, service management, and risk mitigation.  It’s somewhat easier to pitch an integration project to combine several CRMs into a single system to a bunch of sales execs compared to telling them they need to spend money to upgrade network switches to mitigate some theoretical future threat.  Generally if IT infrastructure is currently functioning, no one is ever willing to spend money on it.)  In the same way some organizations think they’re being “agile” by holding a daily stand-up or ITIL because they have a CAB that rubber stamps everything, EA suffers a bit from a lack of definition.   Everyone wants to do EA, but not everyone really knows what this means.

In the same vein, there is limited consensus on what constitutes an enterprise architect and their day to day duties.  I went on the job search site http://indeed.com  and searched for “enterprise architect” and the job descriptions and requirements are all over the place, describing duties of a CTO or director level position, all the way down to an entry level help desk tech.  Things like:

Desired Experience: JIRA, SVN, JavaScript, Xamarin, .Net, Agile, C/C++, Swift Or Objective C, OOP, Oracle, Java, Knockout Js

What is completely clear from the first few pages of the search results is that EA is a sub-field of IT.  The educational requirements say something to the effect of “Bachelors in IT related discipline, Masters preferred.” This is consistent with my own experience, albeit with a limited sample size.  Every organization I’ve been a part of had the EA org reporting to CIO/CTO and maybe a dotted line to a department on the business side.  But at the end of the day, EA = IT.  And this is completely at odds with my experience with the program at PSU, which I feel is a good thing.  EA from an architecture standpoint ostensibly exists to bridge the gap between business needs and IT capabilities.  It also exists to mediate the cultural gaps between IT and business personnel, which approach relations with each other ambivalently, jockeying to meet their respective short term goals while losing site of long term.

Even the first set of readings for this lesson on application architecture are abstract enough for a non-technical person to grasp with no issue.  The IT person may prefer models with more technical details, the business side may only be concerned with process inputs, outputs, and constraints.  It’s the enterprise architect’s job to facilitate agreement between both sides.