This article is part of our Essential Guide: Essential guide to application modernisation

An application ecosystem for the all-digital era

Digital disruption is forcing IT to adopt new operating models and CIOs must face the challenges it brings

This article can also be found in the Premium Editorial Download: Computer Weekly: Opening doors to open source

For the past 10 years, IT professionals have considered the configuration management database (CMDB) and configuration management system (CMS) the linchpins of service management.

CMS concerns mapping applications to infrastructure components. It is a management tool for business services and was created at a time when IT professionals built and ran infrastructure on-premises and a user device meant a laptop or desktop running Microsoft Windows.

This made sense in the context of key processes such as change, incident and capacity-management, and automated dependency discovery tools. But the CMS proved too slow for the complexity of applications and infrastructures in a dynamic and fast-moving environment. Numerous manual corrections and the very scale of the required reconciliation tasks led to very high resource consumption and high CMS project failure rates.

However, the effect of digital disruption on the business and technology is now at the core of technology management’s renewed interest in CMS projects.

To fulfil the business requirements of this digital disruption, IT managers have to pursue a dual agenda that includes systems of record and systems of engagement.

In the age of the customer – where you must tie together systems of record and systems of engagement to optimise customer experiences and business outcomes – the CMS has an expanded role. It needs to facilitate the evolution of systems of record and their integration with systems of engagement.

Read more about IT service management

CERN, the particle physics laboratory, is using IT service management to support operations outside the IT function

The UK's National Offender Management Service (NOMS) has ended a year of IT-led transformation, managed by interim IT chief Ben Booth

Traditional systems of record are typically a mix of in-house, enterprise-specific management software, often built from layers of legacy hardware and software. Systems of engagement, on the other hand, focus on interactions with people such as customers, partners or employees – first through websites, portals and e-commerce, and increasingly through mobile apps. While systems of record require care and support – consuming a large portion of the technology management budget – systems of engagement need innovation, flexibility and speed to keep the business ahead of the competition.

The need to acquire or develop more applications and the complexity of linking systems of engagement to systems of record means organisations must shift budget from maintaining systems of record to innovating in systems of engagement.

The CMS plays a critical role in reducing the maintenance and operating costs of systems and equipment. Reviewing the application portfolio forces the business and technology management organisations to determine what they’re actually using and which applications are redundant or replaceable by another technology, such as a cloud-based software-as-a-service package. It also prepares for application modernisation. The IT department needs to create a complete inventory of what was done and how it worked, if it is to prepare the whole technology management organisation for the all-digital era without major business disruption.

The CMS must change for application ecosystems

The CMS is the cornerstone of service management. But service management as we know it, and as defined by the information technology infrastructure library (ITIL), is fast becoming a thing of the past – or is at least in need of a serious revamping when you take into account infrastructure evolution and the focus on systems of engagement. Does this mean the CMS is obsolete? Actually, it just means that it has to expand to answer emerging problems posed by digital disruption, such as:

  • The use of hybrid and cloud environments. If you create the CMS with a quasi real-time ability to detect changes, you still don’t have much information when it comes to orchestrating applications into a different infrastructure, such as from a physical to virtual environment, or from a virtual to cloud environment.
  • The introduction of DevOps. Systems of engagement require rapid changes to applications delivered in small increments. Application-release automation requires data about items such as configurations and datasets that do not figure in today’s CMS.
  • The increasing use of microservices and containers. As modern applications evolve, re-usable services gradually shrink in size and scope from relatively large subsystems to smaller services that are easier to write, test and re-use. But microservices are too small to warrant a full virtual machine; and, without such isolation, they risk creating hidden dependencies. To solve this problem, containers such as those supported by Docker have exploded in popularity. Containers provide simple, lightweight infrastructure on which developers can deploy microservices.
  • The rise of composite applications. Platform-as-a-service offerings from leading cloud providers give software development teams foundational capabilities and rich sets of services to rapidly build and deploy complex applications with a minimum of coding. These platforms enable companies to build rich applications and focus on creating differentiating value, without having to create complex supporting software. This results in an explosion of many-to-many relationships between applications and services.

 A tall order for the IT department

Creating a CMS – especially in large organisations – is not a walk in the park. You should approach it with a serious project plan, an understanding of the limitations of off-the-shelf systems and reasonable expectations of the time and resources it will take. Most dependency discovery solutions today are based on a bottom-up process – but a top-down approach may yield better results. Why? Because starting at the critical business service level may make it easier to collect data, and you can approach CMS creation incrementally rather than trying to boil the ocean.

Based on a modern CMS, a service information system (SIS) adds data from diverse sources to create a business service ecosystem that condenses information from all corners of the IT organisation. Building an application ecosystem through the SIS forces the IT organisation to work together toward a common goal. Because information-gathering touches many aspects of production, it exposes many of the processes IT uses, and validates or invalidates their effectiveness.

If building a CMS and SIS sounds like a tall order to impose on the IT department, that’s because it is. Digital disruption is forcing IT to adopt new operating models in the near future. We need to move from a Jurassic period of IT – where each technology generation deposits layers upon layers of sediment – to a rational and competitive business technology that focuses on user value rather than technological prowess.

This article is an extract from the Forrester report The all-digital era requires an application ecosystem (June, 2015) by vice-president and principal analyst Jean-Pierre Garbani.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

We’re just now starting to examine both to determine how to best incorporate them into our existing infrastructure, so I’ll be curious to see how the problem of microservices and containerization are addressed.
Cancel

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close