BT

Directing complex IT-landscapes with Agile

| by Ben Linders Follow 25 Followers on Oct 14, 2015. Estimated reading time: 5 minutes |

Where many organizations use agile to develop IT products, agile principles and practices can also be applied for maintaining landscapes of commercial products. Gert Florijn and Eelco Rommes will talk about directing complex IT-landscapes in public sectors such as healthcare and local and national government organizations at the Agile and Software Architecture Symposium 2015.

InfoQ did an interview with Florijn and Rommes about why organizations that are not doing software development would use agile and which benefits they expect to get, examples of using agile in non IT development organizations, using agile to improve collaboration between suppliers and customers of IT systems, reducing the costs of IT operation with DevOps and the role of the product owner in this.

InfoQ: Why would organizations that are not doing software development use agile?

Rommes: Many organizations do not develop their own software but rely instead on what commercial parties have to offer. Typical examples are hospitals, municipalities and some government agencies. But just like any other organisation, these too have to deal with changing requirements. Perhaps it is not a question of "using" agile, but of becoming agile. How do you deal with change when you can hardly adapt the software you that work with?

Florijn: That’s a key point. We want to explore how agile principles and techniques can be applied in situations that involve maintaining (large) landscapes of (mainly) commercial products. How can the evolution of such a landscape be done in a more agile and reliable fashion?

InfoQ: Which benefits do they expect to get from agile?

Florijn: The main goal of agility is to provide reliable products that conform to customer wishes in a predictable way. If you zoom out from an individual system and look at a landscape of systems as a whole, this goal is very desirable.

Agile methods use highly disciplined processes with clear responsibilities for both customers and suppliers. In addition, there is a lot of attention for measurement, quality assurance and maintaining the technical soundness of the product. The key question is how we can scale up these techniques to a landscape level.

Rommes: At the landscape level, we are prone to think in terms of "maintenance", of keeping things up and running. But keeping things stable, hard as it may be, is not good enough anymore.

IT departments face ever more frequent changes. Upgrades to applications, new laws and regulations, user requests, partners that send or need other information. Often, these changes cause a ripple effect where even a minor change in one application causes problems in a number of other systems. A common reflex is to resist changes or at least delay them. We think that leads to a dead end.

InfoQ: Can you give examples of how non IT development organizations are using agile?

Rommes: Current agile processes focus on software development, either from a technical or a process point of view. There is a trend to use Scrum outside of the software business, EduScrum is one example. That is not what we are looking at, here. We are interested in how IT-intensive organizations can embrace change and become more agile. They cannot simply choose an agile method and apply it one-on-one. It involves cherry picking and learning by doing.

InfoQ: Do you have suggestions how agile can be used to improve collaboration between suppliers and customers of IT systems?

Rommes: In the markets that we are looking at, the suppliers have a strong position. When a Dutch hospital needs a new Hospital Information System, there are not that many vendors to choose from. That makes it difficult to assume a product owner role in relationship with a vendor.

Florijn: Within the organisations we consider you can actually distinguish two kinds of suppliers. The external vendor of solutions and the internal IT organisation that manages and maintains the systems. The customer-supplier relationship should be considered between the "business" and the internal provider. And the internal provider should (primarily) deal with the vendors.

The main reason for this is that the introduction of (new versions of) COTS-solutions has a far larger impact than just adding functionality. It has implications for more technical matters such as interfaces, data exchange, platform capabilities and technical skills. These issues need to be brought into the discussion with the business.

InfoQ: Do you have examples of how agile principles and practices, like DevOps, can be used to reduce the costs of IT operation in organizations that do not do IT development?

Rommes: One thing that you can learn from agile, is that you must do the hard things more often. If upgrading an existing application is a very tough job, the IT-department should learn how to make that job easier. If you look at DevOps, it teaches IT-maintainers to think like developers, and vice versa. Even if you do not do software development yourself, you can use the tools and techniques that developers use to make life easier. For example by automating every repetitive task. By testing ruthlessly. By deploying early and often.

InfoQ: Any suggestions on how a Product Owner role can be used to reduce the costs of IT operation?

Rommes: The role of product owner is hard enough in agile software development. For IT maintenance, it becomes even harder. The scope is broader, the stakeholders are even more numerous, with high stakes and opposing views. Still, establishing the product owner role at the right level in the organisation is essential. The product owner should take responsibility for the development of the IT landscape as a whole, setting priorities, breaking large projects into smaller changes where possible. An IT landscape needs a backlog as much as any system under development.

Florijn: In fact, we might need to think about the product owner as a (virtual) team/organisation. This means that product-ownership functions on different levels, but in a coordinated way. On the level of individual systems, the people responsible from the business side will discuss operational issues and coordinate changes. On a tactical level business people responsible for IT in sub-domains or departments are brought together. Here, changes with more cross-cutting impact can be discussed and decided upon. Finally, on a strategic level, decisions that affect the landscape as a whole are discussed and decided upon.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT