To maintain market competitiveness, a business needs to understand customer expectations and needs and then provide quality services (and value for money in some circumstances). The business must strive for continual improvement in the quality of its products and services while maintaining cost effectiveness.
Not much to worry about then…
Services and Applications
Services, comprised of applications (or development programs in some parlance), are the result of systems development that supports the business. Information services are provided when infrastructure and operations “receive” applications and run those applications (often in a structured set of dependent relationships) using computational power.
Generally speaking, problems arise because how the applications will run is not a question that springs to mind when applications are being developed. The resulting issues around high maintenance and change costs largely impact Operations, and thus IT service management “experts” have risen to preach taking over the role of designing services.
How they will perform this without knowledge of the business they serve (rather than of service operations) might, to most sane observers, seem to be something of a challenge. The reality is that developers and operations staff need to liaise more closely and not argue over turf wars that will not benefit the people paying for and reliant upon IT—the business.
A flexible information structure that serves all system needs and all levels of management requires vertical and horizontal integration of data. Different operational areas will use the same data in different ways but all require a common understanding of what the data means and how it should be defined. Therefore, it is important to build in the correct information structure during the business and information systems analysis activities of strategic information systems planning.
The coordination of these activities becomes manageable and sustainable to the extent that it is conducted following an overall plan. Or rather, it should be part of a plan. In many instances, it seems that the need-for-speed has caused many disciplines around planning to be discarded. The rise (and abuse) of Agile methods for example, or the ITILv3 world of “service design” are examples of good practices that are not always properly understood or practiced.
For example, there are widely held misinterpretations (or worse, complete misunderstandings) that have led to the belief that business systems can be built, tested and delivered much more efficiently without project planning, which is certainly not the view of those who actually built the Agile methods. Another misplaced belief is that business services can be built from service catalogs and related technologies, showing a lack of understanding of what a business actually thinks of as a service.
Appropriate plans can address prioritized renovations of current practice as well as more effective progression of future practice. As a result, service designs and delivery become more appropriate to business requirements and to the existing capacity for continual management.
A Strategic Direction
The definition of the future state of the IT services organization must be formulated by producing a strategic vision of the future, setting goals and objectives, and developing an IT service management (ITSM) strategy to achieve the objectives. The goals and objectives are (or should be…) defined in measurable terms.
The ITSM strategy should cover:
- The overall organization, its culture and business units or functions
- The customers served by the organization
- Its products and services
- Key roles and responsibilities
- Key business processes
- Business metrics, which may be based on performance management frameworks, e.g. the balanced scorecard.
An IT service portfolio is possible only when all components of the service can be identified and managed. Therefore, at the strategic level the first activity must be to involve the business(es) and developers. Before a portfolio can be created, the business needs to define (with the help of development and data professionals) what is often described as a Business Entity Model:
- The model must unambiguously describe business operations
- From this business operations description, a glossary can be derived that can properly describe the business functions and allows information requirements and data handling needs to be described
- The degree of interaction between applications and IT services can also be established and documented. At this stage, it is relatively cheap and certainly easy to carry out design changes that would be expensive (and time consuming) to fix later
- At the architectural layer, the design discussions become more complex. The data needed for each required business entity must be described and, at this point, the attributes of the data are described, effectively providing transactional data information
When the Business Entity Model has sufficient detail to allow decision making, data ownership or describe how databases should be designed, then the model can be placed under version control.
And at this point, a wider understanding of configuration management, not simply a technical focus on a CMDB, enables change to be controlled and managed more appropriately.
In essence, understanding that IT exists to support the business and business operations is the key to providing better customer services. IT is not there to implement ITIL or Agile or COBIT or any other “good practice” unless it is going to demonstrably and measurably improve support to the business. After all, who pays our salaries?