by Meg Ramsey
Recently I attended my fourth Amazon Web Services (AWS) Summit of the year. As a seasoned Summit attendee, I appreciate the customer stories that AWS amplifies and look forward to this aspect of each Summit. The keynote usually highlights at least one local startup and one enterprise company to promote their AWS use cases, and sessions are a mix of customer user stories and technical content from AWS evangelists.
The Summit held in New York City did not break the mould, however I noticed that this event focused heavily on the financial services industry, which I believe signals an increase in public cloud adoption by large financial institutions. There was an entire track devoted to this industry that featured companies like IHS Markit, FINRA and AIG. The sessions in this track were filled to capacity.
FICO CIO, Claus Moldt, spoke on the main stage about moving its flagship analytics platform onto the public cloud provider. While some sessions were focused on AWS' new services like analytics and machine learning, one session that seemed to encompass most of the Summit’s major Financial Services topics was with AIG. In the session, AIG told the story of its massive digital transformation project that took its global business claims application from mainframe to hyperscale. It perfectly illustrated the decision points enterprises face when transforming legacy infrastructure for the public cloud.
As I listened to the speaker from AIG detail lessons the company learned along the way, I noted several commonalities with my own experiences. Some of the most prominent takeaways from this session are listed below.
- Sometimes even best practices need an overhaul. The first challenge AIG articulated in its presentation was federated login, and I can understand why. Following AWS best practices requires that companies not only set up an account for every application, but also an account for every environment of that application. Even a simple web application generally has four environments: Development, QA, UAT and Production. If you start consuming AWS in the traditional sense, each user will have separate logins for each account. Multiply that by the number of applications your company is managing at once, and you can imagine how unwieldly it will get from a user-management standpoint.Thankfully, Amazon realised this was a big adoption roadblock for its enterprise customers and created AWS Organisations, a role-based, federated account view for its customers. Prior to AWS Organisations' launch in February 2017, we at Sungard AS built our own account federation tool. When Organisations was GA, we immediately updated our tooling to take advantage of the Organisations feature set. Looking at best practise as an evolving target is, well, best practice.
- Develop to your strengths and leverage (the hell out of) AWS. Our Sungard AS experience incorporating AWS Organisations into our service was not unique. After its announcement in November 2016, we immediately understood the potential of the new service and moved quickly to test it with the goal of replacing our own homegrown account federation tool.We recognised that our own account federation tool would not keep up with Amazon’s pace of development, scalability and flexibility. For us, account federation was a foundational service and not something we use as a differentiator. So instead, we built a managed service that leverages standard AWS services and other third-party tools, while focusing our differentiation on our own strengths. This is an important lesson for enterprises adopting public cloud APIs. Identify what differentiates your services and focus your development efforts there. Then let the public cloud do the rest.
- Public clouds can fail. Plan for recovery accordingly. As every IT manager knows, infrastructure can fail and enterprises must be prepared. AWS is built with this in mind, as evidenced by CTO Werner Vogel's thoughts Expecting the Unexpected in his blog post covering the 10 Lessons from 10 Years of Amazon Web Services. As AIG discussed in its presentation, Amazon is not only willing to admit disaster happens, but it shares its own recovery strategies with customers to help them build their recovery plans. Why admit failure? It’s the most efficient way to learn and grow. Lesson number one in Vogel’s post is “Build evolvable systems,” and as a result of listening to feedback and acknowledging errors, the company does just that. It’s constantly evolving, adding to existing systems, and developing services on which its customers can rely. It’s what Amazon does best.
- Work smarter, not harder. AIG’s talk reinforced something for me. Just as the Summit format is consistent across events, so is the digital transformation experience for so many organisations. Yes, the specifics may differ. Financial services will have different pain points than hospitals or universities. But in the end, we have similar growing pains, and we can learn from each other across industries.It’s a summary lesson that can benefit us all. Focus on what you do best. Identify your strengths, and don’t spend your efforts toiling on systems and services you can source elsewhere by working with experienced and knowledgeable partners.
By taking mission-critical workloads out of their own jurisdiction and moving to the cloud, organisations are wise to leave it to the experts. It’s a smart move for any industry.
Sungard AS is a Re:INVENT bronze sponsor in Booth 2019, Las Vegas, NV, 11/27-12/1. Visit us to meet our team and discuss your Cloud opportunities.