When it comes to building software systems and the development of different platforms and channels, there are many many moving parts.
With this in mind, it’s important that there is a common understanding of the tech, the entire tech product/system and its core components. This is useful not just for development teams, but also from a business investor and stakeholders perspective too. This is what architecture is to me.
Software architecture, in a way, is very similar to building architecture. When a building is done well, people don’t necessarily notice it, but if it’s done badly, it is visibly terrible.
The UK government losing tons of COVID patient data from their Excel spreadsheet is an example of software design going wrong. They really should have thought that one through and figured out the maximum size of a spreadsheet; it was terrible!
Understanding what components, tools and platforms to use
That’s one of the reasons why we put software architecture together in the first place – to give us guidance for what technical standards to be used. These standards can cover the lower level coding but also any tools, and platforms used and their limitations too. You need to know the pros, the cons and the limits of everything you could be using so you know the right technologies and methodologies to pick.
Understanding what components, tools and platforms you use, and if they will fit your functional requirements is a crucial part of good software architecture. But it’s the non-functional perspective that’s important too. Does it scale enough? Does it have enough resiliency built-in to handle unexpected changes? The main thing is figuring out how to balance the starting architecture with the grand vision.
It’s a collaborative process
One of the most important things to keep in mind is that there will always be changes that need to be managed and that architecture will continually evolve as part of this collaborative process. With this in mind, you need to be able to communicate the big picture upfront to your development team, so they know why we are doing what we are doing. By allowing that collaborative piece into the architecture process, you can evolve as you go along and be ready for changes when the need appears.
It’s key that you are not up in an ivory tower somewhere designing it all upfront, adn expecting the development team to follow every decision challenge.
Many times people will pick technologies and processes they already know and in a way that makes sense. It gets the ball rolling nice and quickly, but what they fail to do is anticipate the need for change. Try not to overthink it. You will always have to expect a pivot, especially if you have chosen an older technology or platform to get started.
Good software architecture takes into account those future changes and looks at the process from an agile perspective to plan for future development.
APIs and outer architecture
So make sure to think ahead, or at least have the flexibility to evolve when the time comes. An excellent example of using an agile approach to architecture is looking at APIs.
API (application programming interface) has been a bit of a buzzword recently. In its more generic form, it’s any form of programming interface towards a different programme. However, its more modern meaning is geared toward network communication or web APIs.
There are some really good reasons why they have become popular the more inner architecture level but what’s more interesting is the use of API in outer architecture. APIs are now part of the big world, and now you can collaborate on the software level with other services.
This is where APIs have become really useful. For example, Open Banking APIs drive standardization within the fintech industry, so you can now aggregate several services from entirely different providers of banking which gives a lot more value to the end customer.
Startups can start taking advantage of this too, using public APIs to build seamless customer experience, or expose their APIs as core part of their product. We see it a lot in the engineering community as well, like integrations between GitHub, Slack and other developer tools, and they drive a lot of innovations that way.
Are they a golden goose?
You can build a viable business proposition around APIs too. Some startups that don’t have flashy channels or mobile apple only have the API, and it almost functions as a product itself which shows how useful they have become.
It can be easy to think of APIs these days as this golden goose. They make things easier, better to design and allow us to collaborate with the whole world. However, they do have some scary features too. For instance, one thing about APIs is the dependence that they set up.
For example, if a startup decides they are going to publish an API, as soon as people start using that API, it becomes very hard to change.
Similarly, if you rely on a third-party systems’ API and the third party changes it or, worst case gets rid of it, you have to be prepared for that too. Also, If you do go down the API route, you now have to think about how to evolve and handle failure in a different way.
If one of the API components isn’t scaling as quickly as the others, you may encounter potential bottlenecks that you will need to handle.
Additionally, you may also open yourself up to potentially uncontrolled levels of usage, nefarious or otherwise so you have to build into the architecture of your company some monitoring solution to know when these APIs are becoming overloaded.
So APIs can be incredibly useful when setting up your architecture but make sure you are accounting for some of their dangers too and as we mentioned before, stay open to changes.
Cloud-native architecture – things to consider
These days, with tech advancing as quickly as it is, architectures are almost unrecognisable from the ones five or 10 years ago. Look at what the cloud has done to how systems are designed now. These days we have a whole new “cloud-native architecture” where modern startups are moving to straight away now.
We will be discussing more on the cloud in next week’s blog so I’ll give away no spoilers here – keep an eye out for it!
This provides considerable benefits to startups for many different reasons. For instance, these days, you don’t have to run databases. Instead of having something in the database that you query all the time, you can just update a static website frequently from your build stack. It’s evolved into a completely different way of thinking about things and will continue to do at an increasingly rapid rate.
But whether you use the cloud or not, every architecture should still be built with that scalability and robustness in mind.
The opportunity for startups and new tech products to go directly to the cloud means that we should be thinking a lot more about their pros and cons as part of your general architecture plan. Because in the cloud now, there are so many more moving parts than there used to be. It’s crucial you are identifying and managing the risks involved, or you may end up like our government. Don’t let your Excel spreadsheet fail in the middle of development!
Make sure you catch next week’s blog and episode 6 of our podcast for more pros and cons of cloud-native architecture.
Simple but flexible
Although we talk about a lot of complexity in architecture, a lot of startup architecture will be pretty simple. You’re not a good architect just because you bolt-on extra stuff to a building, right? It’s the same with software.
But simplicity doesn’t mean just sticking it in a box and not worrying about it. You’ve got to be flexible enough to separate things out. Design your architecture so that you can build and deploy different parts independently; that’s the most important part.
Also, be flexible. If you can think in an agile way upfront, it will make changes relatively straightforward to figure out and make. Along with that, keep in mind the communicative aspect, too. Make sure that your architecture demonstrates what it is not only to your technical team but to the stakeholders and board level. If it’s a vital part of the business, it needs to be understood on a wide level.
I think the best architects I’ve seen have been able to show the tech architecture in a way that a business person, although they might not understand how the system works, has a good level of understanding on what it does.
Basically, if you can draw it out on a 2D piece of paper without it looking like chaos, that’s a good place to start.
I hope you have found this useful. If you have any questions or would like to hear more about architecture check out episode 6 of our podcast, “From the Factory Floor” where myself, James and Eric go into more detail. Alternatively feel free to email me at aleksav@thestartupfactory.tech
