We’ve been blogging about DevOps earlier. We’ve done tons of DevOps projects. Still, it seems that the big DO-wave has just started to rise. This blog reflects from the ideas of the doctoral thesis by Marko Leppänen: Vanishing Point: Where Infrastructures, Architectures, and Processes of Software Engineering Meet and its references. If you feel that you need more than what this blog has to offer, then it is time to get serious and learn from the awesome thesis of Dr Leppänen.
Fast, cheap and realiable!
We all know the holy triangle of software project management. A certain scope of features delivered in a certain time produces a certain cost. Fast release means less features. While business needs to follow a fast changing business environment, long delivery times are unacceptable.
Need for speed has produced Agile methods
In Agile, small feature increments deliver constant value stream in a form of new software features. Small increments ensure a continuous value stream, enable a rapid feedback and create a tighter co-operation with the customer. A dream come true.
OK, sounds like a plan. I wanna be continuously agile. How hard can it be?
Speed is pronounced P-A-I
Process can mean anything. Here it means people and ways-of-working. You need the people with the right skills and the right mindset. And you need to empower them. When you have the right people, the process acts as a catalyst or blocker. In other words, you need ability from people and Kaizen from processes.
I’ve divided the Process into sub-chapters titled Culture, Testing, Decisions, Crossfit and Measure. Before going into those, let me draw you a pie diagram about it. OK, let’s make it two.
A situation where people do not have opportunity to coordinate, collaborate, or cooperate their work is called social debt. It is a parallel for technical debt at the organizational level
High speed of development is not enough alone, as the development also has to have a direction and quality
In the complex domain there are no right answers. Therefore, one needs a safe-fail environment
“Social developer” is an overarching concept, where tools, methods, and processes must be in line with each other
Increased situational awareness caused by the quick feedback improves developer motivation
The nature of the tools used for development, testing and deployment depends widely on the domain, technology stack, legacy and user preferences. Still, a continuous deployment pipeline from coding to deployment is required. Process and infra are interrelated, while infra is used as means to automate and speed up the processes. As you know, culture beats strategy. So, for example a cloud strategy is useless if the people disagree.
Infrastructure and process are interrelated
Architecture depends on the chosen tools and technologies. I’ve divided Architecture into sub-chapters Modular and Deployment. There is a reason I’ve taken the Deployment (infrastructure) chapter under Architecture. Keep calm and read on.
Technical debt leads to inaccurate time estimates and speed makes the technical debt visible
Continuous * (everything)
Continuous * provides numerous benefits. Fast delivery feels good at the both ends. Quick feedback increases situational awareness. Flow and visibility increases the developer and stakeholder motivation. Continuous * focuses the communication on what matters most. End users are measured on real-time, so there’s no need for error reporting. Developers can just commit, no need to inform anyone. Automation takes care of the process. Business owners dare to try new ideas, while proof-of-concept implementations are fast to deploy and self-evident to measure. Failing is fast and safe. Everybody are Lean and beautiful.
Remember PAI. Process, architecture and infrastructure are interrelated.
1. Have a well-automated deployment pipeline that is fast to setup
2. Have identical production and development environments (that are fast to setup)
3. Use fast communication and feedback channels
4. Be Lean
5. Don’t use the domain as an excuse. Speed is a state of mind