James McGovern
December 14th 03, 02:21 AM
The industry speaks positively about agile methods for software development
(http://www.agilealliance.org) but hasn't yet applied those principles to
the folks who do networking and infrastructure. It is overdue and I will
take the first shot at some things that can make them more agile:
1.. Keep network and infrastructure architecture to a minimum yet
sufficient
Develop organization-wide standards using an agile Enterprise Architecture
approach for each area of the infrastructure including the network, data
center, desktops, etc. Develop the future state of your enterprise
architecture by making sure that you have only one of a particular type. For
example, today you may have Windows NT and a 100Base T network, where
tomorrow you may be running PDAs on 802.11b.
2.. Maintain centralized control with decentralized operations
Centralized control allows one to control costs, architecture and
deployment standards. Decentralized operations simply mean that it does not
matter where your IT people are located. This works in remote locations and
outsourcing arrangements as well. Support personnel should always be placed
as close as possible to the end customer.
3.. Keep the mainframe holy and worship it daily
In the age of distributed computing, disciplines are more important than
ever. Some non-agile organizations have tried to migrate the mainframe
discipline to client/server and browser based paradigms and have failed
miserably. The disciplines found on the mainframe need to be customized and
streamlined. The vast majority of mainframers grew up with useful methods
for capacity planning, disaster recovery and had extensive change
management. Today we need these time proven practices more than ever without
of course the bureacracy.
4.. Measure everything as you cannot manage what you do not measure
In the days of the mainframe, they could measure everything related to
their infrastructure and could tell you their system availability and other
system qualities. Today, we do not collect these metrics under the guise
that we are too busy. If an organization, calculates their uptime and holds
people accountable the staff will figure out a way to run the systems more
efficiently.
5.. All production systems are equal in the eyes of architects
The vast majority of enterprises today have mainframes, pc's, servers,
pda's and so on and have taken non-agile approaches by organizing support
groups around them. An agile organization will refer to these groups as
simply "technical support" and make sure its staff is cross-trained on as
many platforms as each can handle. Separating support along technologies
results in inefficiencies, political problems, poor communications and ****
poor morale. Reorganize based on maximizing efficiency and utilization not
technology.
6.. Worship users and give them praise
The number one problem with failed projects is the lack of communication.
Being agile requires one to prefer human interaction over processes. If your
IT folks would rather string cable or play with VI then failure itself is
wired. In many shops the communications issue is even more systemic in that
they cannot adequately communication with their own peers. In the days of
the mainframe, it was obvious who did what to whom. In distributed
architectures, everything is spread across disparate tiers, technologies and
even locations. The team should use agile methods and process that instill
communication between IT and customers as well as amongst the various IT
silos. This should be incorporated as part of the job description for all IT
personnel.
7.. Spread joy to people in foreign lands
Many wise dinosaurs from the days when mainframes were king, sat in their
lofty ivory towers meditating on how the world should be. The only time they
would interact with common business folk is when the help desk would summon
them with an usual problem. In other words, being reactionary was status
quo.Todays economy requires IT to walk with the great unwashed and
communicate with their users. Simply, IT needs to shmooze, sell and stand on
their soapbox selling their wares. This is the first step in real
reengineering.
With this thought in mind, I have created a new Yahoo Group to discuss
agile methods in the networking and infrastructure discipline. Check out
http://groups.yahoo.com/group/agileinfrastructure
James McGovern
Co-author of the book: Java Web Services Architecture
http://www.amazon.com/exec/obidos/ASIN/1558609008/chiltownworldwid/
http://www.webservicesarchitecture.com
(http://www.agilealliance.org) but hasn't yet applied those principles to
the folks who do networking and infrastructure. It is overdue and I will
take the first shot at some things that can make them more agile:
1.. Keep network and infrastructure architecture to a minimum yet
sufficient
Develop organization-wide standards using an agile Enterprise Architecture
approach for each area of the infrastructure including the network, data
center, desktops, etc. Develop the future state of your enterprise
architecture by making sure that you have only one of a particular type. For
example, today you may have Windows NT and a 100Base T network, where
tomorrow you may be running PDAs on 802.11b.
2.. Maintain centralized control with decentralized operations
Centralized control allows one to control costs, architecture and
deployment standards. Decentralized operations simply mean that it does not
matter where your IT people are located. This works in remote locations and
outsourcing arrangements as well. Support personnel should always be placed
as close as possible to the end customer.
3.. Keep the mainframe holy and worship it daily
In the age of distributed computing, disciplines are more important than
ever. Some non-agile organizations have tried to migrate the mainframe
discipline to client/server and browser based paradigms and have failed
miserably. The disciplines found on the mainframe need to be customized and
streamlined. The vast majority of mainframers grew up with useful methods
for capacity planning, disaster recovery and had extensive change
management. Today we need these time proven practices more than ever without
of course the bureacracy.
4.. Measure everything as you cannot manage what you do not measure
In the days of the mainframe, they could measure everything related to
their infrastructure and could tell you their system availability and other
system qualities. Today, we do not collect these metrics under the guise
that we are too busy. If an organization, calculates their uptime and holds
people accountable the staff will figure out a way to run the systems more
efficiently.
5.. All production systems are equal in the eyes of architects
The vast majority of enterprises today have mainframes, pc's, servers,
pda's and so on and have taken non-agile approaches by organizing support
groups around them. An agile organization will refer to these groups as
simply "technical support" and make sure its staff is cross-trained on as
many platforms as each can handle. Separating support along technologies
results in inefficiencies, political problems, poor communications and ****
poor morale. Reorganize based on maximizing efficiency and utilization not
technology.
6.. Worship users and give them praise
The number one problem with failed projects is the lack of communication.
Being agile requires one to prefer human interaction over processes. If your
IT folks would rather string cable or play with VI then failure itself is
wired. In many shops the communications issue is even more systemic in that
they cannot adequately communication with their own peers. In the days of
the mainframe, it was obvious who did what to whom. In distributed
architectures, everything is spread across disparate tiers, technologies and
even locations. The team should use agile methods and process that instill
communication between IT and customers as well as amongst the various IT
silos. This should be incorporated as part of the job description for all IT
personnel.
7.. Spread joy to people in foreign lands
Many wise dinosaurs from the days when mainframes were king, sat in their
lofty ivory towers meditating on how the world should be. The only time they
would interact with common business folk is when the help desk would summon
them with an usual problem. In other words, being reactionary was status
quo.Todays economy requires IT to walk with the great unwashed and
communicate with their users. Simply, IT needs to shmooze, sell and stand on
their soapbox selling their wares. This is the first step in real
reengineering.
With this thought in mind, I have created a new Yahoo Group to discuss
agile methods in the networking and infrastructure discipline. Check out
http://groups.yahoo.com/group/agileinfrastructure
James McGovern
Co-author of the book: Java Web Services Architecture
http://www.amazon.com/exec/obidos/ASIN/1558609008/chiltownworldwid/
http://www.webservicesarchitecture.com