Audits, part 2

Part 1 of our audit article certainly pushed some buttons. I received quite few emails regarding previous and current management that insist upon overtaxing existing infrastructure, and/or are completely oblivious to the fact that there is a limit to how much electricity you can use, even though there are plenty of outlets left…On the positive side, I received a reminder regarding vehicles. Many of the larger production truck/trailers have meters on them for power, but it is easy to forget about HVAC loads. On the subject of loads, when adding equipment to vehicles, make sure you consider weight and balance, as both can affect handling and licensing.

Certainly, power and HVAC are big items that need to be monitored for capacity and growth.The explosion of networked equipment brings with it many other areas that really should be monitored but rarely are. These include IP addresses, network bandwidth, usernames and passwords as well as software licensing. Each of these items could be an article in itself, but for now we will touch on the highlights as facility size can greatly influence how they could be handled. Within a small group or facility, these items might all be handled by one person on an as needed basis. Larger facilities might have one or two dedicated staff members assigned to the task, or even outsource it to a local IT shop. Most of the larger groups and networks will have a complete departments focused on tracking all these items and more. In short, the larger the network, the more people will be needed to keep it healthy.

IP addressing is a simple concept that can easily turn into a nightmare if not tracked. For instance, let’s say you take the easy route, set up for DHCP (dynamic host configuration protocol) and allocate a class C address range (256 addresses—254 usable) to the facility. Six to twelve months later, you plug in the 255th device and cannot get an address. In the heat of the moment, the last thing on your mind is going to be that DHCP allocation pool running out.

Setting static IP addresses and keeping track of them on a spreadsheet might be an entirely easier endeavor, if for no other reason than you have to look at it once in a while to get new addresses. DHCP works very well in an office setting where laptops come and go and do not need a set address. For stationary equipment, I have always had much better luck with a static addressing scheme and keeping track of the addresses in a spreadsheet, database or web application.

If you have no idea how your addresses are setup or used, there are numerous network scanners that can provide considerable details as to your network layout. Make sure before you use them that you have the necessary rights and permissions so that the scan is not viewed as a hostile threat. One facility I know of ran a scan on what they thought was an isolated network of about 200 machines and found that someone had infiltrated that network and there were more than 1500 addresses that could access the network—a major security risk!

Network bandwidth, much like all those extra outlets is something that can easily be higher than expected if not monitored. Many switches provide GUIs and SNMP alarms that include bandwidth utilization. Like power and cooling these systems need to be checked regularly and tracked to ensure they are not overcapacity and are in line with expected growth patterns. Trigger points for additional capacity can easily be established well in advance. This will provide additional data when submitting budget requests. Tracking data, combined with previously agreed to limits can make it much easier for management to approve the necessary funds.

Users and passwords are tricky. Obviously, there should be no unauthorized users on your network, but how many pieces of equipment have the default user and password as the primary way in? If the device is on the network and there is access from the outside, it can be a real security problem. How many people have the administrator or root password to the network servers? Do you trust them all? Can you track them? Administrator passwords need to be well guarded, but not too well…if only one person knows it, and they get hit by a bus; then what? A hierarchy of leadership and technical personnel needs to manage the ‘keys’ to the system. Passwords need to be kept secure, but major network passwords should not be trusted to only a single individual. Every business is different, but technical personnel with passwords need to ensure that necessary passwords are accessible by others in the event of an emergency.

As you can see, there are plenty of things within the facility that need to be monitored. If your facility is like most, you are too busy to track these items. Unfortunately, the less they are monitored, the more likely a crisis is. If nothing else, simply mentioning the fact that your current capacity is unknown might get you some help in finding the answers. Good luck!

Posted in Basics, Control, General | Leave a comment

Time for an audit?

Facilities change. ICs replaced transistors, digital replaced analog and HD is replacing SD. One would think that with all the miniaturization, heat loads and power requirements would shrink also. Maybe they did in your facility, but not mine. Any gains I might have realized from reduced loads from video and audio gear have been offset two-to-tenfold by the servers and network gear that is now needed. What’s an engineer to do?

One solution is to hire a local HVAC professional and get a facility audit. They will come in, do a survey of the various heat loads and cooling capacity and determine what is needed. More importantly, they can show you where you have too much cooling, or not enough. Balancing the system so that the cooling is where you need it, instead of where you don’t can make a big difference. They will also determine how much extra capacity you have. This would be a good time to discuss backup cooling. Typically, broadcast facilities have a large cooling unit for the studio. It is needed whenever the studio is in use. If you don’t do daily newscasts, can it be a backup for the equipment area?

As the northern hemisphere moves into summer, HVAC may be the primary concern, but don’t forget about power. If you are short on HVAC, do you have enough power capacity to add another cooling unit? Is it on the UPS/generator? How will you upgrade your power? This is another time for a local professional, it may also be the time to get the local municipality involved. The same applies to corporate management.

One way or another you have some responsibilities. Maybe you have a five year plan, maybe you need to support corporate’s five year plan. Maybe you have the responsibility to modernize an old facility. Maybe you are one of the lucky few that gets to design and build a new facility. Any way you look at it, you need an understanding of what your facility is capable of supporting and how much of that capacity you are using. The last thing you want is put in that new server farm over the winter, and have it meltdown the first time outside temperatures exceed 90 degrees and your AC can’t keep up.

Posted in Basics, General | Leave a comment

Software changes everything

For months this column has discussed reviewing logs, automating processes through scripts and other items that take advantage of today’s technology. What hasn’t been discussed is how easily and effectively today’s technology can take advantage of you if you are not careful (and sometimes even if you are).

RTFM (read the friggin manual) has long been the cry of those that manufacture hardware and software. Lately, however, reading the manual has got me into more trouble than it has gotten me out of. One main reason: The manual is for software version ‘x’ and the device is running version ‘y’ or ‘z’. Rarely, it seems, does the documentation keep pace with the release schedule. To be fair, the technical writers normally need the information long before the software is complete, and changes happen along the way. Few, if any, project managers can keep up with all the changes.

Long ago I had a discussion with a very sharp software engineer. It revolved around the ability of film/video production teams to get things done on schedule, or at least on time, despite continuous change. Change to a group of software engineers is the enemy. In software development, change often causes major amounts of re-work. In production, especially news production, change is constant. And while it may not be a friend, it is accepted as part of the way things happen. The concept of ‘news’ doesn’t work if things don’t happen at the last minute. If nothing changed today, there would not be any ‘news’, it would all be ‘old’.

Software changes seem to be happening more and more often. Nearly every day, I get an update automatically installed in my PC. While I may not be happy about it, it seems to be better than leaving security holes open. Modern professional devices, especially the newest ones, seem to require a lot of upgrades, patches and bug fixes. These devices are used in professional applications where clients and billing are at stake. The last thing you want is for an automatic update to bring down the system due to some incompatibility. In these cases, carefully controlling and testing any upgrades is your best bet. Ideally you have a backup or test device that can be upgraded prior to putting the upgrade in your main system. It is always a good idea to test each upgrade (several times if possible) prior to putting it online. Good documentation, procedures and back-out plans are always a good defense—so is a complete system backup. Additionally, you want to read the release notes and understand what may (or may not) be fixed by this patch/release.

Even the above is not enough. Not all changes are documented in the release notes. Undocumented features are just that—undocumented. In some cases that is a polite way of saying they didn’t work, they are buggy, or they won’t be in the next release. Precise configurations that work with version 2.x may cause minor issues with version 2.y but will prevent version 3.z from working entirely. Do you have a support contract? If so, run current configurations by the vendor and have them confirm you are running with the right settings for your environment. Have them also confirm that those settings are compatible with the release/patch you are planning to install. If the system is running on Linux or Windows, have you added scripts or cron jobs that may be wiped out or may cause unexpected results when the system is patched? Do you have a backup of those customizations? Has the vendor weighed in on whether or not they can cause issues on the system?

I have come to the conclusion that updating software can be the equivalent of removing the old device and installing a new one. Even though the hardware remains, the device can wake on new software with little or no resemblance to its former self. Years ago that was an enticing prospect—all the latest features without having to buy new hardware. Today it seems that new features, configuration changes and the opportunity to ‘brick’ the device due to a failed upgrade, offer a nearly equal opportunity for success or failure. Software changes everything.

Posted in Basics, General | Leave a comment

Routers, what’s in a name?

Often the term router must be given some context. Depending on who you are talking to, the listener might think of a network router used on an Ethernet network, an A/V routing switcher or even a powerful tool for working with wood. I use all three, and am constantly amazed at the power and versatility of each in the hands of skilled personnel. Despite our focus on IP, this article will look at the A/V version.

