I wanted to thank you all again for attending the Enterprise API Adoption Patterns talk yesterday. For those that didn’t get to view the webcast you can watch a replay here: http://resource.soa.com/resource/webinar/enterprise-api-adoption-patterns. We had several questions that appeared in the chat. I had difficulty catching them as they scrolled through. I seemed to have lost all of the questions that were sent directly to me in the chat. I am so sorry. Please feel free to email me at firstname.lastname@example.org or comment on this blog to ask them again. Below are the questions that we were able to capture that were sent to everyone or Roberto. I did remove duplicates.
What do you mean by the business impact of APIs in the presentation? Does it mean whether an API lives up to its quality attributes performance, security etc.? I
In the presentation the business impact is truly that, i.e. what impact does this API strategy have on the business. Does it provide increased revenue through direct or indirect means? Does it expand your partner ecosystem? Does it allow you to streamline your processes, reduce the number of systems and spider web integrations thereby optimizing and reducing your cost basis? Does it increase your customer satisfaction? Remember you should have a means to measure your strategy to see if it meets the goals you set for it.
What is the right place to develop APIs to the legacy system? Develop in ESB and expose through ESB or develop in Java and expose through ESB?
Challenging question that requires some more information. I am assuming by APIs you are talking RESTful APIs that can be exposed for consumption either inside or outsides your enterprise. Does the legacy systems have SOAP services you can leverage? If so you can potentially leverage the mediation capabilities in your API Management platform if not a lot of heavy lifting is required. SOA Software’s API platform provides for both mediation and orchestration workflow capabilities. If there are services into the legacy systems but a lot of work needs to be done to get them in a consumable API form, for example maybe many integrations with complex orchestration logic or multiple transformations, I would leverage a purpose built ESB. If no services exist into the legacy system, you may find an ESB or a gateway that has a connector into that legacy system that you can leverage which should theoretically saves you time depending on the customizations you did with your legacy system. SOA Software provides support for several technology platforms like Microsoft, IBM WebSphere, WebSphere MQ and Mainframe, allowing enterprises to leverage applications built on these platforms and externalize the native services as APIs. If none of the above exists and you have to create from scratch, the decision on whether to build a java app with business logic and connection logic running on an app server to connect to your legacy system or if you should write the connection logic and business logic in your ESB to connect to your backend system I think will depend on many factors such as;
- What are you trying to accomplish.
- What are the legacy systems you are connecting to.
- How many APIs you want to create and how many legacy systems are involved.
- Are you able to decouple the connection logic from the business logic to the legacy system and reuse it.
- Do you have an ESB infrastructure in place?
As you can see it’s not a simple answer without the full context of the situation.
If SOA and APIs are converging … are we going to see a convergence of SOA and API tools. Currently most vendors seem to have a SOA offering and an API management offering
Yes we will see attempts at a convergence of SOA and API tools. SOA Software is the first vendor to provide a completely converged SOA and API toolset that supports the complete lifecycle of both services and APIs from design-time to run-time through monitoring and analytics giving you a complete portfolio view over your enterprise. You can find more about SOA and API differences and convergence at www.soa.com . I see the pure play API Management vendors and vendors who did not have a complete SOA governance solution prior to the API movement, having difficult time extending their solutions backward as there is a vast amount of knowledge that is required to understand enterprise SOA Governance need.
How proxy is different from Gateways?
Ian Goldsmith wrote a great blog on API Proxy or Gateway. You can find that blog here: http://blog.akana.com/api-proxy-or-gateway/
Will SOA software adopt RAML?
SOA Software is working with the RAML working group and incorporating support for RAML.
What is the best way to start learning about API Management? I have good experience in Oracle SOA Suite
There is a wealth of knowledge from beginners to advanced on http://resource.soa.com. I would start with the eBook: Building Successful APIs which is located here: http://resource.soa.com/resource/whitepaper/ebook-building-successful-apis. Additionally there are several books on the market. I recommend reading the book “APIs: A Strategy Guide” by Daniel Jacobson.
How are the security vulnerabilities handled while interacting with partners on data security and encryption / SSL etc
Do you need to buy an API Management platform or can you build your own?
Building an API Management platform is more complicated then you think, as you need to manage developer/partner on-boarding, relationship management, possibly monetization, monitoring & analytics, security and documentation. It all seems quite simple on the glass, but as you get deeper into it, it gets complex very fast. Very quickly, you are not in the business of delivering a solid API strategy that makes revenue for your business, you become operations teams trying to keep your homegrown platform a float. I am working with several companies who have well known APIs in the market that are in this very situation. They are in this situation because they were pioneers and there were no API vendors to help them when they started their journey. They are now in the process of replacing their homegrown solution with a solid API Platform so they can get back to their real business. There are many API vendors in the market. There is a solution that can fit practically every budget now. I wouldn’t waist your precious resources trying to build yourself.
What are best practices in building or initiating a SOA/API program within a federated development environment such as County government which has autonomous LOBs, not currently collaborating via a SOA / API model?
This is a very common question I get across all large enterprises. Before I give my opinion I have to understand a little more about your intent and current environment. What is your goal? Is it to establish a single SOA / API program across all LOBs? Were you given the initiative from an executive to take on this task? If you were, you will definitely need a very high executive sponsorship and mandate to get this done. The executive needs to understand it will require effort on their part. Or is your goal to establish a SOA / API program within your LOB, and then drive adoption of your LOBs APIs across other LOBs? If that is the case you need your LOBs executive backing. In either case you are going to need a strong champion, evangelist to get everyone motivated to participate in this initiative.