Search results (27)
Conclusion: Application portfolio rationalisation offers the promise of reduced ICT maintenance costs while improving data quality, process support and usability for end users, and increasing organisation effectiveness and efficiency.
An effective approach to application portfolio rationalisation involves five steps: 1. understand your business architecture; 2. understand your applications portfolio; 3. develop principles for rationalisation; 4. assess opportunities for rationalisation; and 5. rationalise.
Conclusion: Many organisations in Australia struggle with accurate prediction of project cost and schedule. There are two steps that organisations can make to address this: the first is reuse of well-defined solution building blocks – the second is repeatable construction of solutions using those building blocks.
Architecture and estimation are closely related functions. Therefore CIOs who struggle with projects that run over-time or over-budget should look to enterprise and solution architecture methods to increase the degree of reuse and repeatability when defining ICT-enabled solutions. This leads to improved accuracy in cost and schedule estimates.
Project directors and SROs1 are still falling for the same mistakes that Brooks explained so elegantly in 19722.In large government environments where project scope and deadlines are dictated years in advance by election promises and new policy initiatives, many aspects of ‘agile’ can’t be adopted: BDUF (Big Design Up Front) is alive and well.
Conclusion: Enterprise architecture tools and processes have traditionally missed the mark in providing timely and relevant support for executive decision making. A fresh approach is required that focusses on just enough information to support defensible, evidence-based planning. Enterprise architecture functions must provide value in short, focussed iterations.
Enterprise architecture provides an evidence-based approach that demonstrates clear traceability for investment planning decisions. Astute executives will understand how enterprise architecture can be used as a powerful approach for developing an ICT investment plan that is robust and defensible.
Conclusion: Enterprise architecture should be viewed by CIOs as a fundamental toolset to provide sound, defensible, evidence-based decision making. CIOs who ignore or misunderstand enterprise architecture forego a powerful management device.
CIOs should understand and make use of the enterprise architecture techniques at their disposal; they must also recognise approaches to enterprise architecture that will not work. CIOs should set expectations with their enterprise architects for quick delivery of highly relevant outputs: days not years.
Conclusion: As outlined in a previous research note1, CIOs need to ensure that external-facing websites support an appropriate range of browsers. This is to ensure websites can be accessed by the largest possible percentage of users per dollar spent on development and testing.
The very public nature of the issue means that it is wide open to criticism. Many CIOs have been called on to explain their position. Astute CIOs will have a clearly defensible support policy that can stand the test of public scrutiny.
Implementing whole-of-government information services: trends, drivers, pitfalls and realistic expectations
Conclusion: The federal government has undertaken a number of whole-of-government (WofG) application and information services initiatives over the last five years. Now that these programs have mostly reached closure, a second wave is being initiated. At the same time state and territory governments are looking to implement similar programs.
Conclusion: IT Managers and CIOs who are responsible for external-facing websites are faced by the difficult proposition of determining the optimal set of browsers and browser versions to support. Supporting too many browser platforms wastes money; supporting too few risks alienating users.
Creating a custom assurance process based on the Gateway Review Process: don't throw the baby out with the bathwater
Conclusion: Two-thirds of all ICT projects fail to deliver all of their intended benefits on schedule and within budget1. This results in ICT Executives spending a lot of time explaining why project schedules have slipped, why projects have been abandoned, or why goals and requirements have changed.
The Gateway Review Process(GRP) provides a well-proven and recognised approach to project assurance. Increasingly the process is being used as a basis for developing customised assurance processes in organisations across Australia.
Knowing when and how to customise the process is non-trivial andmust be based on lessons learned from application of the GRP. Many aspects of the GRP have been based on careful design and research – changing those aspects unwittingly will greatly reduce the effectiveness of the custom process created.
Conclusion: Bernard Shaw is attributed with the saying that “Common sense is instinct and enough of it is genius”. The most “genius” statements of ICT Strategy are often those that seem like common sense to the reader.
The ABCD model described in this research note is a helpful model that IBRS has observed in use by a small number of government agencies. The model can be applied in a wide range of situations including agency-wide ICT Strategy development, and problem definition and planning in the context of a specific project of any size. The ABCD method provides a helpful framework for developing a strategy and equally importantly it provides a clear and helpful basis for communicating that strategy to a wider audience. The method can be used by an individual or by a group of any size, and has been used very successful in workshop situations many times by some government organisations.
Conclusion:" Fail to plan and you plan to fail". This statement has been attributed to a number of people including Winston Churchill and Ben Franklin.
Most CIOs know that strategic planning is a key part of their remit1 and the most successful leaders maintain a clear strategic outlook. Effective CIOs make a high priority of articulating a strategic plan for ICT within their organisation, rather than getting involved in the management of each and every project and business unit. Conversely, a lack of clearly defined and widely understood strategy indicates a deficiency in leadership.
A rigorous ICT Strategy must be based on a solid foundation – there are several ways to gather the evidence that will provide that foundation.
Conclusion: A well-written ICT strategy can be a powerful tool for the CIO to showcase the vision and potential of ICT within any organisation. An effective ICT strategy demonstrates to the organisation that the CIO has a plan and is able to provide suitable leadership.
In some jurisdictions, such as NSW1, agencies are required to develop ICT Strategic Plans that demonstrate support and alignment with government priorities and which form a key part of the business case approval process.
Government agencies that do not have a documented ICT strategy have at times come under public or political scrutiny. For example lack of ICT strategy has attracted media attention and has caused questions and criticism in parliamentary forums and “estimates hearings” in various jurisdictions2.
Conclusion: Based on conversations, interviews and meetings with Australian clients, IBRS has compiled a list of the top six mistakes that are probably impacting your architecture practice right now.
Astute CIOs and business executives will take steps to avoid these common mistakes which we see repeated in many organisations.
Conclusion: CIOs need to decide if they will invest in the practice of enterprise architecture and if so, how to approach it. Many CIOs choose to invest in enterprise architecture for the wrong reasons: because other organisations are doing it or because a consultant says it is “best practice”. Instead CIOs should consider which enterprise architecture functions would provide specific benefits, given the functions that are already provided in the organisation.
Conclusion: Mark Twain said “'I didn't have time to write a short letter, so I wrote a long one instead”. Overly long, complex or imprecise RFTs create headaches for all involved.
Astute CIOs will ensure that the statement of requirements in an RFT remains succinct, clear and unambiguous. Sufficient attention to detail will save you from a variety of headaches later in the tendering process.
Careers and reputations have been tarnished when disgruntled vendors expose the shortcomings of the tender process through the courts.
Conclusion: Einstein said that “everything should be made as simple as possible, but not simpler.” This is true in enterprise architecture and project management. CIOs know that simple solutions have many benefits over complex ones. Highly complex projects have high failure rates, like highly complex architectures. However, many CIOs unwittingly encourage and reward complexity. Complexity must be viewed as a primary focus for reducing cost and risk associated with large projects. CIOs should understand some of the key steps that can lead to reduced complexity in projects and systems.
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.
CIOs, architects and managers responsible for IT systems often wonder – how did we end up with this mess? There’s no decent documentation. No-one seems to be responsible for the apparent lack of any rational architecture. A lot of stuff is “due to historical reasons”. Of course this would never have happened under your watch, but now it’s your responsibility to make some sense out of it. If your system represents a substantial investment, it stands to reason that you’ll want to understand why it was designed the way it is before you take any radical action to change it.
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 from project reviews that cost less than $100 million. 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:Emerging Technologies (such as those relating to Tablets, to Cloud, to Social Media, to Big Data) threaten to complicate and disrupt the work of enterprise architecture. As enterprise architects struggle to understand, simplify and bring governance to heterogeneous technology environments, new and emerging technologies get in the way.
Emerging technologies cannot be ignored. They promise tantalising new benefits and bring a vision of hope to CIOs struggling with increasing costs and stagnant budgets.
Enterprise architects must understand what is possible with new technology and matching that to the specific needs of an organisation whilst reducing technology sprawl.
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: 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.
Three recent events have cast serious doubts on the viability of public cloud computing in the Australian marketplace. These events have raised critical concerns about the security, reliability and regulatory aspects of emerging cloud platforms in both public and private sectors.
Conclusion: IT departments continually struggle to replace antiquated business systems. As a result, business processes are supported by inefficient and ineffective technologies that diminish business performance. A common cause is that replacement systems fail to meet expectations and as a contingency, legacy systems must linger on to prop up the shortfall. This imposes the costly burden of maintaining duplicate systems and requiring complex and unwieldy integration. Successful replacement of legacy assets requires a clear strategy and dedicated support for a holistic decommissioning process.
Observations: The IT industry is obsessed with the new and the innovative. Better, faster, cheaper technology solutions are seen as a panacea to the ills of the age. Yet in the excitement to adopt new technologies and systems, the enthusiasm to completely remove the old is sometimes lost. This work is unglamorous and not regarded as a professionally valuable or motivating experience. As a result legacy systems remain like barnacles on the hull of IT.
The need for system decommissioning can arise from two main motivations. The cost of using a superseded technology may become greater than the cost of deploying and using a modern replacement. The technical implications of this scenario are explored in further detail in this research note. Alternatively a system can be made obsolete by a changing business model that no longer requires direct system support, as is often the case when outsourcing business functions. In either circumstance it is essential to have business owners driving the decommissioning agenda through a clear business case focused on realising direct economic benefits.
The easy part: Decommissioning in a technical sense is often perceived as the end-of-lifecycle activities undertaken to remove outdated or superseded hardware: sanitisation of sensitive information; audited removal and disposal of hardware; destruction and recycling of components. Sometimes the decommissioning of a system will not involve the retirement of any hardware at all – as might be the case with new applications that will run on existing hardware. In these circumstances end-stage decommissioning is largely concerned with things such as the retention and archival of historical data; winding down of support and maintenance arrangements and reallocation of supporting resources.
From a system perspective this is the very final stage of the decommissioning process and a fairly straightforward affair. What is immensely challenging however is the process by which the system got to the point where these activities could take place.
The hard part: Getting to the point where you can decommission an IT system involves the implementation of the replacement system and the migration of all required information, workloads, processes and supporting functions from the old to the new. This is fraught with difficulty. Firstly the new system must be specified and built to adequately support the existing business processes. This is often not the case. New systems may be missing critical requirements, have poor performance characteristics or impose unworkable practises on users. Existing systems may also have many hidden dependencies or unknown uses that only emerge during the decommissioning process and require significant extra effort to address. All of these issues create significant cultural momentum by users to retain the legacy system until the new system is “perfect”.
A common scenario is that a new system is built, but due to significant flaws, its use is limited to a subset of the anticipated functionality and the legacy systems that it was meant to replace continues to operate. This situation can continue indefinitely and, ultimately due to the lack of resources to redress the issues with the new system, the combination of the old and new becomes the status quo, with the unfortunate attendant increase in operational and support costs. This scenario has played out many times as organisations have attempted to replace suites of bespoke solutions with packaged application suites such as SAP or Seibel.
Phased decommissioning: To offset the risk of introducing new systems, many organisations choose an approach that allows a phased introduction through an integration architecture that supports operating both old and new systems at the same time. While at a conceptual level this seems like a good idea, in practise it results in many complications. Technically, the complexity of the integration required is always drastically under-estimated. Legacy systems are riddled with obfuscated business logic that is often nigh on impossible to reverse-engineer and can only be discovered through trial and error. Complex integration logic is also a prime source of major performance problems. Running a business process across two systems creates enormous monitoring and reporting headaches.
Direct decommissioning: The alternative of a “big-bang” cutover is challenged by the complexity and size of data migration required to implement such an approach. Many new systems are designed to enforce much higher data quality standards than legacy systems, creating a data conversion conundrum. Interpreting poorly structured legacy data can be dependent on incomprehensible business rules, making the translation of some data from old to new systems almost impossible.
Therefore it is critical to firstly ensure your new system is up to the job before decommissioning the old system. This may sound rather obvious, but while poor IT delivery can often be masked by well marketed scope reductions, creative delivery phasing and limited user deployment – the decommissioning status stands as a stark measure of progress. Measuring the decommissioning process can be spread across three key performance indicators:
the percentage of working, tested functionality in new systems that is required to replace all equivalent legacy functions
the percentage of workloads and historical information that have been migrated from legacy system to new systems
the percentage of functions that have been wound down and removed from operational service in legacy system.
Addressing decommissioning must be done explicitly in the business case for any IT investment. The question must be asked – are financial savings or other critical benefits directly linked to the decommissioning of legacy systems? If so, how dependent is the economic viability of the planned investment on the timely achievement of decommissioning objectives? If the business case is sensitive to planned savings from decommissioning, what is the risk mitigation in the case of decommissioning delays? In any case, strong governance, stakeholder management and communication are essential to successfully pursue a decommissioning strategy.
Many IT business cases promise substantial financial benefits through decommissioning, but the reality is that retiring legacy systems drags on far longer than anyone desires.
Conclusion: The generic term “the business” as used by IT people to refer to their stakeholders, is a gross and somewhat dangerous generalisation. Blithely referring to “the business” while making little effort to understand the real needs and priorities of system constituents can leave IT practitioners disconnected from the people they are trying to serve. Organisations have many different facets and characteristics that all seek different qualities from IT solutions. Understanding these differences is an essential requirement to delivering superior IT services and solutions.
Conclusion: Technical debt is a metaphor for the ongoing cost of bad IT decisions. As with debt in the real world, interest is paid on technical debt in the form of increased cost of operations and maintenance, poor quality solutions and loss of enterprise agility. Prudently managed technical debt can be a useful tactical tool, however uncontrolled technical debt can rapidly become an overwhelming burden and severely reduce the ability to invest in new initiatives. This is toxic technical debt. Crucial to managing technical debt is having an approach to identify and track when and where it is incurred.