Looking back: How I'd build an IT infrastructure today versus how I did it 10 years ago

Credit: Ken Lund via Flickr

Earlier this month at the CITE Forum in New York, I got the opportunity to meet some of my CITEworld colleagues for the first time. As Ron Miller and I were comparing our professional backgrounds over lunch, I described my last full-time job as an IT leader as being an organization that would today be a poster child for cloud and mobility solutions.

The conversation led me to an interesting thought experiment: contrasting the choices I made when I took over as that organization's IT director with the decisions I would make were I taking on that job today. In the process, I realized how dramatically different the pre- and post-consumerization approaches actually were.

Situation: A group of health facilities with no centralized IT

The organization is a mid-sized non-profit founded in the late 1970s as part of the national movement to de-institutionalize care for mental health patients. Its over-arching mandate is to help patients move from an in-patient treatment environment to progressively less restricted environments with the ultimate aim of helping clients live independently. To reach that goal, the organization has a wide range of programs, ranging from residential facilities, through supportive and monitored apartment-based housing programs, to various stages of independent living arrangements with the aid of case managers and community services.

When I started there in the early 2000s, one of the first things I noticed is that the organization had grown significantly since its first two decades, and had added some programs that deviated from the core mission. The result was some programs that acted like independent organizations and a stratification of needs and resources.

That created a major challenge because while there was an IT staff, most of its members served specific programs or facilities. There was no centralized IT department to speak of, no real organization-wide infrastructure, and virtually no IT policies.

For the first month I was there, I made it my mission to visit every program and to learn as much as possible about how each one's core focus, how it functioned, and which technology resources worked and which ones didn't. This was where I learned to appreciate the importance of understanding user processes. It's also one of the reasons I strongly advocate for engaging users and understanding their needs and the problem they are trying to solve when they ask for (or in some cases just start using) specific mobile apps or cloud services. That understanding allows IT professionals to find solutions that both meet user needs and fit into the security and acceptable use profile of an organization.

While there were a number of initiatives that I started or fully implemented during my tenure, I'm going to focus on just a few major projects that I would do differently today.

Task 1: Establishing a network-wide infrastructure

Easily the biggest (and most expensive) task was connecting all the facilities together. Most of the residential facilities had just a couple of PCs in the staff office and one PC for clients to use. Larger programs that shared office space also shared a network resources and server space. There was, however, no connectivity between each site -- something my team resolved with a mix of solutions including site-to-site VPN. This made centralizing all other resources possible and it was the foundation for every other project that we took on.

While you could argue this is still a core need today, there's also a compelling argument that it isn't. The residential facilities had very modest computing needs -- entering case notes, maintaining log books, documenting medication adherence, and reviewing or updating treatment plans. It's easy to contemplate these tasks being accomplished completely from a smartphone or tablet rather than a desktop PC.

It's easy to see HIPAA-compliant cloud services delivering most of that in one form or another. In fact, Box's tagline "use Box as infrastructure" embodies the approach that I would take.

Task 2: Standardizing file servers, directories, and email

With a solid infrastructure in place, the next task was to pull the hodge-podge of Windows and Novell servers along with the PCs (and a few Macs) together to ensure access to resources, security, audit trails, monitoring, backups, and so forth. The easiest solution was to go completely as a Windows shop based around Active Directory and to migrate our archaic and failing email solution to Exchange. The process definitely helped some of the far flung staff feel like part of the larger organization and was the first time many of its case managers had even minimal collaboration options outside of the specific programs.

Today, I wouldn't count Active Directory and Exchange out completely, but I also wouldn't make the nearly automatic leap to them. Google has shown that organizations of varying types and sizes can standardize around Google Apps. Even staying within the Microsoft camp today, I would consider the cloud-based Office 365, partly because it offers the familiarity of Office, which the staff were already very comfortable using.

Given the growing trend of integration options between enterprise-oriented cloud services and traditional enterprise systems like Active Directory, it's conceivable to have a mix of solutions. That's probably the approach I would take.

It's worth mentioning that both Google and Microsoft will sign business associate agreements for healthcare customers relating to Google Apps and Office 365 respectively. That's an important consideration because of the privacy and breach provisions in the HIPAA regulations, which all healthcare providers and vendors must adhere to, and which the department of Health and Human Services updated and tightened earlier this year.

Task 3: Deploying software to users

For many years, the enterprise solution to deploying new PCs or major revisions of OS and applications was to use a monolithic image that made every PC essentially identical. From previous experience, I was very familiar and comfortable with this approach and it actually worked out quite well and allowed us to do a lot of computer cleanup.

Many organizations continue to use monolithic imaging today, but there are also a number of alternatives, including self-provisioning options like enterprise app stores. Although the enterprise app store is generally thought of as a smartphone or tablet solution, it can also be very successfully implemented on traditional PCs. In addition, some cloud solutions make dedicated desktop application suites or specific configurations unnecessary today. Browser-based options or virtual desktops have added appeal in health organizations because data is less likely to be stored locally on a device.

I wouldn't necessarily abandon the idea of deploying locked-down PCs for this organization, but it would certainly be something to discuss or consider. Even if I did advocate for that approach, the technology for deployment options has diversified and I would definitely consider alternative deployment scenarios.

Task 4: Streamline paperwork

Perhaps the biggest challenge was deciding how to handle paperwork. Various state and federal agencies dictated or guided the types of information that each program needed to capture, from initial intakes through treatment plans and daily case notes. There were three approaches to bring that process from a handwritten log into a digital form.

The first, which was in place when I arrived, was simply to create Word templates for each type of documentation. Staff entered data and saved the document to a network share following a specific file naming convention and folder hierarchy -- essentially the same workflow as traditional paper forms. The second, which was in a pilot project when I arrived was an early cloud-based solution specifically dedicated to human services organization that was ultimately rejected because the service was extremely unreliable.

Although there were electronic health record systems on the market at that time, they didn't really address the needs of this organization that mixed treatment and human and social services. In the end, I advocated creating systems tailored to the specific needs of this organization and its programs. It was a costly solution, but at the time it was the optimal approach.

I doubt that I would make that same choice today given the sheer number of additional options. Even if I were to opt for a customer solution, I would almost certainly look at leveraging the APIs available for cloud platforms like Box or Accellion.

I didn't even think about mobile devices

I left this organization a few months before Apple announced the iPhone and several years before the iPad. Although some programs used cell phones for communication and for on-call services, mobile hadn't really penetrated there when I left.

That said, it was immediately obvious to me when Steve Jobs announced the iPad that this device would've been an ideal solution for the staff that needed to visit various locations -- client apartments, doctor's offices, external agency meetings, and so forth. The ability to record and access important content anywhere and anytime would have been a phenomenal improvement for these users.

In the end, the choices I would make today would be much more lightweight because I'd be leveraging the power of cloud technologies. The requisite infrastructure and back end would've likely have been less expensive, more readily available for mobile users, and much more adaptable. 

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies