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.

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

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).

ButAs 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

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
Social media & sharing icons powered by UltimatelySocial
RSS
LinkedIn
Share
WhatsApp