The Architecture and Technology Council

Upon review, I found a fair number of our software projects over the last year came in late, over budget or failed for reasons that attention to architecture could have prevented. We have been unable until recently to get approval for Architects as a position. Even now, we only have one and he is on the smallest development team and so has limited sphere of influence.

So, how to address this gap? Build an Architecture and Technology Council. This council will have one representative from each of our development teams. I can see several benefits to having this council.

Culture: the existence alone of a council brings attention, discussion and, likely, validation that architecture and technology is of significant importance to the success of our projects. More dialogs will open up between technical, project and business teams. The business will see a significant expression of concern for IT's goal for effectiveness and adding value. Project stakeholders and key players might pause to consider if they are taking into consideration concerns published by this council whose focus is project success.

People: the mere existence of a council raises the bar. Council members are acting on the belief that they can make a difference, that we can be change agents. Other IT workers see an example of leadership that is difficult to write off as positional, political or purely based on length of service because these members are selected by their peers. The council is encouraging because shows an avenue of personal and career growth where the technical worker doesn't have to give up their technical role for a management role.

Process: we begin finding a way to address the issues we all agree are issues. The existence of the council gives a moment to confront our classic mistakes, examine our processes and review opportunities for best practices.

The road ahead is not that clear to me at this moment. I think the Council should regularly go through a lessons-learned dissection of a failed or flawed project from the past. I think we should come up with a suggestion for a technology and architecture road map for our organization that addresses their strategy (platform, tools, languages, architecture). From a process view, we should determine where and how checks are executed to prevent IT from doing something to repeat a mistake when we have learned the lesson. These process checks should also keep us from diverging from the road map.