IT Operating Models

The Latest

01 March 2021: ServiceNow released the latest quarterly edition of its platform. 

Why it’s Important

ServiceNow provided the latest quarterly release in March 2021. In this version, called ‘Quebec’, ServiceNow has revised its support model and incorporated major changes to enable the effective upgrades from either New York, Orlando or Paris versions.

A streamlined support structure will help CIO and ITSM team on a ‘learn, prepare and upgrade’ model. 

1. Learn: Identify your upgrade path and consider the release highlights.
2. Prepare: Choose the tools to perform a risk and value assessment of the upgrade. Use the upgrade value calculator, the playbook to maintain platform health and a risk assessment of platform customisations.
3. Upgrade: Maximise the upgrade value by reviewing over 78 release highlights across core functionality, ITSM workflows, AI, asset management, security, risk and cost, customer and field service workflows, employee workflows ,safe workspace, and workspace service delivery

One of the big winners is the telecommunication sector, with enhancements to the product cataloguing, order management and open API’s to assist with alarm management. A new processing engine has been created to automate alerts and incidents.

Who’s impacted

• CIO
• ITSM functional Leads 
• DevOps leads
• Security Leads

What’s Next?

ServiceNow clients should set time to review the release notes for Quebec and consider the ‘learn, prepare and upgrade’ literature to determine whether they are ready for the upgrade. If so, plan and execute once the risks and value are clear.

Related IBRS Advisory

1. New generation IT service management tools Part 1
2. New generation IT service management tools Part 2: Multi-Cloud management
3. New generation IT service management tools Part 3: Multi-Cloud backup and recovery

Conclusion: The massive shift to working from home since the start of the COVID-19 pandemic has led to upsides for employees: more flexibility, no commute and greater productivity. Many executives have been publicly extolling the virtues of remote working. However, a number of management, cultural and work design issues are now starting to emerge. Organisations need to review their current workplace design and practices and prepare for a hybrid home-office workplace post-pandemic.

Conclusion: The COVID-19 pandemic has taken the whole world by storm, shutting down establishments and pushing businesses and public sector agencies towards high levels of uncertainty. It seems it will be a while before this storm lets up.

Regardless of how bleak the effects of the pandemic and ensuing lockdowns are to the economy and the business sector, it can be a platform where leaders and innovators come forth.

Most companies are struggling to determine the next steps and are barely surviving through their business continuity plans. This paper aims to help you pivot towards a different perspective.

Conclusion: Despite being first published over 10 years ago, ITIL service design remains a pain point for both project delivery and service operations teams respectively. The former claims the latter requires the creation of additional deliverables at the point of service transition, while the latter expresses frustration at the lack of attention paid to service design during early stages of project delivery.

The reality is responsibility for IT service design extends beyond both these teams with all functions across IT having a role to play, from strategy all the way through to operations. When all aspects of the IT organisation contribute to the design of new, and modification of existing, services the artificial hump of service design can be avoided. The key is identifying who should be capturing and sharing what information to support service design – an outcome that can be achieved by adopting an end-to-end process integration model for the business IT.

Conclusion: Asset management can be described as ‘the life cycle management of physical assets to achieve the stated outputs of the enterprise’. To achieve the appropriate level of asset management maturity, investment in people, processes and technology all increase the likelihood of developing an effective asset management system. Under-investment could result in asset leakage or increased maintenance costs, thus diminishing the expected returns of the assets.

Where asset management maturity model reaches the level of being ‘integral part of everything we do’, organisations can seek accreditation of the asset management framework using ISO 55000:2014.¹

Where the common question is often ‘why waste our time on asset management’ then assets are usually at risk of leakage or poor customer satisfaction ratings. Outages and incidents may occur regularly. The risk of business collapse increases without recognition and change. Here organisations need to consider the steps to commence a review using the asset management model.

Conclusion: The development of AI-based solutions is heavily dependent on various types of data input in the form of either:

• Large data sets used to conduct experiments to develop models and algorithms for predictive analytics, optimisation and decision recommendations; or
• Enriched and tagged corpuses of images, audio, video and unstructured text used to train neural networks using deep learning techniques.

While at first the data management needs of AI-based solution development might leverage both data scientists and their existing business intelligence platforms to exploit these types of data, the actual lifecycle management needs of AI developers will expand quickly beyond the boundary of the traditional enterprise data warehouse.

Therefore, like the source code and configuration data underpinning transactional business applications, the raw data and algorithms of AI solutions must be managed by evolving DevOps practices towards a comprehensive “DataOps” model.

Conclusion: Australian governments at the federal and state levels have been implementing, modifying, discarding or persevering with shared services models for the better part of 15 years. Most of these initiatives were based on the premise that consolidating corporate service functions into a single entity and providing “shared services” back to the originating agencies would provide significant efficiencies and cost savings. While the concept of shared services does have considerable potential for value creation and efficiencies for government sectors, it is the execution that needs to be rethought.

Shared services operational units need to heed the learnings from other activities including:

• the entrepreneurial sector
• application of UCD
• other service redesign techniques, and effectively generate a spin-off that everyone wants to receive services from.

IT consists of information and communications technologies (ICT) typically used in business, corporate or enterprise management (e.g. computer processing, data management, business processes and applications, customer service, enterprise networking).

OT consists of specific operational technologies used to run a business operation (e.g. capital assets, manufacturing process control, machinery, vehicles, equipment, avionics, telemetry).

This MAP and its companion Compass research note provide guidance on evaluating the forms of organisation necessary to deliver reliable and effective interworking of IT and OT. The proximity of IT and OT varies substantially by industry.

Whatever the industry, organisations must seek out and evaluate existing and emerging opportunities in converging IT and OT. If these opportunities are missed, the business will lag in real-time management and suffer loss of their productivity and competitive edge.

Conclusion: Preparing the modern business for Cloud requires a common computing and networking infrastructure with new Cloud architectures converging with data centres over a hybrid of both direct Cloud connections and traditional wide area networking.

Organisations must begin by conducting a “triage” of their applications into three networking categories: those in pure public Cloud deployment; a hybrid of public and private (“on-premises”) computing; and those that will never go to Cloud (such as legacy apps, or for regulatory or security requirements).

At Cloud-scale the network becomes a fabric that facilitates software-defined technologies¹ (compute virtualisation, SD Storage, SD Networking and SD Security). Software-defined networking (SDN) abstracts network functions so that existing switches, routers and appliances can be made programmable to enhance their functions and reduce costs.

Eventually business IT processing will be delivered by SD Everything as all fundamental IT functions coalesce.

From today, businesses should be placing new emphasis on the “management” of their networking as both “virtual” and physical networks and plan to drastically reduce manual configuration and operation of networked IT as indicated below.

Conclusion: All organisations have technology partners. Some will have long standing partners and some technology partners will play the role of innovation lead or be responsible for introducing new technologies to their customers. However, relying on these traditional technology partners may prevent organisations from achieving digital transformation goals and may even be detrimental to innovation objectives. Organisations that are successful in the digital era will use innovation as a strategic, systemic and technological lever for establishing and supporting agile innovation cultures, new accountable business management practices and processes, and establish or participate in global industry eco-systems. This means being a capable and proactive organisation and knowing how to utilise technology partners without being led by them.

Conclusion: Unless management develops work-place change management strategies and staff are trained to implement the transformation program, employees are likely to become disengaged and could fail to adapt to the changes envisaged. To minimise the risk of failure, the strategy to implement the program must be well planned and stakeholders consulted.

Limited resources and a lack of skilled staff are holding back councils' IT plans. Australia's local councils are under increasing pressure to modernise their operations and improve on-line service delivery for residents, but many are starved of the funds and skills to achieve those goals. These are the key findings of a report from IBRS into local government IT management. The report - Winds of Change also Sweeping Local Government - found that local government IT leaders are grappling with demands to simultaneously improve online customer-centric service delivery while reducing operating expenses.

Full Story

Conclusion: Community Clouds can provide the expected value of using “Cloud”-based services in a shared environment that may be more economical than a closed private Cloud or privately owned and managed IT solutions. But economics may not be the driving factor. Identifying a common “customer” need or client base can be the main driver to getting similar organisations to agree to use shared resources or services.

The effort in getting organisations to recognise the opportunity to work together and to actually implement a community Cloud should not be underestimated. As in arranging car pooling, whilst the benefits may be clear, there is still the challenge of finding the other participants who all want to go to the same place, at the same time, and with agreed cost sharing. A “lead” organisation is necessary to help coordinate the required effort to create a Community Cloud.

Conclusion: Many business leaders around the world have concluded that although information and communications technologies (ICT) are mature, their own business has yet to systematically address digital transformation as an opportunity and a Digital Officer is required to provide that focus. ‘Business-as-Usual’ is an increasingly rejected approach.

A Chief Digital Officer (CDO) or similar appointment with broad responsibilities is clearly needed to deliver radical digital transformation in large or complex enterprises.

Conclusion: To facilitate business and IT transformation PMOs must be given a role that puts them at the forefront of advising management where best to invest scarce resources in business and IT-related projects whilst ensuring business systems are successfully implemented.

