Structuring Open Business Capabilities – A Structuring Approach for API Initiatives
For several years now, not least due to regulatory initiatives such as PSD2 in the EU or Open Banking UK in the United Kingdom, APIs (application programming interfaces) have been finding their way into the banking business. PSD2, for example, came into force in September 2019, forcing banks to provide programming interfaces for third party providers (TPPs). These interfaces provide access to account information, payment services or card information. APIs are also an increasingly important growth catalyst for digital business models. For example, an estimate from 2015 showed that about 50% of salesforce.com’s revenue, about 60% of eBay’s revenue and about 90% of Expedia.com’s revenue is generated via APIs (Iyer, Subramaniam, 2015). It is no wonder that banks have long since gone beyond regulatory requirements by providing numerous APIs as a starting point for new business models or to benefit from internal efficiency improvements. The Singapore bank DBS, one of the pioneers of open banking, now provides more than 200 interfaces (DBS, 2020) for external partners, while European institutions such as ING, Deutsche Bank and Commerzbank have also been working at full speed for years on a comprehensive offering.
In Switzerland, too, there are numerous API projects underway. One central initiative is the OpenBankingProject.ch, which has made it its goal to develop standards for the use of APIs in Switzerland together with all interested parties, because ” only with a cooperative and open approach [the challenges of open banking] can be mastered efficiently and the opportunities successfully exploited ” (OpenBankingProject.ch, 2020). Organizations involved include Avaloq, DXC Technology, Ergon, Finnova, Hypothekarbank Lenzburg with Finstar, the University of Berne and the Business Engineering Institute St. Gallen.
However, the actual value of APIs in the context of enterprise architectures goes far beyond their technical properties. While McKinsey & Company primarily emphasizes the resulting responsiveness[1] as well as flexibility of IT systems (McKinsey & Company, 2018), Accenture assumes that APIs are the key technology for developing various ecosystems (Accenture, 2019). The technology thus represents an important building block in the digital transformation towards networked business models. And this inevitably also raises questions: Which activities should you begin with, for example the provision of an API Developer Portal or an overarching strategy? What factors need to be taken into account (for example, how strongly should you centralize specifications or which infrastructure components do you need to be use when)? How can possible activities related to organizational and infrastructure aspects be prioritized? The “API House of Digital Business” provides assistance in answering these questions. It is based on the St. Gallen House of Digital Business (Leimeister, et al., 2014), a further development of the St. Gallen Business Engineering approach [2] (Oesterle, 1995).
The St. Gallen House of Digital Business
The St. Gallen House of Digital Business is subdivided into the dimensions (1) “user, use, utility centricity”, (2) “business strategy”, (3) “business processes & organizational structure”, (4) “IT”, (5) “products & services”, (6) “managerial functions”, and (7) “data”.
The first dimension serves as a vision that puts the digital user at the center. The second level, the business strategy, describes the medium to long-term corporate development or strategic goals including the positioning of the company in relation to its competitors. The third dimension, “business processes & organizational structure” describes how the strategic goals are operationalized and anchored in the organizational structure. It also lists responsibilities and tasks within the organization. The fourth dimension, the IT or systems level, shows the information systems architecture or IT components. These must be selected in such a way that the processes can be optimally mapped and supported. The fifth dimension, products & services, describes the range of services with regard to digital or hybrid products and services. The sixth dimension shows the tasks of the corresponding managerial functions and how the corresponding role profiles are designed or modified. The seventh dimension describes data as a central resource in the digital age. It should also be noted that digitization greatly accelerates innovation and life cycles.
he St. Gallen House of Digital Business serves as the basis for the API House of Digital Business, which was developed by the Business Engineering Institute St. Gallen to provide companies with a discussion framework for their API initiatives.
The API House of Digital Business
The API House is structured similarly to the original model. It consists of a total of six dimensions that cover all the necessary components that should be considered for the successful planning and implementation of API initiatives in companies.
User-, Use-, Utility-Centricity: This dimension describes the approach that an organization takes in providing web-based interfaces. It is important to distinguish between internal users (from within the organization) and external users (from outside the organization). By providing internal APIs, the infrastructure of an organization gains agility and flexibility. External APIs, on the other hand, allow external customers to access the organization’s data, which leads to the development of new revenue potential for the organization.
Strategic Scope: The strategic scope describes in detail the overarching vision for the use of web-based interfaces. It also describes the project course envisaged by the company, as well as the necessary steps within the individual project phases. One approach could, for example, be “API first”, i.e. that all interfaces, with some exceptions, are developed in reusable APIs and published on a gateway.
Operating Model & Processes: In order to implement APIs and tap their full potential, a meaningful organizational structure (e.g. in the form of an API task force) has to be established which shows clear responsibilities and also defines processes that regulate the development, use, adaptation and possible discontinuation of the APIs. Examples of necessary processes include onboarding or efficient incident management for both internal and external users. Uniform standards and processes allow synergies to be realized between the business units.
IT Infrastructure: This dimension describes the technological components that must be set up to provide APIs. This includes an API gateway, which includes authentication and security components, as well as a developer portal that lists the available APIs along with detailed documentation and thus serves as a starting point for internal and external developers. API gateways can either be purchased from vendors such as Apigee (Google) or Axway in the form of an API platform or developed in-house. In addition, the API platform provides important statistical evaluations on the use of the individual interfaces, which can be used when choosing possible monetization approaches (e.g. per-call or flat rate models).
API Services: This dimension describes how the organization manages the design, development and documentation of web-based interfaces and how these are translated into concrete (API-based) products. It also describes how APIs can be prioritized and specified by the responsible units (i.e. the product teams). In addition, developers can be provided with important information or software development kits (SDKs) that support the consuming parties in connecting the interfaces. The innovation process can also be described here, i.e. the process by which new API-based products are created, usually through the interaction of different product units and across individual functions (business, IT, architecture, etc.).
Culture & Governance: This dimension provides information on how the individual web-based interfaces are used both within the organization and beyond its borders. It also describes how the API transformation is communicated and how legal and compliance functions are integrated, for example, whether and how contract functionalities will be automated or how the applicable data protection guidelines will be adhered to.
The API House of Digital Business and its dimensions pursue two goals. On the one hand, the framework helps to formulate a consistent strategy for the internal and/or cross-company development and use of APIs. In each area, specific
short, medium and long-term goals and tasks are defined. On the other hand, a structured maturity assessment of already implemented API projects can be carried out with the framework. This applies to organizations with a uniform API strategy as well as to organizations which, due to their size or organizational circumstances, have multiple, poorly coordinated initiatives. The latter can first evaluate their initiatives individually using the dimensions of the framework and identify any need for action. In addition, they can compare the individual initiatives by using the framework for structured analysis. This is particularly important if different API initiatives are to become a uniform corporate approach, which will be necessary in the medium term in order to make optimal use of the technology’s potential.
Conclusion
The API House of Digital Business combines relevant activities or structural requirements for a consistent API approach in one framework. The individual dimensions describe all the components of an API-based business model, from strategy to the necessary processes and organizational structures to infrastructure requirements. The tool can be used for the initial structuring of planned API initiatives and for evaluating the maturity of existing API initiatives (for example, by comparing different initiatives within the organization). In addition to the strategic, process-related and, of course, infrastructural dimensions, I would also like to emphasize the Culture & Governance dimension at this point. A purely technological view of the API concept (e.g. in the financial services sector) will hardly do justice to the topic. The implementation of APIs is rather a multidimensional journey that questions or tries to redefine aspects of corporate culture, cooperation methods and organizational structures. A sustainable API approach can only be part of a much larger digital transformation, which requires a new mindset among employees. Collaboration with internal and external partners, as enabled by APIs, requires a cross-functional collaboration approach (e.g. agile methods, devops, etc.). Only if all employees are involved in the transformation, and the corporate culture changes accordingly, an API approach can lead to sustainable success.
[1] Speed and effectiveness with which it is possible to react to emerging changes.
[2] More information on Business Engineering can be found here.
Bibliography
Accenture (2019). APIs: The Digital Glue How Banks can Thrive in an API Economy. Aufgerufen im Januar 2020, Quelle: https://www.accenture.com/_acnmedia/pdf-100/accenture-how-banks-can-thrive-api-economy.pdf
API Developer Portal von DBS. Aufgerufen im Januar 2020, Quelle: https://www.dbs.com/dbsdevelopers/index.html
Iyer, B., Subramaniam, M. (2015). The Strategic Value of APIs,” Harvard Business Review, January 7, 2015. Quelle: https://hbr.org/2015/01/the-strategic-value-of-apis
Leimeister, M., Winter, R., Brenner, W., Jung, R. (2014). Working Paper Series: Research Program “Digital Business & Transformation IWI-HSG”. Aufgerufen im Januar 2020, Quelle: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2501345
McKinsey & Company (2018). The seven make-or-break API challenges CIOs need to address. Aufgerufen im Januar 2020, Quelle: https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/the-seven-make-or-break-api-challenges-cios-need-to-address
Oesterle, H. (1995). Business Engineering: Prozess- und Systementwicklung. Band 1: Entwurfstechniken. Springer, Heidelberg 1994. (2., verbesserte Auflage 1995)
OpenBankingProject.ch. Aufgerufen im Januar 2020, Quelle: https://www.openbankingproject.ch/en/about-us/
