As a high school student, I studied French. I didn't have any great plans to become a translator for the UN, but it was a requirement for the honors diploma that I wanted to graduate with. You had to have a minimum of two years of a foreign language.
During the summer after my second year, the French professor took us to Quebec City, Canada. It wasn't a trip to Paris, but it was much more affordable. Because very few people in Quebec actually speak English, the experience was roughly the same.
I remember that my French was barely passable. I struggled with even basic sentence construction. I'm sure that, somewhere along the line, I said things that were completely unintelligible.
The truly amazing part of this, though, was that the people to whom I was speaking were helpful and we did communicate. The communication wasn't the most straightforward, but it worked. We used a few hand gestures and they allowed me to speak in English if they could respond in French. Generally speaking, we found a common ground that allowed us to communicate as we needed to.
When I think about the relationship that exists between systems integrators and software developers, I am positive that we speak different languages. I am equally positive that some common ground is necessary for us to communicate with one another. Without a basic understanding of each other, the communications breakdowns can be catastrophic.
In the world of software development, we focus on languages, frameworks, APIs, and design patterns. Our thoughts are about algorithms and how to solve problems by the arrangement of mathematical and logical operations.
In the world of systems integration, we focus on packets, bandwidth, ports, and vulnerabilities. We talk about five 9s of availability, about managed switches, RAID, dual power supplies, and a series of other terms and technologies that make your head spin.
There's not a lot of common ground here for us to communicate with one another on. In many ways, the software developer doesn't think the same way that a systems integrator does. The software developer wonders how he can build the system. The question isn't whether the pieces are available or not, but just what they should be made of.
The systems integrator wonders how he can fill the gaps left between different technologies and solutions. In many cases, the systems integrator knows the pieces needed to put together a system. The only question is how the pieces will fit together.
This difference in thinking causes us to communicate in different ways. The software developer is always looking to build a solution where the systems infrastructure staff is looking to pull the pieces apart and look in the cracks. Neither approach is wrong. In fact, these differences can help solve the problem quicker if there is good communication; however, good communication is difficult with such radically different perspectives.
It is because we have this difficulty communicating with each other that it's important that all of us try to learn enough about the other perspective to communicate. This means that software developers should understand the basic components of systems infrastructure. It also means that systems integrators should get a primer on software development.
One of the interesting things about my career is that I've done a fair amount of both systems infrastructure work and a fair amount of work on the software development side. In fact, many of my current consulting engagements rely upon this fact. I am all too often called in to organizations where projects are off track and getting worse. Invariably in these situations, the problem is not that there are not enough talented people who know how to solve problems. The problem is that the software development team doesn't know how to communicate with the systems integration team and vice versa.
Anyone who's worked on a complex system long enough can tell you that eventually something will break down, and when it does, you'll have to be able to track down the problem. This is one of the most difficult things to do. This is particularly true when the problem is so complex that no one person has the answer. It is in those times, it becomes critical that everyone learn to communicate with each other as effectively as they can.
How to learn about systems infrastructure
There is no magic in systems infrastructure, just like there is no magic in software development. There are no pills that will allow you to learn everything about systems infrastructure. Because of that, you'll have to accept your learning about Systems Infrastructure by either buckling down on your own by reading books that describe systems infrastructure or by listening to the systems infrastructure staff at your organization.
The latter method is preferred because your ultimate goal is not to learn everything that there is to know about infrastructure. It is, instead, to be able to better communicate. The best way to invite this kind of learning is to simply ask what really happens when you do something at your workstation, or in your program.
For instance, you might ask about the process that happens when you try to log in. To the software developer, it's just a system call that returns a handle to the user's security token. To the systems infrastructure person, it might be a whole series of communications that take place over the network until a server is found that can authenticate the user name and password as given, or no servers can be found.
On the surface, knowing what is happening when a logon occurs may not seem to be that big a deal. However, the next time that you go to write a program that needs to log the user in, you'll consider how the request to log on might impact the network. It also means that the next time there's a problem with your application trying to log in, you'll have more ideas for things that you can test to validate what's truly happening.
Similarly, consider all of the functions that you call from your code, or those functions that are being called through the objects you are using and ask yourself how much you really know about how the system is able to return that answer to you.
In another example, getting the system time is something that we all take for granted when creating timers and loops. How does the system know what the time really is? Windows 2000 comes with support for time synchronization via a Network Time Protocol. How does that work? What can cause it to break down?
In another example, how does your computer contact the server? How is its name resolved? How is the IP address resolved back to a hardware address? How does the network card control whether it's talking to one workstation on the network or every workstation on the network?
In some cases, you may be asking questions that your systems infrastructure staff doesn't know either; but, in many cases, you may find that they can help you better understand what your system is doing under the covers.
Curiosity may have "killed the cat." It is not, however, a bad approach to learning more about systems infrastructure and building a rapport with the systems infrastructure staff at your organization.
What every developer should know
Despite the fact that there are a limitless number of things that you could choose to know about the network environment that you're software works in, there are some things that you should definitely know about your environment. In particular, you should be aware of all of the dependencies that you're creating with the software that you're developing. These dependencies are important whenever you go to recreate the solution again.
The most common time that software developers experience the need to recreate a solution is when the software is moved from a development environment to a production environment. In most organizations, these environments are separate. The software that was working in the development environment rarely works on the first move to production.
All of the dependencies that were created during the development of the software, including service packs, data sources, DLLs, SDKs, and Registry edits, need to be understood in every development project. These dependencies can also take the form of infrastructure. For instance, if your program needs to resolve names, the program is dependent upon the proper configuration of DNS, WINS, or both.
Without understanding the dependencies that your program requires it is difficult, if not impossible, for the systems infrastructure team to create an environment for your code to live in that works reliably.
I was recently called in to put together some servers for an organization where I didn't do the software development. When I presented them with a question of what they needed I got three answers: IIS, SQL, and the .NET Framework. While it could be that these are the only things that they needed it is quite unlikely. It's more likely that they needed some COM+ packages, the updated MDAC client installed on the IIS box, and potentially even network load balancing. Additionally, these boxes will need to be secured before deployment. It's unclear what SQL client protocol they will be using between the systems—so I'll be hard pressed to truly lock the system down as it should be locked down. Time will tell what was missed on this project—don't let this happen to you.