Modern Network Architecture


November 5, 2011  3:40 PM

IT strategic planning



Posted by: James Murray
Business Strategy, IT Consulting, Modern Network Architecture, strategic Planning, strategy, tactices

Ok so the first thing to understand about strategy is that strategy is not the same thing as tactics.  Technology is very tactical within the business organization.  Because this is not always understood by the management teams in the organization, often it’s often hard for technical people to understand that there is a difference.  The one thing technologists are very good at is execution.  Continued »

October 29, 2011  11:58 AM

Feast or Famine Cycle



Posted by: James Murray
Modern Network Architecture, Planning technology

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.


October 29, 2011  11:53 AM

A small business dilemma



Posted by: James Murray
Modern Network Architecture, seattle IT consulting, Small business dilema

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.


October 23, 2011  6:57 PM

What are the ramifications?



Posted by: James Murray
Modern Network Architecture

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?


October 20, 2011  11:31 PM

Juniper another look…?



Posted by: James Murray
Add new tag, Modern Network Architecture, Unified Communications

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, Continued »


October 16, 2011  11:46 PM

SlA vs OLA



Posted by: James Murray
Modern Network Architecture, seattle IT consulting

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.

For Example:

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.


October 9, 2011  8:47 PM

Service Account and Scalability



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 Continued »


October 8, 2011  9:39 PM

Cloud network Architecture – Reduced planning time



Posted by: James Murray
Cloud Network Architecture, Modern Network Architecture
If you’ve been involved in IT for a while you know that change takes a long time.  Proposing a major technology change is always met with some type of resistance.  This is not just because of the cost.  This is because major changes can disrupt the normal business process for months and sometime years.  The planning, testing, implementation, training and cultural change is enormous.  It’s interesting to note though that migrating to the cloud for even the largest companies does not require the years of planning and preparation required in the past.  With the cloud, the modern network architect needs to know how to leverage the cloud to take advantage of this. 

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.

 


October 8, 2011  9:33 PM

Cloud Network Architecture – Capital Expenditure



Posted by: James Murray
Cloud Network Architecture, Modern Network Architecture

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 Continued »


September 30, 2011  12:41 AM

Unified Communications (UC) Platforms



Posted by: James Murray
Communication newspapers, Digital Age, IT Consulting, Modern Network Architecture, UC platforms, Unified Communications

I’m very intrigued by unified communications (UC) lately. Along with the cloud and Software as a Service (SaaS), I think these technologies will change the look and feel of modern network architecture.

We are all familiar with communication.  Continued »


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: