{"id":9770,"date":"2023-02-22T12:03:12","date_gmt":"2023-02-22T20:03:12","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=9770"},"modified":"2023-03-01T14:05:41","modified_gmt":"2023-03-01T22:05:41","slug":"designing-a-modern-service-architecture-for-the-cloud","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/designing-a-modern-service-architecture-for-the-cloud\/","title":{"rendered":"Designing a modern service architecture for the cloud"},"content":{"rendered":"
The digital transformation that many enterprises are undertaking has its benefits and its challenges: while it brings new opportunities that add value to customers and help drive business, it also places demands on legacy infrastructure, making companies struggle to keep pace with the digital world\u2019s ever-increasing speed of business. Consider an enterprise\u2019s line-of-business (LOB) systems, such as for finance in general, or procurement and payment in particular. These business-critical systems are traditionally based on-premises, can\u2019t scale readily, and in many cases aren\u2019t available to mobile devices.<\/p>\n
As we continue along our digital transformation journey here at Microsoft, we have been looking to the cloud to reinvent how we do business, by streamlining our operations and adding value to our partners and customers. This technical blog post describes how our Microsoft Digital team saw our move to the cloud as an opportunity to completely rethink how we architect and run our core finance processes when they\u2019re built on a modern architecture. Here, we discuss the thought processes and drivers behind the approach that we took to design a new service architecture for our Finance department\u2019s Procure-to-Pay service.<\/p>\n
Financial systems need to be secure by their nature. Moreover, their designs are typically influenced by an organizational culture that is understandably risk averse, so the concept of moving sensitive financial processes to the cloud can be especially challenging. The technical challenges are equally significant: Consider the transactional nature of financial systems, their real-time transactional data processing, auditing frequency and scale, and the numerous regulatory aspects that are associated with financial operations.<\/p>\n
At Microsoft, many of our core business processes (such as procurement and payment) have traditionally been built around numerous monolithic, standalone apps. Each of these apps was siloed in its own on-premises environment, used its own copy of data, and presented one or more interfaces, often disconnected from each other. Without a unifying, overarching strategy, each of these apps evolved independently on an ad hoc<\/em> basis, updating as circumstances required without considering impacts on other parts of the Procure-to-Pay process.<\/p>\n These complex and unwieldly apps required significant resources to maintain, and their redundant data led to inconsistent key performance indicators (KPIs) that were based on different underlying data sets. Furthermore, the user experience suffered because there wasn\u2019t a single end-to-end process for Procure-to-Pay. Instead, people had to work within several different apps\u2014each with its own interface\u2014to complete a task, forcing users to learn to navigate through many different user experiences as they attempted to complete each step. The overall process was made even more cumbersome because people still had to complete manual steps in between certain apps. This in turn slowed completion of every Procure-to-Pay instance and was expensive to maintain.<\/p>\n At Microsoft Digital, our ongoing efforts to shift services to the cloud gave our Microsoft Finance Engineering team an opportunity to completely rethink how to approach Procure-to-Pay by designing a cloud-based, services-oriented architecture for the Finance department\u2019s procurement and payment processes. This, modern cloud-based service, known as Procure-to-Pay, would focus on the end-to-end user experience and would replace the app-centric view of the legacy on-premises systems. Additionally, the cloud-based service would utilize Microsoft Azure\u2019s inherent efficiencies to reduce capital expenditure costs, scale dynamically, and promote referencing of certified master data instead of copying data sets as the legacy apps did.<\/p>\n In this part of the case study, we describe some key principles that we followed when designing our new service-based architecture, and then provide more insight into the architecture\u2019s data, API, and UI.<\/p>\n [Learn how DevOps is sending engineering practices up in smoke<\/a><\/em>. <\/em>Get more Microsoft Azure architecture guidance from us.<\/a><\/em>]<\/p>\n We started this initiative by defining the key principles that would guide our approach to this new architectural design. These principles included:<\/p>\n In the next few sections, we provide additional insights into how we applied these principles from UI, data, and API perspectives as we designed our new architectural model and used it to build our Procure-to-Pay service.<\/p>\n When we surveyed our legacy set of on-premises apps, we discovered a significant overlap of functionality between them. Our approach with the new architectural model was to break down the complete feature set within each app to separate core functionality from duplicated features.<\/p>\n We used this information to consolidate the 36 standalone legacy apps into an architecture that comprises 16 discrete services, each with a unique set of functionality, presentation layer, APIs, and master data. On top of these 16 unique services, we defined an overarching End-to-End User Experience layer that developers can use to create a singular, unified experience that can span numerous services.<\/p>\n As the graphic below illustrates, our modern architecture utilizes a modular approach to services that promotes interconnectivity. Because users interact with the services at the End-to-End User Experience layer, they experience a consistent and unified sequence of events in a single interface. Behind the scenes, developers can connect APIs in one service to another to access the functionality they require, or transparently pass the user from one service\u2019s UI to another as needed to complete the Procure-to-Pay process.<\/p>\n Another critical aspect of providing an end-to-end experience is automating the front- and back-office operations (such as support) as much as possible. To support this automation, our architecture incorporates a Procure-to-Pay Support layer underneath all the services. Developers can integrate support bots into their Procure-to-Pay services to monitor user activity and proactively offer guidance when deemed appropriate. Moreover, if the support bot can\u2019t quickly resolve the issue, it will silently escalate to a human supervisor who can interact with the user within the same support window. Our objective is to make the support experience so seamless that users don\u2019t recognize when they are interacting with a bot vs. a support engineer.<\/p>\n All these connections and data referencing are hidden from the user, resulting in a seamless experience that can be expressed as a portal, a mobile app, or even as a bot.<\/p>\n One ongoing challenge that we experienced with our siloed on-premises apps was how each app utilized its own copy of data, resulting in wasted storage space and inconsistent analytics due to the variances between data sets. In contrast, the new architectural data model had to align with our principle of maintaining single, master copies of data that any service could reference. This required forming a new Finance data lake to store all the data.<\/p>\n The decision to create a data lake required a completely new mindset. We decided to shift away from the traditional approach, in which we needed to understand the nature of each data element and how it would be implemented in a solution. Today, our strategy is to place all<\/em> data into a single repository where it can be available for any potential use\u2014even when the data has no current apparent utility. This approach recognizes the inherent value of data without having to map each data piece to an individual customer\u2019s requirements. Moreover, having a large pool of readily available, certified data was precisely what we needed to support our machine learning (ML) and AI-based discovery and experimentation\u2014processes that require large amounts of quality data that had been unavailable in the old siloed systems.<\/p>\n After we formed the Finance data lake, we defined a layer in our architecture to support different types of data access:<\/p>\n By offering these different types of access, our new architectural model streamlines how people can connect data sources from different places and for different use scenarios.<\/p>\n In the older on-premises apps, the tight coupling of UI and functionality forced users to go through each app\u2019s UI just to access the data. This type of design provided a very poor and disjointed user experience because people had to navigate many different tools with different interfaces to complete their Procure-to-Pay task.<\/p>\n One of the most significant changes that we made to business functionality in our new architectural model was to completely decouple business functionality from UI. As Figure 1 illustrates, our new architectural model has clearly defined layers that place all business functionality in a service\u2019s API layer. This core functionality is further broken down into very small services that perform specific and unique functions; we call these microservices. <\/em><\/p>\n With this approach, any microservice within one service can be called by other services as required. For example, a link-validation microservice can be used to verify employee, partner, or supplier banking details. We also recognized the importance of making these microservices easily discoverable, so we took an open-source approach and published details on Swagger about each microservice. Internal developers can search for internal APIs for reuse, and external developers can search for public APIs.<\/p>\n As an example, the below image illustrates the usage scenario for buying a laptop, where the requester works through the unified User Experience layer. What is hidden to the user is how multiple services including Catalog Management, Purchase Experience, and Purchase Order interact as needed to pass data and hand off the user transparently from service to service to complete the Procure-to-Pay task.<\/p>\n When defining our modern architecture, we wanted to minimize the risk that an update to microservice code might impact end-to-end service functionality. To achieve this, we defined service contracts that map to each API, and how the data interfaces with that API. In other words, all business functionality within the service must conform to the contract\u2019s terms. This allows developers to stub a service with representative behaviors and payloads that other teams can consume while the service code is being updated. Provided the updates are compliant with the contract, the changes to the code won\u2019t break the service.<\/p>\n Finally, our new cloud-based modern architecture gave us an opportunity to improve the user experience by specifying a single sign-on (SSO) event throughout the day, irrespective of how many services a user touches during that time. The key to supporting SSO was to leverage the authentication and authorization processes and protocols that are built into Microsoft Azure Active Directory.<\/p>\n Following are some of the key benefits that our Microsoft Digital team is experiencing by building our Procure-to-Pay service on our modern cloud-based architecture.<\/p>\n At Microsoft, rethinking our approach to services with this cloud-based modern architecture is helping us become a data-driven organization. By consolidating our data into a single data lake and providing an API layer that enables rapid development of end-to-end procurement and payment services, we\u2019ve created a self-serve platform where anyone can consume the certified data and present it in a seamless, end-to-end manner to the user, who can then derive insights and make data-driven decisions.<\/p>\n The Procure-to-Pay service is just one cloud-based service that we built on top of our modern architecture. We\u2019re continuing to mature this service, but we\u2019re also exploring additional end-to-end services that can benefit other Finance processes to the same extent that Procure-to-Pay has modernized procurement and payment.<\/p>\n This new model doesn\u2019t have to be restricted to Finance; our approach has the potential to benefit the entire company. The guiding principles we followed to define our Finance architecture align closely with our leadership\u2019s digital transformation vision. That is why we\u2019re also discussing how we might help other departments outside Finance adopt the same architectural model, build their own end-to-end user experiences, and reap similar rewards.<\/p>\n The digital transformation that many enterprises are undertaking has its benefits and its challenges: while it brings new opportunities that add value to customers and help drive business, it also places demands on legacy infrastructure, making companies struggle to keep pace with the digital world\u2019s ever-increasing speed of business. Consider an enterprise\u2019s line-of-business (LOB) systems, […]<\/p>\n","protected":false},"author":133,"featured_media":9817,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"_hide_featured_on_single":false,"_show_featured_caption_on_single":true,"footnotes":""},"categories":[1],"tags":[328,223,115],"coauthors":[646],"class_list":["post-9770","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-azure-and-cloud-infrastructure","tag-cloud-migration","tag-microsoft-azure","program-microsoft-digital-technical-stories","m-blog-post"],"yoast_head":"\nPrinciples of a service-based architecture<\/h3>\n
\n
Emphasizing a holistic, end-to-end user experience<\/h3>\n
Consolidating data to support end-to-end experiences<\/h3>\n
\n
Designing enterprise services in an API economy<\/h3>\n
Benefits<\/h2>\n
\n
\n
\n
\nWe on the Microsoft Digital team learned some valuable best practices as we designed our modern cloud-based architecture:<\/p>\n\n
Our next steps<\/h2>\n
<\/p>\n
\n