I work at SAP in a department called Innovative Business Solutions. We focus on customer-specific solutions.
This blog is my engineer's view on the development methodology that we're using. I'd like to generalize our approach a bit for you, while emphasizing Systems Thinking.
Do you remember what software development looked like 20 years ago? You started with a requirements engineering phase, then you wrote a specification that included a monolithic architecture. You started development using the waterfall approach. Nothing agile, no domain-driven design, no user experience, no Design Thinking, no DevOps, no microservices, no cloud.
In the past few years, our department has changed its development methodology, as has SAP and the industry in general. The first step was the introduction of Design-Driven Development (D³), which combined requirements engineering, UX, and agile development. Then we moved forward along the DevOps path.
We also created a special initial solution design phase - an Innovation Sprint. We use this phase to design the solution using Design Thinking elements. We don't have an innovation sprint in each and every project, but it has proven useful in situations in which we're dealing with an unclear problem statement or if there's no obvious solution to the problem. This is often the case in innovation projects.
If you're designing and building complex systems, the complexity will require some extra effort. Systems Thinking can help you address this complexity. Systems Thinking is a special way to think - a mindset - that you can use to design and handle complex systems. You can also find traces of Systems Thinking in software engineering, for example, in books like The Phoenix Project, Building Evolutionary Architectures, and Chaos Engineering. Design Thinking is one of the pillars of Systems Thinking.
If you combine Systems Thinking, solution design, architecture, build, and run, you'll get an end-to-end process for designing, building, and running software systems. This is called systems engineering. Since we're talking about software systems here, the more specific term is software systems engineering.
In some of our projects, we're facing high levels of complexity - for example:
You won't necessarily face all of these issues in all projects. But in each of these aspects, you'll have opportunities to contribute to the overall solution and to address the special challenges of your project. Here are some examples how to apply Systems Thinking for each part of the Software Engineering process:
Solution Design: In each and every project, you'll have to describe business context, business requirements, architecture, what's in scope, and what's out of scope. Using the systems lens, you're defining the context, purpose, structure, processes, and boundaries of the system that you want to build.
Targeting feasibility, viability, and desirability of the overall solution is a holistic approach to cover business targets, human factors, and technical feasibility all at once.
If you have an unclear problem statement or no obvious solution, you can use Design Thinking for problem-solving. This will help you define the problem and design the solution. You can also apply principles such as fail early fail often to support fast prototyping and iterations.
User Story Mapping (USM) provides an overview of the scope of the solution. You can use this approach to organize and prioritize the user stories connecting the solution design with the system development.
Architecture: This is closely related to the system's structure and might include sub-systems. And - as there are no entirely separate systems - there will always be a surrounding system. For example, this could be the enterprise that the system is built for. So this might entail alignment with an enterprise architecture.
Feedback loops are an important part of systems for measuring and controlling system behavior. Such loops must be designed. This includes metrics such as business metrics, experience metrics, usage metrics, fitness functions, or operational metrics. The second part of the feedback loop is the measurement. The third is to learn.
When engineering for resilience, for example, if you're dealing with a microservice architecture, you must ensure the availability of the single services. At the same time, you also have to address the system level so that a failure in part of the system doesn't take down the whole system.
Build, Run, and DevOps: Parts of the solution, such as sub-systems, UI designs, or user stories should contribute to the overall business value of the solution. Local optimization does not necessarily improve the whole.
Operations takes care of system runtime to ensure availability and healthiness of the system and components.
DevOps brings together build and run. It takes a lot of systems thinking to optimize the building and running of software systems holistically, such as the principles of flow, principles of feedback, and principles of continual learning and experimentation.
On the one hand, Systems Thinking is a mindset - a way to think. You'll have opportunities to use this mindset in software projects.
But there's another dimension to Systems Thinking. Your software projects will involve a lot of people with different roles and different mindsets working together. They'll all have different perspectives that are equally important for your project. What you can encourage, is a Systems Thinking attitude:
This attitude allows everyone to get involved and also aligns the team to work towards a common goal.
This blog is my engineer's view on the development methodology that we're using. I'd like to generalize our approach a bit for you, while emphasizing Systems Thinking.
Do you remember what software development looked like 20 years ago? You started with a requirements engineering phase, then you wrote a specification that included a monolithic architecture. You started development using the waterfall approach. Nothing agile, no domain-driven design, no user experience, no Design Thinking, no DevOps, no microservices, no cloud.
In the past few years, our department has changed its development methodology, as has SAP and the industry in general. The first step was the introduction of Design-Driven Development (D³), which combined requirements engineering, UX, and agile development. Then we moved forward along the DevOps path.
We also created a special initial solution design phase - an Innovation Sprint. We use this phase to design the solution using Design Thinking elements. We don't have an innovation sprint in each and every project, but it has proven useful in situations in which we're dealing with an unclear problem statement or if there's no obvious solution to the problem. This is often the case in innovation projects.
If you're designing and building complex systems, the complexity will require some extra effort. Systems Thinking can help you address this complexity. Systems Thinking is a special way to think - a mindset - that you can use to design and handle complex systems. You can also find traces of Systems Thinking in software engineering, for example, in books like The Phoenix Project, Building Evolutionary Architectures, and Chaos Engineering. Design Thinking is one of the pillars of Systems Thinking.
Generalization¶
If you combine Systems Thinking, solution design, architecture, build, and run, you'll get an end-to-end process for designing, building, and running software systems. This is called systems engineering. Since we're talking about software systems here, the more specific term is software systems engineering.
Using Systems Thinking in Software Systems Engineering¶
In some of our projects, we're facing high levels of complexity - for example:
- Unclear problem statements and no obvious solution: An example would be a request like this: "We want to do something with machine learning to increase the efficiency of IT ticket handling." It would be quite difficult to write a backlog or give an estimate for the project size. The problem statement must be refined. This requires discussions with the people involved in the business, as well as some design and validations of the machine-learning scenario. There's a need for a solution design.
- Complex projects: We have some programs that span several sub-projects. In these programs, it might be not sufficient to deliver only the sub-projects independently of each other.
- Microservices come with a complex runtime, as there can be many services and service instances. Resilience is one of the topics that must be addressed. The failure of a single service should not lead to a system outage.
You won't necessarily face all of these issues in all projects. But in each of these aspects, you'll have opportunities to contribute to the overall solution and to address the special challenges of your project. Here are some examples how to apply Systems Thinking for each part of the Software Engineering process:
Solution Design: In each and every project, you'll have to describe business context, business requirements, architecture, what's in scope, and what's out of scope. Using the systems lens, you're defining the context, purpose, structure, processes, and boundaries of the system that you want to build.
Targeting feasibility, viability, and desirability of the overall solution is a holistic approach to cover business targets, human factors, and technical feasibility all at once.
If you have an unclear problem statement or no obvious solution, you can use Design Thinking for problem-solving. This will help you define the problem and design the solution. You can also apply principles such as fail early fail often to support fast prototyping and iterations.
User Story Mapping (USM) provides an overview of the scope of the solution. You can use this approach to organize and prioritize the user stories connecting the solution design with the system development.
Architecture: This is closely related to the system's structure and might include sub-systems. And - as there are no entirely separate systems - there will always be a surrounding system. For example, this could be the enterprise that the system is built for. So this might entail alignment with an enterprise architecture.
Feedback loops are an important part of systems for measuring and controlling system behavior. Such loops must be designed. This includes metrics such as business metrics, experience metrics, usage metrics, fitness functions, or operational metrics. The second part of the feedback loop is the measurement. The third is to learn.
When engineering for resilience, for example, if you're dealing with a microservice architecture, you must ensure the availability of the single services. At the same time, you also have to address the system level so that a failure in part of the system doesn't take down the whole system.
Build, Run, and DevOps: Parts of the solution, such as sub-systems, UI designs, or user stories should contribute to the overall business value of the solution. Local optimization does not necessarily improve the whole.
Operations takes care of system runtime to ensure availability and healthiness of the system and components.
DevOps brings together build and run. It takes a lot of systems thinking to optimize the building and running of software systems holistically, such as the principles of flow, principles of feedback, and principles of continual learning and experimentation.
Systems Thinking attitude¶
On the one hand, Systems Thinking is a mindset - a way to think. You'll have opportunities to use this mindset in software projects.
But there's another dimension to Systems Thinking. Your software projects will involve a lot of people with different roles and different mindsets working together. They'll all have different perspectives that are equally important for your project. What you can encourage, is a Systems Thinking attitude:
Use the systems lens and try to improve the whole.
This attitude allows everyone to get involved and also aligns the team to work towards a common goal.
References:
- Thinking in Systems: A Primer by Donella H. Meadows
- Systems Thinking – Managing Chaos and Complexity by Jamshid Gharajedaghi
- The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim and Patrick Debois
- The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win by Gene Kim and Kevin Behr
- Building Evolutionary Architectures: Support Constant Change by Neal Ford and Rebecca Parson
- Chaos Engineering by Chasey Rosenthal
- User Story Mapping: Discover the Whole Story, Build the Right Product by Jeff Patton and Peter Economy
created by:
| Editing: Ella Wittmann | Graphics: Emma Thoma | Contents: Erik Scheid
- SAP Managed Tags:
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 |
