AWS re:Invent 2024 - Building a global SaaS platform from scratch, featuring Werfen (NTA310)

good evening everyone it's almost day three at reent 2024 with halfway through reinvent thank you for taking the time out this afternoon to attend our session on building a Global class platform from scratch featuring warin Healthcare and life scied customers are utilizing the AWS platform and solutions to accelerate Innovation and improve Patient Care by offering better security improving their data management capabilities and operating efficiency Improvement at the same time without compromising on their security posture and cloud-based SAS is allowing our customers to shift to a service oriented model thereby enhancing their competitiveness in the digital Healthcare landscape my name is agasti kukkar I'm a Solutions architect at AWS where I work primarily with customers who are new to Building Solutions on our platform and today I am joined by nes Kumar and PR adimulam from walin who will share with you their own journey of building out the SAS platform from scratch so by a show of hands how many of you are about to build out a new SAS platform or or or are in your initial stages of building one out you and how how many of you want to build out a solution but are concerned about meeting your Regulatory Compliance goals oh I see a fair share of f as well and this is some of the top of- mind concerns we hear from all our customers so I'm glad you're here in this session today we'll address these topics and also learn firstand how warin addressed each one of them during their Journey as well quick review of our agenda today we focus on what are some of the building blocks of SAS now SAS is a very wide concept so what we'll focus on are some what are some of the must know technical aspects to help you get started on your journey then we'll focus on architecting for compliance how do you ensure that you set your foundations right from the get-go and with a focus on Hippa and ISO 2701 NES and Prine will then walk you through the warin digital Solutions platform and also the cloud platforms technology architecture I'll wrap up with a few takeaways and towards the end we will remain available in this area to address any questions that you may have as well so let's get started what exactly we call mean by SAS or software as a service now SAS is a cloud-based software distribution model that allows users to access applications over the Internet typically using a web browser this allows customers to focus on on the end value result without focusing on building out the infrastructure that is required because all that is taken care of by the SAS provider the term tenant in this context means the customer that is using the SAS application now I'm sure all of us in this room have used SAS in some form or the other be it email collaboration tools customer relationship management software file sharing software it's all SAS for you now there's no one Pathway to build a SAS application some customers have existing Enterprise applications that they move to a SAS platform some others get the opportunity to build out something from scratch and there are other business influences for example data residency needs compliance requirements time to Market Etc and given that you'll appreciate there is no one-size fit all model to building SAS but that being said whenever you're building out a as platform from scratch there are a few key considerations that you need to think through and design for while these are not fully exhaustive they are broadly applicable to a wide variety of use cases so let's start with the management aspect how do you manage and operate your SAS platform I would say first thing start with building out and capturing the metrics and analytics that are both tenant aware and application tier aware once you start capturing these metrics it'll give give you insight into how your application is behaving in your production environment and can inform your scaling decisions when it comes to billing we've seen many of our customers utilize models such as usage based billing consumption based billing subscription and off late I've also seen feature-based billing as well and as the platform usage grows you want to provision for user growth provision additional resources and also manage tenant authorization and authentication coming to this actual SAS application you want to focus on how you're going to isolate one tenant from the other how are the data workloads going to be partitioned and finally how are you going to ensure that your end customer is being routed to the tenant that they signed up for tency is another key area when it comes to SAS whenever you're onboarding your applications where are the users going to be stored how are the identities going to be mapped the specific tenant and how is the platform going to render the tier of service that they signed up for so these are some of the high level things as a SAS architect you need to think through and design for and I would highly recommends working closely with your business partners so that you can then finalize your technical design because at the end of the day the final technology design could be influenced heavily by business in factors for example is this an existing application that we are migrating along with its users or a brand brand new application is there what is the speed to Market are there any other compliance or data residency needs right so I would highly encourage you to work closely with your business partners to design this whenever you're thinking about SAS it is helpful to have a mental model of and break it up into two parts the control plane and the application plane the control plane is where all the shared services and the functionality required for your platform to operate resite and these could include metrics billing analytics Etc and all these help operate the application plane now keeping the SAS plane separate helps you operate it as a separate service of its own in a standalone fashion the application plane is where the core functionality of your application resides that is where the microservices are deployed that is where the data partitioning um is utilized tent isolation and all the best practices that are followed and I'll cover these patterns shortly that's where the core functionality resides it is also essential to set up connectivity between your application plane and the control plane now the application plane will scale as the usage grows but for that to happen it must emit Telemetry back to the control plane that helps manage and scale so for it is essential to capture the utilization metrics the tenant utilization tenant activity and the application plane should surface all of it back to the control plane to allow for Effective management now another advantage of separating the control plane and the application plane is it gives you the flexibility to use independent technology stack for each of these planes I've seen some of our customers use servess Technologies for their control plane and for the application plane focus on containers or even virtual machine based Solutions so you can optimize the technology usage based on the patterns and the usage for each one of them and if you're getting started with building out SAS platform from scratch I would highly encourage you to start with the control plane first and then add features to the application plane along with the application or MVPs as you roll it out so across over a period of time you've heard Cloud native application development right so we've seen many of our customers deploy Cloud native develop uh development techniques in their teams and start building applications that follow some best practices of service Discovery tenant isolation routing Etc it might lead to an illusion that you're building SAS however unless you actually build out the control plane and all the services and features that can help operate the SAS platform you're are not truly building SAS so once again the need for you to separate out two separate application plane and control planes and build them and deploy them independently whenever we talk about SAS the term multi tant is is you often hear the term multi tant and it sometimes gets confusing what is multi tent is it is it SAS now typically you deploy infrastructure on a on a shared infrastructure as that makes it multi-tenant by default but that is not SAS in fact many SAS providers deploy the same identical copy of the software stack on dedicated hardware for all their customers a while back our AWS experts from the SAS Factory team put together some methodology or the terms that can help you understand what the deployment models are so The Silo deployment model is where all the resources in the stack are deployed specifically for a tenant and in this case an entire stack is dedicated to a tenant the pool deployment model indicates that there is going to be resources that are shared across multiple tenants and in the bridge model I've seen this rarely used but it is definitely applicable it indicates that the infrastructure some pieces could be siloed some could be pulled as well now whenever customers start building out desk s application I've seen many of them start deploying with the pulled pattern that's where the minimal viable product is built out the initial feature functionality is deployed and as and when the business requirements come in additional uh usage grows they're able to add more customers they move to either of the other patterns based on customer demand and operational excellence tenant isolation is one of the key aspects of SAS right you want to ensure that data stored between from one tenant is not shared between the other you you want to ensure data secur is safely isolated from each other and each of these tenant isolation patterns help uh have have differences based on cost and operational complexity right so full stack isolation pattern indicates that a set of resources are fully isolated for one tenant there is no sharing between them now think of it like you deploy one tenant in one AWS account and the other in the in a different one so that's complete that's your isolation boundary or you could also deploy it in a separate VPC of its own that's your isolation boundary too the the the resource level isolation pattern indicates that you could have separate data and storage infrastructure for for your tenants so for example you could have independent S3 buckets independent RDS instances for those tenants right and the item level isolation is where all the resources belonging to multiple tenants are stored in the same data and storage system now in this case you could drive isolation by using separate tenant ID Keys row level encryption or encrypting the data in each row using specific ten ten specific encryption Keys as well so again when you start building out your SAS application the infrastructure and architecture should be flexible enough to allow you to Port between each of these patterns based on utilization usage business needs and growths that you see in in the business curing is another important aspect that differentiates SAS from the rest of the applications that you deploy right so SAS providers use a combination of deployment strategies and tenant isolation patterns to avoid to offer different tiers of their application to their end customers and these tenants are differentiated these tiers are differentiated between differences in their data isolation pattern the service level up time and in terms of features as well a very quick uh overview of some of the basic uh patterns that we've seen in terms of tiering being deployed some customers start off with basic ADV and platinum tiers many others just use one tier and continue with it for the rest of their operations and add additional tiers only that's driven based on customer demand and again how the business grows okay now when it comes to SAS and cost that is these are like a match made in heaven customers want to adopt SAS given the cost aspects and also want to offer it to their end as end customers given the cost of SAS as well so whenever we talking about SAS one question often I get from all my customers is like how do I figure out the cost per tenant now the business might not necessarily be interested in the cost per tenant metric but it is essential for you to capture that metric because that will give you an idea of how your platform is is expanding and it can set your pricing your packaging tiers based on that we saw the different isolation models so ass SAS platform incurs cost for uh because of running the shared services and also the applications that run on top of it now in a siloed pattern the cost per environment is pretty easy to figure out because you have a dedicated infrastructure you can have utilize the best practices of cost allocation tags and then activate the the tagging strategies Etc and then within the cost and usage report you can figure out okay this tenant is costing me this much to use when it comes to the pool model that's where the complexity comes in so what the thought proc up here I would recommend is instrument your SAS application to First derive the compute usage then check the average utilization of the storage services for example S3 RDS where how much each tenant is consuming and based on that build up a general model of what is the utilization per tenant build use that model and then compare it with your cost and usage report and then figure out like okay this is an approximate cost of a tenant operating in a pool model now I want to highlight the approximate cost here you want to get as close as possible to to the the cost per tenant and not perfect accounting right and at the same time this is the AWS Services there are a variety of AWS partner solutions that can help you get uh derive cost per tenent as well I also want to highlight couple of our services Amazon ECS and eks that support the split cost allocation data model scatter as we call it those provide insights into utilization of these services for so that helps you in your cost calculations too now you've built out your SAS application it's running up and fine now you want to capture Telemetry from your system how well your system is doing and that is where you want to ingest all the data back into into the control plane now honestly there is no shortage of metrics you can capture and it might feel intermediating but my guidance to you is focus on those metrics that are important to you and and your stakeholders for example your stakeholders here could be Executives could be your product owners or your operations team there are AWS services that can help you ingest analyze and visualize these data sets that is the easy part right you want to actually get data from your uh application as well and that is where the development teams need to invest in building that tooling as well the AWS Services can help you capture system level information but at the same time developers need to instrument their application to surface Telemetry around usage building metrics and send it back to the control plane right and in fact we've seen many of our customers build build common shared services or libraries that are reused across their applications to help service this observability at the same time there are solutions from our partners that could help you as well this is a busy slide however this is one example of a SAS seress reference architecture now AWS provides several reference architectures that you can utilize to start building out your SAS platform from scratch and this is one model based on the SAS aspect but there are others from ECS and container based models that you could utilize as well so this particular architecture deploys multi SAS solution using our serverless application development patterns okay and that is built on key key AWS services such as Amazon API Gateway Lambda SDS Cognito Cloud front S3 Etc and the about this is all these are paper Ed so usage Based Services so your team can focus on building value to your customer instead of focusing on managing the infrastructure I wanted to quickly plug in the AWS SAS Builder toolkit and I'll I'll link to it as well towards the end the SAS Builder toolkit is an open- Source developer framework that can help you quickly get started on building out your SAS applications it has a bunch of ready made components that you can utilize it actually reduces the boiler plate code that you need to build out to create your SAS application is ready to use and definitely as I mentioned I'll link to it as well we focus on the technology aspects of building SAS another top of- mind concern that I hear from all our customers is is compliance some of the questions that you might want to answer like I want to build out a SAS platform I want to operate all the services but how do I ensure compliance as app owners as developers you want to build out a plat platform that allows for extensibility and iteration over time without compromising on the compliance posture now whenever we talk about compliance I want to remind everyone in the room about the shared responsibility model this AWS shared responsibility model is a framework that helps you identify what are the responsibilities that AWS will take care of and what our end customers need to focus on AWS will take care of is responsible for security of the cloud and that includes our INF structure our physical data centers our servers our Network our infrastructure virtualization software stack and all the facilities that could be used to deliver the applications as customers you are responsible for security of your application all your data that you deploy in the cloud right so this mental model is extremely essential to understand as we dive deeper into the compliance journey to help you get started first step in our compliance Journey especially when we focus on Healthcare and life Sciences is setting up signing up a baa to help you focus on the Hippa compliance I first thing you do is identify which accounts in your AWS environment will host Hippa compliant workloads and then you sign a baa from those accounts now you have the ability to sign for an individual account or for the entire adless organization as a whole then you start building out your SAS uh applications using Hipp eligible Services now each of these Services um have specific nuances on how you're going to configure them there is a white paper again I link to that that white paper talks about how you're going to configure each of those Services there are minutia that you need to be aware of when you go ahead and build it out so when you talk of Phi you need to ensure that you're encrypting Phi in transit and in rest as well another key area that I've seen most many of our customers focus on is ISO 2701 compliance for ISO 270001 compliance you need to ensure that you're implementing an information security management system or isms that help that meets the St the requirements of the standard while utilizing AWS Services now remember AWS will provide you all the tools and services that can help you achieve ISO 270001 this compliance or certification applies to your implementation of the infrastructure security management system so you utilize this as part of your broader compliance strategy and we also have the global security acceleration program from AWS that provides you guidance around regulatory controls and other security aspects from a compliance strategy that you you should definitely engage with as you embark on your journey and most importantly being compliant is not a one-time thing you need to ensure constant compliance by continuously scanning your environment and remediating any findings from the environment too quick plugin for these two terms it can sometimes confuse uh cause some confusion Hippa eligible is not does not mean Hippa compliant now when you talk about being Hippa eligible it refers to a product or service that can fulfill all the needs of HIPPA compliance it has the belts and whistles or other controls that can help you configure the Hippa compliance and it's designed with HIPPA in mind Hippa compliant is refers to a service or a product or an organization that fulfills all the requirements OFA compliance as mandate has all the necessary controls in place to safeguard Phi and actively monitors the environment and remediat findings as well now being hippaa blind is an ongoing process that requires continuous effort and vigilance we use it as part of a broader strategy to drive compliance through implementing risk management processes education and tooling within the organization too so you've heard of multiple AWS services and you might wonder now which one of these will actually help me get started on my compliance posture right and this is a concern that many of our customers have as well so that is where I want to present the three lines model right the three lines model is is a standard prepared by The Institute of internal Auditors that can help you drive an compliance across your organization now this model describes three lines of defense and the first line of defense is where you define and manage the risk so that is where services such as AWS config cloud trail systems manager control tower license uh and license manager can help help you do that and you you you you manage you deploy the controls and then figure out how the the resources are configured as compared to the best practice are Define the second line is where you want to see a view of all the risk in your platform right you want to have a centralized dashboard like how is my overall landscape my unified Command Center sometimes as I call it right so that is where the a services like security Hub and config can help us the third line of defense is where you call you have you provide Assurance of risk management you want to provide guidance or evidence to your Auditors that you're indeed compliant with the standards that you claim to be so that is why services such as AWS audit manager can help you provide evidence to your Auditors as well quick double click into the a AWS config service that can help you along the compliance Journey now AWS config helps you record evaluate all the resources that are deployed in your AWS infrastructure and also provides you a visual interface to see changes to these resources over time a config rule is something that you can utilize that defines best practices that you can validate whether you're meeting them or not and a conformance pack is a collection of config rules that you can deploy across your entire organization and have them continuously validate the posture that you intended to be compliant with config aggregators help you ingest data from multiple regions and then get a overall sense of how the uh your visibility metrics are just one double click further on this the Hippa compliance bag to help you get started on your Hippa compliance Journey or get a head start up here AWS provides an out of the box Hippa config conformance pack now what it does is a set of rules that that are deployed in the account that continuously scan the environment as with regards to the controls from Hippa and it gives you like these resources are compliant these are not and it also gives you reasons why not right so you should deploy this as part of your overall assessment strategy as well for the iso 270001 compliance standard you should utilize the service offered by AWS audit manager so this has native integration that can help you create assessment generate evidence and generate the reports that you can share with your ENT Auditors it evaluates config rules in the background and that is evidence you can present to your customer your Auditors as well you've heard all SAS good aspects all the services now you might just be wondering okay how do I set up my founding environment get going and that is where I would refer you to The Landing zor accelerator or LGA as we call it the AWS Landing Zone accelerator is a comprehensive solution that can help you set up a multiac account environment with that is compliant with global compliance standards across the globe it is it is built on top of the AWS control tower and it has features like it is built using the AWS cdk so you have infrastructure as code right of the bad then you can have deployment of 35 Plus services multiple compliance standards can be deployed using simplified configuration files all you have to do is configure those files and start your journey up there and it is meant to be deployed ready to deploy in your own account so you can get started right and the landing zone for healthcare is a is an industry specific implementation of the lza that can Fast Track the implementation of HIPPA and ISO 270001 right and the ENT Landing zone is available on GitHub for you take a look at it subscribe to the project and as in when new releases are deployed I I would ask you to deploy it in your environment as well so so far in this journey you've heard all the technology aspects however technology is just one part of being successful and SAS successfully adopting SAS requires you to adopt your organization's operating model and operating culture to utilize the full benefit of sess to walk you through how waren went through this transformation I'll invite on stage n Kumar to give you a ringside view of the of the journey over to you Nish thank you Austy and good afternoon everyone really excited to be here to share warin Cloud Journey um and how we build this uh SAS platform at veren from scratch uh using lot of the building blocks that austi talked about but I will I will leave that for Pine to talk about the tech part now what I want to talk about is more around giving you a business perspective of what it took for us and why we go went this route of you know building out a SAS uh you know um SAS platform and to do that I would like to give you a little bit of an overview of veren and what a what better way than to talk about our purpose our purpose is very very simple yet very strong and very powerful and I will pick three key pieces of you know from that purpose what we are and what we know aim to be is defined by those three pieces one is we are in the specialized Diagnostics area second is global reach and most importantly Innovation so warin as a company works in the works in this five you know specialized Diagnostics uh you know uh domain hemostasis transfusion acute care autoimmunity and and and Transplant and this is where we add value to our customers uh day in and day out Global reach we are a global company we are based out of Barcelona in Spain but we have Tech and business centers all across the globe strategically located and our presence is in 30 plus countries uh taking our innovative solutions to diverse set of population they also provide us a lot of feedback which we use to innovate and and improve Healthcare and then most importantly Innovation we have a rich history of innovation and I will take just one business line and one analyzer and show a a a a timeline with 60 years of innovation and I will not drain the slide there are seven or eight firsts on this slide you know whether it be in of Co oxymetry whether it be the first analyzer to you know incorporate multi-use cartridge or the first analyzer that has gone into the market this year that can detect himalay samples at point of care these things are groundbreaking it saves patient lives where minutes matter however as we look ahead with this Rich Legacy of innovation what's next and we found the opportunity that digital transformation will be that next I would say Innovative leap that will power this company and this provides opportunity for worin this digital formation digital transformation and formation of this digital team provides like three for opportunity one improve clinical outcome that's why we exist I mean if you cannot do that we should cease to exist extend the value of existing medical devices now with smart connectivity and analytics we can gain more Action level intelligence from data and pro and extend the you know value of medical devices and lastly create new revenue streams as we work on products which provide clinical decision support and lab decision support these can be new revenue streams for veren now I think most of us know of a company that started 30 years ago selling books online so we also want to become a key player in digital transformation of healthc care and we think we can do that in a very very you know uh fast time to Market and Ma in a matter that aderes to our principles and our vision and our mission so with that we formed the digital Factory and with a very very well defined uh Mission what is digital Factory consider this as a manufacturing floor for software products so we are based out of veren floor below us are where analyzers and medical devices are actually manufactured and on floor on our floor we manufacture software products that's digital Factory for us and our start and I want to take you through this because this is not an easy journey and a lot of you raised your hand when you know when the question was asked as are you starting or you want to build this and it's not easy this was my day one I was the first external hire into this team and I took this picture literally and figuratively it was an empty canvas we started from this and our task was cut out in our journey it's not about technology only right you have to put your best practices in place new ways of working hiring a team we made a conscious decision to hire a collocated team that was not easy in 2022 trust me uh so those were the things that we started with we started ideating we started talking with our business partners to see what kind of ideas are flowing into that can turn into products that can be monetized in future so this is where and in parallel as we buil together a small team we started tinkering we started playing around with all the tools all the you know building blocks that Austy talked about and say okay what works for us what doesn't without pouring in a lot of investment up front and as part of this tinkering you know experimentation learning failing pivoting we came up with a straw man actually it was two of us Prine and I like hey this is how we think this this this you know this thing will evolve over next few years and it doesn't have to be perfect trust me come up with something something simple something scalable and work off that you know if if you if you try to aim for Perfection right in the first goal uh it's it's a futile exercise trust me uh and then from there this is where we are today the same empty space has become a hub of innovation collaboration where Builders are are very actively you know working together ideating uh giving life to some of the ideas that uh that our business partners brought to us so it's it's it's a pictorial visual representation of a journey which is non Tech related but I I I I feel that is very powerful to show you know when you start from a blank slate know there's a lot of things Beyond technology that that you need to work on Tech is easy for Mo all of you I guess you know uh it's it's the other pieces that hold us back and when we did this we also came up with some business goals as to why are we trying to do this things like faster time to Market we wanted to get products out there faster cost efficiency and scalability we had a finops mindset as I said before we don't didn't want to pour in a significant amount of money and investment and resources before seeing the benefits of it increase Innovation and flexibility that's almost like a hygiene factor for us to survive you know with disruptions happening all around us this is very important alignment between business and software teams without that any such Journey will not succeed you have to get your business partner sit next to you literally and kind of day in and day out work closely with you providing you feedback you know providing your suggestions as this whole thing evolves continuous Improvement and Agility again I consider this an hygiene Factor as you mature over time you should always aim for continuous Improvement agility should be built into the process because there will be times where you will have to PIV pivot business needs might change business requirements might change you might hit a failure or or or or or a impediment you know throughout your technical Journey you should be agile and you should be able to Pivot quickly and take failures in your stride because trust me you will fail a few times you know in this journey and then finally Talent it's very important you know we have to make sure that you build a culture where you can retain and attract attract and retain Talent uh and and take this journey forward so from there I would like to Pivot to what I talked about as a strawman so we came up with this business architecture vision and I will take you top down you know or outside in you know with whatever is the terminology where our business partners let's say I talked about five business units they came up with five product ideas we went through a pressure testing phase evaluated them said wow these are great ideas these are all monetizable these serve are help Sol solve a customer paino and has some very well- defined business needs we have five SAS products at our hand that we might have to build how do you go about that right so first what what we did first was started looking at common business services and trying to ex extract that out or you know and Abstract that out from from these you know these uh these products so you start looking at hey does this do these products need to talk to our lab information system yes then why do we want to do it five different ways let's extract it out as a service is there patient management involved is that order manage management you know is something that we can extract out is quality control something that we can abstract out from these products so again this is not this is illustrative list it's not an exhaustive list but these were the kind of questions we started asking upfront and see what are the things that we can extract out and and then kind of build it on and reuse it across all those five five products we also realize there are a set of Technical Services that needs to be abstracted out augusty talked about control plane this are literally our control plane where we looked at hey we want to do tenant management all those five applications will have to do tenant management identity management data management observability which Austy you know touched upon these are the things you know application management how do you do licensing billing management why do I need to have these five different products do it in their own way why can't I abstract those out and this was the Genesis of verf and Cloud platform all of these Technical Services that will build it once and then it can be reused by all of these uh products that we are uh that we are building analytics you know uh we are on the journey on doing that so so this formed our almost like a control plane or or the verin the cloud platform on which all of these goto market products can uh can recide and finally the infrastructure piece now augusty again talked about Landing Zone and and and and control tower and so on so we heavily leveraged the building blocks you know you call them Lego pieces from AWS uh you know Arsenal or toolbox of of services to build out this infrastructure uh infrastructure piece which was scalable you know secure reliable resilient and all those all those good you know non-functional stuff right so that is how we took a top- down approach starting with what are we building what are the customer pain points that we are trying to solve for and then go down to the tech level and see okay what do we need to solve those pain points make sense so so so so from now so once once I've done this now I will hand it over to Prine to take us bottoms up and say okay from a tech perspective how did we you know leverage some of these building blocks and from when when it came to infrastructure a platform and and build this out and what were our key learnings and and and what we we can share it with you in terms of you know where we failed where we succeeded and what you all should be looking out for as you go on this journey so here you go pro okay all right of the bad I'm going to ask you guys me count how many times I'm going to use data privacy and security CU I want to prove my critics wrong and now when you are dealing with Healthcare Absolute Data privacy and security are absolutely non-negotiable anyways I'm Pro adimulam and I'm an architect with wend cloud and I'm excited to be here to take you through the technical part of this journey all when we began this journey we started as a small tight team you saw the pictures from n with a clear Focus we want to deliver value to our customers quickly and efficiently and to achieve this we established five key design principles first we adopted modular architecture which allowed us to build and update software components independently next we embraced multi-tenant model to ensure we support multiple customers on a Shar infrastructure while keeping their data secure and isolated we leverage AWS manage services which helped us reduce the operational burden on our teams and with cost efficiency we designed our architecture to scale dynamically with demand and finally our iterative approach we wanted to respond quickly to our customer feedback and adapt to the changing requirements so we could build our software in small increments and deliver this is a quite busy slide but it represents a critical component of our solution I'm not going to go through every service or data flow in this uh diagram but would like to mention that this is like I said it's a very critical component and I would like you to take away couple of key points which I'll talk through in this slide and also there is a a reason why we choose this architecture First Security and compliance when dealing with sensitive Phi data data privacy and security I'm being conscious now right data privacy and security are critical and we want to make sure that our architecture ensures both this data privacy and security the another reason was around scalability and flexibility of our architecture our medical devices generate large volumes of data and we want to make sure our architecture scales seamlessly as the data grows and diversifies now talking about the architecture what you see on the left side is a typical customer for us it could be a hospital a clinic or a lab that could be running their workloads in their on-prem data centers I mean there are few customers who run in AWS private Cloud for most often we saw these medical devices running behind a firewall with no direct internet connectivity it might sound familiar to you guys and one of the initial challenges we had was how do we connect these devices to the cloud so we leverage AWS iot Green Grass and set it up as our Gateway which helped us connect this device to the cloud without direct internet exposure that was super critical and then it's it's where in the green grass you could also de identify the data if needed and then once the data moves to the cloud it traverses through multiple different services and that those are the services that we use based on the data type the data processing requirements and the data storage for instance we use iot core which seamlessly connects to iot Greengrass to manage Telemetry data as well as also device management I this architecture was purpose built to balance scalability security and performance while meeting the demands of both our devices and customers as Austy explained earlier when designing a SAS platform careful consideration needs to be made for control plane and application plane what you're seeing on the screen here is a representation of control plane this is our veran Cloud application architecture on the top what you see is a typical single page application architecture and our veran Cloud application which we call it portal or platform is securely accessed by our veran Affiliates or employees to manage tenants those tenants are managed using shared services which is the critical aspect of this architecture which augusty talked earlier right the Shar Services power the whole art architecture by services like tenant management tenant registration infrastructure management and then user management these are very critical Services which we centralized for our platform so all our applications could use them without re like without like I mean trying to rebuild all this architecture so we try to make sure these are centralized and make sure all the applications are able to utilize this supporting these shared services are layers with logging metrics authentication which are vital for any SAS application and moving on to the application Services what you see here is as a small sample of our applications there are some applications which are built using spring boot running in containers or net in containers on then there are some Services which are built serverless using AWS Lambda server serverless architecture our platform was built to ensure that we could support heterogeneous application technology Stacks what you don't see here on this screen is the underlying Cloud infrastructure which is built using lza the landing Zone accelerator for healthcare which I'll touch in the next slide when we started to think about compliance we it was very clear that this was about not ticking a box compliance was about building trust by building a platform which our healthc Care Professionals and patients could trust and when dealing with Phi data data privacy and security are absolutely non-negotiable which is why we choose lza as the foundation for our Cloud platform one of the reasons was LZ provides as built-in Healthcare specific comp uh configurations and compliance controls which align well with HIPPA framework and compliance is not one-time activity it's an ongoing commitment LZ also incorporates AWS best practices for data privacy and security which was also critical for us and where we utilized it for our foundation or laying the foundation for our platform another reason we choose lza was it support of multiple compliance like Frameworks like ISO 27,000 one gdpr as we plan to grow and expand into multiple geographies meeting these diverse regulat requirements are critical and then finally there is a ready to use solution aspect lza accelerated our journey by bringing together more than 35 AWS services in a no code preconfigured solution all right so that was all about the how we build out and what we used now with like Lessons Learned as with any Journey building a SAS platform has its share of challenges and lessons learn I would like to share a few of those first we quickly realize the importance of investing in training not just for our technical teams but also for our business stakeholders and this investment helped us Bridge the knowledge Gap and help us work towards a common Vision to accelerate our SAS buildout we leveraged AWS Proco and engaged with AWS SAS Factory both provided invaluable guidance by providing their expertise and knowledge which helped us overcome the common pitfalls in our journey and helped us focus on our like execution of the platform one of the bigger challenges we faced was adapting our quality assurance and change management for a SAS buildout our existing Pol policies did not fit well with the dynamic and iterative nature of SAS platforms so we had to redefine those policies and ensure that it supports the dynamic nature of that SAS platform another challenge we faced was around monetization separating out the hardware cost from software was harder than we anticipated by working with our business partners we established a goto Market strategy which aligns with SAS first principles then to meet compliance and regulations we had to establish software as medical device regulatory strategy as well and moving on to the technical side using infrastructure as code transformed how we manage our environments by H having a successful and consistent buildout as I mentioned earlier using AWS iot green grass we were able to set it up as an edge Gateway and connect to AWS cloud and that helped us uh connect our medical devices from an on Prem to the cloud while navigating the nuances of hybrid Cloud Solutions also like adjustments you for like manage delivering serverless architecture was also a major adjustment on our teams and then using AWS manage services which reduce further complexities so that our teams could focus on delivering features rather than managing infrastructure and finally by having a finops mindset we managed our cost efficiently all as we look forward to our future our journey is far from over we want to build on the foundation that has been laid so far and the Lessons Learned first we want to expand to multiple geographies our vision is to have our platform accessible globally but with this expansion comes new challenges understanding Regional needs tailoring our Solutions and ensuring scalability across d diverse markets compliance will be the Cornerstone and as we plan to expand into multiple geographies meeting additional compliance requirements like ISO 270001 or gdpr will be critical for us to expand data residency requirements are another Focus many countries now mandate that the data received within the boundaries especially in healthcare and we are exploring solutions for deploying into multiple AWS regions as well as also making sure these Solutions can keep maintaining our integrity and security of the platform and finally analytics will take the Center Stage the data collected on this platform isn't just numbers it's an opportunity for us to drive operational efficiencies deliver meaningful insights and better the patient care right so as we move forward we are excited to collaborate learn and deliver solutions that truly make a difference thank you thank you relation Prine for sharing your journey I'm sure this will inspire many of you in the room and all those watching this broadcast later as well during this entire session I talked about different resources so here they are as promised I've linked white papers to SAS fundamentals the skill Builder courses to build up Business and Technology foundations The Landing Zone accelerator the reference architectures and also the SAS Builder toolkit also link the compliance page and the AWS artifact Service as well I would highly encourage you to take a look at these resources as you get started on your journey so to bring to bring it home to summarize key takeaways for you remember that SAS is both a culture and Technology shift it is essential for you to orient your trans your operating model of your organization along with the technology shift to be truly successful in SAS feel free to engage with the AWS SAS Factory that can provide you both Business and Technology guidance as you get started we have reference architectures business Architects Etc who can literally work hand inand as an extension of your team to deliver on your business goals build compliance right from the outset shift left as we call it utilize compliant AWS region Hippa eligible services AWS security and partner tools to get started on a security Journey utilize the fully managed AWS services so that you can focus on delivering Innovation for your end customers without focusing on the undifferentiated heavy lifting of managing services and finally to get started on a de on a secure foundational environment I would say definitely deploy the AWS Landing Zone accelerator so that you get started with this robust multiac account compliant framework as well and and finally to use the term that our CTO of amazon.com Dr wagal says now go build right once again NES pren and I would sincerely like to thank you for attending our session today please take a couple of minutes to provide feedback on this session from the mo on the mobile app I look wish you good luck on the rest of reent and safe travels back home thank you

2024-12-23 01:47

Other news