Tuesday, October 02, 2007
Enterprise Architecture and Perspectives on Culture
Many folks read my blog and get it twisted by thinking I am providing a portal into my employer when reality is something different. My employer is like a lot of other employers, it has good points and bad points and the focus of my blog isn't on either but more about what I think and the thoughts I have formed with others outside my enterprise. I spend a lot of time thinking about the human condition and at some level know that folks spend more time at work than sleeping and therefore it is a vital component of the equation.
One of the best ways to address the human condition in America is to fix deficiencies in the workplace. For IT folks, that includes making the environment more condusive to producing quality software. The funny thing is that while I may periodically throw daggers and others have a sense of quiet desperation when it comes to their leadership as they always step in it, I have yet to run across an organization that isn't willing to change. Usually the issue is they simply don't know how.
I have observed many enterprises who want to improve where executives have an extreme interest in making things more agile even though their actions result in the contrary. The problem isn't one of interest but of knowledge. It is easy to find acknowledgement of problems and the desire to improve but more difficult to find folks who can truly change the culture for the better.
Some of the best conversations I have had have been with various IT executives who are more open minded than their personas demonstrate. My thesis on changing the IT culture is the fundamental lack of recognition of the principles behind cohesion and coupling where folks think about this as a software principle when it is more aptly applied to humans. People specialize in technologies and are composed into project teams. The worst problem is one of communication. It only gets worse when we further organize ourselves into cubicle farms. Us Enterprise Architects have our own separate meetings and have separate managers from the developers, quality assurance, business analysts, project managers and so on.
The concept of a project is more of a financial construct which eschews the concept of team. A project brings together a user interface person, a DBA, a developer and a project manager. They work away, emailing each other back and forth and most certainly attend lots of meetings of nebolous value until the project is done. At the conclusion of the project, everyone rides off into the sunset. Now, consider how so-called teams are built when you practice this bad behavior by assigning folks to multiple projects simultaneously. You will then see the need for time tracking while watching the entire process devolve.
Have enterprise architects ever asked themselves what would happen if you eliminated time tracking? Do you think that productivity and human interactions would increase or are you more worried that you will lose the ability to produce financial metrics? Of course, financial metrics of nebolous value are important, but are they more important than the human aspects that allow you to deliver higher quality valuable working software to the business?
Links to this post: