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 both 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 sky scraper, 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 in 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:
Technical architects approach each new assignment as though it has never been tackled before or at least don’t reuse as must 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.
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.
The technical architect’s prior experience and technical bias limits their ability to apply critical thinking to new patterns and approaches. As a result, they design and deliver an architecture which 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 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, SaaS have led to:
Non-functional requirements aligning across businesses. From direct experience, most businesses we engage do want to be available 99.99% of the time; support high number of concurrent transactions; deliver an end to end user experience of less than 1 second; comply with ISO27001, GDPR etc.
Automation has become the norm. In the past hardware and software was deployed & configured manually. Today, we automate it all, simplifying redeployments.
Commoditisation of compute and storage.
Organisations choosing to adopt production ready services deployed locally or operated externally as a service.
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:
a) Certainty, low cost, less control and compromise (as the business may need to amend some requirements / use cases)
vs
b) 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.
Comments