For years, I have been a fan of the multilevel routing switcher, or as it is called in some circles, the crosspoint matrix. They are an essential part of nearly every broadcast and production facility’s infrastructure. Flexibility is the key advantage. Unfortunately, while the inputs and outputs increase linearly, the crosspoint count increases exponentially. This has kept some from purchasing these workhorses in favor of patch panels and other simpler solutions. With the coming of age of packet switching networks, it seemed that routers would become less useful. Nothing could be further from the truth.

I recently designed a control room for monitoring an IP-based (Microsoft Mediaroom) 700 channel headend that manages 10 separate markets from coast to coast as well as all of the supporting infrastructure. The system utilizes numerous technologies including composite A/V, ASI over coax and UTP, and multicast streaming of both MPEG-2 and MPEG-4 (h.264) over traditional TCP/IP networks. We have multiviewers and cyclers to constantly monitor all channels (national and local) on the STBs, and there are plenty of monitors scattered throughout the facility. In addition, numerous web servers provide status on alarming, as well as server and network health. In the end, the key to bringing the entire design together was a 64×64 HDMI/DVI crosspoint matrix.

Nearly 95% of the sources had either DVI or HDMI outputs. Monitors for computers as well as TVs typically support one or both and HDMI offers audio. All of the STBs from the various markets exist in our facility, now any STB from any market can be pulled up on our viewing wall or desks for QC checks. Our main viewing wall has computer outputs for the health displays, and because of the router, these too can be brought up on our desktops as needed. We ended up settling on two monitor types; one set of 42” displays for the viewing wall, and some low cost TVs for all desktop work. The TVs have HDMI and VGA inputs and are used for both the router outputs and our laptop/desktop PCs.

While none of the personnel had any experience with this type of router, all are pleased and wondering how we got along without it.

Posted in Audio, Basics, Video | Tagged , , , , | Leave a comment

Revisionist Thinking

One of my early broadcast projects involved building a remote edit suite for a pair of Ampex VPR-80s. The suite was located in a corner of the studio about 50 feet from the machines themselves. Due to the cable route, the cables were close to 75 feet long. At the time, the only control other than the front panel was a parallel cable. As I recall, each connector was about 60 pins. These were solder pins that were placed in a large connector block (~2.5” x 1”). A pin inserter/extractor tool allowed the pins to be soldered outside the block then inserted. Inevitably, with that many pins, one or two were inserted into the wrong positions and the extractor tool made it relatively simple to correct. Relatively large gauge cable had to be used for several of the connections as the edit controller was powered by the machines. When it was all said and done, the remote cables weighed in at about 100lbs. Within a year, serial control became available. What a difference! Today, an Ethernet cable or even wireless is all that is needed to control a variety of equipment.

Technology has come a long way, and I am finding myself seeking features I would have never considered. For instance, the thought of a radio card inside a PC never made much sense when an inexpensive radio cost $50, but the PC was $1000 and the radio card another $25-$50. Recently though, I needed an audio amplifier with a web server. Why? I am building a control room for an IPTV headend and one unusually troublesome item is the number of remote controls on the desk. There are often two operators or more, and remotes are constantly being shuffled around. The new control room has provisions for audio at each operator desk as well as separate audio for the room. What I needed was a way to control the room audio without placing the amplifier in front of one operator and without a physical remote control. Several consumer manufacturers are offering iPad control, but in this application, an iPad is just another device to clutter the desk. Sure enough, Denon (and others) offer web-based remote control of their receivers. Problem solved.

It is interesting that the solution is essentially a PC inside of a radio, rather than the other way around. The question, and real point here is: how are you using technology? Are you applying old patterns such as parallel remote control to new technology? Or, are you thinking outside the box and seeking out new ways of doing things? Once new technologies are embraced, it often becomes harder to solve a problem using older methods; imagine trying to remote control a file server using a parallel cable.

Posted in Basics, Control, General | Leave a comment

What are today’s broadcast skills?

Lately there has been a lot of talk concerning broadcast skills. What skills are needed in today’s job market? A good place to start is with a thorough knowledge of audio (for those going into radio) and a similar knowledge of both audio and video for those wanting to succeed in television. Because this is broadcast, some RF knowledge is helpful. I say that because I know many studio engineers that never get near the transmitter. Obviously, RF knowledge (and electrical safety) is critical if you intend to work on transmitters. Beyond that, the things I always found important were excellent troubleshooting skills, general knowledge of many systems and the ability to work under pressure.

Times have changed. Technology continues to evolve. The basics (audio, video and RF) will always be important, but new skills involving computers, networking and workflows are also needed. Knowing what analog video looks like on a waveform monitor may be helpful, but is not critical in getting an ASI feed to the next device in the signal chain. Knowing how to calculate a subnet mask may be.

I have never had an interest in running the company’s business LAN. I get no thrill out of hooking up the office printer or endlessly patching or re-imaging the sales laptops, however, networked audio and video have distinct advantages. Replacing a facility full of coax and shielded twisted pair with Cat 5e or Cat 6 cabling allows an efficiency that was not possible in the days of analog equipment. Granted, the picture quality is not what was possible then either. Cameras tweaked to 700+ TVL might have made pretty pictures on CRTs, but maintenance was high, tubes cost real money and one wrong move by studio personnel could burn a highlight into a set of tubes in a heartbeat.

Compressed digital images are here to stay. Ever more sophisticated bit-rate reduction will not stop anytime soon. One of my co-workers is a master electrician, climbs towers and knows his way around any type of communication facility, be it satellite, telco or broadcast. Only a few years from retirement, he avoids servers simply because he is smart enough to know he does not know what he is doing. However, he can network numerous devices together, configure routers and switches as well as handle MPEG transport muxes without issue. As stated above, times have changed. Knowledge of fundamentals is important, but knowing and adapting to today’s technology is far more saleable in today’s world than clinging onto technologies that never worked as well as we remember.

Posted in Basics, General | Tagged , , | Leave a comment

Common commands

Several articles back I asked the question “Command line or GUI?” While most are familiar with the GUI, many may not know where to start with the command line. What follows are some of the commands I find not only useful, but that I use almost daily. By the way, to get to a command line on a Windows system, go to Start -> Run-> and type cmd, if you do not have PowerShell, I recommend you get a copy, it is free. On *nix find a shell icon or something that indicates a console. There are a variety of shells out there and depending on the age of the equipment, you may encounter different shell versions. Also, there is no guarantee that the command you need is actually loaded on the system. Today many apparently dedicated devices are actually Linux or Windows boxes that run a specific task. Many of the ‘optional’ parts of the operation system are left out so that what remains can be stored on a small solid-state drive. Also, be aware that most *nix systems are case-sensitive, whereas Windows is usually not.

To get a list of the current NICs and their IP addresses use ipconfig (DOS) or ifconfig (*nix). I end up using this every time I check into a new hotel. My company laptop has the company intranet as its home page, and I normally have to find the gateway and type the gateway’s address into the browser’s address bar to get to the hotel’s sign on page.

telnet or ssh can be used to log into a remote machine if the ports are open. Telnet is fairly simple, type telnet and the ip address or hostname: telnet 192.168.1.11. ssh (secure shell) typically requires a username along with the hostname or ip address:
ssh root@192.168.1.11. Many systems require you to log in as a regular user, then switch to root once you have logged in. That is accomplished with the su (switch user) command. The root user is assumed, or you can switch to a different user (steve) by typing su steve. You will need to provide the password for whatever user you are logging in as or switching to.

ftp or scp can be used to copy files from one machine to another. ftp and scp clients are available for the GUI, but sometime all you need is a simple file copy, and both can be used (ftp in less secure enviroments, scp in secure areas). Command line ftp, like telnet is invoked with ftp and either the ip address or hostname. Scp is a little harder to get used to, but can typically be used at either end (source or destination) to move files either to or from another machine. It is typically called from the destination side with scp user@ip_address:remote_filename local_filename or
scp root@192.168.1.11:config.txt config.txt

In the GUI, folders are used to represent the directory tree. Within the CLI, use cd to change directories. The root, or top level directory is represented with a slash (/) in *nix and a backslash (\) in Windows. To go up one directory, use two periods (..). A single period represents the current directory. The users home directory is represented by the tilde (~). To switch to your home directory: cd ~, to switch to the root cd / or cd \ depending on the system. Most systems also have an autocomplete that will cycle through the available directories if you press the TAB key after typing cd. Windows directories may now contain spaces, and you may need to wrap the line in single quotes: cd ‘Documents and Settings’.

Often I am in a new system and not really sure what I am looking for or where I will find it. The find command is extremely helpful. The following command will search the entire system starting at the root for any file with the .log extension: find / -name *.log Be aware that unless you are logged in as root, (the super user on a *nix system), you may not have access to all directories on a system.

> and >> allow you to take the output of a command to a new file (>) or append an existing file (>>). If you were looking for something using find and found hundreds of matches, it could be difficult to locate what you want. Using find / -name *.log > logfiles.txt will produce a text file with the results that can be viewed/searched in Notepad or another text viewer.

