Return to site

Platform Rethinking

Stop reinventing wheels in digital innovation.


Ian H Smith 

The technology platforms that represent the foundation for digital innovation are rarely understood by business people, and it is usually up to tech people to decide what the 'stack' looks like, as underlying code and architecture for Web, mobile or SaaS apps.

Given the confusing, overlapping classifications of what underlies a technology platform in the cloud, it is very difficult to present a single, unbiased view of what represents optimal architecture or best practices, when considering digital innovation.

In this blog post I am asking both business and tech decision-makers to consider the advantages of our Platform as a way to significantly reduce time and effort in developing new Web and mobile or Software-as-a-Service (SaaS) apps. This is not an 'one-size-fits-all' tech architecture, but a menu of packaged elements.

Why Platform Rethinking?

I have called this blog post Platform Rethinking to emphasise a need to rethink tech infrastructure: to challenge some of the assumptions made on all sides of the fragmented business and tech communities who invest in, produce or consume Web and mobile or SaaS apps. This is an argument for applying our Platform as the starting point for digital innovation - versus reinventing the wheel by coding everything ground-up.

The 'programmer purists' that say Low-Code and No-Code Platforms introduce varying levels of 'technical debt' are raising key questions fundamental to performance and security of Web and mobile or SaaS apps. For larger enterprises in particular, these concerns are often a block to the adoption of a Low-Code or No-Code Platform.

So, ground-up development of new Web and mobile apps continues in the belief that it is necessary. This is outdated thinking. Worse still, many IT services firms who have built their businesses on billable people hours view prebuilt technologies as competitive. This is an extension of the age-old argument in IT of choosing between packaged software applications versus custom development, unduly influenced by a need to monetise an enormous 'bench' of expensive consultants.

Defeating Complex Thinking

In digital innovation there is a need strike an optimum blend of Code, Low-Code (and eventually), No-Code. This is simply an extension of creating the right balance between packaged and custom software, as in the past. But what enterprises should be wary of is Complex Thinking: the tendency of traditional IT services firms who need to maximise billable people hours.

In our view, billable people hours should be subjected to Lean Thinking. This means taking a critical view of what truly represents value-added versus non-value-added in a Value Stream related to a particular process, or service ripe for re-engineering through digital innovation. This is where a set of Reusable Components should always displace ground-up, syntax-level coding, but where this inherently means reducing billable people hours. Beware of conflicts of interest here!

To defeat Complex Thinking we prefer Design Thinking blended with Lean. If we take this blended approach further, we find that Lean, in the form Hoshin Kanri, is a solid way to translate ideas into timely, measurable value outcomes. Hoshin Kanri is two Japanese words translated as 'direction' and 'administration'. It is practised extensively in the automotive manufacturing industry, defined as:

"A method for ensuring that the strategic goals of a company drive progress and action at every level within that company. This eliminates the waste that comes from inconsistent direction and poor communication."

Platform Rethinking Applied

Inside our Design Lab, we have a great team of strategists, designers and developers who are immersed in the real world of creating Web and mobile apps. But we are not lone wolves. We work with Kony to deliver a world-class Platform for digital innovation based, on:

1. Code, Low-Code or No-Code

2. Design Method

3. Design Guidelines

5. Continuous Integration

6. Cloud Fabric

7. App Studio

8. Smart DevOps

#1. Code, Low Code or No-Code

The concept of Low-Code is more mature than No-Code, as complete Platforms. The pure No-Code Platform is some way from being available as an enterprise-grade solution. Since the real world suggests that we will be moving to a blend of Code, Low-Code and No-Code, our Design Lab argues for a tech architecture built on a solid Cloud Fabric (Kony).

On top of the Cloud Fabric is an App Studio: tools that allow any combination of Code, Low-Code and No-Code to apply, and designed for different types of users. This allows a broad community of users to collaborate: from 'hard core' programmers (Code) through tech-savvy IT analysts and developers (Low-Code), and in the future, adding so-called 'citizen developers' (No-Code).

The interplay between the Cloud Fabric and App Studio layers is where Kony provides a packaged solution in the cloud, categorised by leading IT industry analysts Forrester as a Digital eXperience Development Platform (DXDP). This is the Kony AppPlatform, comprising a backend Kony Fabric and frontend Kony Visualizer (the App Studio). This provides rapid, visual assembly of Reusable Components, Templates and Sample Apps and leads to an optimum blend of Code and Low-Code approaches to digital innovation.

Our ultimate goal is to see Code, Low-Code and No-Code as truly interoperable: selected by different users, according to their needs and skills, in a highly-collaborative approach to digital innovation. What we know for sure is that no single organisation can create all three approaches to building the User Interface (UI) and related Reusable Components for the Cloud Fabric layer. We see Radical Collaboration beyond the boundaries of a single organisation as key to achieving more for less in the pursuit of digital innovation.

So, in order to create or participate in a 'marketplace' for Low-Code or No-Code Platform and Reusable Components, at the very least, we need to adopt industry-standard approaches to ensure that all of the various Components (or Objects) of our Platform (and other apps) work together. Today, we see the Kony Visualizer as a solid foundation for the optimum blend of Code and Low-Code in our App Studio layer. As an ongoing part of our own Platform Roadmap, we want to introduce a No-Code capability that truly works for the non-tech 'citizen developer'.

#2. Design Method

A Design Method is essential as a foundation for capturing ideas and uncovering the truth about problems, challenges and opportunities related to digital innovation today. Design Thinking is key to this approach: simply meaning that we solve problems in a people-oriented way.

