Posted by: James Murray
Modern Network Architecture, Network scaleability
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
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.
- Solution 1 – build a bigger bucket – (building a bigger store or assembly line)
- Solution 2 – build a second bucket – (New product lines, new locations etc)
- Solution 3 – Filter what’s put into the bucket – (Target a very specific customer)
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.