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.

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, mobile or SaaS apps. This is an argument for applying a Platform Architecture as the starting point for digital innovation - versus reinventing the wheel by coding everything ground-up.

So, ground-up development of new Web and mobile apps continues in the belief that it is necessary. This is outdated thinking. A Low-Code Platform comes in many forms or degrees of Low-Code versus Reusable Code. This means at one end of the scale, making optimal use of 'drag-and-drop'/'point-and-click' use of 'Widgets', and at the other end, using Code in Reusable forms, as frameworks, or modular 'Microservices' and components. 

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.

Enlightened digital agencies and IT services firms know that they have to build business value beyond the maximisation of billable people hours. Just as many product manufacturers have to adopt the principles of Servitization (selling product 'as-a-service'), so too, services firms (including IT industry variants) must adopt the principles of Productization and generate more revenues from Reusable Components (created with a Low-Code Platform).

Defeating Complex Thinking

In digital innovation there is a need strike an optimum use of a Low-Code Platform with Code - underpinned by Design Thinking as the method of execution. This is simply an extension of creating the right balance between packaged and custom software, as in the past. But what enterprises and government agencies should be wary of is Complex Thinking: the tendency of traditional IT services firms who need to maximise billable people hours. This is a need to embrace Productization.

In our view, billable people hours for Code 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 (built with a Low-Code Platform) should always displace ground-up, syntax-level Code.

To defeat Complex Thinking I prefer Design Thinking blended with Lean Thinking. If we take this blended approach further, you will 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

Armed with a team of strategists, designers and developers, immersed in the real world of creating Web, mobile or SaaS apps you can deliver a world-class Platform Architecture for digital innovation based on:

1. Code, Low-Code or No-Code

2. Design Method

3. Design Guidelines

4. Continuous Integration

5. Business Logic

6. Studio

7. Smart DevOps

#1. Code, Low Code or No-Code

The concept of a Low-Code Platform is more mature than a No-Code Platform, as a complete automation enabler for digital innovation. 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 eventually, No-Code, I argue for a tech architecture built on a solid 'Business Logic', underpinned by use of a Low-Code Platform.

On top of the Business Logic is a 'Studio': tools that allow any combination of Code and Low-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 Business Logic and Studio layers is where a packaged solution in the cloud is categorised by leading IT industry analysts Forrester as a Digital eXperience Development Platform (DXDP). This combination of Business Logic and Studio and provides rapid, visual assembly of Reusable Components, Templates and Sample Apps and leads to an optimum blend of Code and Low-Code Platform-based 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 Business Logic layer. You can see Radical Collaboration beyond the boundaries of a single organisation: it becomes key to achieving more for less in the pursuit of digital innovation.

So, in order to create or participate in a 'marketplace' for a Low-Code Platform and its Reusable Components, then at the very least, we need to adopt industry-standard approaches to ensure that all of the various Microservices, components (or objects) of a Low-Code Platform (and other apps) work together. As an ongoing part of a Platform Roadmap, I then want to see the introduction of a true 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 you can solve problems in a people-oriented way.

This Design Method is based on the five steps advocated by the Hasso Plattner Institute of Design at Stanford University (, and underpins everything you can accomplish with selecting and using a Low-Code Platform for digital innovation.

#3. Design Guidelines

The maturing of Design Guidelines work well for Code-based Web, mobile or SaaS app design, where you can embrace best practices for User Experience (UX) Design.

This also relates to 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, mobile or SaaS app design. This is pragmatic Design Thinking for the ongoing development of the Low-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 Web, mobile or 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

I define Continuous Integration as regularly integrating code changes into the main Source Code Repository of a Low-Code Platform and its 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 a 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 you can achieve clarity for Deliverables and Acceptance in each time-boxed iteration throughout an Engagement, when tailoring or extending the Low-Code 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. Business Logic

State-of-the-art software architectures has led to the creation of Containerised Microservices. This is where Reusable Components built with a Low-Code Platform are packaged as 'Containers', making them easier to manage inside the Business Logic. Docker is a leader in this marketspace.

Running Microservices as Docker Containers enables Web, mobile and SaaS 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. In a taking a pure Code approach, Reusable Components built in say, React and or Node JavaScript (.JS) and containerised on Docker is a well-established and straightforward approach. You need the same level of transparency when using a Low-Code Platform to automate much of the work here.

Underpinning the development of Business Logic is Process Optimisation. This is where IDEF0 is applied: a method designed to model the decisions, actions, and activities of an organisation or system, and originally created by the US Air Force. This is part of a comprehensive method that over time, has been extended to:

  • IDEF0: Function Modelling 
  • IDEF1: Information Modelling
  • IDEF1x: Data Modelling
  • IDEF3: Process Description Capture
  • IDEF4: Object-Oriented Design
  • IDEF5: Ontology Description Capture 

What matters here is a seamless integration between Process Optimisation, Studio and Business Logic. There is no point to achieving a perfect visual notation of a Process (or set of Processes) if it is abstracted from the Studio-based design and development of the Business Logic. This integration is key, regardless of how the ratio of Code versus Low-Code Platform applies to the approach.

#6. Studio

The Studio for the Low-Code Platform must include building blocks known as 'Widgets' - ranging from simple buttons or input fields, to complex 3D images, featuring rotation and transform animations. Here is where you generate Reusable Components. As noted above, this must be seamlessly integrated with the Process Optimisation method (e.g. IDEF0)

As you build new Reusable Components for a Low-Code Platform offering, you will increasingly see the commonality among many Objects: e.g. Orders, Payments, Coupons, Feedback, and Catalogue developed for a Restaurant Platform Blueprint may also apply to say, a Fashion Platform Blueprint. Many other Objects, such as Login, Contacts and Accounts are universal to almost all Blueprints for Web, mobile or SaaS apps.

A team of strategists, designers and developers often decide that the core technologies for theReusable Components and Object Library should be based on a Microservices architecture and a combination of React or Angular ('frontend') and Go (Golang) and/or 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.


Angular is a TypeScript-based open-source front-end application development framework, led by the Angular Team at Google and enhanced by a community of individuals and corporations.

Golang (Go)

The Go programming language is an Open Source project, designed to make programmers more productive. Go is expressive, concise, clean, and efficient - with power compared to C, C++.


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 a Platform Architecture, 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 a Platform performance, whilst minimising costs; and, ensuring that user on-boarding and related app reviews are positive experiences.

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 Business Logic and Studio.


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

#1 Code, Low-Code and (one day) No-Code all have their place in digital innovation, but what matters everywhere is the underlying tech architecture: open, standardised, modular, any cloud.

#2 Design Method provides a solid foundation for turning ideas into tangible innovations, where a people-oriented approach generates sufficient trust to truly understand challenges.

#3 Design Guidelines ensure that best practices in user experience (UX) and user interface (UI) design inform Code and Low-Code approaches to Web and mobile app development.

#4 Continuous Integration results in higher quality code and a more responsive approach to fixing Web and mobile or SaaS apps - early and often.

#5 Business Logic significant reduces effort, time and costs in executing digital innovation, leveraging prebuilt business logic and Reusable Components.

#6 Studio enables less duplication of code, through maximising deployment of Reusable Components and a state-of-the-art Microservices architecture.

#7 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