Everything is a system

In my last article I mentioned 3 core principles of DevOps. Today I want to tell you more about the first principle: Everything is a system, even you.

Just accept it. Systems help to make things easier. Society is a system, a job is a system, you are a system.

A system is typically composed of other systems, and so on. So let’s just assume you’re a DevOps (i.e. a problem-solving system) in a SaaS start-up (i.e. another problem-solving system).

You solve problems for the start-up so it can solve problems for its customers.

Let’s magically remove office politics, social networking and idiots from the parent system (the start-up) and personal preferences from you (the DevOps) and assume both systems can use their full capacity to solve their respective problems.

For both systems it is necessary to know what their purpose is or you won't be able to identify the actual problems to solve:

The start-up’s mission is to collect the latest job-offers in a certain area and deliver them to interested developers looking for jobs. For this, it needs to collect the job-offers form somewhere else and provide a subscription service for their target audience.

The start-up hires the DevOps engineer to solve this problem. For the DevOps, the definition of the problem probably looks slightly different:

• Do we need user accounts?
• Do we need a database? Document-based or SQL? Hosted?
• Use a Framework?
• What language to write in?
• How to SSL?
• What about E-Mail?
• Cloud or on-premise?
• What about data protection and privacy?
• How to collect job offers? Scraping? Manually? Submission?

There are a few things you need to know to solve the business problem – and maybe you can’t deliver on all.

So here’s how a system works:

As a good DevOps you identify the constraints of your own system in regards of the problems it needs to solve and then do 3 things:

1. You optimize your own system so it can optimize the parent system (learn stuff)
2. You do this incremental and employ additional systems if needed (get help)
3. You always implement or prepare for automation (develop processes)

This is an infinite cycle as you will learn in one of the next emails.

Over time, you will incrementally describe your system and the parent system and you will get a better understanding of when, what and how to optimize. This helps on all ends.

Now leaving neverland, back to corporate real-world, where the systems you’re in are full of unrelated obstacles and theatre – where “doing as I want” is often superior to “solving the problem”.

It’s of course not that easy to ever get a glance at the bigger picture or a saying in how things will be done.

Yet, that’s how in DevOps you should percieve your environment. People are relying on the systems you’re taking care of - so the way you solve problems makes a huge difference for the whole system.

In the next articles I'll go over 2 more principles of DevOps that I believe are substantial to the role. Until then, have a fantastic week!