As a computer-enabled employee, you have likely encountered Draconian computing policies common amongst modern organizations. From a support perspective, the reasoning is simple: IT departments are small, lean, and cannot maintain the infrastructure if they revert to laissez-faire management methodologies. From a user-based perspective, support is irrelevant; IT is a utility, a black-box device with which users interact, knowing little of the repercussions of their actions—only their needs. Using a computer at home is vastly dissimilar to utilization at the corporate level, but only because organizational requirements affect the implementation and usage of information systems and technology (IS/T). Such requirements may come in the form of user rights and privileges, bandwidth restrictions, Internet browser limitations, and choice of operating system.

Computers are tools; they provide a means to an end unparalleled with previous technologies. IS/T should enable users, allowing them to engage their work in meaningful and innovative ways (Doctorow, 2009). Sociotechnical systems define such IS/T interactions as technological compatibility with [user] workflow (Katz, 2003). Therefore, recognizing the working relationship between users and technology is the very foundation of effective IS/T implementations (Yang, Moon, & Rowley, 2009).

Organizations should not seek to inhibit their employees, of which Doctorow (2009) makes a very prescient argument; yet the integration of service level agreements (SLA) into IS/T have a substantial impact on infrastructure performance requirements (Hartley, 2005; Karten, 2004). Sociotechnical systems may take into account externalities; however, acceptance and perception of organizational computing policies through SLA’s may detract from their efficacy.

Consider the healthcare industry, one fraught with regulatory requirements from both HIPAA and ARRA to increase patient safety and privacy, whilst minimizing administrative costs (Blumenthal, 2009; Hamelburg, 2009). Clinical information systems (CIS) embody these goals by digitizing the patient medical record. No longer are hospitals relying on paper-analogue methods for clinical documentation, the medical record is now a centralized, evolving document that contains history, encounter information, and laboratory results. The level of data immediately available to clinicians is staggering, but it comes at a cost to flexibility.

Ignoring the diversity in CIS vendor offerings, a basic implementation would consist of servers, workstations, network infrastructure, and software. Each component provides a specific function, and the failure of any results in a failure of the whole. The aforementioned user-perception of IS/T as a utility impedes worker comprehension of their actions on the collective infrastructure. Essentially, individual users have no concept of their singular actions on system-wide functionality. At the final stage of this model, speed, reliability, and stability influence clinician workflow. If a virus outbreak occurs, increases in latency may inhibit clinician documentation or physician access to emergent information. For an industry in which time is a crucial factor, this is unacceptable.

The integration of a code of conduct seeks to minimize the impact of risky computing behavior, but not through ethical corporate compliance. Instead, these restrictions on computer use originate from IS/T departments, whose objectives are not always consistent with the collective needs of the organization (Healy & Iles, 2002). This suggests IS/T departments are inhibiting the success of sociotechnical systems based on control, not alignment with organization goals.

Referring to the healthcare example, not everyone in a hospital uses a CIS, thus rendering the previous model inconsistent for the whole of an organization. This returns to the sociotechnical systems need to accommodate employees with appropriate IS/T solutions. Insofar as clinical documentation, speed, reliability, and stability are integral, although that represents only a fraction of the company. For marketing, human resources, research, or academics, a permissive strategy to IS/T implementation addresses changing social needs. Dynamic changes to IS/T as a function of organizational culture are a fundamental method by which businesses meet the needs of users and subsequently, the organization (Bieberstein, Bose, Walker, & Lynch, 2005; Yang, Moon, & Rowley, 2009).

IS/T leaders must recognize the balance inherent in sociotechnical systems. Adequate collaboration between IS/T departments and business units is necessary to establish solutions that underscore the organization’s mission and the needs of employees. This may not create a paradigm shift in user perception of their collective impact on infrastructure; however, enabling employees to innovate is far more important. The goal of any corporate IS/T department should be to provide users with precisely the tools they need to suit their efforts. Similarly, the goal of any business unit should be to facilitate these behaviors.

Bieberstein, N., Bose, S., Walker, L., & Lynch, A. (2005). Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals. IBM Systems Journal, 44(4), 691.

Blumenthal, D. (2009). Stimulating the adoption of health information technology. The New England Journal of Medicine, 360(15), 1477.

Doctorow, C. (2009, March 12). The high priests of IT—and the heretics. Harvard Business Review. Retrieved March 2, 2010, from http://blogs.hbr.org/now-new-next/2009/03/the-high-priests-of-it.html.

Hamelburg, M. (2009). EHR and HIT incentives in the American Recovery and Reinvestment Act. Intellectual Property & Technology Law Journal, 21(6), 7.

Hartley, K. L. (2005). Defining effective service level agreements for network operation and maintenance. Bell Labs Technical Journal, 9(4), 139-143.

Healy, M., & Iles, J. (2002). The establishment and enforcement of codes. Journal of Business Ethics, 39(1/2), 117.

Karten, N. (2004). With service level agreements, less is more. Information Systems Management, 21(4), 43-44.

