Risk Management Lectures (3)

The following series represents lecture material that I’ve used from time to time in discussing the problem of IT Risk Management. I’ll be providing this material on my blog as a series of information related to the topic.

***

Business Strategy Effects

Risk Analysis helps us determine effect of disasters upon business strategy.

In his text, Peltier rationalizes that risk analysis should happen whenever time, money, and resources are to be spent, as a way to balance operational needs against increasing costs. Risk assessment is a tool that allows a firm to identify potential disastrous circumstances and prioritize a response to mitigate the risk. Peltier describes the risk management process on page nine as conforming to five standard steps or principles:

1. Analysis
2. Design
3. Construction
4. Test
5. Maintenance

As described on page 10, these steps are just a generalist way of performing a risk assessment. Risk assessment, risk management, isn’t new – firms have employed techniques of varying complexity to this model for decades – yet, in the field of information technology, 9/11 opened a lot of eyes to the potential of catastrophic loss and business continuity has been a hot topic in boardrooms ever since. In his introduction, PdIn taking this course, it should become apparent to you that technology implementation without consideration towards disaster recovery is both a severe strategic oversight, and, an uncomfortably stagnant position that monopolizes IT function on the needs of now rather than on the contingent needs of tomorrow.

Client/Server and Peer-To-Peer Architectures Centralized, Distributed, and Stand-alone Architectures

Over the course of the class, we will be discussing various forms of computer architecture and information assets that could be put at risk. It might be useful then to quickly review a couple of concepts concerning scale.

Principles this week concern scale – the evolution, size, complexity, raw processing capability – in component relationships within an information system. As organizations migrate from peer relationships in their computing platforms, they move to more structured, centralized models typically representative of client/server networks.

In peer relationships, services and security contexts are limited to individual microcomputers. In order to manage services and security, you must administer these things directly on the affected computer. As the network grows and business practices become more reliant on the electronic information, this practice can become horribly anarchistic: every computer has its own security context and needs to be managed separately. Over time, the chaos and management overhead eventually leads to a loss of control over data and information services.

Therefore, as organizations mature their information services, they begin to centralize their computing platforms into in client/server relationships: security and services are centralized to a computing platform – a single security context – designated to perform a service function for the network – a server – whereas a client would be a machine that requires use of the service offered by the server. The security context is centralized to the server so that access restrictions may be managed from one point; configurations relating to security can be made on the server, and, any client computer willing to use the server’s resources are subject to that security context.

In client/server relationship models, we’re offering services for dynamic access and use by client machines; the engineering problem is to maintain uptime whereas the support focus is to educate end-user communities to access, leverage, and exploit these services for business process efficiency. Services rendered unavailable generate a very visible denial of access and potential failure of dependent network services and is relatively easy to troubleshoot: the service is working, or it is not; the equipment is online, or it is not; the file is available, or it is not.

The client/server network is therefore primarily concerned about redundancy and fault tolerance if only to maintain the operating system’s stability to offer these services. This isn’t an extraordinary engineering feat anymore – modern operating systems on 32bit and 64bit platforms are remarkably stable following installation, are often equipped with API’s (Application Programming Interfaces) to make managing applications residing on the platform integrated with services and security contexts’ offered by the o/s, and patching is nearly automated. However, performance is measured on both service availability and file availability and the suffering performance usually translates into a minor inconvenience until such time the service and file are brought back online. Ten minutes or ten hours, the lost productivity may be measured but there’s little or no risk to the rest of the information system.

As information systems mature, the reliance on transaction based processing continues to grow, whereas the dynamic of downtime changes; the TPS (Transaction Processing System) layer becomes important to many levels of DBMS processing managing fulfillment obligations on behalf of the company. The role of services and files in client/server begin to diminish – the engineering problem has matured. The problem no longer becomes an inconvenience in a lost service or file, instead, it becomes what to do if, even for two seconds, unavailability results in transactional error or data malformation. The TPS is part of a larger problem in moving data in more real-time from one processing state to another, whereas downtime isn’t an inconvenience, rather, it’s a catastrophic event with enormous consequences to upstream and downstream systems that are also integrated the TPS layer.

So, over time, as investments in information systems grow for a company, they watch their information services mature from client/server architecture to a data center architecture, where the concern isn’t simply for files and services, but, for transactional speed, accuracy, and reliability. Therefore the engineering problem shifts. Our concern is for inspection, for buffer and capture and spooling if another portion of the transactional process is brought offline. The programming and engineering problems concern memory management, I/O constraint, verification and translation activities across multiple DBMS channels. The data center becomes a heart beat – a pulse – for the organization. If the pulse stops, if even for a few moments, the results could be disastrous.

Within the course, we’ll talk about peer/peer networks, client-server relationships, and data centers – even so much as to evaluate these configurations with our case study, Omega Research. In this case study, you’ll be tasked to evaluate the relative risk given facts presented in the case, and asked for your opinion for addressing/mitigating those risks.

R

Russell Mickler works a technology consultant in Battle Ground, WA, USA. With over thirteen years of experience, Mickler holds a CISSP, MCSE, a Masters Degree in Information Technology, and is pursuing his Doctorate at Walden University. His website can be found at www.micklerandassociates.com; he can be contacted at mickler@micklerandassociates.com.

Name (required)

Mail (will not be published) (required)

Website

Notify me of follow-up comments by email.

Notify me of new posts by email.