Hi,
An opinion piece here, so please poke holes and post criticisms below.
Lately I have been going through a lot of system changes at work. That is to say, more than normal, and most at the early stages. We’ve been stuck in a state of limbo, mainly because the several systems we want to upgrade or change all talk to each other in one way or another. I’ll first briefly outline one house of cards, and then move to what should have been done better, generally speaking (or typing as the case may be).
We are on Exchange 2007, and want to go to Exchange 2010. That’s not too difficult you may think, you can build your whole new Exchange environment and move a few mailboxes over for testing, then just do a mass mailbox migration over the weekend and everything’s great.
This would be true, if several other systems weren’t leveraging off of Exchange 2007. Firstly, voicemail. Our phone system will pass unanswered calls through to the Unified Messaging Exchange 2007 server, which means we need the same functionality in Exchange 2010. How do we even test this? We need to contact our PBX support, and pay for changes back and forth out of hours. It’s not something we can easily do without business impact. Then, the PBX has no official support for Exchange 2010, so if something doesn’t work or goes wrong we’re fairly stuck.
Then, we’ve got the same problem with faxing. It goes from our PABX via Unified Messaging. Both of these services are considered business critical.
At the same time, we want to change our PBX system. So we’ve got the above problems in reverse, but on top of that we use OCS 2007 R1 which also needs to get upgraded. So now, we need to deploy a new PBX system, integrate it with a new Exchange environment, which in turn is integrated with Lync to replace OCS, and that talks to the phone system for both making/receiving calls and precense.
Now, because we want to change our PBX system we may need to also change our switch infrastrucutre because if we keep what we have, and went with a provider such as Cisco, they would say that they won’t support what issues happen with vocie quality if the switches aren’t theirs. Our switch infrastructure is up for renewal anyway.
I could go on about this with several other systems that are tied in, but hopefully the above is starting to paint a picture.
When integrating systems, think about how the OSI 7 layer model works. Refresher: each network layer can talk above and below it, regardless of what it is. This means that anything that gets changed in your network environment should work, if it meets the standards. You can swap a network card over, and everything else above it will work exactly the same way as before (drivers pending). You can swap a centralised switch, and it will continue to pass the packets of data around like the old switch did. Your application can talk to anything else on the network when anything below it gets swapped over. Hopefully that shows what I’m trying to say…
Where possible, use standard protocols or single supplier solutions. If you’ve got something that needs to send alerts out, go for simple SMTP emails. Everything supports it, and little to no work should be required when you have to change something. If they won’t support standards like SQL databases of either the latest version or the version before, you should hear alarm bells ringing.
If you need two seperately supplied systems to talk to each other, get each company to show proof they support the other, and will in the future. There’s no use 3 years later saying that company X would say it would work.
This should be the case for any system implemented – think about the future and what would happen, and what might go wrong if you have to swap out any part of it.