Katz, R. (2003). The human side of managing technological innovation (2nd ed.). New York: Oxford University Press.

Scott, W. R. & Davis, G. F. (2007). Organizations and organizing: Rational, natural, and open system perspectives. New York: Prentice Hall.

Yang, H., Moon, Y., & Rowley, C. (2009). Social influence on knowledge worker’s adoption of innovative information technology. The Journal of Computer Information Systems, 50(1), 25-36.

I really have to hand it to Randall Munroe of XKCD fame for his latest comic. Having worked in healthcare information systems and technology (IS/T) for roughly five years, I cannot think of a better example of our service-based economy. Consider again that comic, the hardworking system administrator awoken in the middle of the night, mere hours before they’re required to be at work, just so they can restart an OS service or repair hardware. Because any uptime lower than 99.9% is just too damn hard to bear. Moreover, although the content of a sysadmin’s occupation may be a full order of magnitude above a rank and file employee whose employer can make small concessions, I think sysadmin responsibilities are something worth discussing in greater detail.

Going back to my experience as a clinical systems analyst, I recall how often I was required to perform “on call” duties with each of my jobs. With most IS/T jobs a 15-minute response time from the point of service is average, the resolution time for the problem may vary between one business day to five and that depends entirely upon the industry and service-level agreements (SLA). Now, before I continue, it’s important to recognize that 99.9% uptime is absolutely critical for some [hospital] applications. In fact, anything lower than 100% uptime would be highly undesirable and borderline dangerous depending upon the circumstances. Nevertheless, we need to acknowledge the impossibility of flawless redundancy in light of financial and technological restrictions (Sauvé, Moura, & Marques, 2009).

For example, let’s say the Help Desk at a hospital receives a phone call from a nurse at 7:30PM, not late for most people. The Help Desk Specialist records the call data and rings me with the details. I now have 15 minutes to respond until my backup (another clinical systems analyst) is called and a further 15 (30 minutes total) before my manager is contacted to escalate the issue. Fortunately for me, I get the call in time, understand the issue, and solve the problem over the phone; a simple data entry failure. This would be a best-case scenario. This is highly symptomatic of nervous or uneducated systems users, and attempting data entry a second time might have corrected the issue without wasting my time, the Help Desk’s time, or—more importantly—the nurse’s time. Furthermore, this raises an important question regarding healthcare IS/T efficacy: Why did the nurse not simply place the order with an analogue system in lieu of clinical information system (CIS) failure?

When considering the infeasibility of 100% system uptime, it is reasonable to maintain an analogue system juxtaposed with the superior digital alternative.

In other words, if an important business function can only occur through one system and that system is prone to failure, that function should automatically fail over to an alternative without disruption. Unfortunately in IS/T, this often becomes a customer service issue, a call to the oft-stated “IT as a utility” mantra, a hindrance to the perceived efficacy of any IT department and requiring more than just technical expertise (Murnan, 2003). But if Landry and Koger’s (2006) thorough analysis of disaster recovery suggests anything, it’s that your organization is invariably at risk. Whether that risk is environmental, political, or technological, there will always be a threat to infrastructure uptime.

What pertinence this has to system administration is the specious reasoning on which remote support hinges. Maintaining high levels of remote support for systems that should be capable of functioning reliably or without technology at all seems intrinsic to poor leadership.

Consider again the aforementioned healthcare example. What if a CIS failed and a patient’s chart was unavailable for emergency surgery? Or the cluelessness of an intern who suddenly realizes she’s lost the skill to write a paper chart because she’s so well-adjusted to an electronic medical record (EMR)? If any system requires significant uptime to maintain core business competencies, it is negligent to assume work can be done remotely or needs to be done at all. The solution is rather simple: maintain permanent operations staff to ensure redundancy and 100% uptime, or train users to failover to an analogue process. That said; make sure you have an analogue process. Disrupting sysadmins for issues that could easily wait until the following morning illustrates poor perception of system uptime requirements by both technical and non-technical departments. In the case of reverting to paper medical records, a successful CIS would have the ability to retroactively scan and archive the document as though completed electronically.

This is not an excuse to eliminate “on call” responsibilities for sysadmins, but rather to illustrate the growing customer service demands on IS/T support that do not address serious failures within an organization’s infrastructure. Sysadmins should be a last resort; you should have the reliability and support present within your organization to eliminate (or at least, minimize) the need for remote system administration.

Landry, B. J. & Koger, M. S. (2006). Dispelling 10 common disaster recovery myths: Lessons learned from Hurricane Katrina and other disasters. Journal on Educational Resources in Computing, 6(4).

Murnan, C. A. (2003). Deep in the heart of client services: It’s not just about hardware and software. Proceedings of the 31st Annual ACM SIGUCCS Conference on User Services. New York, NY: ACM.

Sauvé, J., Moura, A., & Marques, F. (2009). Business-driven design of infrastructures for IT services. Journal of Network and Systems Management, 17(4), 422-456.