What was the IT environment like when you came on board? When I came on board, you could tell that there was a deficiency in the IT infrastructure. The company was struggling to do fundamental IT operations such as software distribution, asset inventory, configuration management, back up, restore, disaster recovery, etc
Biomet had several strategic businesses focused on various aspects of the orthopedic industry. These businesses were developed through acquisition. When you acquire a company (this is not a new story), and you acquire their infrastructure, sooner or later you have a hodge-podge of technologies. You have each business unit still acting independently from an IT perspective. There was no strategic IT coordination.
How did you get a handle on that "hodge-podge" environment? One thing that we did, almost day one, was put an enterprise IT steering committee in place. That committee acts as our IT governance mechanism across all of our business units and in all of our operating geographies. That started to build a foundation. It's put an enterprise perspective on the IT decisions that we make, and on what strategies and policies we put in place.
And what was a high priority project that came out of the steering committee? Biomet was a Lotus Notes environment. The first thing we decided was that Lotus was not a strategic platform for us going forward.
Biomet had done extensive development and built some robust outpatient functionality in the Notes environment. Those Notes applications were used primarily in various aspects of the core business; in the manufacturing processes, document management, the CAD environment, and so forth. This made the migration tricky, and we've had to migrate in stages.
What helped people decide that Exchange would a good strategic platform, and that Microsoft would be a good partner? We wanted to come up with strategic partners and build relationships that could help us get to where we were trying to go. We believed Microsoft was going to be one of those partners. Especially from a perspective of IT operations, resolving our standard build, standard configurations, management issues, and so forth. Plus we wanted to do some fairly "Gee Whiz" things.
We have ideas in mind for SharePoint, Project Server, Office Communications Server, and so forth, that will enable us to do much better and robust collaboration with our other organizations and business units.
You mentioned IT infrastructure was acquired through acquisitions. Did a significant amount of Linux and Open Source get acquired? For a while we had open source environments at some of our other business units. Again, because there was no enterprise coordination, a lot of folks would bring in new technologies just because it was the newest, coolest thing. Running a $2 billion organization around just the newest, coolest technology isn't the best practice. We ran into some issues with, what I'll call, maverick organizations that would go off and implement technology. All of a sudden that technology became a mission critical part of the environment.
That caused us problems when we were trying to do migrations inside the company. We chose to move away from that open source environment because, from my experience in almost 20 years in the IT outsourcing industry, I don't see a lot of companies running mission critical environments on Linux and on open source environments. It's just not common practice.
What stands out about Microsoft products vs. the open source software? One of the things we looked at is, from a relationship viewpoint, who could help us accommodate our operational stability issues, or at least a component of operational stability issues? We thought a tier one supplier like Microsoft would be able to help us with that.
When you look at open source versus tier one suppliers, I look at it from the standpoint of, "What's the one throat to choke?" When I have problems, who do I call? Who do I rely on for help when I need it? I don't want to have to go off and look at web logs or Internet chat sessions or newsgroups to figure out, "How do I patch this?", or, "How do I solidify my environment or stabilize my environment?"
Another thing, when I look at it from a security standpoint, open source is one of those things where you really don't know where the code's being generated. Am I really going to bet my business on an application or technology where I don't know where the source came from?
What about access to the source? Doesn't that let you look at the code and decide if it's secure and good quality, regardless of where it came from? No, not really. Here's the advice that I would give clients when I was in the outsourcing industry: "Is maintaining the source and having access to it part of your core business? Is it part of your core competency?" In many cases it's not. Their business is banking, or insurance, or orthopedics, or whatever. That's what they should really be paying attention to. They should be spending their time analyzing where their industry is going, and what business models need to shift.
Most business should not be concerned with where open source is, and where you get the latest source code so you can tweak it. I don't think businesses are paying their IT teams to do that kind of R&D.
You mentioned the value of going with a tier one partner, but how does that play out on an actual project? It's not uncommon to have people directly dedicated to your account or your facility to help when you run into issues, or want help with planning, architecture and design, and quite honestly implementation. Those are the key benefits you get from a tier one player. You're going to run up against issues during a big implementation. You don't get that help from an open source provider.
As you bring consistency to IT implementations, have you seeing a difference in finding people with the skills you need? I haven't done any real baselining but I can tell you that we ask people we interview to show that they have certifications with our tier one partners.
Whether that's an MCSD certification, or a Cisco CNE certification, when you look at people that have gone through that process, and have committed to achieving a certification and certain education level, I think that pool is much more robust.
You can find higher caliber people that can come in and help you go through a transition. The people I interview that have gone through the certification process are well rounded. From a knowledge perspective, they are very sharp.
Why do you think that is? When you look at just the fundamental availability of the coursework and the educational materials put out by tier one players, folks have what they need to go out and get educated and certified on those tier one technologies.
I really don't think that's as much the case for open source or lower tier players. With tier one players, as the products change and the roadmaps change, I think it's much easier to get people up to speed on what that technology looks like, how to use it, how to deploy it, manage it, maintain it, configure it and so forth. I think the tier one players have an edge.
Thanks for chatting with us. What advice would you give to someone else in your position? I think it goes back to a lot of things we have talked about. When you're looking at technologies to choose, and products to deploy, it really comes back to where you want to put your trust.
Ask yourself: Are you willing to bet your business on that technology? Are you able to rely upon a partner that can help you when the times get tough? If you can't answer yes to those questions then I think you definitely have to rethink your choices.
| 
