The API Layer for use by mobile applications.

 This is a continuation from the previous post:

·        Organization also comes with access routines and controls. Row level security and Role based access control continue to dominate this purpose.  Label based controls and organization spanning resource tree access security are increasingly being taken on at the cloud level, so we have less to content within the business implementations.

·        Identity and access management including credentials, keys, ciphers, messages and rotations are increasingly tackled by dedicated and almost ubiquitous platforms and products. Neither the membership provider nor the mechanism or protocol is specific to the business.

·        Plugins are easy ways to bring in functionality into a platform. They also allow isolation and working with the applications, but they need to conform to the plugin architecture. This is like separation of concerns, but it is tighter with consistency requirements. When the customizations by way of plugins have been around for a while, the platform can consolidate some of the functionalities and offer them as usable by the plugins.

·        The way the mobile applications evolve depends on the backend services just as much as the business requirements from the point of sales. Therefore, the mobile applications merely act as a facilitator.

·        APIs like most customer facing software interactions suffer from the same liabilities over time. Fortunately, the versioning and retirement policies can be enforced for all clients with the added advantage that more and more clients accept HTTPS based APIs over other forms of interface. As devices, platforms and ecosystems change, the APIs present an evergreen investment that can stand the test of time better than others. Moreover, they naturally lend themselves to automation, diagnostics and monitoring than most other software.

·        As software matures, many engineers choose to be dainty about the improvements they make often requiring very little change to existing data paths or processes. They do this for several reasons. First, because code reuse and original design decisions work favorably. Second altering existing code paths often runs the risk of regression. Third the cost of churn generally rises higher than the benefits. Also, much of the changes are usually in the form of technical debt – a term used to refer to the corrections needed as features are released by taking shortcuts which create instant debt.