Reaction: The NRE as the new architect

Over at the Packet Pushers, Anthony Miloslavsky suggests that network architects have outlived their usefulness, so it is time to think of a new role. He describes a role called the “NRE” to replace the architect; the NRE would—

…spend no less than 50% of their time focusing on automation, while spending the other 50% deeply embedded in the operations/engineering/architecture realms of networking. They participate in an on-call rotation to stay in touch with the ops side of the house, with a focus on “treating operations as if it’s a software problem” in response. NREs would provide a expert big picture view of BOTH the development/automation and network operation/design sides of the house.

The author goes on to argue that we need someone who will do operations, engineering, architecture, and development because “pure architecture” folks tend to “lose touch” with the operations side of things. It is too easy to “throw a solution over the cubicle wall” without considering the implementation and operational problems. But, as a friend used to ask of everything when I was still in electronics, will it work? I suspect the answer is no for several reasons.

First, there is no such person as described, and I am not certain there ever can be. Splitting your time between operations, engineering, architecture, and development means you will not actually be “deeply embedded” in any of the above. Being in the on-call rotation, for instance, means that you will not have the time required to both research and understand new development practices, languages, and tools. Being in the on-call rotation also means you will not have the time to research any sort of new technology or idea that is being proposed or considered, nor keep up with any research. Perhaps all of these things might seem useless from an operational point of view, but they are not.

Second, again, there is no such person as described. Being in the on-call rotation will prevent you from ever being able to keep up with your coding skills, and it will keep you from being able to develop the “larger picture” thinking you need to do architecture. “Sorry, I was called out for ten hours yesterday, so I did not have time to understand this new line of business being proposed,” is a recipe for diminished respect towards the IT organization.

Third, even if such a person did exist, I am not convinced it would solve the problem. There was a time, when I was in the Technical Assistance Center (TAC) at a vendor, when I wished the coders could just come pull some TAC duty time. And there were many times when the coders, I am certain, wished I would come pull some coding duty time. We tried this. The resulting escalated cases and new bugs resulting from the exercise made more work for everyone.

Fourth, even if such a person did exist, the job of the architect is not to be buried in the details of configurations and coding. The job of the architect is not pull in business, operations, and technology. I know the business part is easy to forget when you are called out at 2AM, but it is still important if you want to have a company that operates a network in the first place.

My estimation is, after seeing this sort of thing tried many times? It will not work.

It is a nice theory, but the job becomes too diluted, too quickly, to be useful to anyone. The entire company ends up being harmed, with poorly laid 5 years plans mixed with poorly implemented operations. If you take the theory here—just make people cross more boundaries in their day-to-day jobs—we could easily have accountants doing programming part time on accounting systems, and programmers doing every job in the company, from accounting to sales to…

If I do not think this is the answer, then what do I think is?

Stronger communications are key. The problem is not who do different jobs, but rather people who do not talk. Figuring out how to build systems that facilitate and encourage communication is ultimately more important than asking someone to do every possible job adjacent to theirs. This is not about meetings, this is about communications—do not ever confuse these two things.

Moving back to the fundamentals is key (part 1). Communication is easier if everyone is working from the same set of ideas and goals. If you have one team focusing on building really cool technology, while another focuses on really far out business ideas, then you are going to have a clash that will cause much pain and anguish.

Moving back to the fundamentals is key (part 2). Start simple, stay simple, and be agile. The less complex the system is, the more it is made up of clearly delineated pieces, the easier it will be to communicate about where it is now, and where it is going. Further, a lot of the reason the architecture folks “throw hard things over the cubicle wall” is they simply do not understand the complexity of the existing system. This is one of the disadvantages of very complex systems—you end up in a complexity wormhole.

Ultimately, everyone needs to understand everyone else’s job, including their limits and capabilities. Sometimes it might be useful to “trade jobs,” or to get folks from one team involved in the daily operations of another. But the overall concept of having a group of people who “try to do everything,” because “architects just do not understand the real worlds of operations any longer,” is generally a recipe for failure.