Performance as a Practice:  Expanding on the Performance Challenge

January 17th, 2016 by

You may have caught my recent article here which talked about the idea of a new year and old challenges. This broke down the disciplines within systems development and administration to three key regions which are:

  • Performance
  • Capacity
  • Cost

Since Performance was first on the list, I thought that was the ideal place to begin. Let’s imagine a system of any type or size to be our base to work from. It could be a small application which is a client/server app, or it could be a large-scale web architecture spanning multiple environments.

Whether your system is localized or monolithic or distributed across many regions, you will find that the fundamentals are the same. This is important for us to recognize because as we simplify the way we attack the problem, we will see that finding ways to improve performance with automation and more becomes just as simple.

Performance as a Practice

Performance is something that is measurable, and results in the delivery of a system or service. It can be a measurement of the system itself as a whole, or a component of the overall system. It can also be a process which interacts with the system. Let’s break it down a bit into these categories more and see what I mean by this.

Performance of the System

Policy_Admin_Component_DiagramThe overall system is measurable in how it can process input into output. This is ultimately what the system is, which is a machine (software or hardware) that takes input, performs some actions on it, and produces an output. Simplifying the view this way allows us to break it down much easier.

If you look at the core of systems architecture as a practice, this is how we document the system. We craft a UML diagram and define the flow of the system. Measuring the flow is the measure of performance. You may notice that this is also deeply entrenched in the Theory of Constraints that keeps popping up when you read a lot of my articles.

So, our first gate that is measured is the larger system. When we see a constraint in the performance of the system, it’s time for us to dive into the next under-layer to narrow down towards other internal constraints.

Performance of the Components of the System

Working at the macro level by looking at the overall system highlighted we have constraints. Clearly, the only logical step is to go into the system and find the bottlenecks within. Find the constraints within the interconnected systems inside the overall system. Most likely, there are data transfers, application handoffs, and many more points at which improvements can be made.

As we see more microservices architectures becoming commonplace, the ability to see the constraints and interactions will become simpler. Ironically, the performance will not be improved by microservices, but it will actually be a better design in spite of degradation of end-to-end performance within the system.

Having a logical view as well as the physical view of the system is very important. That UML diagram or a flow chart of some kind that illustrates the flow will also be the biggest help in knowing where we can gain from removing/reducing constraints.

Performance of the Processes Interacting with the System

Inbound and outbound interaction with the system is probably one of the biggest points that performance can be a challenge. Whether it’s processing large input and the overhead of CPU and memory while ingesting data, or the network latency moving data in and out of the system, or any of a number of other issues that could introduce performance challenges to the system.

While we may have the logical view seeming to be a small system on paper or in a Visio diagram, the reality is that there could be huge expanses of space and networks between components.

Systems Thinking for Performance

The need for Systems Thinking with regards to performance is of absolute importance. Performance of any system is entirely affected by its interaction with other systems. In a dynamic environment, that Excel spreadsheet and neatly printed Visio diagram on the cubicle wall just doesn’t give us the real picture.

In the next article on this, I’ll be diving into capacity as a challenge to help look at what a Systems Thinking approach is to capacity.

Image sources: ,

Leave a Reply

Your email address will not be published. Required fields are marked *