Main
Log in

Infrastructure

Conclusion: Oracle will continue to excel in the Application, Middleware and Database markets, but it also intends to radically transform and simplify IT infrastructure. Oracle’s strategy is to eliminate complexity, create significantly greater business value and reduce infrastructure costs using an Integrated Systems approach. The objective is to enable customers to focus on applications, instead of infrastructure, in the hope they consume more Oracle software.

IT executives should keep abreast of Oracle’s infrastructure innovations, as well as the competitors’, and be prepared to rethink their existing infrastructure approach if an Integrated System can create a significant new opportunity for the business.

Conclusion: The discipline of Enterprise Architecture has evolved from the need to articulate and maintain a big picture overview of how an organisation works, covering organisational structure, processes, and systems. Whilst Enterprise Architecture can assist in implementing industry best practices, several-fold improvements in productivity and quality are only possible if the organisation makes a conscious effort to attract and retain top-level subject matter experts, and if it commits to a so-called Domain Engineering / Software Product Line approach to the strategic analysis of market needs and the design of products and services.

Conclusion: Poor quality and incomplete requirements continue to be a leading cause of IT project failure. While the more widespread use of iterative project management techniques is minimising the impact of bad requirements, it is still not addressing the underlying cause. Accountability for improving the quality of requirements remains elusive. Enterprise architects must take a stronger role in the validation of requirements, and be prepared to intervene when necessary.

Observations: The saying goes that you cannot create a symphony by asking a hundred people to give you ten notes each. This is an apt description of the way requirements may be developed on large IT projects. The result is often a disjointed set of wishful ideas, concepts and assumptive solutions without any intrinsic integrated design or consistent rationale. Given this profoundly flawed starting point, it is not surprising that subsequent project implementation activities that rely on correct and consistent requirements will be inherently challenged.

Challenges in defining requirements: Understanding of the term “requirement” differs among stakeholders. Requirements can be variously perceived as user wish-lists; or detailed product features sets; or complex business process descriptions. The language used to express these requirements is often loose and ambiguous, instead of concise, testable statements of conformance. Requirements often focus on functional behaviour and ignore important non-functional aspects such as performance, security and operational concerns.

Commonly the task of establishing a set of requirements is somewhat blithely described as “requirements gathering” and implies that they already exist ready-formed in perfect shape, and just need to be harvested like simply picking cherries from a tree. Such a perception is a very dangerous attitude – especially among senior executives.

The reality is that high-quality requirements are difficult to create. Unless there is a very clear and concrete understanding of the objectives of the system, and ready access to explicit and accurate supporting information about all relevant dependencies, the process of defining requirements can become a messy and imprecise affair. Common challenges include:

  • conflicting understanding of the underlying business problems between stakeholders

  • limited access to key subject matter experts

  • organisational politics that hinder contribution and create divergent objectives

  • changing circumstances render requirements obsolete

  • time pressures that cause analysis to be incomplete and poorly formed

Dealing with poor quality requirements: Delivery pressures tend to force poor requirements to be accepted unchallenged. In the face of impending (or missed) deadlines, there is acute pressure to have the requirements ‘signed-off’ regardless of the quality. Project governance checkpoints tend to measure when a project milestone has been completed, but not the quality of the actual work products. If requirements are identified as lacking, this advice can be ignored, or dismissed as rework that can occur in later project phases.

The best way to guard against poor quality requirements is to have them validated early and often. Requirements can be quickly tested against some very simple heuristics to gauge the quality and completeness of their definition. Simple tests include:

  • Cohesive – does the requirement address a single, simple business function?

  • Precise – is the requirement completely unambiguous and stated using concise, simple, plain language?

  • Verifiable – can conformance with this requirement be easily proven in the testing phase?

  • Traceable – are all requirements linked back to a clear business need or objective, and are all business needs covered by a comprehensive set of requirements?

The rise of agile delivery techniques has cut the time between requirements definition and requirements testing. This has meant that faulty requirements can be identified faster and at a smaller scale than traditional waterfall techniques. However agile delivery methods are still not pervasively utilised – and very large programs of work found in government and financial sectors still rely heavily on waterfall techniques.

The role of the architect in requirement validation: Requirements elicitation and definition is commonly the domain of the business analyst. Architects tend to be engaged in projects in the earlier conceptual phases to make key decisions about platforms and technologies based on high level business needs. Then, in parallel to the detailed business requirements definition, architects focus on things such as:

  • defining system context and external integration points

  • identifying system components and interactions

  • understanding information structures and flows

  • performance, security and capacity analysis

The risk here is that while the architects are focused on all-things architecture, they remain isolated and disconnected from the detailed requirements definition and validation. But architects are the best placed people to perform requirements validation. They are the experts that should hold the end-to-end system knowledge and enterprise context, coupled with a clear understanding of the business needs and desired benefits to critically and authoritatively validate the quality of requirements.

Despite protestations from architects that requirements validation is unwanted QA of business analyst artefacts, or unnecessary detail, or this is the role of the project manager – architectural validation of detailed requirements must be performed. And project managers must be accountable in ensuring that any deficiencies identified in architectural review are acted upon.

If poor quality requirements are identified by architects, and not addressed by project teams, architects are obligated to escalate the issue for executive attention. Architectural intervention over poor quality requirements is perhaps one of the most important actions that can be taken to improve the chances of project success.

