Next week I’ll be presenting on this “Is Amazon Your Architecture?” topic at Gartner’s EA Summit conference in London, and then again on June 22-23 in San Diego (event details in the links per event — follow on twitter using the #GartnerEA hashtag or me directly @brucemr). My goal is to discuss the way Amazon has architected their store and logistics applications (sites, systems, solutions) with an extreme SOA architecture, and then how they’ve taken a similar extreme services architecture approach for infrastructure services with Amazon Web Services (AWS). For many organizations both the application and infrastructure architecture approaches are useful, depending on the problem.
FYI: I’m only tangentially suggesting enterprises should leverage AWS or Amazon’s store and other “SaaS” like application options. The point here is should their architecture (particularly technical) be used inside the enterprise. For many organizations, I think the answer is yes.
What do you think? Does your organization have solutions that require extreme SOA?
I think many do — and Amazon’s store is something not unlike many of your enterprises might actually try to build, so it’s a good example to use. Amazon’s lessons learned are worth hearing about, I believe.
However, many of us have applications that can NOT take an extreme SOA approach without extensive modification (or complete reworking, more likely), and there’s no money for that any time soon. For these non-extreme applications, should we then consider using AWS? The answer is: sometimes. Monolithic apps that can’t run in parallel on separate virtual machines (and as recent EBS and S3 outages have reminded us — in separate availability zones and regions) are very risky on the infrastructure services Amazon and other providers offer today. However, there are times when the risks are worth it — such as for test and dev work. Depends on the problem and the risk tolerance of the enterprise. Even with the recent Amazon outages, some organizations can live with a system not being up for a whole day. It all depends on the problem and the risk tolerance of the organization.
Still, the real lesson most enterprises should learn from AWS is not to use external cloud services alone, but to structure their own technical services or infrastructure service offerings not unlike AWS. Look at how Amazon defines their AWS portfolio. Look at how they describe each service (not much on the provider, but lots on how to use it and service levels offered). Really peruse aws.amazon.com to see how they market their shared services.
Can your IT organization do this? Have you described the “what does the customer get” part of your shared technical services as well as you’ve defined how they are built or provisioned?
Read Complimentary Relevant Research
Cloud Computing Primer for 2017
Cloud has evolved from a disruption to an expected approach to traditional as well as next-generation IT. Our research helps IT leaders,...
View Relevant Webinars
Cloud Megavendors: CIOs Must Understand Vendor Cloud Strategies
Price wars, partnerships, acquisitions and co-opetition, along with rampant confusion and cloud washing, are setting the stage for battle...
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.