Accelerate Your API-First Strategy: Integrating Enterprise Apps and Data with APIs (Cloud Next ’18)

morning, everybody. Thanks for taking the time
to come to this session. I know it’s the last
day of the conference. Hopefully you guys had
an amazing conference. So today, we will talk about
how do customers really accelerate their API for
strategy and leverage enterprise and apps and the
data, which is logged in there. How do you really
unlock that value and bring it to your customers? So I am Prithpal Bhogill. I’m part of the Apigee Product
Team within Google Cloud. And then I’m also going to
be joined with my co-speaker, Pratik from Informatica. So let’s get started. Today, many, many
enterprises are at some point of time in the digital journey. And it’s really all about
taking the awesome amount of data that they have, which
sometimes is locked in silos, but unlock all of them
as APIs to deliver these connected experiences. That has pretty much
become the hallmark of any successful
digital company. As they’re beginning to
express more and more of that capability
through APIs, it becomes very important to take
an outside-in perspective. And that’s exactly what we mean
by the digital value chain. When we talk to
many customers, it’s pretty obvious they have a lot
of capabilities, some of them which are also enabled an APIs. But it’s not all about having
N number of APIs or services. It’s about how
carefully you curate those APIs to deliver the
right kind of experience to the end user. The app developer plays
a very important role in taking those experiences
and [INAUDIBLE] them up so that the end
user essentially has the experience of
what they need to see. That is what we call as
the outside-in perspective. And in our experience, we have
seen successful API programs really satisfy all the aspects
of the data value chain. Apigee happens to
power successfully be a program for
many, many customers, and we are really
thankful for having an opportunity to serve them. As you may see,
we have customers across all different verticals,
Fortune 100, 500, 1,000, SMBs. All kinds of shapes and sizes. And they have come to
rely on our capabilities to be able to run their
programs successfully. It turns out Apigee has just the
right API management platform. So let’s spend a
few minutes out here thinking about what’s
really required to power an API program. Of course, there’s the
secure and scalable runtime, which you need to
be able to power and manage your API traffic. But the important set of
vertical capabilities, which layer on top of that. So as an example,
the mediation engine gives you all the
bells and whistles, such as I need to secure
all my API traffic. Awesome, we have
a policy for that. You drop it in, and
suddenly all the API traffic is secured using OAuth. Again, you have some
traffic management policies, such as controlling
spikes in traffic or perhaps you want to
enforce business quotes. All those set of
capabilities are provided by the mediation engine. As you start to move
up in the layer, it becomes very
important for you, as a customer, to have
the end-to-end visibility across the entire API
program, whether that means operational metrics
or keeping track of how your API your program is
doing, so developer engagement metrics. Once we have APIs,
are developers even building some apps and
driving traffic against them? And last, but not the least–
this happens to be the most important part of the platform– how do you really engage
with application developers? OK, how many application
developers in the audience out here? Just a quick show of hands. OK, so what we have
seen is today– I’ll just do a very
simple analogy. If you have a mobile app that
you’re using on your phone, and it takes you more
than four seconds for you to navigate from one
screen to the other, chances are you’re going to
go and download another app from the app store, right? APIs are at that level today. If you do not make it
easy for your developers, for the application
developers, to consume the API without any friction
and if the APIs are not clean and simple
to understand, they are going to move to a
different API provider, OK? So it’s very important to
provide a rich catalog of APIs to the developer portal with
complete API documentation, so it is very, very easy
for them to adopt the API. So Apigee’s API management
platform offers exactly that. And artificial intelligence
and machine learning is actually built into
the core of the platform. Many of our customers
have actually used the API and
its capabilities for a period of time,
and they’ve really gotten some good success
out of it, especially in keeping track
of the API program. Although, a lot of
those metrics have been more around
trending parts of what really happened in the
last hour or last week. What we are announcing
today is the beta of the Apigee– the API
monitoring solution. And this really brings the
real-time contextual API monitoring for APIs
integrated into the platform. It helps you better
manage your API SLAs and give you the
ability to diagnose all your issues in a much
shorter period of time. More importantly, we
have seen many customers who expressed the need that in
order for me to diagnose what’s really happening
with my APIs, I have to correlate many things
across a few different tools, such as I want to be able to see
what’s happening with my logs. And I want to see what my
alerts are being fired. And I really want to be able to
correlate the entire sequence. Apigee’s monitoring actually
gives the ability to, just within a few
clicks, have that context at your fingertips. And we don’t want you to
take our word for this. One of our key
customers, Bazaarvoice, has been an early adopter of
the Apigee– the API monitoring solution. And they are using this to
be able to proactively detect and fix issues, even if it
happens to be on the target backends, so that they
can manage the customer’s SLAs better. We will be turning
on this feature for a lot of our customers
over the next 30 days. So really, really, really proud
to announce this capability. Now, let’s shift back to how do
you really accelerate your API first strategy. And what’s really in that? From our experience, we have
seen three high level things, which take the
most pain in terms of trying to become digital. The first one is obviously
how do I easily and securely connect to cloud services,
fast applications, and in many cases, on-premise
applications as well? The second piece that
becomes really important, once you’ve done that, how do
I easily take those assets, turn them into highly
curated APIs that can deliver the right experience? And more importantly, do
not forget the application developer. You want to ensure that the
application developer has the right set of tools,
modular capabilities, so they can reuse those assets
and turn out and churn out API much faster. So for that, let’s
kind of break down the anatomy of how do you
really access a cloud service. It turns out there are a
set of repeatable steps that has to be done
over and over again. So let’s try and just walk
through them very quickly. So let’s say I decide I need
to access some kind of a cloud service. But first, as an
API developer, I have to figure out where
do I store the credentials with that service. Could be a service
account, could be just a simple username, password. I need a secure
mechanism to persist it. Secondly, once they
have that, then I need to go talk to
a token endpoint, passing in those credentials,
so I can actually get a token to that service. Then I have the same issue that
I need to go manage the token, persist it, and also worry about
the exploration and refresh cycles. But once I’ve done
that, finally, I can go call my cloud service. And although that’s
a set of things which you have to do
to access a service, we feel it’s very error prone. If you have one
API developer who’s trying to do that to
access the service and suddenly they need
to scale to provide that to many different
services, it just becomes extremely repetitive. It’s time consuming. It’s not easy to have the API
developer wire those things over and over again. And more importantly,
the [INAUDIBLE] steps tend to build up over time and
causes a loss in productivity. The other thing
we constantly hear is administrators are not
very comfortable letting developers manage and
deal with credentials. OK, they want to have the
right separation of concerns. They want to be able to
have designated roles who can manage credentials, and
more importantly, have the API developers go off and do their
stuff, which is go access those APIs or services and
build some nice experiences. So let’s see how we
can get around this. How many Apigee Edge users
in the audience today? How many have actually touched
the Apigee Edge platform? OK, a few of them. So as you may have come to
know, Apigee is very powerful and comprehensive full lifecycle
API management platform. And it offers you
two big choices. You can use a
configuration-based option, which means you have 30
different out-of-the-box policy that you can use to secure,
to provide traffic management, do some mediation,
transformation, et cetera, right? And that’s great. And using some of
those policies, you can do those four steps
we just spoke about, right? Token, get your credentials,
finally access the service. Or you can use some of the
out-of-the-box coding policies that we have. And we support different
kinds of languages– Java, JavaScript, Node,
Python, et cetera. However, it still requires you
to do those four steps that you just reviewed manually. Today, we’re introducing the
new Apigee extensions capability as beta. And we’re delighted to
have this capability be available to our customers over
the course of the next 30 days. Now, what does extensions
really bring into the mix? It brings three
high level things. It brings a modular
and secure way of connecting to
your cloud services. And it gives
developers the ability to use simple policies, which
we’ll show you in a demo here very quickly, to call and
invoke those specific services. So as part of this
announcement, we are rolling out eight different GCP extensions;
extension of GCP services; a brand new extensions
management user interface, so org admins can actually go
and configure those extensions; and in true Apigee fashion,
an extension Management API, so you can use those APIs
to be able to communicate with the platform if you don’t
want to use our user interface. So here are the
eight new extensions that we are rolling out today. It’s available as beta. So I’m not going to
go through the list, but we’ll actually see a live
demo here very, very soon. In order for me to actually
show you something useful, let’s imagine a use case. We’re going to do
a live demo here. So in this case, how
many of– out here ever have to worry about
data loss from enterprise? Anyone? Come on. Some of you folks are being shy. All right, data
security is a big issue. In this quick example, I want
to show you how simple and easy it is for an Apigee
API developer now, using Apigee extensions, to be
able to interact with a data loss prevention API,
which is a service that Google Cloud
Platform provides, OK? So in this case, let’s
take a quick peek at how we would go about doing that. Going to switch onto
my demo mode here. OK, that works. Awesome. Hopefully the demo
gods are with us today, and the wifi works great. So one of the first things
we’re going to do out here is very quickly go and look at
the new extensions interface. So I’m logged into
an Apigee Edge org. And I can come to this
extensions page under Admin and add any extension. So you can see some
of the extensions that we were
talking about here– the Cloud Vision API, Data
Loss Prevention, Firestore, Stackdriver, Pub/Sub,
so on, and so forth. The idea is we are rolling
out this extension, and we’ll continue to
add more down the road, but these are much more built
towards API-centric use cases, OK? So once I come out
here, I can just select that
particular extension, give it a name and description. And once you do that,
you have the extension listed in your organization. So let me just, for the
purpose of this demo, use an existing
extension out here. The extension has– it can be
deployed across multiple Apigee Edge environments. So in this case, I have
deployed this thing for test. And really, the interface
mechanism is super simple. In this case, you take
the service account that you have from within the
Google Cloud Platform project, you supply the
service credential when you’re deploying
this specific extension, and once you save it,
it will automatically persist the credentials
securely and give you a checksum out here, right? So separation of concerns from a
governance perspective, the org or the extension admin
can come and do this, OK? And out here, you
will see logs as to when that’s specific
extension is communicating with a service in
the background. Great. Now, once I’ve done that, that’s
the one-time configuration that I have to do to
enable that extension. As an API developer my job
becomes extremely simple. So let’s take a look
at this DLP sample. In this simple API proxy,
remember, I still have to go– if I’m not getting
extensions, go and do those four different
steps we spoke about, right? But using extensions,
the credential management overhead is not my issue. So I go out here as
an API developer. I can add a step out here. Click a simple Extension
Callout policy, select any extension that I’ve
configured– in this case, DLP– and it will
automatically populate the right kind of action. So in this case, we have three
actions defined out here, which are obviously reflective
of what the Data Loss Prevention API exhibits,
which is deidentifyWithMask, WithType, or redact the image. So I just happen to use
the deidentifyWithMask. And you can see I’ve already
configured this out here. I’m sorry. deidentifyWithType,
specify the action out here, and that’s it. At this point in
time, let’s go take this thing for a quick test. So I’m using Postman out here. And I’ve made some
changes in my API proxy so that I will compare
the value of the header. And if it is unsafe, I will
not involve the Data Loss Prevention API. Again, you can write this
thing whichever you want to. So in this case, here
is the simple request, which is going in. Let’s hit Send. And when I do that,
you should see the data is just passing through
as is, not really ideal. So now, let’s go out
here really quickly and change this to Safe Mode. And when I do that and
now send it through, you can see that
the data has already been masked automatically by
the Data Loss Prevention API. Very simple example
of how you can use a new connector, the
new extension mechanism to be able to leverage
any kind of service in a very, very module way. OK, so let’s wrap this
one up real quick. So we just went through
the branding extensions capabilities. It’s beta today. It will be available
for customers as we start to roll them
out in the next 30 days. But we are going to be adding
a lot more capabilities. We’re going to be building
more extensions to existing GCP services and to other providers. And more importantly,
we will also be building and rolling
out the same extensions framework to our
customers, so you can build your own custom
or private extensions and use them within
the enterprise, finally evolving into a
marketplace of connectors where many of our
partners and customers can actually contribute
their own extensions, so they can be used within
the Apigee universe. So real quick, what are
some of the key benefits of getting the extensions? First class self-service
extensibility built right into the platform. You can connect to any service. And more importantly,
down the road, you can build and distribute
your own service extensions. OK, so great. We very quickly looked at
how you can accelerate, you know, accessing
different kind of services and turning them into quick
APIs using extensions. But what’s underneath
those APIs? In many cases, turns
out, enterprises have gobs and gobs
of data and a lot of business processes,
which really need to be powered as APIs. As we start to
talk about this, we have heard from many customers
that although the API management platform is really
awesome at curating those APIs into some awesome experiences
for the digital experience that they need to consume– however, we really need to be
able to take the data, which is sitting locked
in silos, leverage the integration processes which
are weaved on top of that, and really bring the entire
solution stack together, because the reality is,
as we talked to customers, we have integration
architects, who need to work on working
and building those business processes. They need to be up
level into APIs, so they can power
mobile, digital, and other connected experiences. And that’s exactly
what we have done. Some of you may have caught
up on the recent announcement we made a couple of weeks back. So Apigee has partnered
with Informatica, both collectively bringing the
best of bread in leading API management solution and
the best of breed iPaaS solution as per leading
industry analyst together. So we give our
customers the ability to actually leverage these
two platforms in unison, be more productive,
and really accelerate their API-first strategy. With this, I would like to
welcome Pratik on the stage. Pratik, take it away. PRATIK PAREKH: Thanks, Prithpal. Thank you, everyone. [APPLAUSE] So what I’m going
to focus on is what this partnership looks
like, where we are today, where we are headed. So before we get
started, let me actually give you a quick overview of
who we are as Informatica. Most of you probably know. We have been in the space of
enterprise data management for over 25 years. And since the beginning, day
one of Informatica’s foundation, what we have done
is worked with data. We have managed the data. We integrate the data. We curate the data. We master the data. We secure the data. That’s what the
Informatica platform– as Informatica, what we do. Today, Informatica
actually has– and this is a good
slide that covers overall the overview of
what Informatica platform looks like. So as you can see, there
are six different categories that we play into– integration, integration in
the cloud, integration on-prem, hybrid, all of that; big
data and big data management; data quality; data governance;
master data management; and price data catalog;
and data security. That experience is what we,
as Informatica and Apigee, in this case, are trying
to nurture and help the customers to unlock
the enterprise data assets that you have in the enterprise
and bring it into the– and help through your digital
transformation journey. The area that we
will be focusing on is integration
platform as a service. How many of you know
what iPaaS stands for? Integration platform
as a service is the new integration
platform that are mostly targeting
the cloud integration and the hybrid integration. Generally, the notion
there is to bring various patterns of integration
into a managed environment. Informatica runs as an
integration platform as a service as a managed cloud
service that supports almost all and supports the
multi-cloud as well as the hybrid integration patterns. Today, we process over 2.5
billion transactions a month. We have over 6,000-plus,
7,000-plus customers. We have over 100-plus
OEMs that actually– embeddable platform underneath. And one of the significant
characteristics that you see in
the top right there is 300% growth on
the API volume, the way customers
are consuming it. And let me go and
walk you through as to what the
platform looks like. So at the high level,
it’s very simple. This is what the iPaaS
from an architecture diagram perspective. First of all, it needs to
support an integration pattern. Integration patterns are
currently– as I said, it’s converging. So there is no big distinction
between an application integration, data
integration, IoT, big data. All of that, you need
to now support that. And the goal here between what
Informatica and Apigee is doing is how do you actually expose
those integrations that you develop in a platform
such as Informatica iPaaS and expose that as an API? And how you can unlock the
data assets that are behind, running those
processes and expose that for your digital
transformation journey? The second thing,
which is very critical, is the audience is actually
expanding beyond an integration architect or an API developer. Today, you want
to actually bring the data in the hands of
various different users within your enterprise– your
business users, your admins, and so on. And they should be able to
do quickly data integration and able to handle the data, and
should be in their fingertips. The third and the key
point is that you need to work with any sort of data. And data is, as
you all know, could be a structured data, which
is locked in an enterprise database or an application. It could be unstructured
data on your files and log data sources. It could be a streaming data
that is coming from various IoT devices and so on. And the ability to actually
work with all sorts of data and expose that as
an API is something that we’ll be talking about. One of the other big thing
is underlying platform should support a lot of– should be able to handle
this volume of data. And that’s where our
enterprise unified metadata intelligence come into play. This is an AI and ML
technology that actually powers the iPaaS platform. And finally, the
platform itself has to be very rock solid,
scalable to actually handle that type of volume
we were talking about. Today, as I said, it is
growing at 300% year over year in terms of API volume. And we expect that
trend to continue. In fact, we are prepared
to actually handle it, over 1,000%. And that’s what we are
prepared to actually handle. The key differentiator
of Informatica is the breadth and the
depth of connectivity. There is no single data source
out there that we cannot connect to, even mainframe. And we know that a
lot of organizations today have data and business
processes locked in mainframe. How do you actually expose
that into your digital transformation journey? And when we talk
about connectors, these are rich connectors,
which are very metadata rich and can handle various different
transformations on those data sets. Here, a quick example of
data stores on the big data side, cloud applications
such as Workday, Marketo, Conquer if you want to
actually reach to data sources and turn that into
APIs, middleware sources such as
TIBCO or anything that you are talking on the
messaging infrastructure, social applications, and so on. What we have announced and what
we are working on with Apigee– and this is where
we are actually announcing the integrated
experience to you all. And by the way, this is in beta. First and foremost, is
the publishing capability. So everything that you have
working with on an Informatica environment– and I’ll give
you a quick demo on that– you can actually expose
that into Apigee natively and with a point-and-click UI. Number two is to consume. If you are an API developer and
you want to actually find out all the various applications
and processes out there, which is
powered by Informatica, how do you actually extract
the value out directly from your Apigee
Edge environment? So that’s the
subscription part of it, and you can actually
auto-discover in the Informatica
toolsets right from within the
Apigee environment. And finally, the piece that we
are working on and we are very diligently focused on that
is how do we make these rich connectors that we have, over
200-plus native connectors but thousands of endpoints
that we can connect to– how can we actually make
that available in the Apigee environment directly
and natively so that you can actually
unlock the power of data and the applications
that are sitting behind those applications and
make it available into Apigee? So with that, let’s go and
look at the first part, the publishing of
Informatica integrations directly into Apigee. And I’ll going into a demo. So what I’m showing here
is a cloud user interface of Informatica Intelligence
Cloud Services. For this particular
demo, what you are seeing is an integration
architect view. And we have provisioned some
of the services of Informatica Cloud Services to this
particular organization. This is a subset of all the
services that Informatica Cloud Services offer. We have the integration hub, and
we have the big data services, and we have data masking
services, and so on, which are not yet visible,
because this org is powered for the integration
architect who is interested in the data
integration and the application integration. So I’m going into the
application integration, and I’m working on an
order-processing application. Now, this is a typical
example, where I already have a process inside
my enterprise, which actually takes in orders. And it is generating
the order information, and it is taking the order
through the lifecycle towards order-to-cash process. And it is doing the
order fulfillment. It doing the order procurement. It has to do all
of those things. Now, imagine as this enterprise
now wants to go digital and makes this
available to your sales people, who are on the road. And they are spending
a lot of cycles right now to actually
do all this manually after they come
back from the field. And we want to make
this available to them seamlessly from
within their iPhone or from their phone
or mobile device. So what we are trying
to look at this is we are taking
an order processor. Let’s look at the process here. The process is a
complex process. It’s touching number
of different endpoints. And it is actually, as I said,
taking the order information, and generating an order, and
then taking the process further into the fulfillment cycle. I want to make this available
to my API developer. And remember, I’m playing the
role of a enterprise architect. So this is where
the integration, the one that I talked about,
of publishing and service or publishing a process
to the API developer is what I’m going to show. So here, as you can see, we have
a natively integrated Apigee here. I’m going to create
this particular– and it gives me a nice
wizard-driven approach to actually publish this
particular process to my API developer. I’m going and selecting
the order processor, and selecting the Apigee org
that I want to deploy to. It’s walking through the
steps, auto-generating the ID for the particular process. You can always rename it. I want all the
interfaces to be exposed. I have various different
security set up that I can actually apply here. In this case, I’m going to
just select the pass through. I can make it available
and secure more as well as insecure more. In this case, I’m
going to make it available in both given
that we are still testing this particular process. And I don’t want to make
it available directly in production. I want to make it
available to the API developer in his sandbox, so
I’m testing the test environment here. And that’s about it. At this point, the
order processing, it’s generating the proxy. And it’s making it available
to the API developer to directly invoke it
from within Apigee. There is an SSO established
between Informatica and Apigee. So I can directly
go into this and get into the Apigee interface here. And as you can see,
that business process is already available. And the endpoint, as you
can see behind the scenes, and the backend system is
talking to Informatica. Let’s see whether this runs. So at this point, I’m going
to go into my Postman client. And I’m going to run
this particular– yeah, I found it. Yeah. So I send the
request over to the– and you can see the order
information was generated. I go back into the Apigee
console to see whether it ran. OK, I need to
start the trace on. And then I’ll work on one
more request on Postman. Yeah, it executed again. OK, and let’s see
the execution trace. Yeah. Let’s look at Informatica Cloud
on the Informatica Cloud side and see that request
came through on here. And it shows you the process
flow, the execution path this particular request took. So that was a quick
demo of publishing from within the Informatica
iPaaS to Apigee. And we saw how seamless
this whole integration was all the way from
actually looking at the internal business
processes and applications and making that available
to an API developer. From there, the API developer
can quickly test prototype it and then make it
available and consume it, in this particular case,
for the mobile application that he was building to
help out his sales team. So we covered this
particular flow of publishing from Informatica
to the Apigee side. At this point, I’ll hand
it back to Prithpal, where he will go into the
other side of the integration. PRITHPAL BHOGILL:
Thanks, Pratik. So what you saw very
briefly out here was how we have taken the time
to automate the user experience for an integration
architect, who is tasked with building
out a lot of these business processes. And within a few clicks, you
can push that as an API proxy within Apigee, right? Cuts down on a lot of the
editor-prone redundancy and other steps that are
needed and automakers that user experience. All of that can be done from
within the Informatica user interface. So let’s take a look at
the second design pattern that we have also enabled. And this is the deep
integration that Apigee has done with Informatica
the other way around, right? So in this case,
in this scenario, really think about you
as an API developer. As you’re building your
API proxy within Apigee, you have a requirement
to be able to reach out to one or more Informatica
business and integration processes, right? So let’s take a peek
at how do we really go about enabling that user
experience without having to leave the Apigee
user interface. In this case, we
have actually built on top of already
extensions framework and built a first class
extension to the Informatica Integration Cloud. And in this design pattern, as
compared to the previous one, the final request
for them ends up with the actual backend target. But in this case, you can
see you may have a existing API, which routes to
your backend target, but you can make
multiple callouts to different kind of
integration processes. So let’s take a peek at this. All right, so let’s start here. So I think this was working. It’s just a matter of too
many screens open out here. The OrderProcessor-3 three was
what Pratik went us through. Now, let’s take a
quick peek at how we would go about doing this
thing the other way around. So I’m going to switch org here. I’m going to gaccelerate4. And so, again, you go
to the admin interface here click on extensions And I
can add an extension from here. So there is this Informatica
Integration Cloud extension that I was talking about. Can click on this, give it
a name, and then save it. For the purpose of this
demo, I actually already have configured an extension. For the AcmeCorp,
it’s the extension which points to that specific
org within Informatica. And in the same style of
the extension interface, we have the credentials, which
are persisted securely for you within this Informatica
Integration Cloud extension. And then as an API developer,
it becomes very easy for me to just call out that business
and integration process which is sitting within Informatica
by using just a simple policy step. So here’s my simple API proxy. I could come out here, click out
on the Extension Callout policy just in the exact same way that
I connected to the Data Loss Prevention API. I can select AcmeCorp. And then I do that,
behind the scenes, this is actually invoking the
Registry API that Informatica has enabled as part of the
product level integration. So this is, in real
time, introspecting the business integration
processes, which are published in
the Informatica org and accessible to me using
simple design time constructs. So I can search out
here, select the one I want, and it’s as
simple as that for me to invoke that service. I’ve already configured the
Extension Callout policy here. And I’m trying to get
lead information back from Informatica. If I hovered out here real quick
within this project structure within the demo, you
have the fetch leads with fields business process. Very, very simple
business process actually goes and fetches data
out of Salesforce. And what I do is I take that
process, call it from Apigee, do a little bit of data
massaging in terms of the way I want to return it, and
then I call that API. So if I go back
out here, let’s go put this thing in trace mode. Let’s start a trace session. I’ll jump onto this out here. I’ll click on my Leads API. Now you can see
that this Lead API URL is different from the
business process that’s available within Informatica. This is the actual API endpoint
that you can use and share with your mobile apps, with
any other kinds of interface that you’re trying to
make this thing with. This API also can
then be published using all the Apigee
tools into a developer portal with nice, clean
general API documentation. And it can be
accessed and available to power many different kinds
of connected experiences. So this really enables– let me run this thing
a couple times here. So when I make a
call to this, it’s actually going over
the wire, making a call to the Informatica
business process, which is talking to Salesforce,
getting the data back. We do a quick transformation
and show the data back in the format, right? So just imagine how the
integration architects would work before we had
these integrations available. It was possible, certainly. However, it took a
lot of manual work. In many cases,
we’ve seen customers who have completely
different integration center of excellence teams
or integration architects and completely separate
API developer teams, right? There’s a lot of hand-holding
and manual passing of information back and
forth, which needs to happen. Very error prone, not as
secure, and more importantly, it doesn’t bring
out the productivity which is required to accelerate
your API-first strategy. So using this kind of
integration patterns, the first one,
again, I’ll recap, which Pratik walked us
through is taking and making the life of an integration
architect super easy by giving you a
couple of clicks. So right from within
the Informatica UI, you can push these
business processes as secure, managed API proxies. And they can then be automated
into the API lifecycle, so you can very confidently
share that with mobile apps, with any other
connected experience that you’re trying to deliver. The second thing that
we looked at was, without leaving the
Apigee user interface, API developers were interacting
with these kind of very critical processes, can simply
use the extensions framework and the first of the
extension that we have built to the
Informatica Integration Cloud and integrate with
those processes, turn them into APIs
very, very rapidly. And the last announcement that
Pratik took us through today was that we are going to use
the exact same extensions framework, which we have
used to enable the nine extensions that you
saw today, and take the rich palette of connectors
that Informatica has to a variety of different
kinds of data sources, all the way from
SaaS applications, big data systems,
mainframes, and a bunch of different on-premise sources
and turn them into connectors, which customers can use directly
from within the Apigee user interface. We believe that tackles a set
of use cases for API developers when they are not really
interested in building a full-blown business
integration process, but simply have
a need to connect to different kinds of sources,
turn that into APIs very, very quickly. So recapping this,
today, we took you through a journey of
how you can accelerate your API-first strategy, unlock
the value in the enterprise app and data sources that
you have and turn them in to secure, manageable, and
monetizable APIs that will power and fuel your data
transmission initiative and your API-first strategy. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *