Lexicon

lex·i·con
/ˈleksiˌkän,-kən/
noun
the vocabulary of a person, language, or branch of knowledge.
“the size of the English lexicon”

– Google, 14 January 2017

To communicate complex technical concepts effectively, people need to speak the same language. The use of technical terms must remain consistent and logical to promote understanding. The absence of common, consistent language hinders the free exchange and easy comprehension of ideas. This is particularly true of system administrator communities that have to deal with a huge library of technical terminology.

Nerds (I use that term affectionately and apply it to myself) have a tendency to invent their own terms for products, processes, and concepts. Some technology professionals cling to incorrect terms, even after learning the correct ones. The best of us misspeak at times, especially when terms sound similar or describe similar things. That is fine, we’re all fallible humans.

The use of incorrect terminology becomes a problem when someone knows the correct term and deliberately uses an incorrect one out of preference. Those of us who have been working on Macs since they were all-in-one beige rectangles may feel a certain amount of “geek cred” when we use older terms, but this can confuse people who are new to the topic, making it difficult to join the conversation. This can also steepen the learning curve as a person new to the topic may not be aware of all of the historical or nonstandard terminology.

At The Mac Admin, we primarily discuss Apple products and services, so we use Apple’s own style guide to describe them. When discussing any other vendors’ products we will use that vendor’s style guide where available. When a guide is not available we will use the vendors’ documentation as a guide. When we need to discuss a concept that does not have any vendor-official term, we will do our best to be consistent and remove ambiguity by defining the term the first time we use it, remaining consistent in that definition, and avoiding terms known to have many conflicting definitions.

For further reading…

Apple Style Guide by Apple Inc.

Mordac the Preventer is Dead

Dilbert.com

The title of this post refers to a character from the Dilbert comic strip by Scott Adams. Mordac is a systems administrator whose “demeanor suggests he simply takes pleasure using his management and technical powers to make the users of “his” systems suffer. This sort of system administrator has long been accepted or even the norm in enterprise IT departments while at the same time being the bane of end users’ existence.

Practitioners of this style of administration are living on borrowed time, unless they change their attitudes.  Systems that lock, block and prevent users from doing things generally create minimal, if any, value and can cause severe hindrances to productivity and morale.

In most organizations, IT is an expense and distraction from the organization’s goals which tend to be things like making money or educating people.  As such, it is in IT’s own best interests to support the success and efficiency of those who contribute to the organization’s primary goals.  When a “Mordac” controls the user experience,  and the standard answer to questions users pose about new and innovative products and workflows is “no”, there are only a few outcomes, none of which are ultimately good.  Assuming the users comply with the denial, the organization may be missing out on increased efficiency and/or competitive advantage.  More likely though, the users will do as they like anyway, potentially exposing sensitive data, or simply getting the job done better without IT.  Either way, IT is far from the hero in this scenario.  I have lost count of the number of times I have visited an office and found the computer issued by the organization sitting in the corner, powered down and the employee working away on a personal laptop.  When asked about the organization’s computer, the usual answer is something like “I can’t use the [expletive deleted] thing, IT is too restrictive”.

Be proactive.  Enter a dialog with the end users.  Have them define their needs as well as wants.  So long as they serve the organization’s goals and don’t run contrary to any legal requirements imposed on the organization, do your best to fulfill them.  When you can’t, let the users know why.  They may have influences you don’t and can help overcome obstacles.  If a particular obstacle can’t be overcome, at least they know you tried and that you’re on the same team.

iOS Deployment Models for OS X Deployments

As Apple continues to blend systems and features between OS X and iOS, lessons learned from iOS deployments are increasingly valuable to OS X deployments.  In Apple’s iOS 6 Education Deployment Guide, three deployment models are identified.  These models are adapted to OS X deployments below.

  • The Personal Ownership model  is described as “similar to the typical consumer experience. The education institution may or may not own the iOS device, but the end user takes responsibility for ongoing maintenance and retains ownership of all apps and content.”  This model is applicable to a great many OS X deployments.  I often define this as the user’s “functional ownership” of a computer even though the user may not have financial or legal ownership of the computer(s) in question.  Bring Your Own (BYO) programs clearly fall into this model, however it’s not uncommon to find organization-owned computers deployed in such a manner. If the end user has an administrator account, you may be dealing with a personal ownership model.
  • The Institutional Ownership model is what I have often described as a “traditional IT environment”.  Words and phrases such as “lock down” and “prevent” are prevalent here.  The user typically doesn’t have an administrator account and is often limited in how much they can deviate from the organization’s Standard Operating Environment (SOE, a useful term not very widely used in the USA, but prevalent elsewhere).  Given a clear, finite and realistic set of requirements based on the functions needed by the end users, this model can be used to great effect. The environments where this model works best are those with well-defined workflows. Creative users tend to be stifled in such an environment, and it takes a great deal of work and preparation on the part of an IT staff to ensure that systems deployed under this model are able to respond to changes in user need and advances in the technological ecosystem.
  • The Layered Ownership model blends the two models already discussed.  According to Apple, “The Layered Ownership deployment allows for both the end user and the institution to own their respective content on the same device, and the end user performs the majority of maintenance tasks on the device.”  This seems like the best of both worlds.  The organization protects its data and assets while freeing the user to work in whatever manner they find most efficient.  In this model, the user would have an administrator account, but the computer would receive some configuration and management from the organization’s IT staff.

Data

Proprietary and/or confidential data should be a primary concern of any IT organization.  iOS neatly sandboxes each application’s data making it easy to protect through managed apps, but this is not yet an option in OS X.  The growth of cloud systems, both public and private, may provide a solution.  Sensitive data can be accessed via secure websites and/or applications.  If the data is never resident on the client’s hardware, there’s nothing to leak.

Nomenclatural Consistency; RIP Imaging

This post is, in part, a response to Anthony Reimer’s well thought out article on deployment terminology, appearing at AFP548 on 21 May, 2013.

I do agree with a great many of Mr. Reimer’s points.  It is helpful to the profession at large, if we adopt some sensible terminology that is not only consistent, but aligned with Apple’s own lexicon.  After all, this is Apple’s world and we’re just living in it.  It surprises me how often Apple-focused technology professionals, at times even Apple-badged employees, display an ignorance of, or on rare occasions, contempt for Apple’s own established lexicon.

Some words in common use are archaic and should be culled from our collective vocabularies.  The entry for the word “machine” in the Apple Style Guide reads: “Don’t use when you mean computer” (italics Apple’s) and appears thirty times in Mr. Reimer’s article.  In the blue-collar mentality many of us have, “machine” brings about grand romantic illusions of a hardworking sweaty engineer in the bowels of an engine room.  The term also serves to portray the computer as a Victorian engine, whirring and clicking along as it solves a never-ending list of calculations.  This may be a lovely vision if you’re a fan of steampunk, but this vision is far from the reality of the solid-state computers and iOS devices with virtually no moving parts being deployed today.  I bring up this point not to nitpick, but to suggest consistency.  Apple has developed and published its own lexicon.  Why should we ignore that and invent our own terms?  I believe it is far more efficient to use Apple’s terminology whenever applicable and only invent new terms where there is an absence of terminology from Apple.

Another term you’re likely to hear, particularly from sales professionals, is “silos”. A common theme is to draw hard lines of distinction between organizations with terms such as “education”, “enterprise” and “government”.  Why create unnecessary divisive language?  Having worked in and for all of these types of organizations, I can attest that, at least for IT staff, they are purely artificial distinctions and serve only to satisfy the misconceptions and/or egos of the C-level or non-technical management staff.  Computers are computers regardless of whether the goals of the organization using them is to make cheese, cars, laws or to educate children.  Each organization is unique in the set of requirements it lays out for itself, with most organizations assembling their requirements without regard to whether an individual requirement is believed to be an education, enterprise or government item.

The bit of Mr. Reimer’s article that resonates with me the most is the term “customizing”.  I believe that imaging is dead and it’s successor is customizing.  With the prevalence of high-speed networks, Apple Recovery HDs, and advanced management tools such as The Casper Suite and its ilk, that there are few, if any, reasons to ever apply an image to a Mac.  One of the biggest challenges Mac system administrators have historically faced is that of creating a single operating system image or installer that will work on all of their hardware.  Many solutions have been put forth, most of them quite clever, but all sharing the fatal flaw that they are unsupported by Apple.  When you step outside supported models, you cause the proverbial buck to stop with you.  The last thing I suggest doing in any deployment scenario is to make yourself ultimately responsible for malfunctions.  The solution is at once easy and obvious.  Apple ships each computer with a functioning operating system.  Erasing and replacing that operating system is a waste of time.  Using deployment tools, the factory-installed operating system can be configured to meet the organization’s needs.  The only semi-valid argument I have heard against this approach comes from very security-conscious entities claiming that they can’t trust the installation that comes from Apple’s factory.  To these organizations, I ask: Will you be using Apple’s installer to replace the system you’ve erased; and if so, how is that any more secure than the original installation?

