One of the challenges that network architects face in very large environments is staying grounded in reality. When an organization is large enough to have a dedicated body of network philosophers (architects) the tendency exists for these network planners to become out of touch with network realities. In trying to combat this problem I have been doing some evaluation of the IT life cycle to see how we can stay grounded in reality.
Through close involvement with network operations team in conjunction with a very large migration, namely the merger of United and Continental airlines passenger service systems which is the heart of the airlines systems, I have come to appreciate recently the necessity to build a strong relationship between network operations and network architecture. In a previous blog post I wrote about the differences between network engineering and architecture and I have been doing a lot of thinking on the topic until them. Something that I didn’t touch on in that blog was how operations fits into the picture. The fact is that operations and architecture share more in common than engineering.
If I were to attempt to summarize the optimal role for a network architect it would be to evaluate the current state of the organization, then by working with other technology groups and business units, determine where the organization needs to be and build a plan to efficiently bridge the gap. Through publishing standards by which other organizations should abide and by direct involvement in large project the architecture team should be shaping the technical direction of a given organization.
What I have come to appreciate more recently is the critical component of first understanding where the organization is. This is not a one time endeavor either, rather an ongoing process. Much like mapping out a journey, it doesn’t do one any good in determining where you are going without first understanding where you are. Previously I was most interested in understanding the front end hand off of architectural standards to engineering since I had come from an engineering role as most architects do. What has become very interesting to me is my greater involvement with operations recently which feels like a return to my roots.
As most other professional packet herders I started in an operational role in networking for a service provider and moved up to engineering and now on to architecture. I have always thought of the operations team as the group tasked with keeping the lights on but what I am gaining an appreciate for is the immense importance of accurately tracking problematic areas and the ongoing network optimization efforts.
The following article and whitepaper refer to Cisco’s PPDIOO model (prepare, plan, design, implement, operate, optimize).
Our Enterprise works loosely within this model and is trying to align further with this model. The more I think about it the more I realize that the architecture, engineering and operations organizations need to overlap rather than own pieces of the model. Architecture should start with optimize and work in conjunction with operations to find the key areas of weakness and the ensure that the long term planning solves these issues.
This seems to me like a reasonable approach to keeping the architecture team grounded in reality but what level of involvement should architecture take in operations? Joining daily operations calls? Weekly touch point meetings? I am certain that the answer will vary from organization to organization, for the time being I will be trying to find the happy medium in my role.