Ok, its 2:59am EST and I couldn't sleep. So, I need to write this out to help my mind put the subject down for the night. :)
In the world of the Dynamic Systems Initiative, one of Microsoft's strongest principles is "designed for operations." Not only does it sound great, but Microsoft's plan to deliver complex enterprise solutions aligned with your company's operational guidance is light years ahead in the industry.
The automated tools to generate management agents for a variety of enterprise solutions is impressive (I saw someone create a MOM management pack for application in mere seconds). And the capability to model health environments (what a healthy state process looks like) is very good. And finally, the infrastructural visibility of capitalizing on the SDM design in Visual Studio is pretty liberating for Infrastructure architects (think of it as supercharged Visio).
However, instead of thinking about designing for operations. I was thinking about: What does it mean to design a solution for YOUR operations specifically. As an infrastructure architect, can you name the core data center services that your company provides across the board for a variety of application solutions? I'm sure you can. I'm sure you might know how these services provide distinctive services to different communication areas (example: providing backup/recovery, file mgmt, storage mgmt, Electrical needs, HVAC, DNS, monitoring and instrumentation in the public facing DMZ). I'm sure you might know the systemic quality features of these services (what is the availability, performance, scalability, interoperability, etc…. for your outbound DNS servers). Even better, some of you might even know the capital expense and ongoing operating expenses for these different core services (as well as the functional and non-functional complexity associated with the systems). Those of you who lead this stuff must also be able to communicate effectively back to management what is the core value (internal rate of return on assets, ROI, TCO) of each of the data center services for operational effectiveness.
Yet, what's becoming more rare to see is those who know the deep infrastructure architecture of the solution being designed and how it impacts all of those specific elements in our operations and business environment to be successful. This is quite common as many in the past have treated applications as encapsulated execution environments that infrastructure architects could effectively ignore ("just auto allocate more resources if it needs it). However, for those who believe that Infrastructure architecture must only be automated deployment of physical resources, I believe they are wrong. Adding another box (or even virtualized box) doesn't necessarily reduce operating expenses and complexity for a business (it sometimes might even make it worse). Without a strong knowledge of the solid infrastructure architectural design needed for a specific complex application architecture, we usually set ourselves up for failure in the future. I know I have made myself an example of such an experience several times in the past. Most architects in the infrastructure space has made this mistake at one time in their professional lives. As most of you already know, if we want to be successful at designing solid infrastructure architecture, we have to be willing to get our hands dirty deep into the solution to design the most optimized and successful infrastructure possible. As we start to break down that solution into deeper infrastructural layers, we can analyze the impact of these decisions and patterns back into our own specific infrastructure architectural environment. Furthermore, we can begin to map the service contracts represented between operational data center services and the mission critical solutions dependent on them (say, in some sort of manifest)
From talking to customers in the field (whether it's focused on Unix, Linux, Mainframe or Windows initiatives), I personally believe that when we start to really understand the impact of our infrastructural architectural decisions for a specific solution on the technical operational environment as well as the business operational environment, we begin to realize the importance of the discriminating business decisions we make every day to assemble solid infrastructure architecture for our company. But of course, I could be wrong...