Managing your application landscape: engineered or emergent

Application landscapesCompanies often have more applications than the business needs. This means IT is spending resources on legacy applications instead of focusing on business innovation and growth. This years Application Landscape Report published by Capgemini concluded:

One of the top priorities of today’s CIO is to build closer alignment between IT and the business. However to achieve this goal, IT first needs to deal with its own inhibitors to change. We have found that today’s application landscape is often more an obstacle to successful business and IT alignment than a testament to it. As a result, first and foremost, IT needs to review its approach to the application landscape and create long-term modernization and rationalization strategies while reaping early benefits as well. Only then can a proper foundation evolve on top of which better alignment between business and IT can flourish.


A while ago I wrote an article about how business agility asks for emergent architectures as a way to align IT with the business by creating flexible application landscapes. More recently I also wrote about the software platform an agile enterprise needs to support its business. Hopefully that’s all quite interesting, but as stated in the conclusion of the report, IT doesn’t seem to have the time and resources to think about these kind of changes. The first step a lot of IT executives need to take is to reduce their application portfolios. In Capgemini’s survey of IT executives, 85% of respondents state that their application portfolios are in need of rationalization. The question: how?

Application landscapes can be managed in different ways. For example, using Model-Driven Enterprise Engineering (it doesn’t have to be a model-driven approach of course, but that’s another discussion). I would call this the “engineered” approach, which can, in a simplified way, be characterized as:

  • Top-down: model the organization, define services based on the organization models, group the services in components, and implement the components.
  • Command-and-control: the architecture board / office decides on the application portfolio and steers the implementation choices.
  • Based on organization models: rigid organization modeling is needed to create a proper overview of the organization and to sufficiently be able to extract the needed services from the model.
  • Standardize on selected technology platforms: the architecture board decides what technology platforms are allowed to be used for application development.
  • Consolidate applications: do not let the business build to much applications, try to merge applications, consolidate on selected technology platforms, etc.

Another way to manage an application landscape is to use, what I would call, the “emergent” approach. This approach can be characterized as:

  • Bottom-up: the application landscape emerges from choices by individuals and business units.
  • Collaboration: applications, requirements for applications, and integrations between applications are created as a collaborative effort among people from different departments and, optionally, external providers.
  • Based on ideation and voting: applications are retired based on what their users think of them. Users can down-vote applications and create idea’s for new applications or extensions of existing applications. Based on voting within an internal social network top idea’s will be selected and unpopular applications will be retired.
  • Standardize on APIs: technology platforms don’t matter as long as they are flexible, ‘managed’ (either by the own IT department or by external (cloud) providers), and provide standardized APIs to allow easy integration and mashups (i.e. a focus on interoperability).
  • Grow application landscape: let the application landscape emerge from “local” choices. Focus on managing the process instead of managing the result.

These are just two examples of ways to manage an application landscape. It’s not an either-or choice, in practice you will probably use elements from both approaches (and more). These approaches probably are not feasible at all if they are followed literally.

Do you recognize the need for rationalization? What mix of elements would you prefer to use? How are you managing your application landscape or how do you think an application portfolio can be best managed?

Photo by M Atif Saeed

3 Comments Added

Join Discussion
  1. Igor Lobanov August 26, 2011 | Reply

    Isn’t it strange that report hasn’t mentioned plain old Application Portfolio Management technique? It is usually what you do to get insight into what actually needs to be rationalized, before even starting thinking about the actual engineering approach? It effectively makes the report look like a sales pitch.

  2. Johan den Haan September 3, 2011 | Reply

    Hi Igor,
    I expect the report to be a “sales pitch” indeed. Or better said: a content marketing strategy. However, it is always interesting to have some statistics based on actual market research.
    For the ones wondering what plain old Application Portfolio Management is: http://en.wikipedia.org/wiki/Application_Portfolio_Management

  3. Johan den Haan September 7, 2011 | Reply

    Read this article http://dontmindrick.com/socialmedia/it-spring-application-friend/ for a much more detailed vision on applying social aspects to application portfolio management. And yes… not all detailed ideas are practical maybe, but the general direction is interesting.

Leave a Reply