Tag: Business

Emerging new job titles in LCNC an indicator of profound change

by Johnin Business2 Comments on Emerging new job titles in LCNC an indicator of profound change

What do we call the users of Low-Code or No-Code platforms that work for the IT dept?

Across the board, business and IT is seeing a transformation that is being driven by Low-Code and No-Code technologies. There is clear change in the job titles around development although the new terms have not yet stabilised.

Historically problems like this, are the indicator of genuine profound change!

Low-Code and No-Code is definitely not a replacement for developers or an IT department, and we will never be out of jobs (who will develop the Low-Code tools, who will design and build the surrounding complex architecture?). However, there are some great side-effects:

  • Business employees are learning the basics of
    • Development processes – the how-to and why they are beneficial, as Low/No-Code processes need to be constrained to stop ballooning and undocumented code.
    • Code and processes are more easily aligning with business processes.
    • Programmatic thought.

This is an exciting time, not only because we are seeing those at the forefront of the new technology explosion see their ideas come to fruition, but also because IT departments will see more understanding from business (as they learn more about IT as they onboard with the LCNC applications and processes), and this is driven by business and economics.

The language problem

Across many eras in IT there seems to be one thing that stands out about true – long lasting and permanent changes to the IT landscape break the language used in the current IT ecosystem. So any “language break-down” emerging is evidence of a strong of a probable trend being confirmed as profound change!

Some changes are fast and have “epoch moments”. Some are slow and creep up on us, leading us to say “this has always been known, but we never said it before in that way”.

Economists note that the one thing that stands out about genuine large scale change, is that the new activity will change what people do, how they are specialised and the job titles that describe it.

A good example of this is web-design. Initially we just had “web-designer”, before shattering that role into multiple disciplines, as we came to understand that improving the interfaces on a website was inherently complex, and architecture was only half the problem. We now have roles like (Sven Jenzer, 2023, Typical UX disciplines, [ONLINE] Available at: https://en.wikipedia.org/wiki/Parenthetical_referencing, Accessed 27 January 2023):

  • User Research
  • Information Architecture
  • Interaction Design
  • Usability Evaluation
  • Accessibility Evaluation
  • Visual Design

We need new job titles in development, so that Low-Code enabled developers can be classified in a way that reflects any extra value that they bring. While distinguishing them from citizen developers who, whilst they are not IT people, are doing ad hoc IT tasks to improve their role and also need a way of classifying their extra skills.

What is the solution?

Let’s look at the typical range of developer roles that we currently have:

  • IT Manager
  • Technical Architect
  • Technical Lead
  • Senior Developer
  • Developer
  • Junior Developer
  • Trainee Developer

We currently have no way of expressing the extra values that trained Low-Code developers and No-Code citizen developers bring. So, let’s break this down, essentially we are trying to express:

  • Experience level
  • Value to the business
  • Potential leadership role
  • Area of expertise

Using these taxonomies, we could potentially create new titles to express these, such as ApiOpenStudio Developer, Senior RapidAPI Developer, Junior Zapier Architect. However, this does beg the question, are users of Zapier or RapidAPI developers or architects? To be honest, not really, and they are definitely not architects. So this will not suffice.

I’m not posing a solution to this yet, and just want to open the floor to a problem that is likely to surface very soon, when those that have spent the time learning these skills want to express their new-found knowledge recognised by the business, or businesses want to find workers with the assets and skills that they want.

API First Concepts and Problems

by Johnin Business, News, Project management, Technical

Introduction

APIs are displaying continued astronomical growth (see https://www.postman.com/state-of-api/api-global-growth/#api-global-growth) and are now a critical part of nearly all modern architecture. However, we have seen a lot of coverage recently of the different terms encompassed by the API First methodology, especially as people try to use these buzz-words to generate excitement over their products without fully understanding what they mean.

In IT, terms tend to evolve, due to the pace of change. But this is not the ideal way to create terms as it can lead to similar terms, causing sub-optimal communication, even mistakes. But unlike industries like aviation and maritime, which are the gold standard for communication, w do not set a standard and declaration for what precise terms to use and when, to prevent confusion, misunderstanding and planes and boats crashing into each other.

For instance, we now have the following:

(Yes, I know that some of these are unrelated to APIs, however there is a real problem with language here – everything sounds the same and confuses people)

  • “API First”
  • “Code First”
  • “Data First”
  • “Design First”
  • “API First Design”
  • “Business First API Design”
  • “Api First Culture”
  • “Api First Company”
  • “Api Strategy”
  • “API as a Product”
  • … and the list goes on…
Knockout
Image: https://www.golfdigest.com/story/deontay-wilders-knockout-is-the-single-most-terrifying-highlight-of-the-sports-weekend

I don’t know about you, but my head is rattling from all of these variants. This is getting ridiculous and incredibly confusing for everyone, requiring a lot of reading of articles to understand the nuances of the new terms that are being introducing and how these may subtly differ from the others.

As technologists, we need the business community to fully grasp the ideas and benefits behind the API first methodology so that we and they can make sound judgements on directions and strategies. This means that the ideas need to be immediately comprehensible and their ramifications obvious.

Rubbish pile
Image: https://www.onmanorama.com/lifestyle/news/2022/08/10/eliminate-impact-single-use-plastic-products.html

I am going to suggest that we throw out a lot of these phrases and keep things simple, but I won’t try to reinvent the wheel and create completely new phrases. For the rest of this article, I will only refer to 3 terms.

API First concepts

Each term has an impact on the technical and business strategies/successes in different measures. But each concept requires a full “buy-in” and understanding from the business.

API First

  • Design the and build the API first!
  • The product is built around the API.
  • This is reflected in the business strategies and revenue models (see API as a product and API design 1st).

API-first is obvious from the business point of view. The API is the primary income generator or essential to other income product/s. Without a revenue model, you do not have a business. Therefore if APIs are the main product or critical to a product that is being created/overhauled, then the API becomes a crucial first-class citizen, not just for the technical dept, but also from the business.

Information and data are key to the modern business, right? APIs are the backbone for nearly all data communication.

Building a new product (not just API) is an expensive task, both in time and money. By going through a full design phase for the API, the correct emphasis and attention is given to the API that it needs, a lot of thought will be put into:

  • What data is being shared across the API.
  • Why this data sharing is required or wanted.
  • Who/what will be consuming the data (internal and/or external).
    • This will reveal any potential flaws or opportunities in assumptions that the business has made.
  • Ensuring that all business processes are made more efficient by the new agile data flow that APIs will provide.
  • Performance.
  • Reliability.
  • Scalability
  • Usability.
  • pricing.
  • Future changes/versioning.

n return, API First will have a causal effect on the business by ensuring that due diligence and research is followed before embarking on a costly venture of system build. A lot of thought will be put into what the business needs and why. Future projections and plans become much clearer.

This does not mean that all other resources sit in idle-mode until the API is built, in fact it can happen simultaneously. Once you have the API model built in documentation like OpenAPI or Redoc (quite early in the process), you have a model that can be used by consumers before you start the full development. This saves time and money on fixing broken assumptions, missing or inadequate requirements.

API as a Product

  1. The API may be the core product, but not necessarily.
  2. API as a product has 2 definitions:
    1. External-facing API that is monetised
    2. Indirect monetisation by a product that requires an API to function or public exposure and usage through a free public API.

API as a product, is tightly coupled to the API design-first concept. In order to implement business strategies for revenue driving APIs, good design and documentation is a “must-have” to enable third parties to consume the APIs, providing an easy-to-use, comprehensive and unified experience.

If the API product is well designed and documented, this will increase the consumption and efficiency of the API (and therefore income). Postman alone has seen very significant increases in traffic and API usage, despite the global downturn and Covid:

Since the 2021 State of the API report was released, the Postman API Platform saw significant surges in use:
* Users: 20 million
* Collections created: 38 million
* Requests created: 1.13 billion

https://www.postman.com/state-of-api/api-global-growth/#api-global-growth

Api First Design

In general, this is a development model for APIs that ensures the following criteria are met:

  • Reach agreement from all stakeholders.
  • Design the APIs models first on OpenAPI or similar product.
  • Build the API.
  • Separate products can be built at the same time as the API.

API design first may not be quite so obvious from the business POV, because at first view, it is just a development process. However, because it requires approval from all stakeholders, it is critical to have business “buy-in” to the process. This enables all of the business to see what/why the API is being built, and ensures that everyone is agreed on the most critical features they need.

In addition, this results in a rare instance of a complete understanding of what is being built and why, by the technical department. Instead of just being told to “build this” by the business without any consultation between them on what the rationale is, what is technically feasible, or if there is a better solution, the developers and department see the vision and are able to work towards that vision in a much more efficient manner and the end result will be a much better product.

Conclusion

This all ties in with discoveries and revelations being made about “Developer Experience”.

Up until recently, a lot of research and time has been invested un user experience (UX) and there is no denying the value that this can contribute to the business by increasing traffic and revenue. However a new key realisation is being made about developer experience (DevX). Who will be directly interacting with and consuming the APIs (and therefore making critical decisions that will impact their business about what APIs to consume and the frequency)? That right, developers!

They will correctly discard badly documented or difficult to use APIs in favour of better APIs. This means your product will be directly impacted by the DevX experience!

Winner Loser Buttons
https://www.stockvault.net/photo/231600/winner-loser-buttons-shows-winning-or-losing

If you are supplying an external facing API for revenue (direct with monetisation or indirectly by offering APIs free with the associated traffic, publicity and exposure), then DevX is crucial to maximise income.

If you are supplying an internal facing API, then good DevX will have an impact on associated systems design, development and maintenance. Business processes that interact with the API will be either made more efficient by a well designed API or made cumbersome slow and inefficient by bad APIs.

Free Support packages, for a limited time!

by Johnin Business, News

We now are seeing an exciting, 27% month on month growth in our install base of the Alpha version (ok “exciting” that’s a marketing term. We don’t normally use them, as that’s not us, but humour me – I think that’s what we are supposed to say).

We are particularly happy about this as we took the decision to launch ApiOpenStudio in an advanced form of Alpha. So we could get early feedback and build the best open source product possible. 

So to celebrate this, and the approaching Beta release, which we now estimate is now only 3 months away. 

We are offering a free 30 min support package to anyone who has downloaded the product. 

As this will support our early adopters, as well as give us the best possible feedback. The key to building the best product possible. 

This will be with our founder John (wherever possible), as we really want to get the maximum from this customer interaction.

So if you would like to take this up, please reach out to Matthew Greally on LinkedIn or the Contact Us form.

Low code trends and the new workflow management

by Matt Greallyin Business, Project management

The recent flood of articles discussing the way that Low-Code is changing the landscape of development have 2 key elements:

  • Low-Code is now clearly emerging as one of those enormous waves in tech, that will change the way that things are done across business and IT development moving forward. For both tech companies and non-tech companies (because everybody is technology driven).
  • In the future, it is really how these tools are used in unison with the company’s “Pro-Code” developers. Which is the real business problem to be riffed on and solved! 

What does the new development environment that includes “Citizen Developers” look like? How will they interact with IT Departments and the Pro-Code developers?

Will Low-code replace Pro-code?

Up front we’d like to point out the answer here is something we are sure of. This will in no way reduce the demand or work for Pro-Code developers.

There is compelling economic reasoning for this. As while it is true that all companies want to save costs, we are in an increasing world of digital transformation, where every business is in reality, a tech business. 

So the one area where you cannot start with cost saving, is technology. Companies will always be in a technology race to the leading/bleeding edge with their competition. That edge will always require having the best Pro-Code people you can get, as they provide the competitive advantage. 

Paradoxically this means if you have that, you also need the best Low-Code resources for two reasons:

  1. Low-Code enhances the output of your Pro-Code work force, doing vital but repetitive, non-challenging tasks. Speed means less hours, more output, and we all get that.
  2. These are considerable the other benefits, beyond cost savings. One of which is the morale & job satisfaction of the Dev team. Developers universally report that in their ideal work environments, they want to be working on important and challenging tasks. Where they have the best chance of learning things along the way.

So Low-Code can reduce the time they spend on these less interesting tasks. Because you can’t make the tasks go away. The answer is to use a tool that lets you get more done in less time.

More accuracy and happier teams

The hidden part of all this is the organisation’s abilities to utilise No-Code/Low-Code and adapt to it.

In terms of moral & satisfaction, there is clear evidence that the most onerous of tasks are the organisational ones. Like storing names & levels of permission on an API, in the case of ApiOpenStudio. These often have a high cognitive load because they require high concentration but they are in no way interesting. Low-Code solutions come with User Interfaces and Dashboards and these reduce cognitive load and risk in these tasks by making the tasks simpler and providing ways of validating your entries are correct and making the editing/deleting of changes easy. So there are huge benefits in day-to-day operations.

Learning a new technology and skill can also be fun. As we know, the primary driver for nearly all employees and their job satisfaction are:

  • Confidence in the leadership team.
    • Implementing Low-Code in a balanced way will demonstrate that the leadership have a forward-thinking mentality.
  • The employee is valued.
    • Providing training in the new technology and processes will show that the business wants to keep them and invest them.
  • Satisfaction with daily tasks.
    • The employee will feel more satisfaction through more responsibility and seeing their work being visibly used.
  • Learning and growth.
    • We all want to grow and extend out knowledge and usefulness, with the additional benefits of making us more desirable to employees.

(InfoSurv Research 2012, What Are the 4 Top Drivers of Employee Satisfaction in 2012?, viewed 17 October 2021, https://www.infosurv.com/what-are-the-4-top-drivers-of-employee-satisfaction-in-2012/):

Governance

With the decision to introduce Low-Code platforms, your first issue should be governance and compliance.

Your “Citizen Developers” and Project Managers should start to deepen their communication and feedback loops. Most importantly, non-technical people have to really feel they can come to the experts with the most basic questions, even if it is just to check they are on track. This is all new to them and they are not professionals in this sphere.

Because deep, first-hand knowledge of requirements is another advantage that citizen developers brings to the table. It’s worth noting that their approach will usually be decided on the functionality that they want. The effects on governance or the rest of the architecture are normally the furthest from their minds.

So from a Project Management perspective, clear leadership is needed right at the start in setting out the processes needed on the project. So that features and functionality are plumbed in properly.

Communication

There needs to be clear communication between the citizen and Pro-Code developers (usually via the Project Manager), but this can also be direct. This will ensure that any requirements between the two teams are met and no-one is adding useless things to the system, or features that will slow down the system performance.

Once you have initiated a communications format between citizen developers and the development team, then testing and documentation can be mapped out.

Documentation

A clearly written and easy to access set of documents will be required by both your citizen developers and all levels of the development team.

This will ensure that:

  • Onboarding is quick and easy for citizen developers and they can quickly find answers to any questions that they have, without feeling overloaded by technical answers.
  • Managers and project management have access to sources of truth that enable them to answer any questions.
  • The Pro-Code developers are aware of the Low-Code systems and how they interact with their work.
  • Leaders of the development team can easily find a broad overview of the different systems, the interaction between them and the processes that have been implemented to govern them.

Quality assurance

Depending on the complexity of the No-Code solutions and their impact on the rest of the technology, it is very likely that extra guard-rails will have to be introduced. This will probably involve QA (quality assurance), the ability to import and export configuration, and the release cycles.

Even if the output of the citizen developers is content (for example: pages in a blog or CMS), there should be systems in place to accomodate proof reading and validating the look and feel on different devices. There are additional complexities here, if the content that the citizen developers create is all in a database and cannot be imported/exported – where will this be tested, how will it be released? Although this issue is usually solved by that specific technology’s community, time should be spent looking at the different solutions proposed to find the best solution for your organisation.

In the case of complex No-Code solutions that interact with the output from the development team, then these need to go through the full QA feedback loop. QA can then validate that the existing functionality is not broken and that the new functionality works as expected and different systems interact as expected.

What is important, is that that the development team should reach out to the management of the Citizen Developers, so that they can have the discussion with them about compliance and governance & how they must comply with the IT departments direction (and vice versa). This is often an issue in companies, where people directly report in their department, and are in effect silo’d from the other departments.

Moving into the era of Low-Code/No-Code enhanced Companies. 

The organisations that are going to maximise the benefits of this new wave, should already be initiating broad company-wide conversations. These will range deeply across all levels of the organisation. From the way that Pro-Coder work days and productivity will be enhanced to evaluating the advantages and disadvantages of implementing Low-Code solutions for specific tasks.

This will even permeate as far as hiring & the HR Dept. As you look to harvest the advantages of onboarding people in traditional roles that have these additional skills, or incentives for current employees who wish to acquire No-Code or even Low-Code capability. 

This is the conversation of the future for all companies that will succeed in this new era!

Are you hitting the low-code sweet spot?

by Johnin NewsLeave a Comment on Are you hitting the low-code sweet spot?

Low-code solutions, as part of your IT landscape, are clearly gaining continuous traction. Low-code now, actually has its own Gartner Magic Quadrant!

Whilst a survey by the other big gun: Forrester, has said that in 2019, 37% of developers in Forrester’s worldwide survey were using or planning to use low-code products. By mid 2020, they predict that this number will rise to more than half of developers.

In 2019, 37% of developers in Forrester’s worldwide survey were using or planning to use low-code products. By mid-2020, we predict that this number will rise to more than half of developers, thanks in part to a renewed push by Microsoft for its PowerApps, Flow, Power BI, and Power Platform products. Microsoft’s “free” and good-enough products will be adopted both in straightforward and sophisticated use cases and serve as catalysts for further growth — and consolidation — in the low-code market.

Finally, to complete the trifecta, CapGemini have now included low-code in their “Top Ten Trends. So all three planets are aligned.

Why You Need To Know About Low-Code, Even If You’re Not Responsible For Software Delivery

Forrester research found that 100% of enterprises who have implemented a Low-Code development platform have received ROI (Forrester 2019, Large Enterprises
Succeeding With Low-Code, viewed 23 June 2021, https://assets.appian.com/uploads/2019/03/forrester-tlp-lowcode.pdf).

But… As ever, a lot of what we read out there is a mix of genuine analysis and the marketing objectives of the company writing it. The question really becomes. Are your low-code strategy and applications hitting your “low-code Sweet Spot”?

What low-code solutions do you need & where? How big should you start with low-code? Who do they enhance? Also, importantly, where shouldn’t you use them?

It’s worth remembering that companies can go too far, trying to remove developer costs. Using low-code the wrong way or too widely can severely limit straight Jacket development options.

Developers and low-code

There is an ideal mix of 4 Key areas. That varies with each business & its development needs:

  • High level expensive developer talent.
  • Less experienced and lower cost developers.
  • The right people with skills to access low-code & no-code solutions.
  • What the industry is now calling “Citizen Developers” (keeping in mind they often know your business processes & requirements better than anyone).

Do you have the right low-code app in place? So your expensive front-end developers don’t have to hand the requirements of an API to an equally expensive back-end developer (who is juggling this with another task that is equally mission critical), even though the front-end Dev has little on that week & will move to lower value tasks.

Or to take advantage of the extra efficiency in the fact that they both no longer have to dedicate time to the communication of what the front-end developer wants?

Communications tasks are typically underestimated costs

With a low-code solution like ApiOpenStudio, front-end developers can go straight to API creation. This can be great if you need to even out the load in a team where they might otherwise be cooling their jets on less important tasks, where they have to spend time defining the API and then send it on to back-end developers to implement.

This flexibility and being able to quantify it is the key to tuning your low-code mix, as the team will become more efficient. 

Finally if they are both flat out, can a lesser developer or in the right environment a cross trained “Citizen Developer” with basic JSON or YAML skills be deployed? Ideally they should be close to the project and its requirements. 

Low-code enables members of the team closer to the requirements & product or project development to build and manage an API themselves. Using, and in many cases, replacing the time they would have used to communicate this to others with actually developing the product.

Equality does not exist in low or no-code

Low-code and no-code platforms exist on a spectrum. On one extreme, you have platforms offering very basic functionalities – i.e. simple form and logic creation, combined with rudimentary document automation capabilities. On the other, you have platforms allowing citizen developers to build large, end to end workflow solutions, encompassing features like e-signature integrations, multi-step approvals, email reminders and data management.

So time and thought needs to put into the use-cases that you want to address with low-code implementations. This will prevent you facing the, often frustrating situations that project or product managers, when developers reply “nope, that can’t be done” due to the limitations of the software.

The balance

Like just about all movements in IT that become long-term, there is still a lot more to it in terms of taking it to your business and marketplace than the initial Marketing Hype. The real sustainable change is almost always different and requires a deeper understanding of how things really work to make sure the rubber hits the road.

So what do you really need to consider to realise the value of low-code across an organisation? 

The fact is that low-code involves a trade-off, that is worth doing, but a trade-off nonetheless. 

On the one hand, low-code enables those closest to the product and business requirements to build what they need and build it faster. It eliminates layers of process and management… business units can, in the right environment, move forward without consulting IT. Low-code makes business Agility happen, as it changes how the business works with software.

HOWEVER…… 

The fact is, though highly effective for many businesses, with low-code, the MORE you use it, the more you straighten your development. That is the trade off. 

This is one of the reasons why pro-code (or pure developers) have little to fear from low-code. Though surveys show many of them fear this, it is not shown in the data. Particularly during the next decade, where Microsoft recently estimated that there would be a shortfall of one million developers in the USA alone. 

Being able to plan and resource your company’s low-code mix, as well as advise where it is not appropriate 
(like when your CFO thinks he can do all with low-code just to save money!!) is becoming part of the career skill set for professional developers.

How low can you go?

Low-code, by definition also enables Fast Followers. As they have a pathway to follow that is quicker and lower revalue. So I would think twice about ever letting your marketing dept tell the world how you got there.

We think it’s important to realise (after years of researching & discussing this market trend with stakeholders) 
low-code and pro-code do not cancel each other out. No organisation should aim to be one or the other.

So the “Democratisation of development”, like all of the most successful democracies… need good checks and balances. judges, oversight and impartiality in the execution.

Summary

So as you would expect, there are quantifiable :aspects to this:

Is it giving you enough power, while liberating you from increasing development cost? Due to the rising price of developers and the need for an increasing number of developers, as companies race to meet the demand for providing richer digital experiences.

Whole platforms for this is not the place to start, & may not be the place to go. But starting with something like API creation and management can reduce both cost of running the internal Apps, the outward business and web apps that the customer sees. In most cases, these apps will rely heavily on external feeds and there is a high benefit in the low-code approach to this.

Joining the API economy

by Johnin News, Technical1 Comment on Joining the API economy

We’ve all heard about the API economy and the extra revenue it can provide while increasing the network and visibility of the business. We will be discussing the processes and advice for how you would actually join the API economy.

Types of API’s

There are basically two areas of API’s:

  • Internal API’s that are never exposed to the outside world, and are generally intended for a micro-service architecture. The benefits and challenges of this will be discussed in a separate post.
  • Externally exposed API’s that offer data and services to 3rd parties. These can either be free or paid.

This post will deal with externally exposed API’s. Purely internal API’s are not strictly part of the API economy, these are services within the company.

Moving into the API economy

The decision to move into the API economy might require a cultural shift within your business, and one that can be that would be very beneficial. It is primarily a business decision, rather than being left solely to the IT department to find ways of using the data that they have collected for the benefit of the business. This is a good thing! It requires all of the business to get together and decide on what data they want to share, is there already enough data to share, what extra data and metrics need to be collected, how will this be collected, does the data need to be changed. etc.

Approach

I would recommend taking a top-down approach to this, rather than launching your IT dept into coding your great idea. The planning of this is very much a business decision, and each department should be involved at nearly every stage, as you move from project inception to meetings and discussions of potential merits of the plan and ideas this will spawn, through to final planning and execution.

This might require a cultural change in your departments, as the different departments start to think about what assets they have or can create to be added to the API suite. They will probably find that they need to change processes and approaches in order to fully embrace this.

REST APIs

Defining what a REST API can do is a separate topic for another post. But essentially, it is built on the rather convenient request types in a HTML request:

  • POST
  • GET
  • PUSH/PUT
  • DELETE

These allow for Create, Read, Update and Delete requests to be made over the API. If you want to impress your IT team, the acronym for this is CRUD. Thus, you can merely Read (i.e. GET) data or you can also Create (POST), Update (Push or Put) and Delete (DELETE) data.

GraphQL APIs

Defining what a GraphQL API can do is another separate topic for a post. But essentially, it is addresses one of the shortcomings of the REST structure: meta-links.

REST has a shortcoming in that you cannot specify data selection parameters and related items in the same request without a custom attributes in the query. So this leads to multiple round trips and requests, e.g. fetch all posts, then the for each post. Each of these items would then contain links for subsequent requests to fetch each things like comments or taxonomy terms for each post. This can significantly increase the data loading time.

GraphQL addresses this problem by allowing an API request to include data structure and request elements in it. Thus, you can fetch your data in one request.

Commercial benefits

Commercial benefits should be made to either make the API’s free or only accessed through a payment gateway and account access to the API’s. Once that is decided upon, Security and volume loads need to be considered. With the explosion of free and commercially driven API’s along with the massive increase in Javascript frameworks and headless architecture, traffic for the could potentially be high, so provision will have to made in the server architecture to be scalable. This is a huge topic for a separate post.

Thought should be made into what service you are providing to 3rd parties and customers:

  • What benefits will they get from these new data and service endpoints?
  • How easy will it be to use and access?
  • What will the format of the data be?
  • Will the customers require any customisation and tailoring to their needs of the services? For instance, Uber’s custom requirements from Google maps API’s
  • Is there a business model for customisation, etc?

If access to the API is going to be limited to paying customers or selected 3rd parties then access control needs to be implemented. This is where ApiOpenStudio and some other API frameworks come into their own. You can define users, departmental and account roles for individual users or groups and then define what access rights these roles have to individual API resources. Perhaps you only want to give a 3rd party Read access to specific data, whilst giving one of your departments full Create/Read/Update/Delete access to all or a subset of the data. Maybe your API model wants to enable a 3rd party or department the ability to control their own silo’d data – so that data would be private to them, but they would have Create/Read/Update/Delete to their own data and only they would have access to it over the API’s (with the exception of you monitoring the data for security, API request rates and data volume control).

Creating your APIs

Before you dive straight into creation of the API’s, you should also consider the API’s from the user’s viewpoint. How easy will they be to use, do they provide data in the format that is most easy for me to consume, how will I discover these resources, i there any benefit for me to create code to consume the API’s, what other competitive resources are out there, are they better?

Once you have decided on the basic API model that you want to provide, you can start getting down to the nitty gritty of defining each resource and what it will do. ApiOpenStudio, and paid-for-services like MuleSoft will allow you to import API resource definitions from Swagger. If the API resources need processing logic on the data before final delivery, this should be defined and created. This is very simple in ApiOpenStudio, it is designed specifically to make this quick and easy. Meaning you do not need to employ expensive developers who are experts in a specific coding language to implement them (which can also be a time costly exercise).

Once you are ready to go, you need to pay specific attention the marketing of the new API suite. If you just put it out there and wait for the customers to come in, it is almost certainly going to fail. It is very important to put thought into how you will let people and companies know about the API. Maybe an email blast to your customers, creation of a specific website for the suite to expose it to the public, blogging, getting listed in aggregate listings of API’s, etc.

WP Twitter Auto Publish Powered By : XYZScripts.com