ANN: Agile Infrastructure

------=_NextPart_000_0029_01C316BE.6C525C00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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 piss
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/

and co-author of the upcoming book: The Practical Guide to Enterprise
Architecture



------=_NextPart_000_0029_01C316BE.6C525C00
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1141" name=GENERATOR></HEAD>
<BODY>


<P>The industry speaks positively about agile methods for software development 
(<A href="http://www.agilealliance.org" 
target=_blank>http://www.agilealliance.org</A>) 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:<BR></P><FONT size=2>
<OL>
  <LI><FONT size=3><STRONG>Keep network and infrastructure architecture to a 
  minimum yet sufficient</STRONG>&nbsp;<BR><SPAN 
  class=768135923-05042003>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.</SPAN> </FONT>
  <LI><SPAN class=768135923-05042003></SPAN><STRONG><FONT 
  size=3>M</FONT></STRONG><SPAN class=768135923-05042003><FONT 
  size=3><STRONG>aintain centralized control with decentralized 
  operations</STRONG><BR>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.</FONT></SPAN><FONT 
  size=3> </FONT>
  <LI><FONT size=3><SPAN class=768135923-05042003><STRONG>Keep the mainframe 
  holy and worship it daily</STRONG><BR>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.</SPAN> </FONT>
  <LI><FONT size=3><SPAN class=768135923-05042003><STRONG>Measure everything as 
  you cannot manage what you do not measure</STRONG><BR>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.</SPAN> </FONT>
  <LI><FONT size=3><SPAN class=768135923-05042003><STRONG>All production systems 
  are equal in the eyes of architects</STRONG><BR>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 piss poor morale. Reorganize based on 
  maximizing efficiency and utilization not technology.</SPAN> </FONT>
  <LI><FONT size=3><SPAN class=768135923-05042003><STRONG>Worship users and give 
  them praise</STRONG><BR>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.</SPAN> </FONT>
  <LI><FONT size=3><FONT face=Arial><SPAN class=768135923-05042003><FONT 
  face="Times New Roman"><STRONG>Spread&nbsp;joy to people in foreign 
  lands</STRONG><BR>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.<BR></FONT><BR></SPAN></FONT><BR>With this thought in mind, I 
  have created a new Yahoo Group to discuss agile methods in the networking and 
  infrastructure discipline. Check out </FONT><A 
  href="http://groups.yahoo.com/group/agileinfrastructure" target=_blank><FONT 
  size=3>http://groups.yahoo.com/group/agileinfrastructure</FONT></A><BR><BR></LI></OL><FONT 
face=Arial size=3></FONT></FONT>
<P><FONT size=2><FONT face=Arial size=3>James McGovern<BR><SPAN 
class=768135923-05042003>Co-a</SPAN>uthor of the book: Java Web Services 
Architecture </FONT><A 
href="http://www.amazon.com/exec/obidos/ASIN/1558609008/chiltownworldwid/" 
target=_blank><FONT face=Arial 
size=3>http://www.amazon.com/exec/obidos/ASIN/1558609008/chiltownworldwid/</FONT></A></FONT></P>
<P><FONT size=2><SPAN class=768135923-05042003></SPAN><FONT face=Arial><FONT 
size=3>a<SPAN class=768135923-05042003>nd co-author of the upcoming book: The 
Practical Guide to Enterprise 
Architecture</SPAN></FONT></FONT><BR><BR></P></FONT>
<br>



<br>
<tt>
To unsubscribe from this group, send an email to:<BR>
[email protected]<BR>
<BR>
</tt>
<br>

<br>
<tt>Your use of Yahoo! Groups is subject to the <a href="http://docs.yahoo.com/info/terms/">Yahoo! Terms of Service</a>.</tt>
</br>

</BODY></HTML>

------=_NextPart_000_0029_01C316BE.6C525C00--