As a Seattle IT Consultant, I review a lot of documentation.  Not because the clients I work with have documentation, but because I am training technicians to write their own documentation for the first time.  Documentation is one of my favorite subjects.  I think that a technician can increase their income faster because they are willing to do what most IT experts seem unwilling or unable to do.  It takes time to get better and I often feel like an English teacher.  Recently I have been working with a client building a knowledge base for Tier 2 and 3 technicians.

Here’s an example I’ve run into on several past Fortune 500 companies.  Tier 4 technicians solving the same problem over and over again.  Tier 4 technicians or problem managers if you go with ITIL definitions, should only be troubleshooting Unknown issues.  So if they are troubleshooting an issue they’ve seen before, there is a problem.  Now the owner is paying for root cause analysis on the same issue four or five times.  For one of my clients it was actually 1000′s of times each month.  The problem wasn’t with the tier 1 technician.  It was with the lack of documentation by the tier 4 technician.  Once the tier 4 technician understood the problem, a KB article should be written for the tier one technician so the tier 1,2 or 3 technician can solve the problem in the future.

By writing “How to…” documents the Tier 4 technician can teach the tier 2 and 3 technicians to solve problems before they become tier 4 issues.  Here’s a very high level layout for a how to document.

Simple Outline for writing a “How To…” documentation

Body Section 1

Define the problem <Documents that fall under the “How to…” Describe the steps for accomplishing tasks as simple as setting up an email account in Outlook or as complex as installing a set of servers.  The first Section in the body outlines the problem and high level steps for solving the problem. In this first section outline the prerequisite, the audience and other issues the reader might need to know before starting the process.>

Body Section 2

<In the second paragraph outline a high level process.  Advanced audiences will be able to pickup the solution without reading the detailed instructions.>

(Note: Mistakes many technicians make Not understanding the needs of their audience Not formatting the steps in a clear way Assuming that the reader knows as much as the author)

Body Paragraph 3

In this section the details are written out.  Writing documentation in High level steps is much simpler for advanced readers.  Then indented below each high level step, giving further instructions for completing these high level steps

Example:

Summary description

Detailed Description

Step 1: High level description

Details to accomplish step 1

Step 2:  High level description

Details to accomplish Step 2

Conclusion

Technician’s notes:

By creating High level steps, if the technician already knows how to do the step, the technician doesn’t have to read the details of the step and can move to the next step.  Technicians that need the details can run through all the steps.  For an outline go to Seattle IT Edge.info

Check out this site for layouts you can copy to document your own network.  If you need someone to create a knowledge base for you check out, www.irrevo.com.   I am creating a list of document descriptions you’ll need to document your systems including, How to…, Settings, Topology and other documents you’ll want for your network.

Working with local Seattle IT Consulting companies, I’ve found that many companies don’t protect themselves with a strong customer onboarding process.  This worked with systems were less complicated and one person could keep everything in their heads.  When systems became more complicated it was impossible for even the strongest technician to get everything done over a weekend.

If you think about it, the onboarding process is just a checklist of things to do.

A)     Identify objects to be migrated

B)      Identify data to be migrated

C)      Identify security settings that will need to be re-created

And so on until the last step before execution

D)     Backup System

E)      Backup system again

F)      Execution of migration plan

There are several phases to an onboarding plan.  When planning I usually start with a three phrase approach like Planning, Execution, Post execution follow-up.  Since I’ve done lots of migrations, here are the phases that I use

• Assessment & Planning
• Execution
• Review of systems
• Optimization

In the assessment and planning the IT Architect, identifies where the system is at.  This is a review of the hardware, software, network objects and settings across the system.  Planning is a step by timeline with all the steps to migrate each component on the system to it’s new environment.  Because very few things work perfectly, we review the systems for a while to verify that all the settings are correct.  This could take a few minutes or more likely days, weeks or months of monitoring and support.

Once the network is stable, the next step is to match the system to your company’s baseline.  So if you were a cloud hosting architect, you know your SLA.  Say it was 99.9% availability.  Your job would be to optimize hardware, software and other objects to a baseline that matched the standard pre-requisites to maintain that 99.9% availability.

A good onboarding plan, in my opinion, has four stages, Assessment & Planning, Execution, Review and Optimization of systems.  Under each phase are different tasks.  About 20% will be unique from migration to migration.  The other 80% will probably be the same from system to system.  As the modern network architect, your job is to not only build, but maintain the integrity of the systems.

