8 Replies Latest reply on Oct 19, 2016 5:34 PM by FormsGirl

    APIs and You: Has the Relationship Changed?

    Bob Rhubart-Oracle

      computer_is_an_API_350.pngIt's time  for me to write another column for Oracle Magazine. This time around I want to focus on the role of APIs in your world.


      Application Program Interfaces -- APIs to their friends -- have been around since before mobile phones could fit in pockets. But APIs have since grown in significance, especially in light of the ongoing evolution and expansion of cloud computing.


      So for this next article I would like to explore the following questions:

      1. What percentage of your work now involves APIs? Has this changed?
      2. How have APIs changed your approach to your work?
      3. Are you an API developer, or an API consumer?


      Your answers to these questions, as well as any additional comments, will provide critical background for my article. Responses may be directly quoted in the article, with full attribution, of course.


      Please post your responses/comments no later than Oct 19.


      [Thanks to Oracle ACE Director Frank Munz for the photo.]

        • 1. Re: APIs and You: Has the Relationship Changed?

          Here my 2 cents:


          1) What percentage of your work now involves APIs? Has this changed?

          A large amount. As we continue to invest heavily into building our Oracle Cloud capability and continue to help customers  transitioning applications to the cloud, the need for APIs to do all sort of things (integration, mobility solutions, data migration, etc) it's absolutely critical.


          Having said that, because we need APIs for building mobile apps and responsive web applications (what I call UX APIs or single purpose APIs), integrating to SaaS, implementing Microservices Architectures and even implementing automation (as even management capabilities are now available via APIs), more and more of our work goes into defining, building, managing or consuming APIs.


          2) How have APIs changed your approach to your work?

          API-led connectivity is driving the industry (or should I say enabling the industry). This starts to become evident as organisations realise they need APIs for building their mobile applications but even more so as they start adopting cloud applications or modern platforms, all of which expose APIs for almost everything (access to data, functionality and even system management).


          Added to this is the fact that organisations that embark on digital strategies (almost every organisation now days)  soon realise that without access to core information and functionality which exists in many legacy systems, a digital strategy is pretty much stuck (and so is the hope to implement "bi-modal IT"). Then the question comes: we need more APIs!!


          So answering the question: dramatically. We're looking at APIs as an strategic "business initiative" to deliver business value. APIs not only serve the purpose of connectivity to either get access to a system and enable mobility solutions, but also have the potential to drive business to business (APIs for inter-org collaboration) and in the best case,  a new source of revenue where a business can materialise on their digital assets by making them accessible to the public via APIs.


          This is why I created an API value chain to depict, in business terms, what value APIs bring to the business through different levels of maturity (page 7 of Oracle API Management in the Year 2026 ). Once the value of APIs is well understood specially to the business and core IT people, then creating a business case for introducing a discipline to manage APIs and its ecosystem (API Management) is straight forward.


          3) Are you an API developer, or an API consumer?

          An architect building platforms to enable API designers, API developers and API consumers to collaborate, build and manage APIs. For example, providing the tools and processes to adopt API-first (ie. with tools like APIary) which have the potential to dramatically speed-up the process of developing consumer-driven APIs, but also providing the core infrastructure to allow different types of APIs to be built, deployed, run and managed.


          Lastly I would like to share my OOW16 presentation: Implementing Enterprise API Management in Oracle Cloud as it covers the topic of APIs and API management in a much broader extend and in the context of an enterprise, where existing traditional SOA investments still play a key role.

          • 2. Re: APIs and You: Has the Relationship Changed?
            Rolando Carrasco

            I've been delivering presentations and conferences about this topic very often from the last past 24 months or so. I've partcipated in different events where the APIs topic is an important one, or even the core of the event. For example, last year at Lima (Perú) I participated in the SOA, Microservices & API Management Conference. Last week (October 4th 2016) I was again in Lima participating in a Digital Transformation Summit organized by Oracle, where my session was about APIs. Together with Luis Weir and Arturo Viveros, we wrote a book related with API Management last year (2015), so the topic has been very present in my conversation.


            I also think that never in the history of the world, programmers have had so many assets at their service to use to build a solution. Nowadays a programmer has the ability and the possiblity to change they way we live at the distance of its fingers. And in a very strong way, is because of the existance of teh WEB APIs. A person whi is not even a tennager, has the possibility to use the available APIs to create something unique that can be used for millions of people arond the globe. He/She just needs an IDE to programm, a place to deploy and reuse the APIs. So that idea itself is amazing, is crazy.


            In the other hand, the produers, which are organizations that are trying to innovate, are constantly figuring out what APIs to create and publish. I was in a customer last week (a Bank) that had a very clear idea on what to define as an API Management stratey. They had a clear vision of creating a Portal fo their 3rd parties, how to charge the, how to monetize those assets that will be published. The benefits that they can create with it, not only for their own, but also for the developers, the end users, etc. So a new economy is in place, and many actors get benefits from it.


            So definitely this is a hot-topic. Is a topic that is for the interest of both IT and the business itself. It is a new way to create new business.


            1. What percentage of your work now involves APIs? Has this changed?

            Yes. It has definitely changed. I think in terms of conferences/presentations that I delivered, that topic is at least present 50% of the time. Every 2 conferences I deliver one is about APIs.

            In terms of what I do as developer/architect, it has also changed, since now are we are constantly trying to focus our endpoint as WEB APIs. We try to document them as APIs. So that has also changed, either if is a public API or an internal one.

            Also in our approach with customers, thas has changed. We try to make them see the importance on this. If they are going into the Digital Transformation, then a way to perceive it, the way to deliver iit could be through APIs.


            2. How have APIs changed your approach to your work?

            It has changed in the way I try to design this for customers. It has changed in my vocabulary when I try to explain something. It has changed in the ways I try to identify new opportunities. It has also changed in the way I am doing business. It has created us a need to publich our new APIS.

            It has changed in the way we managed some of the platforms we use, and more on a Cloud environment. Our engineers are constantly using APIs to do operations tasks, or are building their own.

            So it was changed. And more importantly, we like that change.



            3. Are you an API developer, or an API consumer?

            I can say both. WE develope APIs, and we are also consumers of many APIs.

            And we kind of try to be at the edge of this topic. We have created content around this to help others to understand the economy that is around the APIs.

            • 3. Re: APIs and You: Has the Relationship Changed?

              Hi Bob,


              API’s are not longer a pure developer topic. Mainly the REST API is getting more and more in the focus of an Administrator for Oracle Fusion Middleware Components, but also for Oracle Database Administrator. The REST API’s (RESTFul Management Services) provided by Oracle within WebLogic 12c are enabling the Administrator to fully manage (monitor, create resource, modify resources, delete resource, start and stop operations and so on) the entire Oracle WebLogic Environment just by performing HTTP requests.


              In a changing world of Cloud Services and the corresponding lack of direct access to the underlying Operating System, REST API’s are the perfect methods to monitor, manage and maintain for example your Oracle Fusion Middleware Components.


              This has simply changed my complete way of working with Oracle Fusion Middleware environments.





              • 4. Re: APIs and You: Has the Relationship Changed?
                Sven Bernhardt

                Hi Bob,


                here are my thoughts, regarding the topic:


                APIs are omnipresent, even though they are around for ages. But I think, when talking about APIs today, we need to distinguish respectively classify different types of APIs. Looking at Gartner's Bi-modal IT idea, where we have the Systems of Record, Systems of Differentiation and the Systems of Innovation, different characteristics and purposes for APIs can be identified, like

                • Preferred interaction pattern (sync or async)
                • Interaction participants (e.g. System2System, Human2System)
                • Communication protocol (e.g. HTTP vs. FTP resp. JMS or legacy protocols like RMI)
                • Complexity of data structures (Deeply interleaved, technical structures vs. flat, easy-to-understand data structures)
                • Data representation (e.g. JSON vs. XML)
                • Response times
                • Used security mechanisms (e.g. NTLM auth vs. OAuth)
                • ...

                In pure integration projects, we often work with legacy API, provided by the Enterprise Information Systems (EIS), which are on the level "Systems of Records". There's often no comprehensive documentation available and the interface as such is quite complex. The information exchange is usually done using specific data formats that are quite technical and so hard to understand (e.g. SAP IDOCs). By nature, the interaction pattern is often asynchronous using protocols like FTP, JMS or even SOAP.

                The opposite are API used for mobile devices or even wearables. Those APIs are clearly described, easy-to-understand and are usually working with lightweight protocols and data structures. The interaction pattern is often synchronous, which is important especially, when the interaction with the API is initiated by a human actor, who expects a immediate response.


                1) What percentage of your work now involves APIs? Has this changed?

                In daily business I often work with APIs on the Systems of Records level, while implementing integration solution on the EIS layer. This is really straight-forward, since those APIs are predefined. You have to deal with all the problems and challenges those APIs introduce - you have to deal with it and you can't do anything about the provided interfaces. On this level, customers often wanted to know which systems are integrated with each other and using what interfaces. This is a question that customers wanted to have answered for all of their APIs, to have some kind of dependency overview; which is created automatically by some kind of harvesting mechanism. This seems to be sufficient from the customers, but from my point of view it isn't. And this, what I always try to motivate at customers or even when talking to my colleagues. To enable the adoption of new architectural styles like Microservices as well as new technologies and concepts from the area of IoT, a consistent methodology is needed to manage an enterprises' APIs. From my point of view API Management is a key enabler for those topics and success factor for digital enterprise of tomorrow. Companies have to care about to be competitive on the long term.


                To make customers aware about how important APIs are to e.g. create and establish new products, service or business models, we need to be able to explain the importance of an overall strategy for API Management. A basis for that is to clearly define the basic terms, like API or API Management. I noticed very often that people a different understanding here and only see partial aspects, like API dependencies or lifecycle management. There's no idea about the big picture from an Enterprise Architecture point of view. To somehow create this awareness is a key challenge in daily business, since I can see more and more use cases at customers. Especially, when customers are forced to change their key business with respect to the demand on the market, created by the digital innovation.


                2) How have APIs changed your approach to your work?

                Since the meaning of APIs become more and more important, are intended to add business value and also to force innovations, it is important to consider those points, when creating respectively changing APIs.


                I always try to motivate is to establish an API first approach. Thinking about an API upfront, before starting the implementation it and also interact with the potential consumers, lead to stable and robust APIs. Consequently, the implementation efficiency increases and the time-to-market also decreases, since API consumers and API providers can work in parallel. I also pay more attention on the quality of APIs, which means aspects like

                • Consistency, regarding the API structure and used naming conventions
                • Comprehensibility, regarding the used data structures
                • Stability, regarding compatibility in case of change

                Following those principles is the basis for an APIs success, especially if an API is intended to be public available and consumers should e.g. be charged for an APIs usage. 


                3) Are you an API developer, or an API consumer?

                Depending on a concrete project situation, I can be both a developer as well as a consumer. In general, I would say, it's good to work on both sides to understand to needs of the two roles.

                I think the experiences you made when working with APIs, no matter if you're working as developer or consumer, are key to success. It is important to learn from good and bad experiences and examples regarding e.g. API design. You should try to keep the good things and to avoid the mistakes.


                One final conclusion: I think the topic in the area of APIs and API Management are essential for enterprise for being successful on the long term. Companies should not wait until they're forced by the market, but should proactively think about it, to discover the chances and new opportunities to generate revenue. 




                • 5. Re: APIs and You: Has the Relationship Changed?
                  Sten Vesterli

                  What has changed is

                  1) We are using the word API differently

                  2) We are using APIs (in the new meaning) much more


                  An API used to mean methods in a library that you called from your code - for example, physical hardware came with an API that you could call from your C code.


                  Today it means "a web service called by someone outside your team," and there is definitely more of it. Because your services are now being called by someone you don't know and who don't know you, you need API management. This involves proper documentation, coding examples and a way for the caller to communicate with the provider. It also means that the provider needs to think about how to control access - e.g. you get 10 free calls per day and then you have to pay.


                  I'm using APIs more - both as consumer and provider. I would have liked to report that API management is a well-established discipline, but it isn't. A few people know what it is, and even fewer implement it.

                  • 6. Re: APIs and You: Has the Relationship Changed?
                    Bob Rhubart-Oracle

                    Thanks, everyone, for the excellent responses!

                    • 7. Re: APIs and You: Has the Relationship Changed?



                      1) What percentage of your work now involves APIs? Has this changed?


                      As a database guy, in the past an API always meant a PL/SQL API. Typically packaged procedures/functions that performed business processes, which were called via a database connection. In some cases these were stateless. In some cases they were stateful. I think many developers from the Oracle database world have a long tradition of using APIs in one form or another. They were just not that accessible for developers because they were forced to use an Oracle driver of some sort to call them. So in that sense, the number of APIs have not really changed over time for me. The style of APIs has changed though. For about a decade we've been presenting existing PL/SQL APIs as XML web services (SOAP and REST) using the PL/SQL Web Toolkit. More recently these are being replaced by RESTful web services using JSON, preferably using Oracle REST Data Services (ORDS). Often, these are still calling the same underlying PL/SQL APIs, so the web service part is just a delivery mechanism.


                      2) How have APIs changed your approach to your work?


                      It's not made a drastic difference to my approach as I've always taken the API approach. As mentioned before, it's the deliver mechanism that has changed. What it has done is focused many companies and made them understand the importance of APIs, so it's easier to sell them on the concept, rather than having to drag them kicking and screaming. Ideally, you can convince them of the API-first approach to development, rather than tagging on APIs at the end of the development process.


                      3) Are you an API developer, or an API consumer?


                      I think every developer should be both an API developer and consumer now. Most DBAs should be involved in some form of API development also, as they should be aiming to make their roles more self-service, as we see in the cloud. When it comes to using Cloud Services, both developers and DBAs should be aiming to be API consumers as it is often more efficient and reliable to script tasks using cloud APIs, rather than click on screens.





                      • 8. Re: APIs and You: Has the Relationship Changed?

                          Well for me, API's are pretty much what I  do 100% of the time as APIs are my business. Today, in the world of mobile and cloud, the importance of creating, deploying, securing and monitoring APIs is essential as the entire window into a company’s on-premise business logic and data are through API’s.  Although I agree with Sven that the word API has changed meaning.


                        As IT began to move their data centers and most of their development environments to cloud. The development tools and run time environments needed an interface to access the legacy apps and data that were housed on premise and RESTful API’s were just the solution.


                        Most organizations are already strategizing on how existing systems should be REST enabled  and how to break-up the massive legacy applications into business focused API’s. Companies are challenged to find  the best solution whether it's using packaged API’s that Oracle provides for things like e-Business Suite, or creating customized REST services from database packages and using tools like ORDS or even using solutions such as our API development tool, AuraPlayer to create REST API’s from Oracle Forms and EBS systems. Where AuraPlayer generates Oracle Forms/EBS API’s automatically without redevelopment using a wizard. And of course companies can always elect to go the redevelopment route by extracting the business logic out of the legacy systems and putting it into database to be able to convert them to REST API’s. Whatever the method, the strategy remains the same. The corporate business logic, will be converted to REST API’s. Then the API’s will be plugged into front end development tools like Application Builder Cloud Service to make websites/dashboards, or  integrated using IC Cloud to provide connectors to different cloud tools, and even build mobile apps with Oracle Mobile Cloud service.


                        For me personally, my focus is solely on how to help organizations design, plan and then generate then automatically API’s from their Oracle Forms / EBS systems to leverage their current investments. Since if People are not doing it yet, creating APIs from legacy applications is what they will be doing within the next few months for the next few years.