Information is as much an asset as technology and it often seems that the role of these assets is more important in terms of being toys for IT professionals to justify their existence rather than as essential components to support business operations. Incredible sums are expended on “good practice” for IT to create service models and architectures and to “implement” good practice—but the reasons for doing so are rarely represented by business goals.
For example, how many executives running an insurance business or a car assembly plant have said that IT really needs to “implement ITIL” or become ITIL certified or Agile or whatever is the new direction for IT?
That does not mean good practices and methods are unimportant. Instead, we have to realize that business executives do not care or want to understand what IT wants to “implement.” What they want is reliable and innovative IT. Therefore, the focus should not be on “implementing” a particular good practice or becoming certified, but instead on establishing the good practices that materially (and cost effectively) support improved service.
As IT becomes ever more complex, focusing on the bigger picture (why something is done and how it relates to the business) is more useful and effective than focusing on procedures.
Three Challenges for Service Modeling
Senior management information requirements are complex and often require external data even in a smaller organization. In large organizations, it is rare for the information required for business operations to be solely based on data under the direct control of the organization concerned.
Therefore, the first challenge when modeling services is to take on the significant task of data reconciliation from different areas within the same organization and then to reconcile with external data. Such external information may come from customers, suppliers, competitors and other organizations and influences. Since information is also an asset, no different in many respects from physical assets, it all has a value.
The second challenge concerns different types of applications ranging from large scale new systems, to ad hoc requests, to Agile developments of (mostly but not exclusively) web-based applications.
The third is the complexity of process types required by any one application. Processes that enable applications are often not entirely batch or entirely real-time/on-line, but instead a combination of the two.
Handling the Challenges
These challenges are exacerbated by the gap that has traditionally existed between management information design and information system design. Its impact on business usage of management data is reflected in consideration of “the data pyramid.”
Data types relevant to strategic planning form the major part of strategic level planning. Strategic plans are developed by senior levels of management who require data to help them set long-range policy and organizational direction. When systems are individually developed without concern for overall requirements, it is difficult to share data to meet strategic level needs.
A tactical level corresponds to second line management, or higher, and is primarily concerned with summary information, historical data, quarterly information, and year-end data and so on. For example, we might have a typical management information system which requires summary data from multiple financial systems (from various lines of business). However, the various accounting applications may have different data structures because they were developed over time or for different /new product lines. These differences mean that the data is not readily available to the overarching Management Information System.
The operational level (the base of the pyramid) requires very specific information for daily business activities. These activities may be supported by information systems that automate the basic business functions including accounts receivable, payroll, inventory and so forth. During development of a new information system, the ideal approach to the data design is to create it when the system is designed and in isolation from other systems’ data designs. The data designer would use the current technology available to develop the data structure. With this approach, the data for one system is most likely completely different from the data in another system. Consequently, where systems need to exchange data, this can only be achieved after more time is spent on data analysis, development and then maintenance of data interchange systems.
The Information Systems
Information systems (IS), the development assets that support the businesses of organizations, have a lifecycle. In the context of the strategic planning for information systems, this lifecycle has three viewpoints: plans, business view and technical activities.
The business view of services relates to planning and not to the technical activities that are involved in the IS system development lifecycle. The business view of services is even more remote from the ITIL world of the service lifecycle. Within the systems development lifecycle (SDLC), there is a progression from defining what information systems the business needs to how these services or systems are actually provided. In the world of the ITIL lifecycle, there is a general misunderstanding that an IT service is the same as business service.
For example, “on boarding” or “password resetting” are commonly described as business services. A better definition would be “IT services that support business operations” because business services are related to lines of business (LoB) and applications developed to support the LoB.
A Business Focus on Service Modeling
A business focus is achieved by analyzing the information needs of the organization, defining how these needs can be addressed by information systems and identifying the technology required to support the application portfolio. This also results in the business having a clear understanding of how the infrastructure is valuable to the business; it does not mean they particularly care, but they do understand the relevance.
In the course of this process, the organization has to decide on the policies (standards and rules) that are to apply to the systems and technology. The resulting IS strategy also considers how the systems are to be provided and whether applications are to be package-based or bespoke (made to order).
IT vendors have promoted the role of ITIL to the extent that one could be forgiven for thinking IS no longer exists. ITIL encourages IT to rise in maturity to a level where it (so it is believed) drives business. Businesses think otherwise; right or wrong, the business understanding of IT remains with applications (IS). Until IT and ITIL managers learn that IT mainly supports the business and that IT managers cannot dictate IT use without incurring outsourcing as at least a threat!
IT knows best what it currently supports and operates. But, without a specific analysis of the business, attempting to create an applications portfolio (and/or catalogue and/or CMDB/CMS) from the position of “what is already running” rather than “what should be designed and built” is difficult and prone to error—to say the least.
To structure the development effort, programs should be selected and planned to target a whole business operation. The corporate data model can help with the situation by identifying the information (current or required) associated with business areas in question and identifying possible interactions and overlaps between information systems within and outside the scope of proposed programs.
Program management is defined, in the OGC (formerly the CCTA) Program and Project Management library publications, MSP (Management of Strategic Programs) and Successful Delivery Toolkit as:
The selection and coordinated planning of a portfolio of projects so as to achieve a set of business objectives, and the efficient execution of these projects within a controlled environment such that they realize maximum benefit for the resulting business operations.
IT infrastructure is the hardware, communications networks and generic software needed to support the applications systems that in turn support an organization’s strategic and operational business objectives. The IT infrastructure must be planned to meet the new requirements of business programs as well as new technical circumstances as they arise.
A key concept of program management is that it helps organizations to ensure adherence to technical policies and standards through their active management:
IT infrastructure provision can be regarded as a technical matter to be actively managed within and across programs; and as a program in its own right
Knowledge, or more precisely Information management, can also be implemented as part of an infrastructure program which applies its own set of conditions on the infrastructure. It requires software to enable data to be effectively shared, controlled and accessed
Note that the creation of a service portfolio as promoted by adherents of ITIL (v3) would be supported if the assumptions about related business and applications requirements were modeled first; without the prior modeling, a service portfolio would at best be an IT(IL) exercise to attempt to define what already exists—not much use in an environment of change, business agility and “integration”.
Reconciling IS and IT: the Issue of Lifecycles
A modern IS development environment consists of a number of methods and techniques bundled together to help in the production of information systems to meet the organization’s needs. The development environment embraces the following lifecycles:
- Information Management
- System Development
- Project Management
- Quality Management
Each of these lifecycles interacts and overlaps with the others. The task of developing information systems involves the management of each lifecycle and, specifically, of the overlapping areas. It is the responsibility of the management of an organization to manage these lifecycles, even if the activities are outsourced to an external body.
Furthermore, in this context a “service lifecycle” as introduced by ITIL version 3 is part of the systems (applications) development lifecycle. Irrespective of politics, if the ITSM organization wishes to adopt a service lifecycle, then it must interact with the accepted design lifecycles; it does not replace them. ITIL is an excellent set of guidance for infrastructure managers; it is not guidance written by or for domain experts in information, system (SDLC), project, or quality management.
When wading in a pool of alligators, it is hard to remember that your first objective is to drain the swamp. When it comes to IT complexity, IT is a swamp and it is clear that we will use any tool or method that promises to make our lives easier. Most often the focus is on the minutiae despite the best efforts to look at wider pictures. Using the good (and bad) example of ITIL, excellent advice about planning, managing and controlling has been largely ignored in the race to become certified or to implement best practice processes and procedures.
Instead of focusing on managing incidents, assets or changes as a service, the focus is on implementing procedures. The same is true of many good practices in that the practice itself has become the goal rather than ensuring that all good practice efforts are in place to support cost-effective and appropriate support to the business by building services that do what is needed reliably, rapidly and without undue maintenance. Build better!