Aug 24 2011   6:44PM GMT

Architecting Scalability

Posted by: James Murray
Network Architecture, Network scaleability, Organizational productivity

Ignoring scalability when designing network architecture is the number one reason, in my opinion, networks fail. 

The profitability of the organization is dependent on the organizational productivity of the business.  The organizational productivity of the business is dependent on the capacity of the network infrastructure.  The capacity of the network infrastructure is dependent on the sophistication of the network architecture design. Therefore the profitability of the company is dependent on a network architecture that supports the increasing capacity requirements of the organization.  A business with an infrastructure capacity that can only support $100,000 a year will choke a business attempting to break capacity goals exceeding $400,000 a year.

The one thing we know about a successful business is that it will grow.  A $40,000 startup will need to double in capacity 6 times before breaking the $1,000,000 sales mark.  Each time that business doubles in sales production, the business must double in production capacity to support those sales.  This means that the company must be able to create more goods or services.  A 15 minute task each week for a single customer, by itself becomes a full time FTE position for 100 customers and a full department for 1000 customers. Doubling sales means the organization must distribute twice as many goods and/or services.  The billing department must track more customers.  As new employees are added to produce more goods and services, payroll needs to pay those employees and management needs to track those employees.  If the business plans to grow, the network architect needs to plan for that growth.

A strange example is the spreadsheet…

The spreadsheet seems like a fast track solution for young employees with great ambition.  See a problem; use a spreadsheet to create a workaround.  Suddenly the department seems more productive. Yet as the usage grows the manager begins to realize that the more people using the spreadsheet the more failures and corruption occurs in the spreadsheet.  Still the usage grows and now the spreadsheet is mission critical to the department.

Most departments have mission critical spreadsheets everywhere.  When the hotshot who created the spreadsheet moves on, now there is nobody that understands the spreadsheet or how to fix it.  So the IT department is called in to fix the spreadsheet.

The IT technician explains the limitations of spreadsheets and shows the manager that there is a tool in the organizations CRM system that can do the same job, is already paid for and supported by the IT department.  Unlike the rogue spreadsheet the department was using.

I’m curious how many stories we can collect about tools that seemed like a good idea at the time that later became costly long term problems.