These are but a few examples. I have found the more I use the command line, the better I get at doing complex tasks in it. Not surprisingly, there are many tasks that are straightforward at the command line but are complex or nearly impossible in the GUI without an application or special software.

Posted in Basics, General | Tagged , , | Leave a comment

Interdependence is real

Over several postings, we have discussed logs and errors. I, like many, often find digging through logs to be tedious. However, it is a necessary evil. Despite what many tell you, IP/Network/computer-based systems do not operate independently. An error in one system can ‘infect’ another, supposedly independent system. Often errors will propagate downstream, but to my way of thinking, a bad SDI signal in a router layer never affected the other SDI streams in a router. With software, and software-based hardware that is not always true.

Code is code. Well-written code performs better than poorly written code, but in the end, handling errors chews up processor time. The more time spent handling errors, and writing messages to the log, the less time there is to do things correctly. Think of it this way: Take your average IP grooming device and run the maximum number of signals through it. One groomer I have worked with recently allows 936Mb/s on its GigE port. Allowing for some overhead, let’s put 180 4.5Mb/s signals in and allow each signal just over 10% additional bandwidth for processing (500kb/s). That gives us an input datarate of 810Mb/s and an output rate of 900Mb/s. With that many signals running through the device, the processor is keeping busy. Incoming packets need to be examined, groomed if needed and output in a very consistent manner such that errors and jitter are not introduced.

If one of the signals is non-existent or creating errors, the processor needs to work harder to handle and log the error. Now, instead of one bad signal, make it twenty, or thirty, or even one hundred. Each new error adds to the processor’s workload. Each increases the likelihood that a ‘good’ signal will get stepped on because the processor was working harder than necessary. Granted, in well-designed equipment, none of these things ‘should’ happen, but in reality, software is written by people, and things get into the code that result in issues.

The bottom line is the fewer errors in the system, the fewer problems you will have. If you are not looking, you will not find them until it is too late—when the system comes crashing down. Having support contracts for today’s systems is important. Proper installation and maintenance is also important. When you purchase and install a new piece of equipment, as part of the checkout, have the logs analyzed. This accomplishes several things. First, going in and getting the logs, or watching tech support do it, provides you with the location of the logs. Second, the first round of logs gives you a baseline to work from. Third, it may reveal some things about your system that you should be aware of. For instance, what if, on the new device you set an input stream at 4.5Mb/s, knowing your constant bit rate (CBR) encoder is running at 4.5Mb/s, and the new device is constantly giving you buffer overflow errors? The first thought may be that the thresholds are too tight, but if they are set at 500kb/s that should provide more than enough room. Further investigation may reveal that despite the label in the GUI, that rate is for video rather than transport rate. When the audio is added in, the overall transport rate gets very close to the upper limit (5Mb/s). It is likely an easy fix, simply adjust the rates as needed, but something that could have easily caused errors at each and every device downstream.

So, where and how do you start? My first recommendation is to start at both ends and work towards the middle. Get a baseline of the first device in the chain as well as the last. My guess is that errors in device #1 are propagating through the system and as you address them, you will see the number of errors at the end decrease. Use tools such as grep to parse logs looking for ‘ERR’ or other easily identifiable keywords. Capture and save the logs for reference later. If you are into scripting, much of this can be automated and sent to you via daily emails. Regardless of how, the point is you need to do this if you intend to be successful in this new world of IP based systems. Good Luck!

Posted in Basics | Leave a comment

Staying above the noise floor

It used to be the question was: “Do you have a license to carry that little green tweaker?” Back then, maintenance often consisted of making numerous fine adjustments – “tweaks” to the analog devices in the signal chain. Business (read non-technical) managers found it difficult to understand that walking around checking signal levels, looking for loose screws, cleaning filters and listening for different sounds was productive. However, much of the key to keeping the system running was watching for the minor changes that indicated problems were near. Picking out (and replacing) the fan with a failed bushing prevented a piece of equipment from overheating; an out of the ordinary ‘slap’ indicated a broken claw on the cartridge eject arm of the ACR-25. All those little indicators of big problems were part of television engineering in years past. Today, short of fans, there is little to listen for in server-based equipment rooms. Regardless, there is plenty of maintenance to be done.

