Software Engineering builds two Things

Software Engineering builds two Things

When we write software, we build two things.

The software that provides the business solution.

A software ecosystem in which the solution runs.

You'll need more attention to the ecosystem as time passes.

In the Beginning

Initially, you start with something simple: you have computation and storage (possibly located in the cloud, but it does not matter for this discussion). You use this to implement your business logic and provide a user interface generated by presentation either for web or mobile devices.

Article content
In the beginning, your ecosystem is super simple.

The ecosystem is super simple, and because of this, you hardly notice it. All your attention is spent on providing an excellent experience for your users.

Then, you decide you need authentication and authorisation and that containers make sense to help isolate the growing number of applications from one another.

Your ecosystem becomes:

Article content
ecosystem v2

And you attract more users. This is great.

To handle the additional load, you expand your technical infrastructure, and your ecosystem becomes:

Article content
Your evolved ecosystem to v3

You update your architecture with logically centralised storage and improve your configuration so that all of your services uniquely identify the API invocation (to help run down errors). You install additional services to centralise logs and put into place both run-time monitoring for better fail-over response and metrics so you can measure end-to-end performance.

These improvements do not provide new features; they enhance how you deliver them, enabling engineering to achieve more for the business in the future.

You Hire

By the time you get to ecosystem version three, you realise you have created a new system requiring full-time attention, one that cannot be solely looked after by software engineers.

Your software engineering team provides product solutions.

It would be best if you now had an additional team to maintain and develop the ecosystem.

The Future

As your business implements new features, you increase the demands on your ecosystem. Every feature asks questions about what you currently have in place.

Pay attention to your ecosystem to ensure your features are the best for your customer.

To view or add a comment, sign in

More articles by Huw Evans

  • The Joys of Caching

    Caching data can improve system performance. Let's take a look.

    1 Comment
  • Debugging and the Scientific Method

    The scientific method helps you gain knowledge [1]. You make an observation and test it with an experiment that shows…

  • Debugging

    This is typically how I go about debugging a piece of code: What is wrong? Reproducing the error Finding the source of…

  • Understanding Inconsistency with SUDs

    This article shows why inconsistency and latency are fundamental when building distributed systems and how PACELC and…

  • Smaller teams are more reactive

    On November 2 2022, I wrote an article on how I had recruited 12 new employees. This article covers what happened next.

  • Lazily filtering out non-Cats

    In a previous article, I discussed how to safely generate a list of subtypes from an original list defined on a…

  • Cats are not Dogs

    Who in life has not tried to do this? Trying to treat a list of Animal as a list of a subtype. This does not compile in…

  • Failure is a subtype of Success

    This article considers how to cleanly handle both the failure and success paths in code, taking a look at how Java's…

  • Teaching Agile gives student a fish

    Teaching a student or colleague agile software development or more generally agile project management gives them a…

  • Agile Manifesto #5

    The Agile Manifesto [1] states that the left-hand side of the following are preferred over the right-hand side:…

Others also viewed

Explore content categories