Next steps:

  1. Examine how the quality of requirements is assured on projects within the enterprise.

  2. Check whether architects have appropriate review and oversight of requirement quality, or is this left as a project manager responsibility.

  3. Make architects accountable for requirement validation as a mandated governance checkpoint.

  4. Ensure appropriate escalation path exists for architecture intervention if necessary.

 

Conclusion Leading IT organisations now recognise that selecting and integrating a mix of best-of-breed servers, storage and networks no longer adds value to their organisation. Instead they are purchasing Integrated Systems from a single vendor that eliminates the cost and complexity of integrating these components; lowers the integration and support risks; and reduces the time to deliver a working solution.

To make this paradigm shift most organisations will need to change the kind of relationship they have with their infrastructure vendors from a purely transactional supplier to a long term strategic partner. For many IT, and vendor staff, this will be a difficult and traumatic transition.

Conclusion: Mature Unified Communications (MUC) is more than a blending of messaging, voice, and presence information. The coming wave of unified communications will be executed as part of a larger ’worker mobility’ strategy and be more closely coupled with business processes. This type of unified communications allows significant organisational structural change. Thus, planning for MUC begins with an examination of organisational processes and discovery of where knowledge is located within the organisation, and then evolves into a discussion regarding how to restructure teams to gain a competitive advantage.

Conclusion: VMware’s vSphere Storage Appliance (VSA) is the beginning of the end of the modular storage market. While built for the low end of the market, the VSA will scale-up over time and disrupt the modular storage market. The key benefits of the VSA in a VMware cluster are: lower infrastructure complexity, lower capital costs, greater workload agility and reduced IT skills.

SMBs should consider the VSA at their next major infrastructure refresh. Enterprises should experiment with a standalone environment, such as dev/test or a new departmental application, and become familiar with this technology. Enterprise should then create an adoption strategy to replace modular storage in their VMware server cluster as the VSA matures and scales up.

As a consequence of the Internet, and with it, the development of several technologies, and e-commerce (and piracy, too) and now, all things ‘social’ there is an expectation that disruptive innovation is critical to success. More than that: disruptive is the key to success, and without it businesses will die. Survive or die; it’s either/or. The choice is clear.

In the US, as each new social media IPO is a success, the disruptive power of social is proven and now figuratively slapping the faces of tired old enterprise IT. Look at the P/E ratios of Cisco and Microsoft and Google – too low and unexciting because they are not disruptive. They are like remnants of the US steel industry, slowly rusting.

Conclusion: Australian IT organisations should be setting the bar higher to extract maximum value from outsourcing arrangements. Furthermore, if the level of outcomes for many providers has been exceeded, it is often only because those expectations were set so low, with a focus on organisations pushing off low-hanging IT functions.

Clearly the blame in allowing the sub-optimal outcomes to occur is shared by both vendor and customer. Organisations must ensure that they are evolving the way in which they manage their outsourcing vendors to take advantage of cloud and utility based service delivery.

Conclusion: Most branch office data is poorly protected by the organisation’s existing backup strategy. Recent improvements in network connectivity, and the commoditisation of advanced deduplication techniques, fundamentally change the landscape and make highly automated, reliable and cost effective branch office affordable to most organisations.

Organisations with extensive branch office data that is not adequately protected should revaluate their branch office backup strategy.

Conclusion: Running a robust, cost efficient data centre requires a scale of operations and capital expenditure that is beyond most ANZ organisations. Organisations that host equipment in their own facilities have a higher business risk. Business management is unlikely to be aware of these risks, and has not signed off on them, leaving the IT organisation exposed.

Business management should ask for a business impact assessment to expose these risks to an appropriate decision making level. Management can either sign-off on these risks or request a mitigation plan. For many organisations, moving to a commercial Tier-2/3 data centre reduces risk without substantially changing the total cost. SMEs should consider migrating to a cloud environment (IaaS and/or SaaS) and get out of the business of owning and running their own IT infrastructure.

In the News

Managed security: a big gamble for Aussie IT providers - CRN - 02 August 2018

TechSci Research estimates the Australian managed security services (MSS) market will grow at a CAGR of more than 15 percent from 2018-23 as a result of the increased uptake of cloud computing and...
Read More...

Kids, Education and The Future of Work with Dr Joseph Sweeney - Potential Psychology - 25 July 2018

What is the future of work and how do we prepare our kids for it? Are schools and universities setting kids up for future success? Does technology in the classroom improve outcomes for kids? Should...
Read More...

PageUp starts rebuilding and looks to learn lessons after data breach nightmare - AFR - 27 June 2018

The timing couldn't have been worse for PageUp; two days before Europe's new data protection regime came into force the Melbourne-based online recruitment specialist's security systems detected...
Read More...

Australia is still in the cyber security dark ages - AFR - 28 June 2018

In terms of cyber security years, Australia is still in the dark ages, a period typified by a lack of records, and diminished understanding and learning. We're only a few months into practising...
Read More...

AMP does maths on infosec shortage - ITnews - 18th June 2018

Cyber security and risk advisor at analyst firm IBRS, James Turner, said the cyber skills shortage was prompting a wider rethink around the domain in terms of resourcing for the last few years....
Read More...

Subscribe to IBRS Updates

Invalid Input
Invalid Input
Please enter a valid email address
Please enter your mobile phone number
Invalid Input

Get in-context advice from our experts about your most pressing issues or areas of interest

Make an Inquiry

Sitemap

Already a subscriber?

Login to read your premium content.

        Forgot your password?
Recently Viewed Articles
Related Articles