Servers and networks have definite maintenance needs. And, just like mechanical systems, need to be monitored for out of the ordinary events and issues. ‘Network traffic’ never really changed on a piece of coax dedicated to SDI. It was always 270Mb/s. Bit Error Rate was checked upon installation, and unless there was a problem, things remained pretty much as they were. Category 5 cables for TCP/IP are not that simple. Granted, the one carrying data for the configuration website for that ASI DA Frame may not be a big deal, but that cable is likely connected to a 24-48 port switch that aggregates numerous IPs together onto a single 10/100 link into your control network. What about that aggregate link? Is it taking errors? Are there collisions happening regularly? How would you know?

What about all the servers in your facility? Are the hard drives full? Are the fans all functioning? When was the last time the anti-virus software was updated? Are your backups working? How do you know? Do you even have backups? Do the servers have all the latest (tested and approved) software? What about support contracts and software licenses?

While all of this may be handled by your IT department for the business LAN, who is doing it for the studio equipment? Where do newsroom and weather systems fit into that model? In my experience, business IT people are fine on the business LAN, but have little interest in the equipment LAN in Master Control. Somehow those worlds just don’t fit together. It is not that they aren’t capable, it is just that they seldom have the passion needed to function effectively in the broadcast environment.

The answer is to find someone amongst your staff with the aptitude and passion needed to check and maintain the data and network side of your environment. Someone that can write scripts, navigate a hard drive structure and setup some automation to notify someone in the event of an issue. If you can’t find someone in-house, maybe a local college or trade school can identify a prospect that you could contract for a few weeks to get things setup.

It is likely that once they get started, you find out a lot more about the data side of your operation than you wanted to know. And, probably a few things that you wish you didn’t. The time to start is now, while things (hopefully) are running smoothly. That way you have something you can use as a baseline. My guess is, when you start looking at the network, logs and server systems, the number of errors will be in the thousands, and the first thing you will need to do is eliminate the false alarms (noise) so you can see the real ones.

Posted in Basics, General | Tagged | Leave a comment

Do it yourself or hire a Systems Integrator?

Let’s face it, times are tough. Ad revenue is down, costs are up and your aging infrastructure is not getting any younger. Very soon, you will be faced with a major upgrade, and the question will be posed: Do we do it ourselves, or hire an integrator to do it for us? Right off the bat, the three things you need to consider are your timeline, budget and in-house skill set. With a top-notch in-house staff, you may be able to get it done in less time than hiring an outside firm. That is mainly because an outside group needs to ramp up personnel and resources to handle your job. They need to understand your needs. You need to understand your needs. Let me say that again, you need to understand your needs. Often, upgrades start out pretty nebulous and need planning time and understanding before they are clearly focussed. Bringing in a Systems Integrator can often result in a clearer understanding of what you want and/or need.

Today’s facilities and operations are usually severely intertwined. Things are done in specific ways due to equipment limitations, personal interactions, long standing politics and a variety of other factors that have little to do with the actual work or workflow needing to be done. For instance, the current teleprompter may only accept .txt files; which leads to a requirement for .txt files from the newsroom system. Eliminating the teleprompter eliminates the requirement. Maybe it is time to retire the heavy CRT-based teleprompters and replace them with LCDs that take VGA/DVI inputs directly from a computer or newsroom system.

Bringing in an outside firm can expose some of the arcane ‘traditions’ that all facilities develop over time. They can provide a variety of alternative workflow scenarios that could be accomplished with new equipment, a new infrastructure, and yes, new thinking (read processes) around the problems at hand. Be aware that these new workflows may also require new (costlier) personnel due to the different skill sets required. Your current personnel may be able to adapt, or may not. Some may fight for their jobs by resisting the changes. Regardless, in considering these changes, consider your current personnel and how they will fit into the new roles getting their support in the new endeavor increase the chances of success..

In doing it yourself, you may face exactly the opposite battle—no new ideas and many of the old traditions will be adapted to new equipment. Years ago, when I started at the magazine, we produced one magazine a month with a staff of 5 using typesetters. For each page in the magazine, typeset paragraphs, photos and graphics were hand-mounted on clear acetate pages. Seven years later we were using Adobe Pagemaker and laser printers. We still had a staff of 5, and still produced one magazine a month, and none of the processes had been adapted to accommodate the new computer-based changes. There were plenty of opportunities to improve the process, but only a few were adopted.

So, do you do it yourself? Or, do you hire a systems integrator? Unless you really understand your needs and have the skills and personnel ready to go, seriously consider an integrator. If you don’t have the budget for a turnkey solution, maybe they can design the system and your staff can do the hands-on labor with the integrator overseeing the process. The networked world that we live in is full of both opportunities and pitfalls, if you are new to the journey, hire a guide.

Posted in Basics | Tagged | Leave a comment