Working and building my Seattle IT Consulting Company my clients are the SMB market but in the last 18 years most of my previous clients have been a mixture with a predominance of fortune 500 companies. I like this because it has allowed me to see the beginning, middle and end of the technology spectrum. It also gives me a unique viewpoint in that I’ve watched many businesses struggling with the same problems despite business size. One of the pitfalls every new business struggles with is the entrepreneurial (feast or famine) business cycle. Technology experts who aren’t aware of this cycle will unintentionally lock a business into this feast or famine cycle by listening to an non-technical manager express technical requirements. The modern network architect needs to understand the feast or famine cycle and help businesses circumnavigate this cycle.
If you start a new business you need a service (or product) and a customer. The new business is in constant search of customers. Then once a customer is found the service is provided and the business gets paid. Then the cycle starts over again with the business looking for clients again. The reason I call this the feast or famine cycle is because during the customer finding stage, the business is not making money. During the customer service phase the customer is making money. So either the business is in the feast (servicing customers & making money) or famine (Finding customers & not making money) cycle. The goal is for the business to make a continuous income with continual sales and customer service cycles.
One of the problems I see are businesses that never break out of the Feast or Famine cycle. 100′s of business owners give up on their businesses because they can’t seem to break out of this cycle. Other businesses assume the cycle is typical and invest in technology that will lock the business into the feast or famine cycles. Talk to many business owners and the focus is on new sales. The goal seems to be to have too many customers. The problem that occurs for the business is that with too many customers, customer service suffers. In the information age, every customer expects customized service. In return for that customized service the customer returns a much higher level of customer loyalty. Without that highly customized offering, there is no customer loyalty. The business ends up cycling new customer over and over. In the process the company wastes resources focusing on new customers and ignoring the 20% of customers that provide 80% of the company’s income.
Many business owners mistakenly assume they need to invest in customer finding technologies at the expense of customer capacity technologies. Does the owner invest business resources in business capacity to support more customers? On the other hand, should the owner invest resources in marketing and sales to find more customers? Many owners are seduced by the thought that the money the owner receives from the new customers will be used to increase the customer service capacity of the business. What really happens is that the resources are instead funneled back to bring in more new customers into the business. The business capacity to support customers never grows. The business owner is locked into a cycle of finding more and more customers, then dealing with more and more customer churn. Eventually the business fails when key business systems fail.
When I walk in the door it’s often after a key business technology has failed. The reality is that enterprise technology hardware has about a 5 year life cycle before it fails. The business has often taken the funds for capital expenditure spending on new technology and moved them into marketing the business. A new customer sales campaign can easily overwhelm a technical system that is already over-taxed. I get to share the bad news with the new client that the technology expert before me should have explained and prevented. It’s unfortunate that when the systems and the business is down, it’s always easier to get an owners attention. The job of the technology expert is to get the owners attention before things fail. What if the technology expert is just a technology expert? After all a technology expert isn’t trained in business? That’s actually one of the differences between the technology expert and the technology architect.
Technology experts are 90 to 100% technology focused. Often technology experts aren’t even aware of the business services or products the company produces. System administrators are still highly focused on the technical system they manage, but need to be able to discuss the systems with technical managers. The next level, the System architect must have a 60% or better understanding of the business vision, goals and strategies in order to build a new system. A strong architect can help a business owner understand how the feast or famine business cycles affect the business. The technical architect, along with the CTO, work as a team to identify opportunities. Then the architect can design the future technical solutions. That move the organization out of the feast or famine cycle.]]>
What I love about architecting technology for business is the complexity of the problems. There is a time component where you are trying to figure out how to solve todays problems of time, scope and resources… while at the same time guessing the future thinking about where you will be at 2, 5 and 10 years from now. There is a scope consideration where I need to guess where you will be in the future vs your problems today. There is a resources issue where we have to weigh what is going on today for pricing, compared to what it will cost in the future when the system dead ends.
This article was inspired by a conversation with one of my new Seattle IT Consulting clients. They have been in business for about 2 years, 4 employees and have grown to 70 clients. In the first 2 years of growth they’ve used every free internet tool they can find. Today the company uses tools like Gmail, drop box and whatever software component someone recommended. The result is that their business growth has come to a screeching halt. Because their business capacity is zero, while the customer demand for their services continues to grow.
The company wanted me to begin solving the problem in about two weeks. If I’d just wanted to solve today’s problem I could have solved it in a couple hours. A few months later, with their growth they would have been solving a new problem that was even more expensive. Here is some of the conversation I had with them around the Time, Scope and Resources questions when expanding the time line past today but just a few years into the future.
Time: Let’s think about where you will be in two years, 5 years and 10 years from now. In 24 months the business has 70 businesses in her CRM. From what I’m hearing high growth is what you want. So is it reasonable that if Bobbie could find them, she could have 140 businesses in two years? Possibly 280 businesses in 4 years and 560 businesses in 6 years?
What will limit that growth is not the sales skills of the organization. In the Suzy’s case the limitation will be her company’s capacity to support all those business clients. If we consider that we spend only 2 man/woman hours per week (and we know it will probably be more) on 70 businesses that works out to 7,280 hours or 182 weeks / year or 4.6 FTE’s per year working full time 52 weeks per year. At the present growth rate, two years from now that will be 9.2 FTE’s and in 6 years 18.4. This only counts FTE hours focused directly on the business accounts. In other words this is just billable customer service hours. It doesn’t count the cost of supporting those FTEs. As the business expands, there will be Payroll costs, Accounting and billing costs, HR costs etc.
Even at half this growth, the company will need to grow to 9 Account FTEs and between 5 and 12 support FTEs. This is a huge managerial undertaking. I have to ask… will they be telecommuting, moving to new locations… etc etc. All these pieces become factors when considering the design of the system.
Scope: So presently the company is focused on Branding, websites etc for their business clients. As the business grows will it continue to be a full service marketing company? I know that in the future there will be more partners like Carl, potentially in multiple areas. If the company technology is going to grow with the business, I need to consider the variety of systems that may need to collaborate with her company.
So I need a robust platform that is cheap enough for her collaboration partners to use. When thinking about this, How many additional franchise and collaboration partners will you have? It’s hard for the business owner to know, yet the technology group needs to build a technical system that anticipates where the company man need to go? It will depend on how much FTE work the business wants to farm out vs. how much will be in-house. Plus the technology architect needs to consider whether management will continues to maintain the broad scope of services for their business clients.
Therefore I need a system flexible enough to grow horizontally, supporting multiple areas of marketing as well as growing vertically with the number of clients.
Resources: We have to consider what the company can afford today on a shoe string versus what it will cost to replace the system when she outgrows the shoe string system. We also have to consider that every hardware and software platform will double the cost of doing business. Not in technology costs but in business productivity costs/losses.
I’m writing this after working with a small business I’m working with has run into a serious problem. They’ve been bootstrapping with free software. Unfortunately they chose software without thinking about these questions. If they had spent a little more on compatible systems in the beginning, this cost could have been in the 100′s of dollars instead of 1000′s of dollars. If we pick the wrong system, in two years when the company doubles her business again, the capacity of the business will need to double again.
If we take the time now to build a system that will scale over the next 6 years, we won’t have to replace it between now and then. If we continue to build patches and work- arounds eventually we will have to replace everything. The cost in the future will be 10 times higher. Not because the technology costs will be higher, rather because the business systems will be much more complex. Statistically each hour spent planning will benefit the company with two more weeks of productivity each year.
Many times IT departments get excited about the way a technology will solve a problem today, without considering the ramifications. Good ideas have a way of spreading throughout the organization. Yet many good ideas are ideas that focus on solving today’s problems without considering how those problems will affect the future. Opening the eyes of clients and team members is one of the soft skills required of the modern network architect.]]>
It’s been predicted that notebook and desktop sales will be exceeded by tablet sales by 2015. Are there any ramifications to the modern network architect if this happens?
Microsoft has been dominating the desktop and Laptop world for operating systems. It would be very tough to ever move into the desktop OS world without a great deal of expense. Yet if we look at the tablet world there are some new players ready to compete in this market. Apple is an obvious competitor. The Android OS is already making inroads on the tablet world. Who else is going to be there?
Is a tablet a smaller laptop? Or is it a big phone?
With Unified Communications (UC) on the horizon a phone and laptop could be interchangeable. With the next generation tablet, I could see people carrying tablets around instead of phones. From the tablet they can make a phone call or connect to network document or an internet website. This is not new technology and we are already seeing the early adopters moving to these types of systems. It would seem that as more and more tablets are being produced with more and more processor speed. It makes sense that if a laptop could shrink, so could the smart phone grow into a tablet.
We all know about the security issues with phones right now. Would a system administrator really want an Android tablet on the network? What would be the rules on the network if a tablet was hacked or stolen?
First we are seeing on-premise network systems move into the cloud. Then phones and laptops will become tablets. We are already seeing remote service desks. It seems like in the next 5 years, nothing in infrastructure technology will look the same? Working as an Seattle IT Consultant I am already noticing the change all around Seattle and Redmond. I wonder if the trend is already affecting the other parts of the country?]]>
I’ve been looking harder at the Juniper routers. Each year I keep hearing better things about Juniper routers, firewalls and switches. Lately I’m looking at unified Communication (UC) architecture and once again am impressed by the Juniper offering. I’m wondering if others are beginning to move to Juniper as well. Working with Network infrastructure I’ve had the attitude, sure it’s more expensive but it’s the best. Lately though I keep wondering whether Cisco is the best solution for everything? In this article about modern network architecture, I’m wondering what other people are thinking.
The first thing I’ve noticed is just how robust the Juniper systems are. These systems are designed for data centers and have some of the lowest latency speeds. I’ve been looking at the MX series for a front end, Internet facing router. There is nothing for Juniper to be embarrassed about. In fact I think in many ways the systems are faster than the equivalent competitor system. I really like the way multiple systems fit together. The Juniper system has a separate control plane from the forward plane. I’m thinking about all the scenarios where we’ve had to reboot routers, where this feature may have helped maintain our 9′s if we’d had it.
The Junos OS is also very cool. The interface is much simpler to use and configure. What is more interesting is that all the Juniper systems run the same Junos OS. So any technician that is comfortable with the low end systems is also able to work on the high end systems. There may be a 10% additional learning curve, but from what I can see life will be much less hectic. As an operations manager, keeping qualified people on every shift is much simpler.
Another benefit seems to be the way they roll out changes. Imagine knowing when patches are being rolled out for every system. Hard vendors make it difficult when it comes to keeping track of every patch for every system. Especially in that every patch needs to be tested in a separate environment before being rolled out. With similar operating systems this hassle is reduced. All patches are rolled out at the same time, and because Junos is similar, the complexity of testing patches is significantly reduced.
Add in a scripting library and now customer customization is so much simpler. Building a Hosted UC environment also means customizing the environment for each business client. Every customer claims to be an exception and seems to have its own complex configuration needs. Now with a library of scripts, customizing each customer environment is actually do-able.
On the MX, EX and SRX series the latency is very low. What it looks like is that the core switching components can reduced and in our case eliminate the complexity around the aggregated switching layer. In the architecture I’m working on we are able to eliminate the aggregated switching layer and connect directly to the access switching layer from the core switching layer. Imagine this on an infrastructure where the end user base almost seems to be growing exponentially. Reducing the aggregated switching layer means reduced complexity and unexpected resources for additional customer features.
I’m just amazed… is anyone else noticing this?]]>
Service Level agreements (SLA) and Operation Level Agreement (OLA) are two ideas in Modern Network Architecture. Many departments promise their users levels of service. Understanding OLA and SLA the network architect can provide the level of service promised and saves the department money by not promising more services than are possible.
I usually think of an OLA as an agreement between a “vendor” and customer where the customer is the IT department. As long as the vendor can provide the level of service that the IT department is promising to the departments end users everything is ok. The problem comes when the IT department promises more service than the IT vendor can provide.
A Seattle IT consulting client I worked with found itself in trouble when a vendor promises 1.5 Mbits/sec to the internet to the IT department. Yet the IT department promised 10 Mbits / sec to the end users in the company.
Obviously the end user will only have 1.5 Mbits / sec even if the internal network infrastructure could support 10 Mbits / sec. The bottle neck for the system will be the vendor OLA.
An OLA is important to understand when designing the network. Knowing what the OLA agreement from the vendors determines the SLA that can be provided to end users.
In many companies the IT department is separate from the other departments. Agreements are made between the individual departments and the IT department. Each department pays the IT department for support, bandwidth, server access and other variables managed by the IT department. These agreements between the IT department and the company are SLAs.
An SLA is valuable because it promises a level of service that is quantifiable. One SLA focus is availability measured in 9′s. 99.9% availability means less than 9 hours of server downtime per year. 99% availability means 3.65 days per year of down time.
So if a vendor was providing an OLA promising 99% availability of service. Then the IT department provided an SLA promising 99.9% availability to end users. Obviously there would be a problem because the IT department can’t provide more availability than the OLA of its vendor.
The network architect obviously must understand all these requirements. First the network architect must understand the business requirements of each department. Next network architect must understand the OLA of its vendors. Finally the network architect must match business requirements and vendors OLAs before committing to a departmental SLA.]]>
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.]]>
Cloud services come in many shapes and sizes. The ultimate cloud service would be moving a physical or virtual server from on-premise hardware into a NOC (Network Operating Center) and serving applications and data from these servers. SaaS (Software as a Service) involve migrating data into applications hosted on the cloud. Another service is Unified Communications (UC) where traditional communication technology silos are integrated in a way that allows these technologies to share data. Understanding the cloud means understand these formats and the other services being offered in the cloud.
When a server reaches the end of its physical life, the company should be preparing to replace the server. This often means the planning that goes into determining the new server hardware, upgrades to the software etc. This change must be consistent with the present standards or new standards may be created to replace the present servers as they get older. In addition to identifying the new hardware an implementation plan needs to be created. The plan will need to replace the present system with a minimum impact on the business. This planning and process could take several months of planning and waiting for the right moment to gather all the implementation resources for maximum effect while the system is down.
What if the testing and implementation phases could be reduced to days or hours?
Imagine the steps involved in a new technology implementation. My first major enterprise level upgrade was a Novell 3.11 to Novell 4.1 upgrade along with desktop upgrades for a small major city in preparation for Y2K. The upgrade involved consolidating servers, identifying problem desktops and servers and upgrading the NOS for an entire city organization. This project took over 2 years to complete but was nothing compared to my first PeopleSoft migration. This involved Hundreds of small and large departments. There was a small problem in that there were over 3,000 databases that needed to be consolidated into this one system. Complicate this with customizing input and output to each of these departments. Planners and implementers had the additional headache in that more and more new business requirements were added after implementation began. The project took over a year to plan; implementation of new scope changes was never ending.
Imagine these types of projects taking months instead of years to complete. Understanding technology means understanding business and business process. The next step is matching business processes to match the final technology implementation.
The reality is that the reason systems become so complicated in an on-premise implementation project is politics. After building a solid infrastructure and application layer, there are really only a few variables that need to be customized. With a cloud implementation the infrastructure is already setup and stable before the customer takes over the system or the application. This stability reduces planning and implementation time enormously. New technologies can be tested and implemented in much less time.
Planning is limited to the customizations required for the new system. No new infrastructure needs to be built to support the system. The infrastructure including backup systems, redundancy, Active directory, front end firewalls and routing all have been created before the project began. Testing of these same systems has also already been done. The systems are monitored and have a 99% availability SLA. In many cased the software is also already loaded. All that is left are the customizations.
The new technology becomes just something turned out without too much thought. Turning on new technology will be as simple as turning on a water spigot or flipping an electrical switch in our modern homes today.
Cloud Network Architecture Capital Expenditure Benefit for Cloud
If you were like me when you started in technology you had no idea want the terms Capex or OPex spending meant. Over the years I did realize that whether your technology proposal was successful was dependent on what budget it came from. Over the years I began to realize that there were different budgets for different things. I found that managers had certain portions of the budget that could only be spent on certain things. A project proposal’s success depended on aligning project with the right type of budget expense. Capex or Capital budget expenditures was the budget I usually found my projects being funded by. Everyone wants Capex funding, so there is always competition for these funds. The modern network architect needs to find ways to compete for Capex spending. But there is another way…
What if the Opex or Operations Expenditures budget has lots of money? Capex spending is focused when a business spends money either to buy fixed assets or to add to the value of an existing fixed asset with a useful life extending beyond the taxable year. So major technology projects where new servers and software are purchased and built come under the capex budget. On the other hand the Opex is used for ongoing cost for running the business. Electricity is an example of an Opex expenditure. I always thought that the money comes from the same place why are they blocking my project when there was lots of money in the overall budget. When the Capex budget is gone it means no more new technology projects. For a consultant this could mean no more work until the next budget year.
So let’s say you have an old server that needs to be replaced. Because a server is a long term asset (Long term assets are used longer than a year.) it needs to be added to the Capex budget. The cost will include the hardware, software licensing of the server, the backup system, redundancy systems etc. Operational expenses will be the electricity and other normal maintenance costs. Opex spending are purchases that don’t bring asset value to the company.
What if we take that same server; Convert the server to a virtual server, then migrate that server into the cloud. In this case no long term asset has been purchased. Yet at the same time the virtual server now functions like a brand new server in an enterprise cloud environment. There is a monthly maintenance cost but that can be offset by the Opex expenses associated with the original server. Suddenly replacing the server stops being a Capital Expenditure and becomes and Operational Expenditure. Imagine a manager who finds out that by moving the server into the cloud Opex funds are available for other projects and operational expenses on the server are less than the original server? Oh and don’t forget the server is now scalable and more robust than the original server. For most managers this is an easy choice to make. This is because the manager is able to lower long term expenses for the business the manager is able to show upper management a reduction in overall expenses which means more overall profitability for the organization.
Understanding the difference between capex and opex spending helps the modern network architect push through more technology projects and bring higher profitability to the company.]]>