As a Seattle IT Consulting company I get lots of help from the most unexpected sources.  This morning I got an email telling me about this great CRM add-on.  My friend knew that I was giving a talk on CRM on January 10th here in Seattle.  So shared with me something that he thought would help me out.  I always appreciate this type of help.  Who can keep up with all the new technologies going on.  As I explained to him, I try to be vendor and technology agnostic in my approach.  So I am always open to interesting options.  I function at a very strategic level.  Long before we know the technology that is required, I am working with a management team to identify the business problem that is going to be solved and the solution.

The reason I try to stay agnostic is that every business situation is different.

For example:

Car Dealer A has a different set of priorities from Car Dealer B… they might use the same technology platform or a different platform it depends on their requirements.

Now take a Trucking Company C that delivers shipping containers around the Puget Sound area here in Washington state.  They may also be using the same technology platform as Car Company A, but it may look to the user as a completely different system.

The technician sees what is behind the Curtain (referring to the Wizard of Oz) and the technology platform may appear to be the same for each of these companies.  Each company of course has servers, software, switches, routers and more.  From the technicians context, the choice is mostly about the hardware and software platform.  The technical perspective is that the car dealers and the shipping company have the same needs for information.

From the business perspective though, the technician doesn’t have a complete picture.  Each company needs that information presented in different ways.  Information requirements are dependent on the industry, the size of the company and more.  Now add a small manufacturer that does closet customization or a small software development company focused on Mobile VPN or a craft beer brewer (my favorite type of client) or a coffee manufacturer/distributer.  Each has different industry issues, managerial prejudices, size issues, long term goals and so on.  While the platform might be the same from company to company, they each have a small portion of difference, that I call the custom bits.  These custom bits make the business completely unique.

Most business owners don’t understand these custom bits and often leave these choices to the technician.  This causes problems because the technicians context is so different.  In order to understand them a business must first understand its own business requirements.  I find that most business owners stop caring, they just want to move forward and don’t care about the details.  My role is a problem management role and is to push back and encourage them to start thinking strategically about their technology…  I usually start with what I call my –ability analysis…  I have them rate an order for these abilities for their technology

• Scalability
• Usability
• Reliability
• Secure-ability
• Availability

It starts with these five.  I have them number each one in priority from one to five.  As we do this, the technology choices become more and more obvious.   If for example Scalability (my personal favorite) were top priority we would analyze the proposed tool from the context of scalability as the top priority.  If usability (most managers preference to maintain productivity of their workforce) we analyze the software from this first priority of usability.  Then we go to the second, the third and so on.

By the time we get to the bottom of the list we may have added more abilities… but the answer becomes quickly obvious what the right choice is.  So this add-on might be perfect for one business, but not another.

I love it when people I trust do free technology reviews of new software as my friend did for me.  I never have enough time for this type of review.  So it’s appreciated when someone will do the work for me.  These types of people are becoming my informal IT Support team.  I find that anyone willing to dedicate some free time to me, that actually is what I need, seems to get referrals and work from me.  I’m beginning to suspect that I have a much bigger team backing you up than meets the eye.  It gives me pause, because I think that this is the weakness I keep running up against.  As I finish this article I realize that my own issues focus around sharing this leadership vision of what I need with lots of people.  Then letting them help me build my business with their help.  So here’s my question for my readers…

How do I build these types of IT Consulting teams that support me in a way that supports both of us, while at the same time not getting lost in the management of those teams?

When I started my IT Career I heard this joke about developers…,

…A team of IT experts/developers are sitting together in a room bragging to each other about their skills.  Then the phone rings.  The head developer picks up the phone and talks for a few minutes.  Then hangs up the phone and says to the group, “That was the boss; he has a new software project for us.  You guys start coding; I’ll run upstairs to see what he wants.”

At least I thought it was a joke.  Too often working with software development teams, IT experts and even for managers this is the exact scenario I run into over and over again.  There’s this idea that we need to start getting something done before we know where we are at or where we are going.  What happens a year later we hear the lament,

“If I knew now what I knew then, I would have done it completely differently, but now it’s too late.”

Long before there was a PMP certification, Agile or Scrum we were developing strategies for avoiding these types of “cart before the horse” problems.  I’ve found that the first successful step is a strategic Assessment.  I outline this in my planning process on my site.

I like to think of a project like a walk through a dark crowded forest.  (I probably read the Hobbit at too young and age and it has affected how I think about these things.) If you had a map of the forest you would need to identify two things before you find a path.  You must understand “Where you are at” and “Where you want to go”.  The strategic assessment identifies where you are at today.

I’ve noticed that lots of developers prefer to start over from scratch.  Especially when working on a website.  I know that building a Network for the first time is similar for the infrastructure expert.  I think this is because when there is nothing, we know where we are at today.  We are at ground zero.  We have to build something from scratch.  As the business grows and the network grows, networks become convoluted.  So without a good change control process, most IT groups have no idea where they are starting from.   When looking at a map, it’s obvious that in order to create a path from point A to point B, you must know where point A is.  Yet IT experts seldom know where Point A is.  So when trying to get to Point B, they miss steps.  These steps become problems that haunt the IT department for years.  Unfortunately if the IT department has no idea where they are at today, they have to admit this to management.  Admitting this to anyone means admitting to fallibility in the minds of some IT experts.  Instead these experts start “coding” like our experts in the joke.  This gives the impression that they know what they are doing.

Just as important as knowing where you are going on a project is knowing where you are starting from.  “Winging it” means that you really don’t know where you are starting from.  For the client this is going to be wasteful of the time and resources while the IT team tries to figure out where they are going.  The strategic assessment becomes the tool for identifying where you are at today.  Consultants like me, work with IT departments who have never done a strategic assessment.  It often puts us at odds with IT departments.  I would recommend to any IT expert, to develop an IT assessment process.  This way when the IT consultant is brought in, it’s only a verification that you do know where you are at

As a business grows there is often a rebellion in IT departments.  On the one hand, IT technicians become overworked.  What I call IT cowboys enjoy the opportunity to wander the network arbitrarily fixing problems and playing the “lone wolf” on the network.  As the business grows though more and more “lone wolves” wander the network they begin stepping all over each other’s work.  In other words without understanding the changes or discoveries another lone wolf … err… technician has made, there is a risk.  The risk is that the change will break the fix of another technician made earlier. 

In a previous posting I discussed how IT people need to be Team players.  In another I discussed the supporting operational roles to the Incident and Problem management roles.  In this article I’d like to discuss a problem I recently ran into on a client site.  As an IT Consultant, I run into these problems all the time.  The simplest solution is to re-organize the department.

Two common symptoms of poor IT business behavior:  

No Root Cause analysis -

Without a problem management team, the Incident team will end up troubleshooting and fixing problems over and over again.  If the company pays $10 to resolve a ticket, each time the incident reoccurs the company pays another $10 for the ticket resolution.  It’s not unusual for tickets to re-occur hundreds of times in a year’s period.  This increases the cost of incident support per problem from $10 to $10 times the hundreds of times the problem goes through the incident process again and again.

Symptom: runaway costs fixing the same problem over and over again.

No Change Management -

A common problem I see is a technician coming in to fix a problem.  After the technician leaves, the customer finds a new problem or even worse an old problem has come back.  The incident team is called and a new ticket is open for each error.  Each technician continues to work on the same problems over and over again.

Symptom: runaway cost fixing the same problem over and over again.  This becomes compounded because while technicians fix one problem, they are breaking an old fix or creating new problems.  Incident problems on the network begin to snowball.

The most important thing to understand is that accountability.  As in any business department there must be a way to track and verify problems.  Managers are taught to first assign tasks, then second follow-up on those tasks.  This follow-up maintains the integrity of the business system.  Too often IT is seen as black magic.  Therefore the second management task does not occur.  Without follow-up IT experts setup their own priorities.

For example making the CPA and the controller the same person is asking for trouble.  Who follows up on the CPA if the CPA is the controller?  The same is true for when making the Incident manager and the problem manager the same person.  Making them the same person reduces accountability of the owner of the two roles.  By building in accountability, technical problems are reduced in the IT department in the same way financial errors and bankruptcy is reduced when a controller role is added to the accounting department.

This accountability is something the old “Lone Wolf” type of technician never had to deal with.  Yet as the business grows, this type of behavior actually damages the real value of the organization.  As a Seattle IT Consultant I work with IT departments and business owners to reorganize departments to avoid these types of conflicts between technicians. 

In working with clients between about $800,000 / year and 5 Million dollars per year, companies need to make a change.  I started out as more of a Seattle IT Cowboy than a Seattle IT Consultant.  I thought IT was about fixing broken computers.  As time went by though, eventually the companies grew and there was too much work for a simple cowboy.  It became necessary to become a team player.  What does an IT team look like?  To understand this I wanted to start with the IT Support tactical roles and how they should interact.  I like to use the term “healthy conflict.”  In this article I wanted to talk about the operational roles and conflict between Incident and Problem management.

The IT tactical roles support the IT strategic roles leveraging the “Healthy Conflict” strategy we’ve described. 

Incident – Failures on the network starts with the incident management role.  Incident management first makes a determination if this is a known or unknown error.  The majority of errors are known errors and are handled without a great deal of problem by the incident management team. 

Problem – Problem management focuses on unknown errors.  These types of errors require a much more in-depth understanding of the problem.  Sometimes requiring log file information that occurred during the error.  Sometimes even a re-creation of the error in a test environment of equivalent systems.

The most common “healthy conflict” in IT is between the Incident team and the problem management teams. 

The 1^st priority of the Incident team is to get the system up and running as quickly as possible.  This way less productivity is lost.  While the incident is being solved; a user, set of users or even an entire company is down.  While the system is down, the company is losing the productivity of the employee and the business systems.  The risk though is that by not understanding the problem the same problem may (and probably will) re-occur again and again until the root cause is understood.

For the problem manager, the priority is different.  Instead of bringing up the system quickly; the problem management team’s 1^st priority is root cause analysis.  An incident manager can reboot the server and if the server functions the way it’s expected, the incident manager’s job is done and the ticket is marked resolved.  The server may fail again in an hour, a week or next year.  The incident manager doesn’t care, once the ticket is resolved the Incident manager moves on to the next problem.  The problem manager’s job is to look at the “resolved” ticket and determine why the incident happened.  If the problem has a known cause, the ticket is then marked closed.  If the ticket is determined to have an unknown cause, the ticket goes into the problem manager’s cue for root cause analysis.

The root-cause analysis process is a long forensic journey looking for hidden clues.  The root cause could be a failing piece of hardware, mistakes in the software program, a misconfigured setting or even a mistake in the business process.  The analysis review may search through log files, software code, interviews with the incident manager and even with the non-technical employees who discovered the problem. 

What I’ve found working the last 21 years as a consultant, is that this healthy conflict is essential for a well-run IT department.  When these teams are separate people with opposing objectives, more quality work gets done.  Where without this conflict, more problems arise as one or the other team players begin to dominate the leadership of the organization.

I am getting very tired of Systems Administrators that blame their users.  Once again I found myself between an IT Services vendor and their client.  As a Seattle IT Consultant I am often called in to help an owner fix their network.  Most IT Services Vendors are anxious when I walk in the door, thinking I may be trying to steal their clients.  The good ones find themselves with more work because I hand out a lot of referrals. I’m not an IT Services vendor in the traditional sense.  I work with clients to sit on their side of the table.  I translate the technical speak so common in our industry, into a language business owners understand.

Statistically thirty Percent of network system errors are caused by hardware failure.  If you’ve been in IT you know that most hardware errors occur in the first couple months the system is setup.  Once the system is running and doing what it’s supposed to, hardware failures are very rare.

Statistically we know that 80% of businesses report consistently IT failures

Once the system is up and running whose fault is it?  What I’ve found is that it’s usually not the user.  Yet when I’m called in, I find that more often than not the users in the organization are being blamed.  I’ve seen one extreme example after another.  Where users are being blamed, but the real problem is the system technician, system administrator or the systems architect.  It’s very easy to blame the system failure on technology.  The technology is never offended.  The technology vendor is always willing to take the blame, if it means you buy more hardware.  The problem is that once the hardware is replaced, if the system continues to fail, you know it isn’t the hardware.  So eventually technology vendors begin blaming the users.  After all who else is there that could be causing the problem.

Statistically 70% of IT failures is due to human error. 

If so, human error is always user error isn’t it?  The reality is that hardware and software vendors have made technology so bullet proof from the user, that users really can’t bring down a network any longer.  Not when that network is setup in its default configuration from the manufacturer.  The reality is that most network failures are not cause by users.  They are caused by the poor planning of Systems experts. 

There are a lot of advantages to the cloud.  There is the advantage gained by removing the ongoing cost of server replacement from the organization’s capital expenditures budgets.  In a Break/fix network environment most networks function between 85 and 95% availability.  By improving Availability from 95 to 99.9% availability organizations improve workplace productivity.  Workplace productivity losses average around $7,000 / hour for small businesses and $50,000 / hour for larger businesses and can be millions of dollars a minute for the largest enterprise organizations.  Recovering 4.9% or more of workplace productivity can mean the difference between red and black accounting ink.

There’s another unspoken reason for the cloud though.  That’s to take technology out of the hands of the average system administrator.  Today’s small business system administrator is a “Jack of all trades” master of none.  Small businesses can’t afford an entire IT department.  Instead they hire someone who is good at everything.  In the cloud, teams of technical experts are hired with deep technical knowledge in every technology.  These teams are working in a highly organized network.  Most IT Support vendors are still tracking tickets in their head or on paper.  There are managed services organizations that manage 1000′s of clients.  Then there are cloud providers who manage literally Millions of clients at a per user cost that is much less and provide 3, 4 and even more 9′s of availability to clients.

The reality is that the cloud is possible because todays small business systems administrators are statistically the real reason for most IT Failures.  These administrators don’t even admit it and charge their customers for fixing their failures.  These system’s people think they are fooling their clients.  They do know and are looking for some way to protect themselves.

Want to stay in business?  My recommendation is never blame the user… even if it is their fault.  Design systems that are bulletproof, highly available and highly scalable.  It’s probably too late though because the cloud is coming.

In a previous article, Modern Network Architecture – Network Failures, I wrote about the importance of planning for the modern network architecture.  As a Seattle IT Consultant is see failures in IT design.  In that article I described how $1 of planning can avoid $10 in incident costs and $100 in replacement costs.  I run into networks with very little anticipatory planning.  The excuse, the network is too small for such planning.  The problem: Networks grow faster and in directions that are seldom so predictable.

When networks fail, poor planners will recommend replacing hardware and software components.  Then breathe a sigh of relieve thinking they’ve fixed the problem.  As the technology becomes more and more complex, this replacement choice becomes more and more costly.  In small networks a system is often a server.  Replacing the server solves the mistakes made.  As the company gets larger the server is no longer the system.  The server is one component in a much larger system.  System replacements become more than just replacing $5000 or $10,000 server, instead the system footprint covers multiple servers and touches dozens of other servers.  Each system replacement potentially affects throughput on multiple systems and may require setting changes or system components changes to each system that need to access information from the failing system.  Replacing a system in a complex network become a business impact that can affect 100′s or even 1000′ of users, customers and data points within the system.  Replacement stops being an issue.

Problem management, or root cause analysis is the most expensive and least understood process in failing network.  When building new systems, I often hear experts saying… “Install the system, we’ll fix the problems later.”  Grandma knew better when she said, “A stitch in time save’s nine”.  Modern planners use the 1, 10, 100 rule to statistically show Grandma was right.

Problem anticipation starts with a process flow chart.  When thinking about what could go wrong, walk the customer through each step of the business process.  When thinking about data walk the data through every step of the process.

For example:

At the 60,000 foot level, every process can be broken down into three phases I call the three P phases.  The pre-process, process and Post-process.  Now identify the 50,000 foot level steps that occur in each phase.  Then as you move lower and lower in altitude, more and more process becomes apparent.

Looking something like

60,000 foot level

• Phase 1: Pre-process
• Phase 2: Process
• Phase 3: Post Process

30,000 foot level

• Phase 1: Pre-process
  • o Pre process Step 1: Requirement Steps
  • o Pre process Step 2: Requirement Compilation
  • o Pre Process Step 3: Verification & Reporting
• Phase 2: Process
  • o Process Step 1: Requirement Verification Steps
  • o Process Step 2: Execution
  • o Process Step 3: Test & Reporting
• Phase 3: Post Process
  • o Post-Process Step 1: Baseline Verification Steps
  • o Post-Process Step 2: Customer Handoff
  • o Post-Process Step 3: Post Mortem & Process update recommendations

Each level (60,000, 30,000, 10,000, 100 and 1 foot levels) more detail is added to the plan.  During the pre-phase planning risk and opportunity are identified, the requirement compilation customizes the execution plan to each customer situation.  This pre-process is the planning stage.  This is where the tactical aspects of the plan are aligned with the strategic intent of the plan. This is where the tactical execution experts may try to move the process along before every situation can be anticipated. 

Short changing the planning process short changes the owners of the organizations we support.  Statistically it can be shown that for every $1 of planning we scrimp the owner pays for in lost productivity and higher support and replacement costs.

“The network is down…” 

There are a few phrases that bring angst to business owners like this one.

“The IRS is waiting in the lobby….”

“There is a 60 Minutes film crew wanting to see you…”

Both these phrases may be worse to hear when the owner first sits down at his/her desk with the first cup of coffee in the morning.  But in the normal day to day normal business world, when the network is down, that’s probably the most heart stopping phrase for a small or medium size business owner.  In my roles as modern network architect or as a Seattle IT consultant I have my own feelings about this phrase.

Statistically – 20% of any non-technical managers work week is spent putting out IT fires. 

As network architects this is an embarrassing statistic.  As IT leaders this is unacceptable.  Whether the business is small, large or Enterprise affects the entire organization.  If a manager’s salary is $100,000 / year in order to justify him/her as a manager the company needs to make $300,000 / year from the work performed by that manager.  This pays for the manager’s salary, benefits, vacation time as well as the profitability the company will ultimately receive.  If 20% of a managers time is spent putting out IT fires that means that 20% of the $300,000 in workplace productivity is lost to the organization.  That means that while the manager loses 2 days per week in productivity.  For the company it represents $60,000 in lost workplace productivity just for that manager.  This is just one manager.  If the organization has 10 managers this works out to $600,000 in lost productivity.  This doesn’t count the lost productivity of the employees the manager is employing.  It also doesn’t count the cost in hardware, licensing and extra man hours put in by the IT department to fix the problem.

There is a rule of thumb that I call the 1, 10, 100 maxim…

It costs $1 to plan around a potential problem, $10 to fix the problem and $100 to rebuild the system so that the problem doesn’t happen again.  As the network architects we can that any problem we ignore will cost 10 times more each time we create a work-a-round and $100 dollars to finally fix, compared to each $1 of planning we put into anticipating the problem. 

There is always fall-out when the network fails.  As an Seattle IT consultant, every time an owner hears the phrase, “The network is down…” he or she will be calling someone like me and blaming the problem on their present architect.  If I’m the architect, I know that if my client is hearing the same phrase I know that I will be getting a queasy fear in the pit of my stomach imagining  my client calling for someone else’s help.

Recently I was meeting with a business owner and discussing customer relationship management (CRM) systems.  We were comparing Dynamics, Sales Force and Zoho from a business standpoint.  The three CRMs have three very different price point models, so how does one compare.  This is a pretty major choice and really will determine the technical architecture the organization will be able to utilize.  As a modern network architect, it’s essential to understand how the choice of a technology platform can affect the business.

We’ve talked about technology, so you’ve probably heard this before.  There are 5 stages a business goes through…

• Enrapture (Beginning entrepreneurs – where the business model is in the brain)
• Build (Where the entrepreneur creates a repeatable business model – Information is translated to workflows)
• Scale (where the model is duplicated or grown to support 10 to 100 times more capacity – No tribal knowledge)
• Efficiency (Where the weaknesses and risks found during scale are addressed.)
• Innovation (A strategic change in the whole business process)

The benefit of a CRM system is in collaboration created through strong workflow design.  The workflow is like a wizard that walks the user through the customer process.  In a sophisticated system there will be a workflow for the sales person, service desk, operations and even for the front desk people when they talk with customers and potential customers.  I don’t like Sales force because if you ever want to move from the system, you can’t take the workflows with you.  So many people casually decide on Sale Force because everyone seems to use it.  The ramifications are that you must build all your technology around Sales Force.  Today that might be ok, but what is the ramification in the future when the company is 10 times larger?

I like Dynamics (Windows Platform) and Zoho (Open Source Platform) as Cloud Architecture solutions, because they are compatible with so many other systems.  Microsoft Dynamics is compatible with everything Microsoft.  While Zoho has an even more comprehensive list of private and open source tools that it integrates with.   The systems then become very comprehensive so you don’t have to build the systems over and over again at every business stage.  The platform is robust enough that you can take the business to any level or in any direction.  Both Dynamics and Zoho are compatible with tools that will further enhance the scalability and efficiency of the organization.

There are over 50 CRM applications out there.  If we look back at the way industry grows we see a life cycle.  In the beginning of the life cycle of an industry there are many different options.  When we look back at the desktop computer.  In the beginning days of Apple they had to compete with IBM and HP, but they also had to compete with everybody that thought they could build a computer in their garage.  The industry matures and there are fewer and fewer competitors.  Whether the industry is computer hardware, software or even breakfast cereals (go back 100 years ago and read the history of Post and Kellogs.) three or four companies will dominate.  Therefore if we know that there are 50+ CRMs today, the final guess the Modern Network architecture expert needs to make is to guess which CRM will still be around 5 years from now.