To be successful PMO staff need:

• People management skills to help project managers reach their potential
• Business acumen to assess competing claims for funds for business systems projects
• To be able to shape management’s expectations of what IT can and cannot deliver.

Conclusion: Advisor reviews of recent business cases evaluating Cloud contact centres (CC) show that any upgrade needs to be driven by a customer service business strategy (not just a technology refresh).

Cloud delivery has become the dominant technology for any new contact Centres for two main reasons:

1. Simplified contact centre acquisition and operation, and

2. The new paradigm supports a wide range of current and emerging business strategies by providing relatively direct and complete integration into related enterprise systems such as CRM, ERP and eCommerce platforms which are critical for service fulfilment and creating positive customer experiences (CX).

Conclusion: In order to develop an IT transformation program it is important to understand today’s operational and workplace context and use the insights gained to shape the way change can be achieved with a minimum of risk.

Conclusion: when managing both client server (legacy) and Anything-as-a-Service (XaaS) environment it is important the legacy environment does not constrain the potentially superior XaaS environment.

Conclusion: Organisations have been slowly and organically embracing virtual team management models over the past few years and there is every indication that this is the model of the future. Managing virtual teams and developing highly functional communities have been largely hit and miss. There are still many instances of dysfunctional teams exacerbated by the tyranny of distance. Systemically assessing the virtual distance within an organisation can provide insights and assist executive managers to develop and implement initiatives to significantly increase the effectiveness of virtual teams.

Conclusion: Governments across Australia have been engaged in shared services initiatives for almost a decade. Unfortunately, while the benefits are clear in theory, in practice all large scale shared services initiatives in the Australian public sector have been problematic. While a number of state shared service programs have been significantly scaled back or completely abandoned, the promise of shared services benefits remains to be realised. Recently, the Australian government has commenced progression towards shared services. Most of the shared services projects were implemented as a ‘spin off’ and failed, while a ‘start up’ strategy may overcome many of the challenges of the previous implementations.

Conclusion: For many good reasons collaboration is seen as a means to improve productivity and kick-start innovation. Both productivity and innovation are how organisations can raise their effectiveness and competitive edge.

However, simply ‘doing collaboration’, as though it comes as a readymade solution, is a certainty to fail. Collaboration needs governance and management. The expectations have to be established and the tools to achieve an organisation’s goals need clarity and agreement. The biggest factor is people and culture, and how these respond and develop over time.

Conclusion: Organisations that do not upgrade their major assets to reflect new technologies and practices quickly fall by the wayside. Similarly, organisations that do not critically review the effectiveness of their ERP solution, and either replace it or reinvigorate it, are failing their stakeholders.

Conclusion: Every business now operates in a context that includes the use of digital services. While the IT strategies of many organisations articulate a business case for technological innovation, they offer little guidance in terms of organisational patterns that enable and facilitate the delivery of useful and reliable digital services. Organisational structures must be adapted to meet the needs of the new world of digital service networks.

Conclusion: Infrastructure as a Service (IaaS) is starting to be used in dev/test and production environments by many ANZ organisations. CIOs who get IaaS right will create significant benefits for their organisation, both in cost and agility, and greatly improve the perception of IT with their peers in the organisation.

However, a general lack of experience with Cloud, and the use of outdated infrastructure purchasing approaches, may result in poor IaaS contracts that can cost the organisation hundreds of thousands, if not millions of dollars per year in excess fees. To combat this, CIOs should adopt a just-in-time approach to IaaS, eliminating vendors that lack the contract terms, or depth of infrastructure resources, to accommodate this approach.

Conclusion: Significant changes in both business organisation and the ICT industry overall will occur as emerging technology trends such as cloud computing become more mainstream over the next two to three years. As part of ICT strategic planning activities, CIOs need to understand not only how they will respond to these changes but also how their traditional partners will respond in terms of products and services, business models and the acquisition, retention and development of appropriate skills to deliver to their customers.

Conclusion: DevOps is a grassroots movement that is only a few years old but has quickly spread across the globe, and its influence is present in virtually all organisations that operate popular Cloud services. DevOps is a portmanteau of software system Development and Operations, referring to the desire to bridge the gap between development and operations that is inspired by agile techniques, and that is driven by the need to continuously operate and upgrade Cloud services. The DevOps movement is having a profound impact in terms of the tools and techniques that are used in the engine rooms of Clouds, leading to order of magnitude changes in the ability to perform hot system upgrades.

Conclusion: Unless you have a definition of the key data items for your enterprise, you will not be able to manage your data effectively. Astute CIOs have an understanding of the key data items that their organisation relies on for effective decision-making.

An enterprise data model documents the data in your organisation. It is a key enterprise architecture asset that enables more effective data management as well as offering the CIO the ability to reduce duplication and provide a higher level of service to the organisation.

Conclusion: Increasingly, organisations are looking beyond classical agile methodologies, towards lean techniques pioneered in industrial production. The transposition of lean techniques into the context of corporate IT is a challenge that requires a high level of process maturity and organisational discipline. The desired benefits only materialise if the lean approach is applied to processes that can be put under statistical control, and if the approach feeds into a domain engineering process that addresses the root causes of operational inefficiencies.

Conclusion:  The goals of enterprise architecture include prioritisation and strategic alignment of investments, savings through reduction in unnecessary duplication, and improved agility through reduced complexity.  When these goals are achieved the positive impacts can be enormous.

These goals are achieved when the enterprise architecture function has input to investment decision making and the way that solutions chosen and implemented.  Astute CEOs will involve enterprise architects in assessment of business cases, procurement decisions and project reviews.

The UK Government reported a direct saving of AU$6.3 billion[1] from project reviews that cost less than $100 million[2].  Many of these were ICT-based projects, which are known to be higher risk than other project types and are placed under greater scrutiny.  Astute CIOs have a clearly defined strategy and process for review of projects under their purview.

Conclusion: Without governance, investment in enterprise architecture is usually wasted. Organisations that have implemented effective architecture boards typically realise benefits that include cost savings, better-controlled and structured systems, and better alignment to strategic architectures.

CIOs should draw on the lessons learned from organisations that have implemented effective architecture governance through an architecture board.

Conclusion: Business Capability Modelling is a simple, structured approach that offers a strategic view of an enterprise. A Business Capability Model remains stable even as business processes change, and as your organisation is restructured. A Business Capability Model offers a higher return on investment than Business Process Modelling, and has several advantages as a tool to help bring the ICT organisation closer to becoming a partner with the business.

Conclusion: Within the working environment, complexity is often introduced unwittingly. At times, expediency is to blame, when intended short term fixes (such as code or business process changes) get baked into the organisational DNA. Unchecked, layer upon layer of complexity can builds up, undermining efficiency and causing ambiguity that troubles staff and confuses clients. With economic gloom casting a shadow over IT budgets, a systematic approach to re-instituting simplicity is warranted. Though more time-consuming to implement than conventional IT savings measures (such as cutting back contractor numbers or reducing training costs) the cost saving and efficiency benefits should be longer lasting.

Conclusion: The ICT organisation within any enterprise can benefit from a structured approach to understanding business capability of the enterprise. Business Capability Modelling is an Enterprise Architecture technique that IBRS sees playing a key role in transforming the relationship in many enterprises between ICT and the business.

In organisations where ICT deeply understands the business we see a close relationship between respected partners, and often this is reflected by a direct reporting link between CIO and CEO.

Failure to appreciate the business capability consigns the ICT organisation to be a subservient commodity supplier (rather than a business partner). Where the relationship between business and ICT is fragile, the potential of outsourcing to another provider means that the ICT organisation is not seen as a valued strategic partner.

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: An effective Enterprise Architecture should enable the strategy of an organisation to be clearly linked to the underlying business processes and information technology assets. Established enterprise architecture frameworks such as Zachman, TOGAF et al. include limited support for modelling the strategy of an organisation. An emerging framework, the Business Motivation Model, provides a much richer structure for capturing an organisation’s objective. Focusing on the strategy of an organisation represents an opportunity for Enterprise Architects to engage with the highest level of organisational planning and reflect true business intent, rather than reverting to a limited techno-centric perspective.

Observations: The Open Management Group defines “business architecture” as:

"A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands."

Enterprise Architects have long been comfortable managing the raw technology assets (applications, infrastructure, information etc.) that support the “tactical demands” of system design required to support enterprise change. IBRS’ experience has also shown that many organisations in Australia are making great progress in mapping business processes and services into an integrated architecture picture. The challenge is now connecting the knowledge of business processes and business rules to the higher-level strategic objectives that govern organisational evolution.

The first prerequisite in linking architecture to strategy is that an organisation has agreed and defined a strategy that clearly articulates its mission and purpose. There are many challenges in doing so. Sometimes organisations struggle to agree on their core purpose; neglect strategic planning activities; or maintain the strategy in tacit form without ever formally documenting it. An organisation may have a valid strategy defined, but the Enterprise Architecture team may not be appreciative of it.

