As a Service

  • On-Premises Cloud: Real flexibility or just a finance plan?

    Conclusion: Paying for Infrastructure as a Service (IaaS) which is kept on-premises, but paid for on an Opex model rather than as a Capex outlay, is often positioned as ‘Cloud-like’. There can be use cases and specific workloads where this model makes sense and does give some advantages to the organisation.

    However, on-premises management of an organisation’s own Cloud can be lacking in the degree of flexibility and pace of innovation that can be achieved when compared to some of the larger and more successful public Cloud offerings such as Amazon Web Services or Microsoft Azure.

    Organisations need to weigh up specific use cases and workloads and determine the optimal balance of when to use ‘on-premises’ Cloud versus public Cloud.

  • Running IT-as-a-Service Part 19: The emergence of Cloud service brokers

    Conclusion: While the increased adoption of public IaaS1 can reduce cost and simplify technology procurement challenges, IaaS does not meet all IT organisations’ sourcing requirements such as legacy applications maintenance and IT service management. Hence, IT organisations are left with no alternative but to use multiple service providers to satisfy all their needs. This will increase clients’ governance cost of service providers and extend the duration of external services acquisition. As a result, a service broker model has emerged to provide one single point of accountability to all sourcing deliverables, simplify go-to-market strategies and fulfil the Cloud migration requirements in a cost-effective manner. IT organisations should assess the applicability of this model to their environment.

  • Running IT-as-a-Service Part 18: Creating service differentiation

    Conclusion: Forward thinking IT organisations wishing to create a service differentiation should analyse their value activities to construct a “uniqueness capability”. The outcome should convince business lines that IT services can generate business value at a competitive price. The value chain firstly requires to address service delivery processes by constructing the IT value chain1 , secondly to realise cost advantage2 and thirdly to create service differentiation (this note).

  • Running IT-as-a-Service Part 17: Realising cost advantage

    Conclusion: Cost advantage can be achieved by firstly, estimating the existing services costs. Secondly, use cost effective external services. Thirdly, integrate services. Fourthly, retain cost advantage. This can be achieved by removing duplicated activities and influencing cost drivers.

  • Running IT-as-a-Service Part 16: Constructing IT value chain

    Conclusion: Many IT organisations are perceived by their business units as high cost/low quality service providers. Much of this perception is due to the IT group’s inability to successfully articulate service value, demonstrate cost competitiveness, and create internal service differentiation. IT organisations should construct service value chain models to diagnose the IT organisation’s deficiencies, improve image, and link to vendors’ value chains. This can be achieved by disaggregating the business of IT into its strategic activities (e. g. service definition and communication, customer service). This will result in understanding the cost behaviour and identifying existing and potential differentiation sources such as accelerating the release of business products to market and improving IT and business lines interaction.

  • Running IT-as-a-Service Part 15: Traditional enterprise architecture is irrelevant to digital transformation

    Conclusion: While technology is becoming increasingly critical to business transformation, IT organisations are becoming less important to business stakeholders. This is because enterprise architecture practice’s main focus remains on back-office systems and on initiatives that do not necessarily contribute to business performance improvement and business cost reduction initiatives. IT organisations should revive the enterprise architecture practice by delivering IT-as-a-Service with an outward focus targeting business, information, applications, and infrastructure domains. This will increase IT organisations’ credibility to become key players in business transformation projects.

  • Running IT-as-a-Service Part 14: Digital transformation requires a new software release approach

    Conclusion: IT organisations should not be treating software releases to support the digital transformation as “business as usual”, because they may overlook the demand for extra-company IT management process integration, rapid application deployment, and speedy problem resolution. IT organisations should recreate their “release to production” processes to address the new applications’ unique requirements for appropriate security, resilient architecture, and elevated service level standards.

  • Running IT-as-a-Service Part 13: Maturing the business relationship function

    Conclusion: IT organisations establishing business relationship management to excel at coordinating business and IT strategic matters should assess the current maturity of this role. The rationale is to allow IT to deliver solutions that improve business performance, reduce the cost of doing business and mitigate business risks.

  • Running IT-as-a-Service Part 12: The evolution of Service Catalogues

    Conclusion: The Service Catalogue required by the ITIL framework has undergone several variations during the last 20 years. The rationale was to address the emerging service trends in in-house and outsourced modes of operations. However, while the original service catalogues’ objectives were achieved, they are inadequate in acquiring hybrid Cloud core services (e. g. storage) that should be delivered under outcome-based service contracts.

  • Run IT as a Service

    Many IT organisations are trying to change their perceived image from high-cost / low quality to value-added service providers. However, many of the adopted approaches revolve around improving just few processes (e.g. problem management). While these processes are important, they are insufficient to produce the desired effect for IT groups to deliver value-added services. 

    In this IBRS Master Advisory Presentation (MAP), IBRS outlines the high-level issues, surrounding Running IT as a Service from both business and technology viewpoints.This MAP is designed to guide and stimulate discussions between business and technology groups and point the way for more detailed activity. It also provides links to further reading to support these follow-up activities.

    The MAP is provided as a set of presentation slides,  and as a script and executive briefing document.

  • Running IT-as-a-Service Part 11: DevOps is not different from mature ITIL Release Management

    Conclusion: There is debate within the IT industry whether or not DevOps can replace ITIL1. From ITIL perspective, many IT organisations, especially in Australia, have been implementing ITIL processes since 1994 with significant investment in technology and professional services. Hence, it is impractical to just drop ITIL and adopt DevOps. This is because firstly, DevOps covers only Release Management which is only one process of the 26 processes of ITIL v3 and secondly, DevOps in not different from mature2 ITIL Release Management. In this light, existing ITIL organisations embarking on digital transformation should plan to mature Release Management to match DevOps principles. DevOps3 sites need to leverage the lessons learnt from ITIL implementation to enjoy a smooth business transformation as fixing only the software release process without integrating this with the remaining 25 ITIL processes is insufficient to raise the overall IT performance to the level needed by the digital world. This research outlines that ITIL and DevOps can co-exist in the same organisation once brought to the right maturity level.

  • Running IT-as-a-Service Part 10: Designing Practical Configuration Management Databases

    Conclusion: Since 1994 many Australian IT organisations have been implementing Configuration Management practices. However, it has been done with limited success when assessed against the key objectives of Configuration Management process and its associated database (CMDB) in terms of service availability and configuration items interdependencies. IT organisations should review their Configuration Management plans in view of the latest public Cloud offerings and adopt a phased implementation approach.

  • Running IT-as-a-Service Part 9: Significant ERP Maintenance Savings are real

    Conclusion: One IT-as-a-Service strategy remains to migrate legacy systems to SaaS to reduce cost, improve service level and achieve excellence in end user experience. However, large-scale ERP SaaS migrations are still not imminent, primarily due to the significant ERP customisation made by Australian organisations during the last twenty years, which prevent the use of standard SaaS architecture without re-engineering the business processes. However, it is worth noting that there are third party ERP maintenance and support services, which used in the short term may result in up-to 50 % reduction in the current yearly maintenance and support cost.

  • Running IT-as-a-Service Part 8: Governance processes critical for HyperCloud success

    Conclusion: IT organisations adopting IT-as-a-Service strategies tend to acquire the best of breed services from the market instead of building them in-house. This leads to increased adoption of multi-sourced services, whereby reliable governance processes are critical success factors to realise the desired business benefits in a timely and cost-effective manner.

  • Running IT-as-a-Service Part 7: Constructing Service Value Agreements

    Conclusion: in the publication ‘Running-IT-as-a-Service part 4’, IBRS defined how Service Value Agreements can be constructed by correlating business performance metrics with IT service levels. This note describes how Service Value Agreements can be constructed by aligning IT service levels with business service levels and processes. As a result, meeting or exceeding SLA targets will demonstrate the IT organisation’s contribution to business performance improvement and cost reduction undertakings.

  • Running IT as a Service Part 6: Managing supply/demand

    Conclusion: IT organisations adopting IT-as-a-Service practices are often challenged by limited resources to meet service demands, especially in the IT Operations space. IT operations groups should develop supply/demand models that link to business priorities and ensure funds allocation. These models will enable IT organisations to meet client necessities, clear workload backlogs, and set the foundation for effective resource management methods.

  • Running IT as a Service Part 5: Escrow your SaaS Contract

    Conclusion: with the increased adoption of SaaS for business systems (e. g. ERP), new SaaS providers continue to appear in the market. While those providers are offering easy-to-use products and low start-up costs compared to running in-house business systems services, there is a risk that some service providers might cease to do business. As a result, SaaS clients will be at risk recovering services on time and without data loss. To address this issue, several escrow services have been evolving. IT organisations wishing to migrate critical services to public SaaS should explore escrow1 services. Unfortunately, escrow service costs have to-date been fully absorbed by the buyer. In this light, IT organisations should incorporate the escrow services cost into the SaaS migration business case.

  • Running IT as a Service Part 4: Transforming from Service Level Agreements to Service Value Agreements

    Conclusion: Running IT-as-a-Service requires offering broad IT services tied to external-value that goes beyond meeting or exceeding SLA targets. This is because the majority of existing SLAs are IT centric and vaguely relate to business value. Much of this issue is related to IT Groups’ lack of business analysis skills and IT ad hoc methods to comprehend business strategic requirements. As a result, business lines perceive IT as a support function instead of being a strategic business partner.

  • Running IT as a Service Part 3: Preventing IT Policies from obstructing the Business

    Conclusion: IT organisations developing IT policies in isolation from business units1 will face challenges to tie policies to business drivers and limit policies acceptance rate. IT organisations should formulate policies by involving business units at an early stage in policy scope discussion. IT best practices2 should be leveraged to develop reliable and practical policies. The resources needed to develop the new policies should come from both sides and a business benefits realisation plan should jointly be developed and tracked.

  • Running IT as a Service Part 2: Business-centric IT Strategy

    Conclusion: Business-centric IT strategies are critical to run IT-as-a-Service1 because they attempt to integrate IT with business strategies. The rationale is to support business operations by implementing new technologies that reduce business risks, create business opportunities and achieve high levels of customer satisfaction.

    Business-centric IT strategies focus on addressing the business critical issues by implementing new IT solutions in a timely and cost-effective manner. The proposed IT solutions should provide capabilities that address the current and emerging market forces such as consumerisation, mobility, social media and Cloud. This will signal to business lines that IT is being modernised to meet consumers’ exigent needs.

    It is critical for business-centric IT strategies to be developed within two months to accelerate IT-as-a-Service transitioning.

  • Running IT as a Service Part 1: Prerequisite Building Blocks

    Conclusion: To improve business performance and/or reduce the cost of doing business, forward-thinking IT organisations are trying to run IT as a Service. However, they are challenged by long software implementation timescales, fragmented delivery processes and insufficient skilled resources to meet business demands.

    To address these challenges, IT organisations should emulate the commercial practices related to delivering quality IT solutions at reasonable costs.

  • Software as a Service - a way to try before you buy

    Conclusion: Software as a Service (SaaS) is gaining mainstream acceptance as a viable sourcing strategy for enterprise applications in both the public and private sector. IDC predicts that by 2015 24% of all new business software purchases will be of service-enabled software with SaaS delivery being 13.1% of worldwide software spending1.SaaS is being considered by many organisations as a means of achieving faster delivery times, cost reductions and access to innovative capability. In addition, organisations can exploit the SaaS model during the acquisition phase to reduce risk, improve business change management and test activities if they are prepared to move away from more traditional approaches and deal with organisation cultural issues. This paper focuses on the early stages of the acquisition process prior to contract finalisation.

  • Selecting a Software as a Service Solution - The "SaaSability" Questionnaire

    Conclusion: When selecting Software as a Service (SaaS) solutions, IT managers should demand evidenced from SaaS providers as the levels of service that can be expected using a formal framework. Including IBRS’s SaaSability questionnaire in requests for information will help to ensure that all parties understand their roles and responsibilities.