So far I've described the components that form the Revenues part of the PILS formula. In this and subsequent posts I'll describe the components that form the MTB Costs side, starting with the Cost of Production bugs (CPB). Measuring the costs of fixing production bugs is important because CPB reduces the overall profitability of IT live systems and it's an indicator of the IT deliverables quality. For these reasons, our goal as IT leaders should be to reduce CPB. How could we go about it? In order to answer this question we first need to identify the causes that lead... Continue reading

In my previous article I started describing the various PILS formula components, by describing PBV (Perceived Business Value). In this article I will describe the other PILS formula component that represents the Revenues side of the formula: The Business Value of a CTB Project (BVCP). In order to understand BVCP one needs to understand what is a CTB project. In my book on <ALT+F> I divide projects into two categories when it comes to BVCP: Change The Business (CTB) Maintain The Business (MTB) CTB projects are new IT projects that the business see as revenue generators and/or games changes. Examples... Continue reading

In my opening article I introduced the ALT+F framework. In this article, I'll describe the first of the PILS formula components: PBV (Perceived Business Value). As a reminder, this is the PILS formula: PBV appears on the revenues side of the formula. It represents the business value the business perceives IT systems currently live are contributing to an organisation's revenues. Why perceived? When we think of IT systems, we can identify two categories: Those that directly generate revenue (e.g. trading systems) Those that provide a service (e.g. HR applications) When it comes to the first category, it's easy to identify... Continue reading

In my opening article I introduced the <ALT+F> framework as a tool to help IT leaders to streamline IT Operations. I discussed how the framework moves withing the MAPE (Measure, Adapt, Plan and Execute) lifecycle. In this article I'll describe ALTPD (Average Lead Time of a Production Delivery). This is one of the most important measurements in the Measure phase of the MAPE lifecycle. In a nutshell, ALTPD defines the average number of days that it takes a requirement to be delivered to production from the day it was requested by the business. Why is important? In order to answer... Continue reading

In my previous article I described the most common problems affecting IT performance. In this article I'll describe ScruXBan, a methodology that I defined while writing my book on <ALT+F>. I'll start looking at the most common Agile methodologies currently in use today, identifying pros and cons. I'll then describe ScruXBan as a possible alternative to those methodologies; an alternative that can help us improve the value we deliver the business with. When faced with the problems I described in my previous article, the IT community moved from pre-emptive methodologies such as Waterfall to Agile first and, most recently, Lean.... Continue reading

In my previous post I introduced the <ALT+F> framework. I mentioned how the framework moves withint the MAPE (Measure, Adapt, Plan and Execute) lifecycle. If, during the Measure phase, the <ALT+F> templates show poor IT Operations performance, the next steps in the Adapt and Plan phases are to identify optimal targets to achieve operational excellence and best-in-class status and then to set the stage for an Agile and Lean transformation strategy that should be executed on two levels: On the organisation level, the transformation strategy should educate people on both sides of the fence (i.e. business and IT) to what... Continue reading

After nearly 11 months, I finally published my book on <ALT+F>. The book kept me away from blogging for quite some time, but now that it's finished I've got a bit more time to blog. I'd like to restart my blogging by introducing <ALT+F>. This is a framework that provides Agile and Lean leaders with a tool to help the organisations they work for streamline their IT Operations. How does it do that? The framework follows the MAPE lifecycle, i.e. a cycle composed of the following phases: Measure Adapt Plan Execute In the Measure phase, the framework implementors use the... Continue reading

I've been working in Agile environments for almost 6 years now and I still manage to learn everyday! Recently, for instance, I came across one reason why story points are a good measure for planning. We had a list of stories whose complexity the team had estimated in story points; however because we were at the beginning of our release, there was a high number of unknowns (which we addressed by creating spikes). We use to divide a story in tasks and to estimate tasks in Ideal Engineering Hours (IEH); however due to the number of unknowns, we didn't know... Continue reading

Today I learnt something incredibly useful while reading Becoming a Technical Leader, by Gerald Weinberg. As Technical Leaders we are graded by multiplication rather than addition.Typically there are various dimensions to our grading, technical skills and the so called soft skills being two of them. Let's imagine that one is very good technically but occasionally has a bad temper. In grading terms, we could say that technical skills are graded at 80 and soft skills at 40. Firstly, the grade of this person is not 80 + 40 but rather 80 x 40 giving a 0.32 instead of 1.2.This becomes... Continue reading

In this last article of the series I'll show how to use the native JMX support within the JDK to implement a notification mechanism which alerts a listener when the HEAP memory is above a certain threshold. As discussed in my previous article this approach is ideal because is push instead of pull, is not intrusive and places minimal computing demand on your application. These are the key components to the solution illustrated in this article: MemoryWarningService: This component acts as a listener and registers itself with the Memory MBean to receive notifications. It is configurable with a threshold in... Continue reading

Hi, in my previous article I explained how to setup a JMX server through Spring and how to protect access to it through authentication and authorisation. In this article I will show how to implement a simple MBean which allows users to change the level of a Log4j logger at runtime without the need to restart the application. The Spring configuration has changed only slightly from my previous article to facilitate testing; the substance remains the same though. The Spring configuration <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:util="http://www.springframework.org/schema/util" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.0.xsd"> <bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations">... Continue reading

This is the first of three articles which will show how to empower your Spring applications with JMX support. Maven Configuration This is the Maven pom.xml to setup the code for this example: <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>uk.co.jemos.experiments.jmx</groupId> <artifactId>jemos-jmx-experiments</artifactId> <version>0.0.1-SNAPSHOT</version> <name>jemos-jmx-experiments</name> <description>Jemos JMX Experiments</description> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.8.2</version> <scope>test</scope> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.16</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>3.0.5.RELEASE</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>3.0.5.RELEASE</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-jmx</artifactId> <version>2.0.8</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <version>3.0.5.RELEASE</version> <type>jar</type> <scope>test</scope> </dependency> </dependencies> </project> Spring... Continue reading

This article shows *one* way to mock the JMS infrastructure in a Spring JMS application. This allows us to test our JMS infrastructure without actually having to depend on a physical connection being available. If you are reading this article, chances are that you are also frustrated with failing tests in your continuous integration environment due to a JMS server being (temporarily) unavailable. By mocking the JMS provider, developers are left free to test not only the functionality of their API (unit tests) but also the plumbing of the different components, e.g. in a Spring container. In this article I... Continue reading