In the absence of a defined strategy, Enterprise Architecture development can be a compelling voice calling for the establishment of a defined strategy, or indeed even leading the charge in its creation. However, beware the political risks attached to launching into this debate. Questioning or challenging an organisation’s strategy (or absence thereof) can be a confronting experience and risks adverse reactions from important stakeholders who have not bought into the concept.

Assuming a strategy has been identified and agreed there needs to be a way for it to be expressed architecturally. Popular Enterprise Architecture frameworks usually have some capability to capture important strategy elements. For example:

• The Zachman framework includes what it calls the “motivation description” as one of the core six dimensions of its taxonomy

• The TOGAF 9.0 framework optionally includes business drivers, goals and objectives in the “Motivation Extensions” of the core meta-model

• The Australian Government Architecture 2.0 defines the “Mission and Business Results” area of the Performance Reference Model which maps to the strategic outcomes and outputs defined by the government for public service agencies

For organisations which have not yet embraced an Enterprise Architecture framework there is support available in frameworks such as the Open Management Group’s Business Motivation Model¹ (BMM). In essence the BMM is a formal model for depicting business plans. However the BMM is not currently well known within the enterprise architecture field so it is worth examining in more detail.

The BMM is a structure that supports understanding the ‘doing’ of an organisation (mission, strategy, tactics) alongside the ‘being’ (vision, goals, objectives). The BMM situates the means (“doing”) and end (“being”) in the context of the forces or “influencers” that could impact on to either the means or the ends. Related to the “influencers” are the “assessments” of the potential impacts of the influencers and the mitigation approaches to deal with them.

These “means”, “ends” and “influencers” are then linked to the responsible organisational units and business processes. These responsible elements should already be defined in an Enterprise Architecture model, or business architecture view and are not directly part of the BMM itself. The operation of the organisational units and business processes are governed by “directives” that specify the business policies and rules that apply to the “means” in pursuit of the “ends”.

The BMM provides a much richer level of detail than the established mainstream Enterprise Architecture frameworks for documenting a strategy – delving into business policies, impact assessments, assets, liabilities and so on. This richer level of detail facilitates the modelling of a high-fidelity business plan (or strategy) if so desired. For large organisations the BMM model can reflect a nested approach where each organisation unit can generate a BMM model that can link to the superior or subordinate BMM models as appropriate.

The linkage between BMM elements and underlying technology architecture is through the associated business processes and rules. The linkages to business processes and rules once defined in the BMM can be mapped back to the supporting systems and applications. This establishes the linkages from business aspirations through to technology implementation.

It is worth noting that the BMM is methodology neutral. It describes the information to be managed, but not how the information should be gathered. In practice maintenance of a BMM or any Enterprise Architecture framework strategy model should be done in lock-step with the strategic planning decision-making cycle of an organisation.

Ultimately the value of maintaining an organisation strategy as an architectural model (EA framework, BMM or otherwise) provides a number of key benefits:

• an organisation’s strategy can be made explicit and the rationale behind changes to it become visible and shareable

• the outcomes of strategic decisions can be traced to the operational impacts across systems and services

Next steps:

1. Understand the how the organisations strategy is defined – is it well formed and formally documented?

   • If a written strategy exists have the Enterprise Architecture team document the strategy within either established EA frameworks or adopt an offering like the BMM for that purpose.

   • If not, advocate for better clarity and rigour around organisational strategy.

2. Make the incorporation of the strategy into the enterprise architecture pass the executive “so what?” test.

   • Apply it to real life examples to increase understanding or clarify decision making for a particular important issue.

3. Embed the maintenance of the architecture view into the strategic planning lifecycle for the organisation.

Conclusion: Effective IT Strategic Plans (ITSPs) are blueprints. They path future directions, provide rationale, explain benefits and can offer a rallying-point for staff. Yet many ITSPs become shelf-ware. Some become disused as initiatives enacted diverge from those in the plan, thereby undermining their credibility. Other ITSPs simply lack sparkle – the ‘Ah Hah’ factor that signals to stakeholders that the strategies will propel IT and the organisation into exciting, yet well-considered, new directions.

Conclusion: Neither written languages nor formal programming languages are capable of representing organisational knowledge in a human-friendly format. Even though Semantic Web technologies attempt to offer assistance in this area, their scope of applicability is limited to the role of establishing crude links between elements of knowledge in the public domain. Making organisational knowledge tangible and easily accessible requires new techniques, and dedicated technologies.

Conclusion:Value chain analysis is one of the fastest ways to understand the essence of a business or an organisation, provided appropriate techniques are used in the analysis. The only concepts needed for recording value chains are roles, systems, artefacts, the links between these concepts, and a distinction between artefacts that are exchanged with other organisations and artefacts that are only relevant within the organisation. One of the biggest pitfalls in value chain analysis is to lose track of the big picture, and to get lost in the details - which can easily be avoided by following a small set of best practices to avoid work that does not add value.

Conclusion: A decade ago Knowledge Management was the next big thing, and according to the analysts responsible for the Knowledge Management hype, it has evolved into a well-understood concept that is firmly established in the majority of organisations. Nothing could be further from the truth. Only very few organisations have a practically useful definition of knowledge, and even fewer realise that knowledge is not something that needs to managed, but something that needs to be nurtured - by committing to capture knowledge in its purest form, neither diluted by implementation technologies, nor distorted by organisational politics.

Conclusion: In recessions focus falls on efficiency and productivity. It becomes fundamental to a survival strategy. Designed to assist organisations with the productivity concept, Telstra’s Productivity Indicator¹ offers some solutions but fails on methodological grounds and therefore on the application of its tool.

Now is the time to understand productivity because if not already, then it will become the dominating idea of business for the next two years. Firstly it will be used to make some drastic decisions and secondly it will be applied on the other side of recession. Knowing well and measuring productivity will be essential to manage organisations through this crisis and beyond.

Conclusion: One commonly used approach for model management in Unified Modeling Language (UML) tools centres on using package-based modularisation and versioning of models – but this leads to a complex and unlimited web of inter-module dependencies. Another approach consists in the use of a scalable multi-user repository, and versioning at the level of individual atomic model elements. The latter technique, although largely eliminating practical contention and consistency issues between users, still does not encourage good modularisation, and gives no indication as to the state of completeness of a model. Fortunately, there are a set of best practices that can be applied to ensure modularity is treated as a first-class concern, such that model versioning is adequately addressed with standard version control software and minimal additional tooling.

Conclusion: During times of tight corporate budgets the IT budget is often cut down. Planned IT projects are deferred and in some cases selected running projects are cancelled. Unless a systematic and economically sound approach for allocating IT budgets is used, the result can easily backfire, leading to increased operational costs and unusable half-finished applications. Yet, if the right steps are taken, a reduced IT budget provides the ideal opportunity for decommissioning cost ineffective legacy systems and for refocusing attention on those applications that really matter.

Conclusion: Exploring better content management solutions to remain competitive and to raise the value of online investments is a wise policy to adopt now. With much slower economic prospects ahead, gaining greater efficiency or reaching users in better ways is going to be necessary.

For commercial websites the criteria to implement content management should be underpinned by usage – that is, click rates, content access and so on. The web sites that create dynamic – and personalised – online environments are more likely to outperform stale Web sites. Having a better content management system process may also use resources more efficiently and help align an organisation’s objectives to the new business conditions.

Conclusion: Business process and software modelling tools provide a good example of a domain with an impressive number of industry standards, many of which are of questionable value. Although software modelling is an extremely valuable activity, and many of the available tools are of high quality, there are significant shortcomings in terms of practical interoperability. The current situation is the result of a broken process for software industry standard development and false expectation. Corresponding lessons have already been learned in other IT disciplines, indicating a path towards practical interoperability.

Conclusion: It is all good and well to talk about alignment between business and IT, but it is easy to get trapped – either in purely theoretical business process models that bear little resemblance to reality, or in technical jargon associated with the latest and greatest implementation technologies. Given appropriate executive backing, significant productivity and quality gains can be achieved within six months or less by implementing a small number of fundamental best practices.

Conclusion: A new age for business applications is unfolding. Arguably, in 2008 applications are at a tipping point akin to that experienced in the early to mid-1990s, which was marked by the emergence of mature ERP technology and subsequent explosive sales growth. CIOs are urged to put applications firmly on their radar and begin acting upon their application portfolios as well as the methodologies and governance approaches that underpin them.

Conclusion: Most organisations aspire to be innovative and offer better services to their clients at lower costs. In some cases innovation programs span many years and acquire a life of their own, while in others they are tactical and focused on meeting short term goals.

Because most programs focused on innovation rely on having superior business intelligence or a smarter systems solution, active participation from IT management and staff is paramount. The article presumes all opportunities identified have a high IT component.

Conclusion: Establishing a Portfolio Management competency is now commonly regarded as best practice for organisations seeking to gain maximum benefit from their investment in IT. Whilst there is growing interest in this practice, many who attempt it are likely to fail, or at the very least find that it won’t deliver the expected outcomes.

