Akana, All Rights Reserved Contact Us Privacy Policy. SOA and API Convergence What It Means for IBM Customers

Transcription

1 Akana, All Rights Reserved Contact Us Privacy Policy SOA and API Convergence What It Means for IBM Customers

2 Executive Summary IBM customers are expressing a greater and greater interest in APIs and API management. The execution of an API program naturally raises questions about its proper relationship with SOA governance initiatives. Industry analysts and early adopters correctly observe that SOA and API management technologies will follow a path of convergence into the future. SOA governance and API management each have attributes that lead to important differences and important similarities between them. Misunderstanding or ignoring these attributes will lead to a confused and conflicted enterprise where service consumption does not evolve alongside service production, resulting in the opposite of the benefits that SOA and API intend to offer. Implementation of different models of convergence leads to long term success or failure depending on each convergence model s ability to capitalize on the strengths of both SOA and API management technology. The ideal convergence model starts with the intersection of a robust SOA governance solution and a robust API management solution, leveraging the strengths of each. Over time coevolution of the two technologies leads to a single unified solution that perfectly balances service production and service consumption. Contents Executive Summary... 2 Introduction... 3 Comparing SOA and API... 3 Preparing for SOA and API Convergence... 5 SOA and API Convergence in IBM Environments... 9 Conclusion Akana and IBM WebSphere DataPower offer a unified solution for SOA and API management that follows the correct model of convergence on the IBM platform. Akana provides key features such as lifecycle management, runtime management, community management, and DataPower automation for both internal SOA services and external APIs across the enterprise. IBM WebSphere DataPower offers a first class SOA and API gateway to host services managed and modelled by Akana. DataPower s rich SOA and API features and deep integration with the full IBM platform, together with Akana, makes convergence on the IBM platform strategic, cost effective, and unified. 2

3 Introduction IBM customers are expressing a greater and greater interest in APIs and API management. Some are looking to APIs to help drive their mobile app initiatives. Others are drawn to the ability of APIs to open up new marketing and digital channels. Still others desire the ubiquity and ease that API technology promises. Industry analysts like Gartner and Forrester have begun to call attention to not only the need for APIs and API management, but also to define the relationship between APIs and service oriented architecture (SOA). For example, in Gartner s Application Services Governance (2013), the authors are convinced that SOA and API management will one day unify: Gartner recently introduced the term application services governance to refer to the union of SOA governance technology functionality and API management, thus preserving the terminology differences between the two, with the view that these aspects will eventually be unified. And Forrester s API Management Platforms (2013) paper highlights the concerns of enterprise architects who do not want to lose the value of their SOA investments: [There is] pressure from enterprise architecture and S&R pros to make sure these [API] efforts don t create undue risk and that they capitalize on the existing SOA investments. Enterprise architects and development managers alike ask us, Isn t this just SOA all over again? and Can t we just apply existing SOA governance tools in a public fashion? This whitepaper details the relationship between SOA and API programs, arguing that a successful API program must intersect with a strong foundation of SOA governance fundamentals. It then discusses both API and SOA management in the context of IBM-based IT solutions, showing an approach to unified SOA and API programs for IBM customers using Akana s SOA and API management solutions and the IBM WebSphere DataPower line of gateways. Comparing SOA and API Before we can understand the relationship between SOA and API management, we need to first compare the two technologies. The table below compares some of the key attributes of each technology: SOA Key Attributes Focus on internal and business partner use Pays strict attention to data schemas and interfaces Pays strict attention to process and procedure Mainly hosted and consumed internally, behind the firewall Tends to use technology like SOAP, WS-Security, and SAML Key goals include application integration, IT sharing, and cost savings Figure 1 Key SOA and API Attributes Key SOA and API Attributes API Key Attributes Typically external but now being used for internal and B2B use Structure and definition still in infancy. Waiting to see what role standards like Swagger and WADL will play Early adopters and developers try to steer away from process and procedure Hosted and consumed in the cloud or internally Tends to use technology like REST, HTTP basic auth, OAuth, and JSON Key goals include new market channels, mobile enablement, and competitive differentiation APIs have quickly gained prominence as they are more open and well documented. They are often self-provisioned, with little or no guidance, making them better suited for external and digital channels. APIs are better suited for business with their focus on marketing and branding. SOA technology largely focuses on refactoring IT infrastructure in the interest of internal IT agility and cost savings. While it is often associated with SOAP and XML, SOA, or service oriented architecture defines at its core architectural best practices for building de-coupled applications and fostering service reuse. It has matured over a period of time with 3

4 concepts such as well-defined data schemas and interfaces and service lifecycle governance. Over a period of time enterprises have realized that in order to achieve overall agility and efficiency, it is important to adopt a holistic unified governance model. API programs pay less attention to well defined data schemas, interfaces, and processes and procedures. But should they? The need for strict data schemas, a mainstay of SOA governance, helps developers and architects alike communicate the structure of an enterprise s data so that they can easily design and build applications that consume that critical data. There is nothing inherent in APIs that removes the necessity of communicating the structure of enterprise data. Indeed API and app developers have as much to gain from formalizing the data they work with as enterprise SOA architects. Therefore some of the attributes special to SOA governance are really special to API management as well. We can clearly observe this trend with APIs as the technology matures with initiatives like WADL, Swagger, and Blueprint. Although these technologies are new, they strive to provide standardized definitions for APIs, similar to the goals of SOA governance. But lightweight technology can help SOA infrastructures as well. The technology utilized by SOA infrastructures today stems from a combination of enterprise technical requirements and historical precedent. To the extent that SOA infrastructures can benefit from the new technology available in API infrastructures, such as REST and JSON, those infrastructures will adopt that new technology and change. But SOA infrastructures can only adopt API features if they are readily available. With lightweight technology, internal SOA developers and architects can realize important reductions in development costs, time to market, and maintenance effort. SOA technology brings critical features to API technology and API technology brings critical features to SOA infrastructures. This insight forms the basis for the convergence of these two technologies. The following diagram shows some of the key ways that each technology will contribute to this convergence. SOA and API Convergence We also need to consider the immaturity of today s API programs as a clue in the gap between SOA and API management. It was not evident in 1995 that websites would need application servers, caching networks, content management systems, and other critical infrastructure to realize their true potential. As APIs continue to grow out of novelty and into mainstream business, they too will not reach their full potential unless practitioners look to the firm foundations of SOA technology for guidance. Poorly considered engineering practices or missing backend application integration technology will ultimately result in the failure of API programs as their size, scale, and business criticality increase over time. Moving from SOA to API technology, we see that APIs use lighter weight technology. This is a result of their need to support less sophisticated consumers like mobile phones and tablets as compared with sophisticated application servers, web servers, and internal packaged applications that regularly consume SOA services. SOA Contribution Formal data and interface modelling and management Robust operational model, including service deployment, testing, issue resolution, and environment monitoring Stronger focus on the production side of services Formal service lifecycle management Cost savings and agility Application integration Figure 2 SOA and API Convergence API Contribution Focus on business metrics and value Stronger focus on the consumption side of services Simplified technology, especially for consumers Large scale, ubiquitous consumption Cloud and SaaS delivery models Building and nurturing large scale developer communities 4

5 The contributions by both SOA technology and API technology to this convergence are substantial. IT organizations that can capitalize on this convergence will stand to gain the most. The first gain is cost savings, because the strengths of each initiative can be utilized by the other without need for duplication of software, hardware, operations staff, and without the need for costly and time consuming solution redesign and integration. The second gain is the realization of the new capabilities that convergence brings. Delivering a SOA program in a more business-centric manner with greater measurement and metrics as well as more focus on business value represents a large gain for the enterprise. Likewise, adding much needed process and formality to APIs helps to steer API programs away from the rocky shoals of chaotic, unplanned growth. The third gain will be unification of the enterprise. An SOA infrastructure sitting next to and independent of one or more API programs will result in confusion, useless infighting and competition, and internal friction that will serve to slow the business down and cancel any strategic gains each technology intended to deliver. This unintended effect may not be evident in today s dawn of APIs. But as APIs grow in size and stature, it is inevitable that, because both APIs and SOA share so many of the same strategic goals, not planning for their convergence will end poorly for all stakeholders involved. The following diagram shows just how similar SOA and APIs are in their strategic goals. Similarity of Strategic Goals of API and SOA Programs Expose critical enterprise data to a wide variety of consumers Treat all enterprise data as reusable, well designed, easy to consume interfaces Bring consistency and reliability to all IT interfaces Increase visibility and accessibility of all IT assets The fourth gain will be the ability to future proof SOA and API infrastructures. As new technologies and standards develop, they have the potential to displace existing technologies like REST. Today we observe promise in protocols such as MQTT and WebSockets, which could very well replace RESTful APIs for Internet of Things, mobile, and real time applications. Organizations should invest in a services infrastructure that can easily adapt to these types of technological changes. Now that we know that SOA and API convergence is the natural and most beneficial course for the two technologies, we turn our attention in the next section to what convergence really means and what strategies enterprises must adopt to ensure that they gain and not lose from this dynamic. Preparing for SOA and API Convergence Initially, it seemed that SOA and API management are two different concerns with two different trajectories. But in the last section we saw how SOA governance benefits from API management and API management benefits from SOA governance. We also saw how the two technologies shared many common strategic goals, and the fatal drawbacks of developing one to the exclusion of the other. To prepare for the convergence of SOA and API, we need to first understand the nature of convergence. There are three different ways to think about how SOA and API management converge over time. Service production versus service consumption is a useful lens through which to view convergence, and it is the lens we will use to understand different convergence models. SOA governance traditionally focuses on service production, ensuring the enterprise can model and produce services that expose complex data and applications living in disparate places throughout the data center. API management focuses on service consumption, ensuring enterprises can first market and then grant access to their complex data and applications to consumers such as mobile devices and websites. Therefore, any convergence model needs to answer the question of how production and consumption will evolve over time. Figure 3 Similarity of Strategic Goals of API and SOA programs 5

