Software architectures in 2017

How the story always ends...

If IT development is a story, we already know the ending: create your own architecture. At least, this is the mantra (almost) all IT companies follow and impose on their clients. The decision to ’create your own’ is invariably justified by legitimate-sounding claims and crystallised by professional-sounding arguments.

For business people, these claims and arguments always seem too good to be true: frankly, they say, IT - for all its benefits - is a time-consuming, overcomplicated black-box, jealously guarded by the keepers of an arcane holy order.
And to be honest, they are perfectly right on this.

Allow me to be blunt and project the software development onto the world of aviation. A client wants to start a business: to carry people between cities and countries. Fair enough, you need: aircrafts, business partners, employees, to comply with regulations... millions of details to take care of.

IT is indispensable and is destined to give the tool such business can be launched: the aircrafts. But instead of renting or buying a proper and bespoke airships, IT takes to design, maintain and gadgeteer an aircraft.

Your first thought is correct: this is mental.

“Creation over adoption” is sold as gold, and we - IT people - really know how to sell our grand designs. We use overwhelming phrases to reach the sky and so we justify the man hours, the disruption, the expense, and the complication. But all the client just can not match the “high abstraction” and “advanced technology” with the situation seen:

  • Recurring and costly disruption from focusing on business logic
  • Widened field of testing / monitoring / deployment / training
  • Custom tools and processes leading to jungle laws
  • Heavy load on the devops team
  • Extra continuous development / maintenance cycles

It’s certainly enough headache to make a CEO wonder "Why shouldn’t I adopt instead?"

A new way...

In which case the IT people creating the company’s own architecture will most probably throw up their hands and say:

  • Adopted architecture means you can’t count it as an intellectual property asset in the future
  • Adopted architecture is second rate and won’t fit seamlessly into the company culture
  • Adopted tools might lead to bloated structures

Well firstly, source-code doesn’t hold its value – would you pay a dime for a ten-year-old architecture that was already out-of-date when it was released?

Similarly, if there’s one thing that’s second-rate, it’s out-of-date architecture – whether it’s ’yours’ or not is neither here nor there! Moreover, the messy building site and jungle laws of ’create your own’ clearly don’t fit in with any company’s culture.

Finally, regarding bloated structures, lets call out the elephant in the room here: only business logic can rise above the sands of time - the architecture never can (as Ozymandias found out).

Experience tells us that new things get old – and never more so than in the world of IT. In the era of the cloud, it just doesn’t make sense to buy something vast and clunky that immediately becomes old, when you can hire something that arrives fast and will always be cutting edge.

Following this path, I decided to start a series of articles about how a company can orchestrate a bespoke architecture fitting the way we treat infrastructure, version control or continuous integration. To distinguish it from ’Create your Own’ I’ve called it:

Architecture as a Service

It’s definitely a new way of looking at IT development and because it challenges some established mantras it’s going to be controversial for many…

BUT it promises a real win-win for developers AND their clients so I hope you’ll join me and read on…

Fancy to read more? Here is our blog:

comments powered by Disqus