Posts

Rajapinnat REST API

About API’s and their publicness

A modern application lives or dies based on the availability of its public API. Before having a deeper look into what API’s mean to us, and how they can be used in the most effective way, we should understand the basics.

API (Application Programming Interface) is an interface that allows the application data and functionality to be reached, as well as allowing for further programming of the program or a part of it, for example in regards to standard libraries. These interfaces can function on a very low level and deal with the inner functions of the application itself, for example calling open source libraries within the system. However this article only covers public API’s that are expandable or can be integrated and allow for the application data to be used in a variety of different ways.

API-centric architecture

Traditionally API’s have been considered to be an internal part of the application, or at the very least to be used as a means to integrate something to the application. Modern applications act as services, and this is why it’s important to make sure that expanding the system is just as easy as is the use of the data included in it. Modern applications use and offer a multitude of interfaces, for example social media applications like Facebook and LinkedIn are mainly run on interfaces with separate user interfaces built on top of them (e.g., browser, mobile, etc.).

In an API-centric architecture the applications connect to each other over these interfaces. How a single application has been built doesn’t matter as long as it follows the general practices in its interfaces. API-centric architecture also makes it easier to create device independent applications, so that for example the application can be run on multiple mobile operating systems using the same interface on them all.

 

Adeona_PIM_2017

RESTful API

Using general practices and de facto standards when connecting applications and using the data via different applications makes the whole process easy.

REST (Representational state transfer) is an stateless interface architecture model based on HTTP protocol. Typically REST API offers the information in JSON (JavaScript Object Notation) or in XML format. Our REST API’s use JSON, which is an open format based on readable text and attribute value pairs.

Public API

One of the main ideas of an API-centric architecture in that the interfaces are publicly available and that they contain a comprehensive documentation. Even a good interface will go unused if it’s hard to use or lacks documentation completely. In the best case scenario all the information and logic of the application can be reached via the API. This makes it flexible to connect, integrate and expand the system with needed applications.

Public API doesn’t however mean that all the information within the system would be publicly available. API calls are always authenticated so that the user will only have access to information they have credentials for.

More information:

https://en.wikipedia.org/wiki/Application_programming_interface
https://en.wikipedia.org/wiki/Representational_state_transfer

 

Vision of a CIO: Kill ’em all!

I recently had an interesting conversation with an information management officer from a medium-sized Finnish company. He had joined the company around a year earlier, and it seemed like the strategic work on enterprise architecture had been completed and the roadmap for systems architecture was beginning to be clear. Moderate-scale modernisation, renovation, and systems updates expected within the next three years. Or four years –

these plans always overrun a little bit.

The guy’s vision for 2020 was music to a well-marinated PIM consultant’s ears. Paraphrasing liberally, the goal is an updated, modern architecture where master data and its related processes have been put in order, information flows according to API thinking, and communication with customers, at the highest possible level, is allowed using information resources and automation.

From our nice and straightforward chat, one quip stuck in my mind.

So my aim here is to kill around 16 systems, leaving only 5 or 6 systems instead. In the spirit of Metallica: Kill ’em All!

Excitement in the air and brains in overdrive – great vibes! Extra points for getting the favourite band from our youth mixed into the same pot with business applications, interfaces and data. I also got the feeling that it might be fun to work with them in the future.

After the meeting, however, I got to thinking about today’s challenges in leadership in information management. Though if any topic has been written about at length and from different perspectives, it is this one. And in Finland we have some really solid know-how, recognized at an international level too (take IT Standard for Business as a single example).

But right now I couldn’t stop contemplating the Metallica approach.

The remaining 5-6 systems specified by the CIO are, of course, main systems critical to business activities. They own the basic information associated with each system. In this case, they also include a platform for e-commerce that, among other things, will be used to run future online trading of different business units.

canter_sieniasateella_blogi

This is the basis on which business and core processes operate. Master data is managed and cared for using best practice, and modern interfaces deliver it to the right place at the right time. Using BI and analytics tools, valuable information is produced to support decision-making so that operations can be developed in the right direction and that leadership can be based on knowledge, not guesswork.

Then there is the layer that is full of the pulp of tools and applications, and the boundaries of which are irritatingly mushy.

Business wants to develop customer experience and communication, online commerce and sales toolbox – let alone marketing digi-gizmos. All this as agilely as possible, please. At the same time costs need to be kept under control and activities need to become more efficient.

In turn, people, regardless of unit and role description, wish to use tools that are quick to learn and easy and efficient to use. Perfectly natural. If this is not realized, problems tend to get piled on the desks of data governors and information management.

How should this ever-growing and shape-shifting tangle of applications, utility programs, and cloud services be managed? Who is responsilbe for what? Who even knows what apps we have in use, and for what purposes? Which is the right model for us: the ’Master of Apps’ or ’…And Apps for All’? What information is used where? Is some place producing information that is valuable from a business point of view and which should be linked to a process or analytics? And so on…

By the way, I am not jealous of today’s CIOs.

I am also not surprised that there is a worldwide race to invent new titles and roles to manage these areas, as one man/woman shows have not been sufficient in a long time.

It would be interesting to hear real-life examples of what practices you have in place for depicting applications and information flows. Are there, or have you come across, any good ready-made models, or have you developed or drawn ones for your own needs? Leave a comment or send a private message. I would gladly exchange views on this.

Next time I was planning to open up and explain how I have tended to structure, from a product information management and digital development perspective, an information architecture framework that addresses the requirements of today. I suggest that nobody holds their breath waiting for that though, as a suggestion entitled ’Mushroom gathering trip to the forests of Nuuksio’ hit my inbox while I was writing this. Have a nice fall!