I was talking with a financial planner last week. This planner specialized in helping people create wealth systems for his clients. Systems that people with no money in savings could use to continually increase their wealth. The one thing that struck me was his constant reference to change and scalability of the financial systems he created. I could relate thinking back to another article on the importance of scalability in network design. My friend discussed the importance of designing a system that is constantly changing and growing. I was struck by how important it is for the modern network architect also must be planning for the growth of the information systems.
One thing we know about businesses and networks is that when they are successful they grow. This growth can be dramatic. I often walk into networks where the infrastructure and system growth of the organization has taken a strange path. The path might even be called a dead end. The niche I’ve carved for myself is to help the technical team understand why they’ve reached a dead end. The problem is that not only has the technology reached a dead end, but the business is dependent on the technology to be successful. So if the technology is at a dead end, the business itself is at a dead end as well because it has reached the limit of its growth potential.
I think of it like a bucket. The business owner has built this bucket and begins filling it with sand. The sand represents the business, the customers and really the capacity of the business to increase the income potential of the business. Sometimes technology consultants see the problem differently than the business owner.
Thinking, “Oh the problem is that the bucket is full, I can fix that problem..”
Then the technology consultant punches a hole in the bottom of the bucket. While the sand is running out the bottom of the bucket, the business is also disappearing through the hole. Now the only choice of the owner is to continue to shovel sand into the top of the bucket to compensate for the sand leaking out of the hole. While it’s true that the “Bucket being full” problem is solved, there is now a new problem. Because of the hole, the volume and costs of business are increasing yet the company itself is not making more money.
While there are hundreds of ways to solve the bucket problem there are only three true options that help the business continue to grow.
Each of these solutions has benefits and consequences. The best solution shouldn’t be decided by the technician but by the C-level managers of the business. In the first example the technician made the decision without the help of the board. The result was a solution that solved the immediate problem but created a dead end for the business because the solution wasn’t scalable. Even if the business could shovel more sand into the bucket, the new solution would be to build a bigger hole in the bucket and income for the organization would still be limited to the size of the present bucket.
For a simple technical example let’s use the simple service account. A service account, of course, is an account setup for an application. Not meant to be used as a logon account, the best practices for a service account is to setup a separate account. After the account is created only assign the minimum level of rights the services account. Finally the passwords for the account should be known only by a small group of systems administrators.
Imagine how surprising it would be after changing the Network Admin account, all the production applications stopped working. The Network Admin Account(s) should be changed at a minimum each time the old admin moves to another company. So if the admin account is changed and applications stop working, it often means that the administrators account was being used as a service account.
Imagine a similar scenario but instead of the admin account being changed imagine if something happened to an entire development team. Imagine a development process without a test environment. All testing is done on the production environment. A new IT manager walks in the door and is shocked that the development team is allowed on the production environment. The solution, remove permissions for the development team for the production environment. Within hours all the software in the production environment has stopped running and nobody knows why. It turns out that instead of following best practices the development team had used their own accounts as service accounts.
Though simple, these types of incident happen. They seem like minor decisions to the technician at the time. Yet for one organization, I worked with, there was a $2000 / minute hole in their bucket. This hole continued to leak money while the problem was being detected and continued as someone was trying to troubleshoot the problem. The troubleshooting teams in these cases had no change control log and had no idea the password change had even occurred for over an hour and a half. When the access was given back to the development team 3 hours later, the systems began working again at a productivity cost of $360,000.
Purely technical solutions are seldom scalable. By allowing the technician to cut a hole in the bucket, it doesn’t mean that the solution supports the business. When the bucket is full, capacity has been reached. The job of the modern network architect is to work with the management team to either build a bigger bucket, add a bucket or filter what’s going into the bucket so if fills more slowly with only the best opportunities.
For my friend the financial planner and the modern network architect, understanding scalability seems to be the key to a growing network and ultimately growing profitability for the business.]]>
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.]]>