Friday, March 03, 2006
Agilists who practice command and control
On the way home yesterday, I stopped at Lowes to pick up vacuum belts when I ran across an old IT professional who has been in the business for a long time. He mentioned to me that he was interested in bringing agile approaches to his enterprise but was struggling with adoption. In our conversation, I learned that he was busy morphing the real intent of agile methods into something suitable for his environment and more devious to support his own agenda. He adopted the vocabulary of practicing agility but in all reality was doing something else...
Information technology in the vast majority of large enterprises was born under the control mindset and no matter how hard one tries, they can never really shake it. New IT architectures especially Enterprise Service Oriented Architectures are creating much more flexible platforms for business activities. What will occur over the next couple of years is that we will have better technical architecture approaches for increasing agility but will not have solved for the real problem to out of control IT expenses...
Architects need to return to basic principles to discover a different approach to managing projects, programs and architectures — one that can fully exploit the economic potential of collaboration and flexibility. Ultimately, IT executives and their business counterparts want to be assured of one thing (well there may be more but that's not important right now): that IT will deliver valuable working software as promised. Control is one, increasingly less effective way of assuring that this happens. Trust offers a different architecture approach designed to assure the same thing.
Trust focuses on establishing shared expectations regarding end products, rather than specifying in detail the actions that must be performed to deliver the end products. Trust based architectures then concentrates on designing appropriate incentive structures and reducing barriers to motivate appropriate action.
One practice that is growing in corporate America is the desire for "reference architectures". In many conversations, you will hear all of the buzzwords being thrown around including: buy-in, synergies, best practices, standards and other feel good words but the real problem may not be any of these things. I wonder what would happen if enterprises stopped thinking about reference architectures as command and control mechanisms and started adopting more of a stewardship mindset towards them?
In my travels I have ran across lots of folks who have savagely read many of the books on enterprise architecture and still have gotten it wrong. In fact, many of the books on this topic are detrimental to the success of the enterprise and should be burnt. None of these tomes (except for one) even hints at the notion of trust (they do talk about buy-in though) and seeks to set IT up to fail. Ttrust based architecture approaches can help to insulate businesses from unanticipated events better than more conventional control based approaches and can become a better enabler of success than what is commonly practiced today.
One of my peers at work will be joining the blogosphere shortly, who has a strong .NET background and a ton of integrity. Maybe he would be willing to share in his first blog entry his own thoughts on better ways enterprises can think about the use of reference architectures? Anyway, it is my belief that reference architectures as traditionally thought about are for the most part failures as they tend to focus on detailed activities required to deliver the end products rather than focusing on the end product itself. It is somewhat humorous to think that most reference architectures that state in writing the goal of loose coupling are really tightly coupled themselves.
Trust based architectures encourage more loosely coupled business activities. Participants (people and processes) can be added and removed much more easily. More specialization can occur because loosely coupled relationships can accommodate more participants. Rapid innovation can occur in all areas of business activity because the loose coupling allows participants to change the way they operate without disrupting the operations of others.
Many reference architectures succeed at creating shared documentation but most fall short in the goal of creating shared understanding. Reference architectures can also be counter-productive when the "guidance" start to intrude upon the activities required to deliver the end product. Maybe one should ask themselves, if I am developing reference architectures, and I believe in open source and I am also outsourcing, how will these three things converge? Sadly, most folks don't know the answer.
I wonder how many folks have ever thought about developing reference architectures in a loosely coupled way? Tight coupling in the development of reference architecture is usually detectable when the impact of an attack on one participant dampens the spirit, motivation, mediocrity for other participants. This is mostly do to the design of the relationship. Rather than tightly linked activities where a disruption in one activity ripples inexorably through all the other activities, the activities in loosely coupled relationships occur much more independently of each other, connected only by end products delivered by one participant to the next.
Loosely coupled relationships can accommodate far more participants than tightly coupled relationships. As a result, architects developing reference architectures can work with multiple participants having similar capabilities. Since more participants can be accommodated, architecture teams can draw on much more specialized capabilities and go even deeper. These specialized capabilities can be useful both in the anticipation and more importantly in the eyes of the business community, the rapid recovery when one fails.
Being that my day job is now Chief Security Architect, I too sometimes fall into the trap of command and control. It is usually manifested by finding reasons to increase the size of my team. Of course I can rationalize anything but deep down, it may be all about command and control. Of course, I have countered my own demons and haven't filled many open job requisitions in order to maintain a level of integrity.
As you know, I am also a savage believer in agile methods and open source and practice declarative living yet have struggled to understand how to approach the separation of security and openess as traditionally practiced. Control based architects must build their own security capabilities (aka staff) internally to reduce dependence on others. I think I folks may be in for a pleasant surprise when they see what Enterprise Architecture 2.0 feels like and we are the first ones to demonstrate in a transparent manner all of the questions that noted Monk James Governor tends to talk about and more. Stay tuned...
| | View blog reactionsInformation technology in the vast majority of large enterprises was born under the control mindset and no matter how hard one tries, they can never really shake it. New IT architectures especially Enterprise Service Oriented Architectures are creating much more flexible platforms for business activities. What will occur over the next couple of years is that we will have better technical architecture approaches for increasing agility but will not have solved for the real problem to out of control IT expenses...
Architects need to return to basic principles to discover a different approach to managing projects, programs and architectures — one that can fully exploit the economic potential of collaboration and flexibility. Ultimately, IT executives and their business counterparts want to be assured of one thing (well there may be more but that's not important right now): that IT will deliver valuable working software as promised. Control is one, increasingly less effective way of assuring that this happens. Trust offers a different architecture approach designed to assure the same thing.
Trust focuses on establishing shared expectations regarding end products, rather than specifying in detail the actions that must be performed to deliver the end products. Trust based architectures then concentrates on designing appropriate incentive structures and reducing barriers to motivate appropriate action.
One practice that is growing in corporate America is the desire for "reference architectures". In many conversations, you will hear all of the buzzwords being thrown around including: buy-in, synergies, best practices, standards and other feel good words but the real problem may not be any of these things. I wonder what would happen if enterprises stopped thinking about reference architectures as command and control mechanisms and started adopting more of a stewardship mindset towards them?
In my travels I have ran across lots of folks who have savagely read many of the books on enterprise architecture and still have gotten it wrong. In fact, many of the books on this topic are detrimental to the success of the enterprise and should be burnt. None of these tomes (except for one) even hints at the notion of trust (they do talk about buy-in though) and seeks to set IT up to fail. Ttrust based architecture approaches can help to insulate businesses from unanticipated events better than more conventional control based approaches and can become a better enabler of success than what is commonly practiced today.
One of my peers at work will be joining the blogosphere shortly, who has a strong .NET background and a ton of integrity. Maybe he would be willing to share in his first blog entry his own thoughts on better ways enterprises can think about the use of reference architectures? Anyway, it is my belief that reference architectures as traditionally thought about are for the most part failures as they tend to focus on detailed activities required to deliver the end products rather than focusing on the end product itself. It is somewhat humorous to think that most reference architectures that state in writing the goal of loose coupling are really tightly coupled themselves.
Trust based architectures encourage more loosely coupled business activities. Participants (people and processes) can be added and removed much more easily. More specialization can occur because loosely coupled relationships can accommodate more participants. Rapid innovation can occur in all areas of business activity because the loose coupling allows participants to change the way they operate without disrupting the operations of others.
Many reference architectures succeed at creating shared documentation but most fall short in the goal of creating shared understanding. Reference architectures can also be counter-productive when the "guidance" start to intrude upon the activities required to deliver the end product. Maybe one should ask themselves, if I am developing reference architectures, and I believe in open source and I am also outsourcing, how will these three things converge? Sadly, most folks don't know the answer.
I wonder how many folks have ever thought about developing reference architectures in a loosely coupled way? Tight coupling in the development of reference architecture is usually detectable when the impact of an attack on one participant dampens the spirit, motivation, mediocrity for other participants. This is mostly do to the design of the relationship. Rather than tightly linked activities where a disruption in one activity ripples inexorably through all the other activities, the activities in loosely coupled relationships occur much more independently of each other, connected only by end products delivered by one participant to the next.
Loosely coupled relationships can accommodate far more participants than tightly coupled relationships. As a result, architects developing reference architectures can work with multiple participants having similar capabilities. Since more participants can be accommodated, architecture teams can draw on much more specialized capabilities and go even deeper. These specialized capabilities can be useful both in the anticipation and more importantly in the eyes of the business community, the rapid recovery when one fails.
Being that my day job is now Chief Security Architect, I too sometimes fall into the trap of command and control. It is usually manifested by finding reasons to increase the size of my team. Of course I can rationalize anything but deep down, it may be all about command and control. Of course, I have countered my own demons and haven't filled many open job requisitions in order to maintain a level of integrity.
As you know, I am also a savage believer in agile methods and open source and practice declarative living yet have struggled to understand how to approach the separation of security and openess as traditionally practiced. Control based architects must build their own security capabilities (aka staff) internally to reduce dependence on others. I think I folks may be in for a pleasant surprise when they see what Enterprise Architecture 2.0 feels like and we are the first ones to demonstrate in a transparent manner all of the questions that noted Monk James Governor tends to talk about and more. Stay tuned...