Conclusion: Lack of involvement of business unit management in IT has been found to be one of the main contributors to the difficulties that can arise in the IT/ business relationship. There are however a number of initiatives that can be instituted, particularly in Applications Development and Project Management, which have been found to have a very positive impact on the relationship.

Conclusion: Initially oriented towards IT auditors and control professionals, COBIT¹ has matured into a broadly-based governance framework capable of being used by board members and C level executives, such as COOs and CFOs, when seeking to understand and effectively harness IT capabilities. Importantly however, in its new form COBIT also provides a valuable reference guide for the CIO and his or her staff, when wanting to establish a sound framework upon which to improve IT performance at all levels.

Conclusion: Shared services commenced as a movement in the early 1990s and rapidly became a worldwide trend in both the private and public sectors. Conceptually the prospect of doing of more with less is appealing. However, anecdotally, there have been just as many failures as successes, especially in the delivery of IT shared services.

Conclusion: Organisations striving to reduce their cost base may choose to investigate shared services strategies in areas such as Finance, Human Resources and IT. Changing past practices, and more importantly delivering bottom line benefits, can be challenging, particularly in IT. Whilst the stakes may be high, the organisational risk can also be high and resistance is likely to be encountered from those who fear their futures threatened by any planned changes.

Conclusion: Business Process Re-engineering (BPR) has been reborn, albeit in a new form. After achieving cult-like status for a number of years in the 1990s following publication of the book “Reengineering the Corporation”, authored by Michael Hammer and James Champy, BPR seemed to disappear from the corporate radar.

Conclusions: Due to a lack of transparency in the relationship between the demand for IT services and the cost of service delivery, most IT departments find themselves constantly justifying their IT budget to the CFO while simultaneously fighting with business units about additional demand for services. The major source of this dysfunction is the typical IT cost allocation, e.g., overhead or chargeback based on technical measures, which do not create the sufficient transparency to show the real cost drivers and incents undesirable behaviours.

Leading IT organisations are resolving this by recreating IT as an internal service provider with a formal IT Services Catalogue. This makes clear the relationship between demand and cost and uses economic incentives to drive the desired behaviours. It also has the benefit of aligning the service delivery expectations of the business unit and the IT organisation, thus reducing frustration.

Conclusion: Astute managers know that by developing comprehensive requirements for an RFP for IT hardware or services and engaging potential providers so they understand them, the probability they will get the best deal for their organisation is high.

Conclusion: Within the software engineering community only few people fully understand the difference between the traditional use of models in software engineering, and newer so called "model-driven" approaches. In particular the discipline of Enterprise Architecture makes extensive use of modeling techniques, and mainstream practice has not yet caught up with the model-driven approaches that are possible with today's leading edge software tools.

The problem is largely educational, and is compounded by a reluctance to step out of the comfort zone and rise to the challenge of producing precise and unambiguous models that can be used to power a highly automated software production facility. In model-driven approaches models and model transformations take on the same role as traditional source code - requiring a mindshift comparable to the one that was required in the transition from assembler programming to modern 3^rd generation programming languages.

Conclusion: There is an increasing trend for the IT function to become decentralised. Feedback from IBRS clients indicates that more than 60% of organisations have elected to adopt some form of decentralised IT responsibility. Our observation is that this figure is increasing, driven by:

Conclusion: Every organisation needs to assess its level of maturity in the management of its IT asset at least annually. Because most managers focus on meeting service delivery levels, they can easily overlook the need to manage the life cycle processes for IT assets from acquisition to retirement. By not investing in initiatives to increase their level of maturity in IT assets management, as per the table below, managers could be putting their careers at risk.

Conclusion: It is easy for software development teams to be preoccupied with, and to get lost in low level design. The simplest preventative measure to curb spurious complexity, without being prescriptive at the micro-level, is to consistently make use of a nested subsystem structure within the system architecture. The result is an architecture with fewer point-to-point interfaces. This strategy improves maintainability of code, and it works regardless of the quality of design at the micro-level.

Conclusion – Organisations that that have a clearly developed software release management strategy to help decide when to implement new releases will find it will easier to manage their inventory of mission critical software, keep their TCO (Total Cost of Ownership) under control and gain industry recognition for their proficiency in managing their IT investments.

Conclusion: Much of the work undertaken by IT Departments (systems development, maintenance, systems upgrades, selection of new technologies, etc) could well be managed under a project framework. Instead many organisations choose to manage this work using permanent teams under a hierarchical structure. This is serious mistake that inevitably drives higher than necessary IT costs.