Our Design Method is expended upon in our blog post Design Thinking Applied. This is based on the five steps advocated by the Hasso Plattner Institute of Design at Stanford University (, and underpins everything we do in relation to Platform-based digital innovation.

#3. Design Guidelines

The maturing of Design Guidelines work well for Code-based Web and mobile app design, where we embrace best practices for user experience (UX) design.

This also relates to my blog post entitled Three Design Principles, comprising:

I. Meaningful Journey

II. Fierce Reduction

III. Progressive Disclosure

All of these Design Guidelines and Design Principles serve a foundation beyond Code-only approaches to Web and mobile app design. This is pragmatic Design Thinking for the ongoing development of the Low-Code and No-Code Platform options too.

I. Meaningful Journey

When designing a next generation SaaS app, the first thing to create is its journey: the path, steps or tasks that users will complete in providing a service, undertaking work or solving a problem. With Lean Thinking at the heart of the design, this means removing steps or tasks that are wasteful or unnecessary. Therefore, this journey must be a Meaningful Journey: from the moment a user goes to the login page, to the moment they logout, when the task(s) or work is done.

II. Fierce Reduction

When users get confused with SaaS apps, it's usually because what they are confronted with on a page view offers too many choices of what to do next. Often, there is no obvious place to go or action to take from a particular stage in what should be a Meaningful Journey. What's needed is a fiercely reductive mindset: a way to eliminate everything on each screen that distracts from any action at each stage.

III. Progressive Disclosure

When designing a Meaningful Journey and applying Fierce Reduction, it is better to have more clicks or swipes through pages of say, a SaaS app, than add too many options in any given page or screen view. This means that with a fiercely reductive mindset, you will have to engage in a trade-off between simplicity of page or screen view, versus the number of pages on a Meaningful Journey. This is ensuring that Progressive Disclosure is applied to Web, mobile or SaaS app design.

#4. Continuous Integration

Inside our Design Lab, we define Continuous Integration as regularly integrating code changes into the main Source Code Repository of our Platform and specific Reusable Components. This means testing the changes, as early and often as possible - e.g. multiple updates, daily.

The inherent advantages here are:

Continuous Builds: Building the latest release as soon as a change is made. Ideally, the delta between each build is a single change-set - granular, and therefore faster.

Automated Testing: The programatic validation of the software code maximise quality. Tests initiate corrective actions in a truly Agile manner.

This also relates to our Design Lab Scrumban method: the combination of the Scrum approach to Agile software development - underpinned by Kanban Boards, as left-to-right progression through all tasks attributed to creating and enhancing a new app.

Here we achieve clarity for Deliverables and Acceptance in each time-boxed iteration throughout an Engagement, when tailoring or extending our Platform. Each iteration is typically of two weeks duration, and, for those readers not familiar with the jargon, this is commonly known as a Sprint. All of this relates to Continuous Integration.

#5. Cloud Fabric

State-of-the-art software architectures has led to the creation of Containerised Microservices. This is where Reusable Components built with our Platform are packaged as 'containers', making them easier to manage inside the Cloud Fabric. Docker is the leader in this space, and is adopted by our Design Lab. We then move Reusable Components created with the App Studio through an AppFactory process, including Smart DevOps. 

Running Microservices as Docker Containers enables Web and mobile apps to become portable across many Trusted Cloud environments, including extensions to packaged Cloud Fabric, as described above. This also helps to reduce bugs through the Continuous Integration process applied in structured QA and production instances.Reusable Components built on React and Node JavaScript (.JS) and containerised on Docker is a well-established and straightforward approach.

#6. App Studio

The App Studio for our Platform is based on Kony Visualizer. This includes building blocks known as Widgets - ranging from simple buttons or input fields, to complex 3D images, featuring rotation and transform animations. Here is where we generate Reusable Components.

As we build new Reusable Components for our Platform offering, we increasingly see the commonality among many Objects: Orders, Payments, Coupons, Feedback, and Catalogue developed for our Restaurant Platform Blueprint also apply, for example, to our Fashion Platform options. Many other Objects, such as Login, Contacts and Accounts are universal to almost all Blueprints we have available now and in the future.

Our Design Lab team of strategists, designers and developers decided that the core technologies for our Reusable Components and Object Library should be based on a Microservices architecture and a combination of the Kony Visualizer and React ('frontend') and Node ("backend') JavaScript (.JS) technologies. These elements may be defined as:


In simple business language, Microservices are an approach to Web and mobile app development, where a larger app is built from a suite of modular, Reusable Components as services.


React is a JavaScript (.JS) library for building user interfaces (UIs) and is maintained by Facebook. React is well-suited to Web apps that require intense user interaction and changing data.


Node is an open-source, cross-platform, run-time environment that executes code on the serverside (Backend) and includes everything you need to execute a program written in JavaScript (.JS).

As we build new Reusable Components for our Platform offering, we are increasingly seeing the commonality among many: Orders, Payments, Coupons, Feedback, and Catalogue developed for the Restaurant Platform Blueprint also apply, for example, to our Fashion Platform options. Many other Reusable Components, such as Login, Contacts and Accounts are universal to almost all Blueprints we have available now and in the future.

#7. Smart DevOps

As tech professionals reading this blog post know, DevOps is short for 'Development Operations': meaning the combination of mindset, method, competencies and tools applied to 'operationalise' services related to mobile and Web apps in the cloud.

Done right, this is delivering the services at high velocity to shorten time-to-market; optimising our Platform performance, whilst minimising costs; and, ensuring that user on-boarding and related app reviews are positive experiences.

For our Design Lab, Smart DevOps brings together many things: the ability to define and create a digital innovations with our Platform that achieves an optimal path to timely go-live releases; an app built for scale, yet minimises costs of underlying Cloud Fabric and App Studio.

Our Platform includes the Kony AppFactory as an integral part of our Smart DevOps lifecycle.


This blog post is work-in-progress and I welcome feedback on any of the eight Elements set-out here in this Platform Rethinking we have undertaken in creating our Platform. The key points here (so far) are:

  • Code, Low-Code and No-Code all have their place in digital innovation, but what matters everywhere is the underlying tech architecture: open, standardised, modular, any cloud.
  • Design Method provides a solid foundation for turning ideas into tangible, timely innovations, where a people-oriented approach generates sufficient trust to truly understand challenges.
  • Design Guidelines ensure that best practices in user experience (UX) and user interface (UI) design inform the Code and Low-Code approaches to Web and mobile app development.
  • Continuous Integration results in higher quality code and a more responsive approach to fixing Web and mobile or SaaS apps - early and often. 
  • Cloud Fabric significant reduces effort, time and costs in executing digital innovation, leveraging prebuilt business logic and Reusable Components.
  • App Studio enables less duplication of code, through maximising deployment of Reusable Components and a state-of-the-art Microservices architecture.
  • Smart DevOps shortens time-to-market and optimises app performance, whilst minimising costs; ensuring that user on-boarding and related app reviews are positive experiences.
All Posts

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly