Conclusion: The Australian Institute of Management recognises that leadership and management will need to continue to evolve to keep up with technological innovation and globalisation. Whilst organisations are usually aware of the need to keep up with technological changes, they often struggle with the practical implications for management and impact on organisational structure. On the one hand operational management can increasingly be automated, and on the other hand the ability to build and lead high performance teams is gaining in importance. Having appropriate people in executive team leadership positions is critical.
Operations & Service Delivery
Conclusion: The intense focus on social media and related technologies and how it will influence organisations has increased in the last year. Nor will it dim. The catalyst for the change has emanated from four companies and their products which have significantly altered behaviour and interaction with technology – in particular with devices.
Business and IT executives wishing to understand the forces of consumerisation and social media (Social IT) and its impact within organisations need to look at the compound effect brought about by network connections between those four companies and how people connect with them.
Conclusion: A competency centre for Business Intelligence (BI) must have an active mandate and involvement from the senior executive to sustain optimised delivery of the organisational BI strategy. This leadership is a key factor in the ability to successfully deliver the initial benefits of the competency centre within a three month development period, establishing long term benefits.
Conclusion: Organisations that are still running Windows XP fleets are debating holding off a desktop refresh (to Windows 7) until Windows 8 becomes available. There are three key considerations to this discussion: product functionality, management, and licensing. In each of these three categories, IBRS concludes that there is no compelling reason to wait for Windows 8.
Conclusion: The challenge of servicing customers well through various channels and over many devices has added considerable complexity to operations. The blindness of monitoring how well the IT operation is working has been removed and now data flows in huge amounts. The principal goal is to provide high quality customer experience and not simply rely on dashboards to churn out machine data reports.
The skills of analysis and insight should be more keenly applied to the data in order to reveal and clarify the value of the data. How the reams of data can be used for an organisation to deliver a high customer experience remains the main task. Organisations that believe that solely monitoring data to support transactions will likely miss the significance of what the data can yield and strengthen their customer contacts.
Conclusion: Cloud computing has multiple dimensions that must be considered when analysing risk. The use of four key variables can rapidly identify the expected level of risk in a cloud computing scenario. These four variables – deployment model, geographic location of data, supplier arrangements and information criticality – can be quickly applied to assess the level of risk and determine a suitable mitigation strategy.
Observations: Cloud computing has long been obscured by media hype and vendor exaggeration. The reality is that cloud computing is many-facetted and its suitability must be considered in the context of the particular circumstances where it might be applied.
The commonly accepted definition for cloud computing from the American National Institute of Standards and Technology identifies five essential characteristics, four deployment models and three service models that apply to cloud computing.
Essential characteristics: The essential characteristics of cloud computing are defined as: on demand self-service; broad network access; resource pooling; rapid elasticity; measured service. These characteristics can be used to test whether a “cloud” service is truly a cloud offering or merely an existing service or product “passing off”.
Service models: The service models of cloud computing are defined as Infrastructure as a Service (IaaS); Platform as a Service (PaaS); and, Software as a Service (SaaS). These service models describe the range of offerings available – whether low level storage and compute (Iaas), application development and customisation (PaaS) or end-user applications (SaaS).
Deployment models: The four deployment models Private, Community, Public, and Hybrid describe the degree to which cloud computing facilities are held privately, shared with other interested parties, or accessed as a public utility.
Of these three components of the cloud computing definition – it is the deployment model which has the biggest impact on the level of possible risk. The deployment model introduces the organisational barriers which come with the attendant contractual issues of warranty and liability.
Key external risk factors in cloud computing: Along with the deployment model there are three other key factors that influence the level of risk in cloud computing. These are:
Geographic location: The use of cloud computing is greatly complicated by cross-jurisdictional issues. This boils down to whether the data will either be transmitted or stored within a single nation or sovereign entity, or cross over into other legal jurisdictions, either nationally or internationally. Trans-border data flows are subject to legislative scrutiny through government and regulatory instruments such as the Privacy Act and the Australian Prudential Regulation Authority. Also the laws of other countries outside of Australia can have an adverse impact on the security and privacy of data.
Information sensitivity and criticality: The sensitivity of information can range from: publicly available material; the personal details of individuals, commercially sensitive knowledge; or, confidential or secret government information. The more sensitive the information, the greater the risk that is exposed in a cloud computing scenario.
The criticality of information is also important – is the availability of this information critical to the operation of core business processes? What would be the impact if this information was unavailable at any point in time? Public cloud computing introduces a critical dependence on the network connectivity between subscribers and providers. Internal network problems or local ISP outages will cause cloud services to be completely unavailable.
Supply arrangements: The delivery of cloud computing services can be either directly, as internal facilities, or through the services of a third-party enterprise services partner. The use of such a third party requires contractual agreements which must effectively cover the complicated nature of cloud computing services. Issues such as promises, remedies, limitations and obligations must all be contractually treated in watertight but workable manner.
The use of the following four variables allows a high-level risk matrix to be constructed that can be used to assess the level of risk for a particular cloud computing scenario:
This matrix identifies three levels of risk
Low: Established business practise and low level of risk if normal due diligence is observed.
Medium: Acceptable business practise but heightened level of diligence required in managing risks.
High: Not common practice and extreme caution advised.
Treating cloud computing risks: The following steps are advised to mitigate the level of risk incurred in a cloud computing scenario.
Management: Ensure that entry and exit scenarios are explicitly defined and supported. Support for continuity of operations and visibility of compliance activities is critical. Service levels and more importantly remedies must be formally agreed.
Information governance: Ensure that data is openly accessible and can be transferred in bulk if need be. Ensure data confidentiality through appropriate separation or encryption where necessary. Data location should be disclosed – both at rest and in transit.
Security and reliability: Identity and access management must be thorough and apply at all levels – people, process, and technology. Physical security should be audited and compliance reports made available for inspection.
Applications and software: Standard development tools and technologies should be available. Application environments should support multi-user access and source control across the end-to-end code/build/test cycle. Configuration management of underlying application components and operating system resources must be clear to avoid surprise upgrades of dependent technology.
Use the risk matrix to identify the likely level of risk applicable to a cloud computing scenario.
Decide whether the risk can be mitigated, or cloud computing is not an option given the circumstances
Apply appropriate risk mitigation strategies.
Conclusion: Despite recent IT Shared Services (ITSS) failures in government, the global appetite for ITSS seems to continue unabated. Given evolving developments in the cloud, ITSS seems assured of longevity. It is thus important to understand its nuances, especially from a delivery perspective. Whilst tempting to think of ITSS initiatives merely as ambitious programs of work capable of delivering attractive savings, it seems that a scaled-backed, incremental delivery approach, though perhaps more costly and time-consuming than other methods, may result in more lasting and beneficial outcomes.
Conclusion: The instincts of greed and ambition can sometime blindside the architects of IT Shared Services (ITSS) initiatives. Thinking too grandiosely and without sufficient regard for the consequences of ITSS can doom such ventures from the outset. Conversely, taking more level-headed approaches, tempered by the honest counsel of those that aren’t necessarily management sycophants, can have the opposite effect.
Conclusion: The seemingly growing deployment of enterprise social media may add another layer to organisational communications and collaborative suites; or it may replace them altogether. At this stage definite judgement is not possible, given the varying feedback on usage, value and overall benefits.
Ostensibly these tools are being introduced to improve collaboration and productivity. Yet the evidence is not conclusive on those criteria. Nevertheless, it is not necessary to rationalise such deployments on efficacy criteria alone.
Conclusion: There is a perception that public sector organisations experience higher failure rates with IT Shared Services (ITSS) ventures than their private sector counterparts. While no definitive studies have confirmed this, it remains true that both sectors have a chequered history of success with ITSS. However, perceptions are skewed by the sometimes massive and very public ITSS failures that have occurred locally in the public sector. Curiously, many of these failures could have been averted by following some simple steps.