Conclusion:The IT Contribution Model is the latest measurement performance model to be offered to managers in evaluating IT investment. Professors Marc J. Epstein and Adriana Rejc have created a highly abstract and all inclusive model of processes to classify and measure the role of IT in business outcomes, with a reference to profitability.

The quality of the model, however, and the argument to sustain it, is diminished by: the high level of generality and abstraction i.e. IT strategy as an input variable; and a naïve mechanistic explanation of the causal relationship between applied resources and economic results. The conceptual underpinning is not helped either by basic errors of logic, such as the expounded procedure to determine a metric which is circular and a formal tautology and cannot be used to derive what it lamely wishes.¹ This inept thinking is compounded by the equally lazy use of these adjectives: ‘critical’, key’ and ‘careful’, to explain various aspects in the creation of the model’s implementation.

Managers are already obliged to do many of the things the Model offers, albeit at a lower scale, and not necessarily finding the linkage between IT investment and overall profitability. The IT Contribution Model is a conceptual system or engine for making a measurement although systems, such as this model, do not validate its own results, regardless of its own coherence.

Conclusion: Organisations should not use old style systems development methodologies when implementing off-the-shelf packages. Package implementations need to tailor business processes to meet the operational characteristics of the selected package. Old style systems development methodologies assume a green field approach where the objective is to tailor the system to meet exact business requirements.

Heavily tailoring an off-the-shelf package will significantly increase ownership costs (by up to 10 times), while reducing the organisation’s ability to adopt future offerings that have been designed to work with the standard package.

Implementing a new package creates an opportunity to improve the way the organisation operates. Trying to fit a new package into old ways of working is an expensive exercise that invariably fails to take advantage of new business opportunities.

Business professionals must be involved in redesigning / changing business processes. As obvious as this sounds it is not hard to find example after example where it isn’t done.

Conclusion: BPM solutions essentially separate the business logic and activity flow from transaction management.  The latest generation of software applications operate through two key components, which are:

Conclusion: Before IT managers can start to measure targets against a balanced scorecard or any other mechanism it is important to agree with business executives what the targets will be measured and what each target actually means.

IT managers can use a combination of frameworks such as Balanced Score Card and CobiT to set and communicate targets to their staff and the wider organisation.

Conclusion: Despite increasingly affordable prices, basic workflow management systems are  still not widely used in Australian businesses. E-commerce, intranets, websites, corporate email and other desktop automation trends appear to have obscured the basic usefulness and wide application of one of the most powerful technologies brought to market in the last twenty years.

Service-level agreements (SLAs) serve as a powerful tool for enabling an IS organisation to understand the business'' definition of adequate service (based on business requirements) and for business communities to understand the support function''s responsibilities. If the services are sourced externally, then they are also one of the most critical factors in the success of the outsourcing relationship.

Conclusion: When the business environment is changing and support systems need to adapt to the change, managers have the option of developing an ITSP (IT Strategic Plan) with a long range focus, or a BSIP (Business Solutions Investment Plan) that  concentrates on investment needed in the next 12 - 24 months. A synopsis of both options is set out below.     

Conclusion: Very few organisations have effective ICT strategic planning processes resulting in a poor return of investment for ICT assets and missed business opportunities. 

Do not confuse ICT strategic plans with technical ICT plans.  ICT strategic plans are business oriented and focus on the future systems portfolio and its contribution to future business priorities.  Technical ICT plans simply focus on the technology investments an organisation needs to make over time.  A technology plan will be just one of many deliverables from an effective ICT strategic plan.

Conclusion: Without a proven framework that reflects the true value of each system in their portfolio IT managers and business unit managers run the risk of incorrectly prioritising new ICT investments and inappropriately identifying the risks associated with these investments.

To gain a clearer picture of the value and risk associated with each new ICT investment IT managers should map their proposed and existing systems portfolio on frameworks such as the Strategic Grid. This allows investments to be analysed and the results shared with a business audience.

Conclusion: Many organisations have two business strategies – an actual strategy and an espoused strategy.For IT managers this creates a major problem because these actual and espoused strategies can be very different. If the IT managers align IT systems and processes to the organisations espoused business strategy they will almost certainly make inappropriate IT investments in terms of the actual business strategy.

Recently I found one example where business executives said their organisation was aiming for product / service innovation while the IT manager was implementing an architecture aimed at overall cost leadership. These two different business strategies require completely different systems portfolios supported by equally different IT architectures. In this case the IT manager and the business executive were heading for an inevitable disagreement – one the IT manager was going to loose.

IT managers need to work with business managers to uncover their actual business strategy. To do this IT managers and business managers need to become familiar with a new set of concepts – ones that help business managers uncover the gap between what organisations would like to be and what they really are.