6 The diagram below shows the first model convergence model A. Model A Ad Hoc Integration Ad Hoc Integration Ad Hoc Integration Convergence model B, below, begins with the current state of an enterprise s SOA program, which is more focused on production. Over time, as interest grows in exposing APIs, and without a proper service production foundation in the API management solution, service production capabilities shrink while service consumption capabilities grow. The model ends with an enterprise dominated by service consumption capabilities coupled with a fatal loss of internal governance controls. Convergence model B presumes that API management is an evolution of and improvement over SOA governance. Over time, organizations that started with SOA (or never invested in SOA) will start to phase it out as they invest in the new promises of API management. TIME Today s API Focus Figure 4 - SOA and API Convergence Model A Today s SOA Focus Model B In convergence model A, a set of external integrations between independent SOA and API infrastructures creates some level of sharing across their feature sets. For example, an SOA infrastructure could export certain data schemas and service interfaces to be imported into an API infrastructure. Or an API infrastructure could expose its OAuth security server to an SOA infrastructure in cases where SOA services need to work with OAuth security. Convergence model A suffers from an ad hoc approach to convergence and does not lead to a unified enterprise. Service production remains largely independent of service consumption over time. Different stakeholders struggle to adopt what they think are best practices in their individual realms, pulling different bits of functionality from different solutions and infrastructures. A desire to promote service consumption externally is not balanced with the needs of internal production. Functionality is based on expensive, point-to-point integrations which quickly lead to an inferior solution that the enterprise cannot run and maintain. Convergence model A is essentially the result of strategically planning for no convergence. TIME Today s API Focus Figure 5 - SOA and API Convergence Model B Today s SOA Focus Convergence model B misses the critical point, raised in the prior section, regarding the differences between SOA and API management. Although SOA and API management share important strategic goals, they still each bring unique perspectives to the enterprise, including asymmetric strengths in service production and service consumption. Just as there are merits to both SQL and NoSQL databases in the enterprise, there are also merits to both SOA governance and API management technology. Indeed recent progress with NewSQL databases like Google Spanner further prove this model of convergence, where the strongest features 6

