About

Background

Nowadays in an IT profession it is sometimes difficult to stay innovative and progressive when your own company has reached a certain size. Especially when 2 decisive factors come into play:

• IT security
• A strictly regulated environment (such as exists in the banking and finance sector)

TL;DR

Trying to set up an IT business from scratch and documenting all the steps, ideas and pitfalls in this blog in a kind of diary. Positive side effect: A central documentation about this attempt is created implicitly at this point.

Reasons

Lack of right DevOps approach

Even if the DevOps approach is in place, it may not be applied properly. A tenet of DevOps is and always has been:
“You build it, you ship it, you run it.”

Unfortunately, in the company where I’ve been employed for almost 2 decades now, that’s felt as far away as the sun in the next galaxy. And I believe that is also the reason why we are now failing with it and have become less innovative & pragmatic, as well as lost significant speed in rolling out new features, which breaks the first two DevOps principle:
Customer-Centric action
Create with end in mind

Why is that? Well, one reason is that we as developers are not allowed to do deployments all the way into production. We usually have 4 environments (5 if you add the “local” one - why the “local” is in quotation marks follows shortly) - these are:

• developer integration
• quality assurance integration
• user acceptance integration
• production

So basically a very good approach to increase the quality of the delivered software with each change to the next environment and to ensure that the deployments are done in a controlled way and exclusively for the desired versions. In addition, the final production rollout requires an approval from the business department first.
But this is where the first problems arise. The development teams have sovereignty over the first two environments, and the operating teams have sovereignty over the other two. As a result, the deployment mechanisms sometimes differ between different stages, which violates another two fundamental DevOps principles:
End-To-End Responsibility and
Cross-functional autonomous Teams

And sometimes the sixth one simultaneously: Automate everything you can
Basically, almost all deployments work automatically, at least from environment 3, but since there is no guarantee that deployments in the previous environments will take place in the same way, nobody can of course prevent manual deployments from taking place as well nor that these deployments are done in the same manner like later in production.

In this context, it should be briefly mentioned that the entire procedure and process naturally involves additional organizational efforts that are difficult to quantify, but nothing happens without the appropriate tickets. Furthermore, there are corresponding committees that coordinate and approve the requested changes operationally and not to mention the documentation required for this. All in all, an uncountable overhead you won’t find in any startup or medium-sized company.

IT security restrictions (in the cage with handcuffs)

Another reason is that developers are more and more restricted due to IT security. Don’t get me wrong - IT security is super important, but you can’t just slam all the doors that were previously available to a developer and not offer any new ones, thus taking away all the artistic¹ freedom that is sometimes necessary in software development. When I started in the company the number of employees was somewhere between 200-250, of which about half or a bit more were employed in the IT area (software development, quality assurance, operating). Everything was family-like, we were disruptive, innovative, fast and had also made a certain name for themselves in the industry. With success comes growth and so the company has grown, meanwhile under a new name, to over 1200-1300 employees.

It is understandable that for this reason the requirements for internal IT security have increased and that the company generally has to deal much more with attacks on its own IT systems and needs to defend them more and more.
The regulated provision of hardware and desktop workstations for the number of employees alone required standardization and development was not excluded from this. So with a lot of effort, a solution was created that allows you to work on a remote desktop, which is generally not bad and is used in many companies, including the resulting advantages that cannot be denied - alone the onboarding of new colleagues is much easier like that, and you won’t need single IP based firewall rules exclusively for your own workstation anymore for example.
Unfortunately, it took more than 2 years for the development system to be so mature and set up that one could work with it. Nevertheless, as a developer, you still have to deal with significant performance losses compared to live on a local developer workstation or on a developer’s laptop. I don’t know if that is because the remote solution is a special setup provided by a global provider in that field or if the requirements for development, especially in a Java environment, were underestimated from the beginning. In any case, there is now a specially created team that only takes care that this environment works and that everyone can somehow work.

Remote working was also possible prior to the new solution and was done via VPN and typically using a company-supplied developer notebook. Developers were able and used to working with local devices and with all available power. Instead of only using the VPN connection to transfer data when needed (e.g. when pushing to the Git repository or loading internal pages such as those of the ticket or collaboration system), you now need the full bandwidth of the connection to transfer the remote desktop all the time.
Even if this is optimized by the proprietary protocol used, you notice the difference in graphics, response time of inputs and read and write access - especially with well-known build tools. And for the average PC user, that may seem bearable, but developers have a different DNA and a different aspiration.

Furthermore, all previously existing location-related solutions including servers which served for own testing, playground, scm, ci/cd, and publishing were centralized in the company’s own data center, which is also positive by first hand and should have shifted responsibility to where it belongs - the operating of those systems. Unfortunately, this happened partly only. And through this, all development departments are dependent in some way when something doesn’t work anymore - and this often happens, unfortunately. In the past, one developer or team who felt responsible for a certain system² could quickly lend a hand and get the necessary systems up and running again to solve the issue. Now you need to open a ticket and wait until it gets solved - in the meantime you may not able to work on your current tasks.

So that said experimentation, minimizing waste and optimize speed and costs is almost impossible which leads to not being able to follow the fifth
DevOps principle: Continuous improvement

Too much overhead

The last reason I would like to go into here is the perceived ever-increasing overhead inside and outside of projects and work in day-to-day business like mentioned in the first chapter.
Everything has to be documented & discussed in detail, conference calls, meeting minutes, global guidelines, definition of each process etc. We are now at a point where extra project managers are being hired to manage the transition process and sending invitations which force you to participate in regular status calls. Personally, many of these things keep me from doing what I actually want to do and what I’m actually employed to do - develop, test and deliver software and eliminate problems with the help of IT or automate manual processes in the business.

Conclusion

Some years ago, a colleague recommended two books. The first one was “The Lean Startup” by Eric Ries, which describes how to build a new company based on lessons learned from leading startups and the hypotheses to first provide a minimal viable product (MVP) based on the offered framework in the book instead of creating big business plans in the first hand.
The second book was “The Phoenix Project” by Gene Kim, Kevin Behr, and George Spafford, three of the thought leaders of the DevOps movement. Basically, it’s a novel which explores how integrating development and IT operation teams of a company’s IT department can improve in working together and demonstrating how the DevOps approach can help an organization.
So, based on this knowledge and with the aim of proving that there is a better way, I am trying to start building an own small business and will describe all the steps taken here in this blog. Because I don’t want to sacrifice a large budget for this at the moment, I’ll try to realize the whole thing with minimal costs as far as possible. Most of the tools that help you with this and offer the possibility of collaboration are available online and usually offer a free tier, which should be sufficient for a 1-man operation at the beginning. So I will try not to use any hardware other than my laptop to develop, ship and run this business including publishing this site.

Thanks for reading.