You may be thinking that this is all well and good for a new computer, but what about when a computer needs to be repurposed or reassigned?  This is where NetInstall, the Apple Recovery HD, or Internet Recovery if necessary, comes in.  Using Apple’s own installer, the disk can be erased and a fresh operating system, designed and tested by Apple for the hardware in question, can be installed.  Then it’s a matter of customization for the computer’s new intended use.

Lock It Down

securityIn the previous article, we discussed the consumerized model of IT.  Now let’s have a look at a locked down model, and some guidelines that will help maintain sanity both for the IT group and the user community at large.

Why Lock Down?

After considering the consumerized model, one might think that it sounds so progressive & cost effective that no one should bother locking down computers any more.  Well, no solution is one-size-fits-all.  If there is an existing user community accustomed to a certain level of support and management, or if there are legal requirements to satisfy, we can’t simply board up the help desk and redirect the support line to the nearest Genius Bar.

By far, I see legal requirements as the most common and important reason to maintain a locked-down environment.  Legislation such as SOX & HIPAA, and standards such as PCI all place limits on how certain computer systems are allowed to operate.

In some organizations, it may be important to remove distractions and potential wrong turns in workflows.  There are still plenty of computer illiterate people in the workforce.  If these folks dominate an organization, it may be wise to limit the damage they can do through a series of electronically-enforced policies and restrictions.

No Admins

When implementing a locked-down model, I believe in one cardinal rule: In a locked-down environment no user outside the IT team should have administrative privileges.

If  this rule is broken, the environment is no longer locked down.  Administrative privileges are the keys to the proverbial kingdom.  A user with administrative privileges can change or remove any or all enforced settings, add or remove software as they see fit, and disable reporting to any inventory or compliance systems.  In short, IT cannot maintain any sort of Support Level Agreements or ensure compliance if the users have administrative privileges.

Even within the IT team, administrative privileges should be used only when necessary, meaning that IT staffers should be using non-admin accounts to do their routine work but have the means to elevate their access when needed and within carefully considered limits to balance security, accountability and efficiency.  An IT team that operates with administrative rights will usually have no idea of the issues faced by the typical non-admin user.  In addition, IT staffers are people too, and as such are prone to mistakes and bad judgement just like the rest of us.  Detailed and strict processes help to mitigate human error.

IT departments often face political pressure or directives from superiors to make exceptions to a “no-admins” policy.  If you find yourself in this position, I recommend preparing a cost-benefit analysis for your superior(s).  This report should include things like  data loss, lost productivity, support costs, and the costs of lost opportunities.  I have always felt that it is part of the job of an IT staff to let management and the business know when they’re trying to do something detrimental.  It is more desirable and generally less costly to prevent problems than fix them after the fact.  When an employer asks for something dumb, it’s a good idea to tell them it’s dumb and why it’s dumb in a quantifiable (and tactful) fashion.  If they still insist on the dumb thing, they can’t blame you for not doing your due diligence and informing them of the pitfalls.

When Not To Lock Down: Social Issues

Technology is often called upon to solve social issues.  I see this as a waste of time and resources as well as an unnecessary restriction of user capabilities.  Rather than limit everyone for fear that someone may misbehave, I feel it is much more productive to only punish the miscreant if misbehavior occurs.  There are many reasons to lock down computers and their functions, but in this sysadmin’s opinion, solving social issues should never be one of them.

Another Mac sysadmin once said “you can’t teach a backpack not to carry a Playboy” in response to a request to ensure that “naughty pictures” couldn’t appear on a school’s computers.  If little Bobby is caught with a Playboy in his backpack, it is confiscated, he’s sent to the principal’s office and Bobby is given the prescribed punishment, all because Bobby has misbehaved.  If however, Bobby accesses similar material in a computer lab, the IT staff ends up taking much of the blame because it happened on a computer, even though it’s still Bobby that misbehaved.  Misbehavior is still misbehavior whether it involves a computer or not.  If little Bobby is looking at naughty pictures in school, that is a disciplinary issue to dealt with accordingly.  Similarly, if Sally in accounting is playing solitaire all day and not doing her work, then Sally’s boss needs to have a chat with her and/or start looking for a new Sally. Technology is a moving target and users, especially children, are very resourceful and have nothing but time on their hands.  An IT staff that tries to manage social issues with technology will find themselves fighting a battle that is impossible to win.

Only Lock What Is Necessary

Heavy handed restrictions are the most likely to be circumvented.  I have been to offices where end users have very expensive company-supplied computers on their desks but never use them because they find the draconian restrictions imposed by an overzealous IT staff make the systems unusable.  These employees end up bringing their own laptops to work, thus creating a de-facto Bring-Your-Own model that the IT group has absolutely no control over, and often no knowledge of.

Each restriction that is not legally or contractually mandated should be carefully examined to determine if it is actually necessary.  What risks are being mitigated, and what are the potential impacts on user productivity?  Does the potential risk outweigh lost productivity and/or user dissatisfaction?  Unless the answer to that last question is yes, the restriction shouldn’t be implemented.

I hope these ideas will help make your restrictions more sensible and useful.

Consumerized IT or Bring Your Own

openLock

On any given day, I’m likely to have some form of conversation that includes a discussion of why no one should have administrative privileges, or why everyone should have them and IT shouldn’t care.  To paraphrase Mr. Kenobi, both arguments are correct, from a certain point of view.

The core of the issue comes down to determining what is most important to an organization.  Some organizations need extreme control and security.  In these organizations, having computers and devices locked down and only capable of performing approved tasks is required, often by law.  Many other organizations may not be bound by these laws or have as great a need for security and may instead place greater value on creative freedom and the flexibility to be productive according to an individual’s own work habits and quirks.  Since the locked-down model has been the IT standard for decades, we’ll leave that topic alone for now and instead discuss some of the ideas behind a consumerized model.

What Is Consumerization

The consumerization of IT is a topic that is in relative infancy, but rapidly growing, sort of like “cloud computing” was just a short few years ago.  Being a young and evolving concept, it’s not uncommon to to find varying definitions, and what follows is my own working definition as of December 2011.

“The Consumerization of IT” describes a trend where organizations expect employees to own a computer, be able to use said computer, and be able to obtain service and support for that computer.

Similar to the fact that most employers expect their employees to own and maintain phones and the means to get to work, a company following a consumerized IT model expects employees to own and maintain a computer.  These organizations may give employees a stipend to purchase the computer or may even provide a computer, but offer little to no support for the device or common commercial software.  This approach is often referred to as a bring-your-own or “BYO” model.

The primary goals of IT in a BYO scenario are to provide access to proprietary data and software tools that the user community needs to accomplish the organization’s goals rather than duplicating the support efforts of Apple, Microsoft, et al.  Schools worry about the educational process and a bread company worries about making and selling bread.  Both leave the business of Mac OS X support to Apple, Word support to Microsoft and Photoshop support to Adobe.

Why It Works

At the dawn of IT, we had to cope with baby boomers who grew up with slide rules and musty encyclopedias.  These people needed legions of helpers to translate the digital voodoo that would allow them to do their jobs.  Baby boomers are now retiring in droves.  Their children and grandchildren don’t need the same kind of handholding.

Also consider the fact that the young people who have entered the workforce in the past several years, and will be entering it going forward, have grown up with computers almost since birth.  These people came through school using the Internet, word processors and cellular phones.  Children born on the day the Internet was opened to commercial activity have bachelor’s degrees now.  These young adults may have been using an iPhone for as long as or even longer than their employers.  Aside from having a level of competence with technology, and perhaps because of it, these employees are more likely to chafe against a tightly locked system.

Some Management

Whether it’s software distribution, managing compliance with legal guidelines, providing critical software patches, or configuring an email account, even organizations that have consumerized IT will benefit from some degree of client management.

Since the end user will be in ultimate control of the computer, it is important to have clear communication between IT and the user regarding the management tools used and what is expected of each party.  A balance must be struck between the privacy needs of the employee and the security needs of the employer, and the stipulations of that balance should be well understood by both parties.

How It Works

Since the end user has administrative privileges, common IT terms like “push” and “lock” don’t apply.  To have effective management, we need to link compliance with desired and/or required items.  Examples might include automatically locking out a user’s directory service account if their computer doesn’t comply with security requirements or removing network access and/or email configurations if the device fails to meet other agreed-upon management requirements.  In this way, we are able to give the end user the tools they need, but only when they agree to and comply with the organization’s policies and requirements.

Software installations and even many management tasks may be delivered by a client-driven mechanism, such as The Casper Suite’s Self Service tool or similar mechanisms; although there will likely be some settings such as those discussed above that will be enforced as a mandatory requirement of participating in the BYO program.

It is important to design the systems and processes involved to be as simple, user friendly and foolproof as possible.  While today’s end users tend to be more savvy than their predecessors, not everyone is a technology nerd, and shouldn’t be expected to be one.  Apple users in particular expect things to “just work.”  Maintaining that same high level of usability should be a requirement of any BYO project.  If something can be done in two clicks, don’t make the user do it in three.  Make sure interfaces are labeled well and consistently.  Finally, always use the system yourself.  You can’t relate to your users’ frustrations very well if you never use the systems they use.  If you find yourself not wanting to use a system, that’s a great indication that the system needs work.

I hope this overview proves useful.  We may explore these concepts further in future articles if there is significant response.