It’s not usual for development projects to undergo an architecture review, but too many times these reviews consist only of developers. There are no server or network folks, much less any DBAs or security personnel. When I’ve brought this up to some of my developer friends, they wonder what the issue is. After all, developers have a good grasp of how things work, right?
If you’re an infrastructure type, you’re probably chuckling right now (or shaking your head sadly). If you’re a developer, let me ask you a very basic question, “Do you think the admins who support you understand everything about the code you write?” The obvious answer is, “No,” they don’t. They are very smart people but you’ve spent years learning to code, working through design patterns, finding and solving bugs, and a whole lot more about writing code that infrastructure folks don’t even think about.
Infrastructure folks also spend years specializing in what they know. A lot of what we know don’t even enter into the realm of the developer. Most developers just don’t encounter the problems and issues we do because we solve them before they do. For instance, a recent install comes to mind where the installation was having an issue because of a hardened configuration with respect to the NICs.
If you just thought, “What do you mean, hardened NIC configuration?” you just proved my point. If you do know what I mean but you don’t deal with that sort of thing regularly, you’ve also proved my point. If you do think about those things regularly but are quite aware that most developers don’t, you probably see my point. Infrastructure folks have specialized knowledge to bring to an architecture discussion that is not in the wheelhouse of most developers. This knowledge, if the infrastructure people are absent, is also absent.
Infrastructure folks aren’t looking to throw roadblocks up on projects out of malevolence. Okay, MOST infrastructure folks aren’t looking to do that. What we are looking to do is doing our best to ensure that systems going in or being updated are as secure as possible and perform as well as we can make them. We want to minimize risk for the organization. We want to help the organization make the most out of every IT investment. Sometimes that means we challenge back. We see an issue or an area for improvement. Of course we are going to bring it up.
The later in the project where we get a look at what’s going in, the harder and more costly it will be to the organization to try and make things better. If it’s a showstopper, there may not be time to avoid everything coming to a screeching halt. That’s why it’s important to get the infrastructure folks involved early and keep them involved throughout the whole project. It’s harder, yes, but it’s also what is best for the organization.
