Sbuilder Roadmap v2 part 1/2

Introduction

This blog entry argues that managing on-line openness has become more important for businesses with the emergence of API ecosystems, and, in the future, it will be even more important as blockchain technologies mature. To help in managing on-line openness this post suggests modeling API ecosystem.

Table of Contents

Emerging API Ecosystems

Just a few years ago, application programming interfaces (APIs) were largely viewed as simple specifications between applications and services, early 2000 introduce service-oriented architecture (SOA) with idea of business-to-business relationships via standard interfaces, later Web-friendly technologies, such as REpresentational State Transfer (REST) greatly simplified reusability, and today we are seeing a surge of open APIs, API “mashups” integrating existing APIs, and API ecosystems as key business drivers [ref], [ref].

Open APIs compounded annual growth rate has been approximately 100% from 2005 to 2011 [ref] with thirtyfold increase since 2006 [ref].

In the future, blockchain technology, with the ability to facilitate transactions without the need for a central authority, combined with the speed and cost benefits may be disruptive to many industries.

One example is logistics industry, where the possibility for all parties in supply chain to work off the same synchronized version, has great potential to remove friction and unproductive work, and to increase the efficiency of supply chain [ref].

A little bit further in the future may be the vision of “world of many blockchain networks” presented in Hyperledger white paper

the future will involve a world with many interconnected distributed databases and blockchains, each of which will be specialized to suit the purposes of its users, but may also require communication with other ledgers.

shown in the picture below

As a summary, walled garden business models, relying on retaining on control applications, content, and media, will be more commonly replaced by open platform business models, based on open standards and open APIs.

Managing On-line Openness

Businesses are facing the challenge to balance their on-line openness. On one hand, more openness has the potential to add-value to consumers, producers, and on the other hand, due to network effects, too much openness can have value-destroying effects, such as poor quality contributions or misbehavior of some participants that causes others to defect.

Perhaps the ultimate case for openness are blockchain platforms, such as Ethereum or Hyperledger, implementing smarts contracts with monetary value. On Ethereum, there has already been several incidents with actual or potential thefts or losses. Ethereum community is addressing these problems in multiple ways by using common patterns in contract coding, by creating standardized mid-level components, by liming contract execution model on Ethereum Virtual Machine (EVM), by using compilers to issue warnings on dubious coding practices, by having contracts defining governance rules, and on top of all the other techniques, by pursuing the use of formal verification techniques.

Problems on Ethereum platform are symptomatic to a situation, where business is requiring agility, and fast response, which IT fails to deliver in a managed way. Ethereum is an open source project, but also businesses are facing problems as control of IT infrastructure is not in the hands of any single company. IT governance practices, applicable in walled garden business model, may not be sufficient in open API-economy, anymore.

Modeling To Help in Managing On-line Openness

To manage on-line openness in API ecosystems we need to have a representation, a model, describing aspects of a system that is not easily or sufficiently captured through implementation:

Having a understanding of a single API is not enough, and the model should allow us to reason on the behavior of API compositions.

Instead of being mere static representation, the model should be runnable to help developers to gain understanding of the dynamic behavior of the API ecosystem.

API ecosystem, as IT-system generally, go trough multiple development cycles. API ecosystem modeling should support simulation using a model based on as-is status of implementation merged with planned changes of the next cycle step.

Boundaries between transacting parties tend set by what kind of institutions (firms, markets, franchises, etc.) minimize the transaction costs of producing and distributing a particular good or service. In API ecosystem implementation, we would expect relatively more complexity in interactions, and not so much complexity in computation. A programming language interpretation: expect complexity in control flow more than complexity of expressions. This opens the opportunity to extract part of a API ecosystem model from implementation code base. However, some parts must be abstracted manually, and the ease of integrating these two elements is vital for the whole idea of API ecosystem modeling, as presented here.

Expect implementation environment of API ecosystems to be heterogeneous. Integration with multiple implementation langauages should be well supported.

Any overhead to development process should be kept minimal. Demand for rapid innovations is so high that proposals slowing down release cycle are likely to be rejected. However, as the impact of failures may be severe, justified changes in development practices and system architectures are possible, and should be acceptable to all stakeholders.

Fin

This blog entry has argued that managing openess is becoming increasing more important in future API ecosystems, and presented high level requirements for API ecosystem modeling to help in this task.

The next blog entry explains, how sbuilder -tool matches with these requirements, or more precisely, how it should be extended to have a better match.