ASAS 2015 Guestblog: Agile for non-development organizations

Agile is rooted in software development and so it is unsurprising that most agile thinking and working focuses on better ways of creating software. But there are many organisations that do not develop software themselves, hospitals and municipalities come to mind, what about them? These organizations face problems similar to the ones that agile practices seek to tackle.

If you take a closer look, you will usually find a few Really Large Applications that dominate the IT-landscapes of such organizations. In a hospital, it is the electronic patient record or the Hospital Information System (HIS). In a municipality, it concerns applications that deal with registration, permits, taxes, or the social domain. These really large applications are normally selected, acquired and deployed using a waterfall approach. Buying and implementing a HIS for example, is usually a matter of years, not months or weeks.

There are many smaller applications that surround these big ones – smaller in functionality, license fees and data stored. These are sometimes purchased in a similar fashion, but they can also be impulse purchases that were at some point dropped off at the IT-operations to be deployed and managed.

As a reaction, the operations department may start to dig trenches and put up barbed wire to keep unwanted applications out in an effort to avoid more unexpected changes because, as we all know, changes are risky and they cost money. This usually leads to frustration on both sides as the pace of change only accelerates. New applications are brought in, existing ones are updated and tied to one another. The technical debt piles up, change becomes harder and harder.

What can such organizations learn from agile methods and practices, if anything? At first glance, very little. After all, they do not develop software, but are stuck with what the market has to offer. Often, there are just a few suppliers that they can choose from. It’s take it or leave it.

One thing you can learn from agile development, is that when something is really hard to do, you should do it more often. In this case, changing an existing application is hard. The reflex is to resist any change and thus to create no-go areas in the IT-landscape. The counterintuitive, but more productive, response is to welcome change. There is a lot of methods and tooling available that helps ease the pain of changing an application. Keeping your test environment close to the actual production is a good start. Next, use tools such as Docker to make deployment easier. Monitoring tools help to quickly pinpoint a problem when it occurs. And who said regression testing was only useful during development? Creating an automated test suite for an application’s interfaces – both outgoing and incoming – can greatly reduce the pain when the application (or its neighbor) changes.

Another agile practice that can be really helpful in this context is ownership. An agile project has a product owner or an on-site customer, a business expert who is responsible for setting priorities and accepting changes before a product is released. In practice, it will be a rare occasion where a product owner-developer relationship can be established with a supplier of a Really Large Application. We are stuck in a seller’s market, after all. But when you look at the IT-landscape as whole as a system, there is much more that you can influence. Usually, there are owners for each application, but being the owner often only means that the license fees are booked on your budget. On the level of an IT-landscape, some organisations have an ‘information manager’, but it is often unclear what his tasks and responsibilities are.

The product owner of an IT landscape should be responsible for the direction in which the IT-landscape changes. As such, he should have a backlog for all intended changes to the landscape, one that is prioritized and can be subdivided in tasks that can be realised by IT operations in sprints. Needless to say, the two groups should work closely together. This means the product owner should work with the people actually doing the work, not just their managers.

And this is where it all comes together. If IT operations behaves more like an agile team, and information managers become product owners of the whole landscape, together, they may be able to simplify and improve a complex IT-landscape until change is no longer scary, but something to embrace.

About the authors

Gert Florijn is principal consultant at M&I/Partners. He has been active in software and enterprise architecture since 1992. His main focus is to assist organizations in getting and maintaining grip on (large) IT landscapes. Eelco Rommes is a senior consultant at M&I/Partners. He helps organizations to become more effective with architecture.

Gert Florijn and Eelco Rommes will be speaking at the Agile and Software Architecture Symposium 2015.