Infinite Architecture

Bob Martin coined beautifully in his book “Clean Architecture” that software – the products we forge from our imaginations to deliver value to other humans – can be described as a combination of behaviour and structure.

Behaviour

This is what the product does; ultimately it does something beneficial for a human somewhere, even if this is several times removed. It’s features, the benefits those features deliver.

Behaviour of the product delivers the value to the customer and therefore the business owners, and is quite rightly the main focus of software development.

Structure

The products shape, or its architecture. How the components; methods, classes, assemblies and services are inter-related. The mapping of responsibilities to deliver the functional components that combine to deliver the desired behaviour.

Every product has structure – very few have a “good” structure. Good structure allows rapid change with minimal cost, championing leaving options open and decisions late (more on this later).

Structure is often thought of and presented as flow charts in 2 dimensions. However, in most cases a products structure is actually a multi-layered 3 dimensional affair, very difficult to actually envision, to share and to design. This challenge to communicate structure and it’s importance (value) often means it falls to secondary “nice to have” objective.

In the short term, structure (architecture) appears to slow down software development. An apparent pointless activity adding effort and $$ onto a usually time constrained development process.

Behaviour over Structure

Commercial enterprises need revenue to keep the lights on. That means customer value is king; and for a start-up they need to return as much value as quickly as possible. The pressure to deliver function is extreme.

The sprint to sprint focus is customer value results, with many teams being pressurised to deliver function (behaviour) over architecture (structure). For many start-ups without technology at their core, these initial developers will also be contractors embedded with short-termism. They want their month to month contracts renewed, so they need to focus on delivering what the business wants, not what they need. In addition my experience is many developers (even Computer Science qualified) do not understand the concept or importance of architecture (structure) in software development.

This leads us to an industry full of products that have poor architecture. They cannot change – cannot evolve as the customer, the market and teams surely will.

Many times I’ve come to brown field products which were a hideous, convoluted mess. Change is very difficult or impossible to deliver. What’s probably worse is the business owners had no awareness that they owned a train wreck, completely unable to change until it’s too late.

Structure over Behaviour

Is it more important to have a product that does what the customer wants, but can’t change? Or a product which does not do what the customer wants, but can change rapidly?

That’s the question we’re asking when we are seeking to understand which we prioritise; structure or behaviour.

Last year I read Simon Sinek’s amazing book “The Infinite Game“, which I highly recommend. It inspired me in my technical leadership – and I think we have a lot to learn from his thoughts in the software industry.

As software developers we should create and maintain products which are designed with an “infinite” mindset.

To develop systems which are designed to be alive, maintained and competitive decades into the future.

Structure is the first and continuously the most important aspect of a software system. We should be focusing on the product being able to evolve and change with the minimum of cost, maximising ROI of the value being delivered to the customer (or user).

What’s next

I’m going to be posting more blog posts on this expansive subject. Whether you’re a business owner or a software developer, stick around to see how critical an “infinite architecture” mindset is to a successful technology company.

Being a CTO

When I started at Flipper back in October 2019 (feels like an eon ago now) I took the time to reflect on what it means to be a Chief Technology Officer / Head of Development based on my experience at Digital Forge.

Rather than picking up a book or looking at other peoples blogs, I did what I usually do – make something up. Ultimately everything humans do that’s worth a damn is “made up” by someone (and polished in the fire of failure!) so I’m good with that. It also fits with my personality profile on 16 Personalities of a “Logician”. I’m probably wrong in some way, but *shrug* I’m happy with the result of my musings.

I wanted something rooted in the Agile Manifesto at the heart of all agile frameworks, something that leveraged my understanding of the commercials of business, and something that ties in my understanding of the importance of systems that can change and evolve with business needs.

I’ve broken the role into 5 areas. If I was click-bait I’d put them on a separate page covered in adverts for making money at home, but we can be better than that. *<:OD

People

You may be surprised that I – of all people – start with fleshy meat bags. It is all about the people actually, the technology is secondary and detail. Motivated developers, who have fun doing their job, delivering high value, well designed change return a far better investment in terms of value to the business. There’s a mind boggling number of things to consider to create a motivated, happy, high performing team (or teams) – especially to someone like me – but it’s the core of what we’re going to achieve (and across the business I might add).

This piece boils down to team (fostering a high performance, cohesive, collaborative team), growth (couching and mentoring, personal development) and morale (getting up in the morning excited to come into work).

Enabling Change

This is what true agility looks like. Bonus points for naming the game 😀

Businesses never stand still – like a small mammal evolving 100 million years ago – if it stands still it’s dead. It’s incredibly important a company (and it’s product and services) can change as a result of the various influencing pressures altering it requirements / objectives. Even if we stand still, the market, regulations and customers never do… so we must be able to change, and sometimes rapidly.

Agile provides the framework from a process perspective, but that’s just 1/3 of the equation. It’s also the people (above!) and the technology.

From a technology perspective, change is about the architecture of the products involved; their shape – often multi-dimensional (those flow charts you get shown only cover one perspective) they should be designed with separation of concerns and SOLID at their heart. This reaches into development, change control, quality assurance and testing, CI / CD deployment and ongoing maintenance and support.

I’ll talk about enabling change in business across several other blogs, its a deep and interesting subject to me.

Return on Investment

Getting the balance right!

Certainly for service and technical industries, development and technology forms a large part of their operational expenditure. It’s really important what we spend our time doing is returning at least equal (and usually more) commercial value back to the business and crucially the customer. If it doesn’t there needs to be a damn good reason why not (strategic, long term goals outside the usual budget rhythm).

For me, a key part of this is prioritising work frequently (also know as constantly) and ensuring we’re recording the cost and value of change. We need to plan long term, seeing the “infinite game” to make sure we’re not working ourselves down a dead end, causing us more, far greater costs in the future (Technical Debt!).

Having a great relationship with the business and the customer is critical to figure out prioritisation of work and thus return on investment.

Another key part is optimisation and efficiency. That doesn’t mean squeezing every drop of effort from our developers, that’s a fools strategy. I mean making things slick, cost effective and fun for our teams. Chop out the unnecessary process and bureaucracy, review licence costs and processes on a routine basis. The sprint retrospective is a great example of this in action.

Operations

Handling general requests from the business, monitoring the service, raising BI data to the business etc etc. We need to make sure what we deliver is running well, as expected and the business has the data they need to validate their past and future decision making.

I must say, I love a good dashboard. Getting telemetry right is hard to do – but when it all slots into place to provide a tangible representation of your systems, they can just come to life in a way that gets the IT / developers really engaged and excited.

Maybe that’s just me.

Security & Compliance

The most boring part of the job. Sure, security can be fun – and it’s certainly part of the job creating robust, secure products.

Compliance just sucks – we usually have to do something because some third party is making us do it or the company would have to pay X; they seldom actually make sense alone, or don’t actually form part of our priorities if it wasn’t for the big stick waiting to clobber us with hefty fines.

I feel for those in Financial Services, where this is a big part of the job.

TLDR

Thanks for making it to the end – let me know your comments and the bazillion other things I’ve missed out! 😀