How prefabricated technical foundations can deliver lower cost and predictable business solutions

This article provides an alternative approach to technical architecture. It considers whether the adoption of a pre-fabricated architecture may offer a better way to support the delivery of business goals as opposed to custom technical architectures.

This article assumes the reader has an understanding of what a technical architecture is and how it is a prerequisite for business application delivery.

What does construction and software development have in common?

We can all agree (I hope) that both construction and software development require solid (technical) foundations. Aside from this, it can be argued that software development is usually more like constructing something that’s never been built before: the first skyscraper, the Golden Gate Bridge, or the Hoover Dam. The requirements are unique, the pieces have never been assembled in such a way before, and there’s an inherent level of risk in creating something new.

Unlike construction, where there are multiple mandatory inspections by independent qualified parties to ensure that the foundations are built to specification, during software development, there is often no one to provide independent qualified assurance that the ‘right technical architecture’ has been designed and subsequently delivered.

By ‘right technical architecture’, I mean one where the architecture enables the business to meet their non-functional requirements around areas such as performance, reliability, and security, whereas the ‘wrong technical architecture’ is the converse of this.

Over my career, I have observed multiple instances where, close to go-live, significant architectural deficiencies were identified (usually during technical testing), resulting in the programme facing delays, additional cost, and some difficult conversations with stakeholders.

Why does this happen?

Technical architecture is usually designed with the right intent (i.e., to meet or exceed the non-functional requirements, i.e., performance, reliability, security, and scalability, etc). However, these good intentions don’t always lead to success because:

1. Technical architects approach each new assignment as though it has never been tackled before, or at least don’t reuse as much as they could/should. As a result, the technical architecture design is unique and usually consists of products & services that are unproven in combination, creating unpredictable behaviours.

2. Technical architects succumb to agreeing to exceptions without understanding or explaining the implications adequately to the business. This creates a precedent for more exceptions, and over time compromises the integrity of the end-to-end technical architecture. Think about construction foundations, if you keep drilling holes through them, eventually it will crumble. Technical architecture is often less resilient than a building’s foundations.

3. The technical architect’s prior experience and technical bias limit their ability to apply critical thinking to new patterns and approaches. As a result, they design and deliver an architecture that is a hybrid of old and new and does neither well.

Does Technical Architecture really need to be unique for each software development project?

There are still lots of good reasons why a unique architecture could be required; they include:

• Business requirements are unique. Not all businesses require their business services to be highly available 99.99%, support 100 transactions per second at peak, and comply with the same security requirements as ISO27001, GDPR, etc.

• Compatibility with existing or preselected hardware/software packages.

• Learnings from previous designs (after all, if we are building something new, why not apply lessons previously learnt).

• Implementation time & budget.

• The desire to future-proof.

• The teams’ expertise & experience.

• Etc

In the past, any number of the above will have led to unique architectures being designed.

Despite the above, there are areas of software development, such as Customer Relationship Management (CRM), which have evolved to such an extent that different organisational requirements are now broadly aligned:

This evolution has resulted in price erosion, but it still isn’t fully commoditised, as not all offerings are the same. However, we have reached a point in the evolution where it is rarely advantageous for an organisation to build a custom CRM solution or customise a COTS solution. Instead, when there is a mismatch of requirements, the organisation will align their business process to the software instead.

This evolution hasn’t stopped at CRM. The advent of cloud platforms, online processing, DevOps, Microservices, and SaaS has led to:

1. Non-functional requirements align across businesses. From direct experience, most businesses we engage do want to be available 99.99% of the time; support a high number of concurrent transactions; deliver an end-to-end user experience of less than 1 second; comply with ISO27001, GDPR, etc.

2. Automation has become the norm. In the past, hardware and software were deployed & configured manually. Today, we automate it all, simplifying redeployments.

3. Commoditisation of compute and storage.

4. Organisations choosing to adopt production-ready services deployed locally or operated externally as a service.

5. The general adoption of microservices.

Whilst there continues to be plenty of innovation and choice of products and services to adopt, it is however possible, (Midships are doing this), to design an architecture using a combination of SaaS and open source software that can be deployed to any of the major cloud platforms in a fully automated manner and that will meet (we believe) the majority of an organisations’ non-functional requirements as well as enforce microservice best practices.

We developed this approach to enable traditional banks to go digital without incurring the delays and high costs usually associated with this. This stemmed from working with Banks, where we found that they all had a common set of non-functional requirements and technology ambitions. However, similarly, they all facing architectural challenges which delayed their progress and added. This led us to develop the Midships Reference Architecture to support Bank Use Cases. From other discussions, it is now evident that this reference architecture will be relevant across industry sectors.

Could this approach of a prefabricated technical architecture better serve an organisation?

The following table examines some of the key pros and cons for an organisation to adopt a prefabricated technical architecture.

Of course, one could adopt a hybrid and use the prefabricated technical architecture as a starting point to accelerate the delivery and then customise it to meet specific needs. However, when considering this option, it should be approached with caution as it is likely to face similar challenges to those that occur when you customise a Commercial Off The Shelf product, such as a CRM solution, where upgrades become complex and support becomes limited.

What I believe this comes down to is a stark choice for the senior leadership to decide on between:

1. Certainty, low cost, less control, and compromise (as the business may need to amend some requirements/use cases)

   vs

2. Uncertainty, high cost, control, and no compromise.

What will you choose?

To learn more about what Midships is doing to simplify, accelerate and lower the cost of delivery, please contact me at ajit@midships.io or alternatively schedule a one hour free non-binding consultation here.

Ajit Gupta is a cofounder of Midships and has over 20+ years of complex delivery and architecture experience. All constructive comments & feedback are welcome.

Midships is a global, cloud focused consultancy with roots in Spain, India, Ghana, the Netherlands and England. We help organisations become cloud native in an accelerated, guided, low risk, value focused and economic way. We combine our deep technical architecture and product and cloud platform knowledge with our automation capabilities to create relevant products and services to accelerate our customers’ delivery whilst reducing cost and SME footprint.

Writer’s Overview

Ajit Gupta – Co-Founder & CEO, Midships

Ajit leads Midships Group’s transition from a specialist identity consultancy to a portfolio of autonomous, AI-native business units. He focuses on long-term business relevance through platform thinking, customer outcomes, and scalable operating models.

Short bio: Ajit is a strategic founder with deep expertise in IAM, platform delivery, and AI services, driving Midships’ expansion across Asia, the Middle East, and beyond.

📧 ajit@midships.io

🔗 LinkedIn: Ajit Gupta