7 of the constituent SQL technologies converge on a future solution that combines their respective strengths. Furthermore, designing and running an API infrastructure will never include the full feature set required by an SOA infrastructure. For example, some production-centric security technologies such as WS- Security or SAML would never make sense in an API solution that only considers the needs of API consumers, such as mobile apps. Convergence model C, the preferred convergence model shown below, starts with a strong existing base of service production capabilities. Service consumption capabilities grow out of and intersect this service production base. Model C Unified and Concerns raised in earlier sections like service lifecycle management, definition of data schemas and interfaces, and integration with backend systems are conceptually equivalent between SOA and API technologies. These are not technology concerns, but cross-discipline capability concerns. Attempting to solve these complex concerns in two or more competing solutions is expensive and counterproductive. Instead, in areas where API programs need specialized functionality, such as marketing driven metrics, chargeback bookkeeping, and developer portals, a unified solution realizes that functionality with new features that are still intrinsic to a unified SOA and API management solution. The execution of convergence model C yields the most benefit and reward for the enterprise. Convergence model C creates conditions for the long term success of both service production and service consumption by: Unifying the practice of SOA and API management under a single solution Solving the complexity of backend enterprise application integration with a single solution specifically designed for this challenge Removing the need for risky and costly integrations between disparate SOA and API platforms TIME Today s API Focus Today s SOA Focus Removing confusion in roles and responsibilities across the enterprise Figure 6 - SOA and API Convergence Model C Then, over time, production capabilities coevolve with consumption capabilities as each area grows. Features and functions across both areas are intrinsically available to all use cases, internal and external, without need for special integrations or forethought. The final step in this convergence is a fully-unified solution across all production and consumption concerns, where the needs of any given use case is not solved along technology lines, like SOA governance or API management, but solved via a unified solution where all production and consumption features are universally available. Removing expensive duplication of effort Leveraging the strengths of SOA governance for API management and the strengths of API management for SOA governance Ensuring that the enterprise can expose the same backend resources and enterprise data to diverse consumers using a consistent set of patterns, practices, tools, and processes 7

8 Preparation for convergence model C follows a well-defined path. If the enterprise already maintains an SOA program, convergence model C lets them continue to realize the benefits of that SOA program, reusing those benefits for APIs while bringing in new features specific to API management. If the enterprise does not maintain an SOA program today, convergence model C lets it start putting in place the proper solutions for both SOA and API management. As both of these disciplines grow, both the SOA and API infrastructure mutually grow. Convergence model C correctly recognizes that SOA governance and service production is the foundation for both SOA and API infrastructures. This creates an environment where the shared needs of both internal SOA services and external APIs grow in tandem. Regardless of whether the enterprise is starting from scratch with an SOA program or leveraging an SOA infrastructure with a rich history of investment, preparing for convergence means ensuring that both the SOA and API management solutions have the proper roles and directions. Starting with SOA governance, enterprises need to ensure that their SOA platform provides a strong foundation for both SOA and API management. The following best practices summarize the areas you need to start planning for within your SOA infrastructure: Area Lifecycle Management Planning for Convergence: SOA Platform Best Practices Ensure your SOA solution can support the full service lifecycle of both internal SOA services and external APIs. Into the future, all services should be seen as fully enabled, fully managed members of a consistent service lifecycle. This includes the planning, building, running, and sharing of all services both internal and API. Application Integration Operational Model Figure 7 Planning for Convergence: SOA Platform Ensure that your SOA solution provides a substrate for application integration. Both internal SOA services and external APIs have a deep and critical need to integrate with the full range of enterprise backend systems. This complex activity involves ensuring proven integration patterns with backend mainframes, WebSphere application servers, IBM Integration Buses, and WebSphere MQ everywhere that enterprise data lives. Some of the key goals include the establishment of shared security and other policies, monitoring and alerting, load balancing, SLAs, mediation, transformation, clustering, and micro-orchestration. The enterprise needs a single, consistent model and solution for running all aspects of all services both internal SOA services and external APIs. This includes topics such as service deployment, monitoring, high availability, failover and disaster recovery, service promotion, and testing. With the direction and roles in place for your SOA governance platform, it is time to turn your attention to maturing an API program that intersects with and builds on your SOA governance platform. Your SOA governance platform has already solved many of the most important foundational aspects of your API program, including service lifecycle management, application integration, and operational patterns. You will specialize many of these aspects for the unique needs of your API program, but your SOA governance platform is the foundation for this functionality. Beyond foundational aspects of your API program, you need to plan for the needs of your API platform that are special and beyond the needs of SOA governance. The following best practices highlight the key areas. Data Schemas and Interfaces Ensure that your SOA solution can catalog and manage all data schemas and service interfaces. This provides a single, consistent view into enterprise data, and what interfaces exist to expose that data. This lets you repurpose the same data for internal use, trading partner use, and mobile app use, using the same consistent patterns and practices. Ensure that your SOA solution provides a substrate for application 8

9 Area Developer Portal Planning for Convergence: API Platform Best Practices Ensure you have a robust platform for sharing APIs and the apps that consume those APIs. The developer portal should not only expose newly designed and developed APIs, but should be able to expose any or all existing SOA services as APIs easily and quickly. The developer portal needs to be robust and unified enough to support both internal SOA and external API needs. To the extent that API management offers powerful features in the exposure, marketing, consumption, and business value management that is useful for all services, you will want to leverage your developer portal both internally and externally. Now that we understand that convergence model C intersecting API management and SOA governance in a unified solution is the right convergence model to follow, we turn our attention in the next section to how we can implement this model on the IBM platform. SOA and API Convergence in IBM Environments The prior section discussed ways to prepare for the convergence of SOA and API technologies. Chief among these preparation steps is to ensure that you develop and mature an SOA governance foundation that can supply the needs of an SOA and API management program and over which your consumption-centric API features can intersect and grow. API Security API Specific Features API security requires heavy security mediation because of the common requirement for APIs to interoperate with two very different types of technology: the small scale consumer and the large scale backend provider. The large scale backend, such as WebSphere Application Server or WebSphere MQ, requires support for security standards such as LDAP, SAML, and Kerberos. The small scale consumer, such as an iphone app or REST driven web application, will require support, in the same transaction with the large scale backend provider, for security standards such as HTTP basic authentication and OAuth. Your API platform therefore needs to leverage the standard SOA support for interconnecting with large scale backend providers, while at the same time offering support for mediating with small scale consumers. Your APIs will require features beyond what you offer today for internal SOA services. This includes features such as metering and payments, cost-benefit analysis, branding, and rate limiting. You will need to ensure that your SOA and API management solution can intrinsically offer these features without the need for bolt-on solutions or ad hoc approaches. Moreover, to the extent that they are useful internally, you should be able to leverage these features for existing internal SOA services as well. This section discusses an approach to implementing the previously discussed convergence model C on the IBM platform that puts you in the maximum position to benefit from the convergence of these two important technologies. The approach uses Akana s comprehensive SOA and API management solution alongside IBM WebSphere s DataPower gateway appliance to create a unified SOA and API platform that solves every major challenge on the path to convergence. The fully integrated and unified nature of Akana s comprehensive SOA and API management solution together with the DataPower gateway appliance provides one of the most compelling reasons why this combination perfectly suits the needs of SOA and API convergence. Akana s solution provides a full SOA governance platform and a full API management platform in a single comprehensive package. Likewise, it is fully integrated with the DataPower appliance, which provides powerful application integration capabilities with the full IBM platform of middleware and backend technologies, while also providing a full feature set for supporting internal SOA consumers and external API consumers. This dedication to both SOA and API technologies in an out of box solution is one of the critical success factors for benefiting from SOA and API convergence. Figure 8 Planning for Convergence: API Platform 9

10 The diagram below shows how Akana and IBM work together to provide a platform that drives SOA and API convergence. Akana Policy Manager lets you model and run your SOA services and APIs using facilities such as policies, security contracts, monitoring, clustering, and service level agreements. Policy Manager understands how to model service integration with backend IBM systems using powerful mediation, micro-orchestration, and security features. This ensures that both internal SOA services and external APIs can use the same model to leverage the same DataPower strengths in integrating with and accessing your backend IBM systems. Akana s SOA and API management solution automatically deploys to the DataPower appliance the SOA services and APIs managed by Lifecycle Manager and modelled by Policy Manager. This gives ultimate flexibility in deciding to which DataPower appliance you deploy any of your SOA services and APIs. This also offers to you a standard operational, maintenance, hardware, and infrastructure model across all your SOA services and APIs, offering important benefits in terms of cost savings, standardization, quality, and agility. Figure 9 - SOA and API Convergence in IBM Environments Akana Community Manager introduces powerful service consumption features over all the earlier lifecycle and runtime capabilities discussed. Community Manager offers a developer portal and rich tools for exposing, sharing, marketing, and collaborating over your APIs. Community Manager fully integrates with the DataPower appliance, so the APIs running across all your DataPower appliances are fully available within the features offered by Community Manager. Because Community Manager is integrated with the full Akana SOA and API management solution, you can use it to expose and share existing internal SOA services running on DataPower as APIs for consumption by apps running on mobile devices. From an SOA governance standpoint Lifecycle Manager provides management of the full service lifecycle of both SOA services and APIs. Therefore the same set of tools, workflows, procedures, processes, and standards can be used to drive an internal SOA service one day, while then driving an API the next. Lifecycle Manager can accommodate differences in the needs of the SOA lifecycle and the API lifecycle to increase flexibility. 10

11 Switching to where your SOA services and APIs actually run, the IBM WebSphere DataPower appliance provides the powerful SOA and API gateway features needed to run all your services. DataPower provides the crucial component in the SOA and API management convergence in IBM environments because DataPower has the rich set of features needed to run both SOA services and APIs managed and modeled in Lifecycle Manager and Policy Manager DataPower has very strong application integration features on the IBM platform. This includes integration with systems like System z mainframe, WebSphere MQ, WebSphere Application Server, IBM Integration Bus, and Tivoli. These features are crucial for both internal SOA services and APIs By running both SOA services and APIs, even on the same appliance, DataPower makes possible a unified operational model where you can standardize across all your SOA services and APIs on hardware and infrastructure as well as deployment and operational processes, tools, and procedures DataPower can support the needs of internal SOA consumers, trading partners, and API consumer such as mobile devices. Its powerful set of features and mediation capabilities means that you can repurpose backend systems and enterprise data for a variety of consumer needs using the same appliance platform (and SOA and API management solution) Akana s SOA and API management solution partnered with the DataPower gateway appliance provide the full foundation for the convergence of SOA and API technology. The solution offers all the benefits of convergence in IBM environments within a fully-unified solution that covers the needs of both SOA and API. This ensures that you can leverage the best features of both SOA and API technologies within all your service production and service consumption needs, that you can enable deep integration with the IBM platform, and that you can offer a well-defined and consistent service lifecycle across all SOA services and APIs. As new business requirements arise, as new technology grows in popularity, and as SOA and API technology converges into the future, this unified solution grows alongside these changes without the need for architectural refactoring, expensive integrations, or bolt-on solutions. Every aspect of the total solution, from service lifecycle management to service security to external sharing, responds with the right set of features and functions needed to solve the full range of challenges. This solution can then support a model of SOA and API convergence that fully balances service production and service consumption in a unified whole that can grow and mature as the enterprise grows and matures. Conclusion SOA and API management is an important topic that deserves time and consideration and the development of strategies to ensure you realize the maximum benefits of their convergence over time. Without a proper strategy, the two technologies will mature and evolve independently of each other within your enterprise, leading to confusion, needless competition, duplication, rework, and high costs. SOA governance and API management technologies both have important contributions to make to the clean running of your IT infrastructure in the years ahead. By recognizing the unique differences between these technologies, as well as what they have in common, you can harness the power of both without needing to minimize one or the other. The IBM platform is a powerful and complex set of middleware and backend technologies that help to run major portions of your business. By utilizing IBM WebSphere DataPower as the runtime foundation of both your SOA services and APIs, you choose a gateway appliance that can effectively expose critical enterprise data running on these backend systems. By utilizing Akana s SOA and API management solution in partnership with DataPower, you can effectively manage and automate every aspect of your service production and service consumption needs. 11

12 About Akana Akana is a leading provider of API Security and Management products that help businesses plan, build, run and share APIs, through comprehensive cloud and on-premise solutions that encompass API lifecycle, security, management and developer engagement. The world s largest companies including Bank of America, Pfizer, and Verizon use Akana solutions to transform their business. For more information, please visit Akana, API Gateway, Community Manager, Lifecycle Manager, Policy Manager, Portfolio Manager, Repository Manager, Service Manager, and SOLA are trademarks of Akana, Inc. All other product and company names herein may be trademarks and/or registered trademarks of their registered owners. Trademarks Akana, Policy Manager, Portfolio Manager, Lifecycle Manager, Service Manager, and Community Manager are trademarks of Akana, Inc. All other product and company names herein may be trademarks and/or registered trademarks of their registered owners Akana, All Rights Reserved Contact Us Privacy Policy Akana Wilshire Blvd, Suite 1800 Los Angeles, CA (866) info@akana.com Disclaimer: The information provided in this document is provided AS IS WITHOUT ANY WARRANTIES OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF INTELLECTUAL PROPERTY. Akana may make changes to this document at any time without notice. All comparisons, functionalities and measures as related to similar products and services offered by other vendors are based on Akana s internal assessment and/or publicly available information of Akana and other vendor product features, unless otherwise specifically stated. Reliance by you on these assessments / comparative assessments are to be made solely on your own discretion and at your own risk. The content of this document may be out of date, and Akana makes no commitment to update this content. This document may refer to products, programs or services that are not available in your country. Consult your local Akana business contact for information regarding the products, programs and services that may be available to you. Applicable law may not allow the exclusion of implied warranties, so the above exclusion may not apply to you.