ITIL and MOF are two strategies that help manage the complexity and sometimes chaotic processes internal to many IT departments.  When I started in technology, if you were any good, you were probably a cowboy.  Cowboys were great because you could quickly get things done.  Cowboys later became poison because nobody could keep track of everything on the network.  The top cowboy became the organizational technology support bottleneck.  Business growth was often limited not by the sales team or the production line, but rather the level of understanding of the Cowboy.  This led to the question for management, “…how do we manage an IT department?”  ITIL and MOF became two common methods that allowed management to hold IT services groups accountable.  The modern network architect struggles with how to implement technology in the most effective way.

Microsoft Operations Framework (MOF) is a series of guides aimed at helping information technology (IT) professionals establish and implement reliable, cost-effective services.

The Information Technology Infrastructure Library (ITIL), is a set of good practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business.

When I come into a new network the first question I ask is, “Where’s the documentation.”  The first reply is usually, “We have no documentation.”  Sometimes the IT Department laughs at me for asking that question.  The next laugh is on them because we begin the documentation process.

ITIL and MOF are all about documentation.  Fortunately both systems have done a great deal of the documentation for you.  As an IT consultant the reason I ask for documentation is that I don’t want to pick up someone else’s mess.  If you take over a network, IT department or Technology System you take over all the headaches and mistakes of the last person who managed the department.  The reason they last person isn’t working there is because the department probably outgrew the last IT Manager’s skillset.  I find that identifying the documentation problem is the first step.  Then I can start developing the roles, SLAs and business processes of the department.  Fortunately ITIL has all this documented.  I don’t have to re-invent the wheel.  Just customize it to the new group or department.

In business managers define business process with management points.  Each management point has a quantifiable business value that helps the manager understand what is going on throughout the process.  MOF is heavily into process and management points.  Most IT departments are managed by technical people who think that it’s all about the technology.  They have their own language and processes.  Are those processes good?  Most of the time, from a business standpoint, these processes are convoluted and created by a technician interested in making his/her own job easier.  With MOF we can take the most obtuse technical process and build structured management points around that process.

By understanding the roles and business processes like MOF and ITIL modern network architecture is not just more business stable, but is also more technically stable.  Cloud architecture is being built utilizing a standard business and process architecture.  Older networks function between 85% and 95% availability averaging a month of downtime per year.  Modern network architecture functions at a minimum of 99.9% (about 15 minutes of downtime per year).  There are even some cloud network and unified communication providers that provide a 100% SLA to customers.  This is unheard of in only 5 years ago for most network environments.  ITIL and MOF standards have changed network infrastructure in a way that makes cloud services possible and profitable.

I spoke with another client.  He was a small client who was considering going back to night school to study technology.  He described how difficult life is being held hostage by his IT consulting company.  I’m hearing this more and more often as I talk about cloud network architecture.  Our clients are feeling like hostages to their technology and to their IT consultants.  I think the modern network architect needs to understand how to build systems that enable not trap the business owner.

Imagine a client that is so frustrated with the situation that he gives up talking to his IT support company and goes back to get a school to free himself.  I’ve begun asking questions of business owners, “Do you feel like a hostage to your IT department or IT contractors.”

The facial emotions quickly go blank.  Almost as if they are thinking, “… But you are the enemy… can I trust you with the truth?”

I explain why I’m asking the question.  After hearing that many business owners feel the same way a sense of relief seems to overtake the owner.

Then they admit that yes they do and then I get an earful about the problem

Having worked with IT experts for many years I know that most IT Experts are doing the best they can for their clients.  The problem isn’t that they aren’t trying to do a good job.  I think the problem is ignorance about the needs of the customer.  I think there is also ignorance about some of the basic roles within technology.  Most IT Support experts focus on Incident support and little focus on Problem management or root cause analysis.  So it’s no wonder that problem keep re-occurring over and over again.  This is probably also why most on-premise networks are managed without a Service Level Agreement (SLA) for availability.  A professionally run IT Consulting Company understands the conflict cause by the technical power of the technologist and the effect they have on the bottom line.

I think this is one of the biggest advantages of the cloud.  The cloud will move on-premise networks out of the office building and into a professionally run network operating center (NOC).  The NOC will have incident and every other IT Operations role.  Once in the “Cloud” the owner will get the same type of reporting and feedback that he/she gets from the other departments.  The political power that the technician has over the business and the business owner will be lost.  With cloud architecture the modern network architect will be releasing the business owner from being a hostage to IT.

The term “cloud” is a metaphor for the internet.  The term was borrowed from the past representations of the phone system.  From a technical standpoint what is the cloud really?  Isn’t it basically a physical NOC (network operating center) where systems are stored?  Those systems can be virtual or physical systems.  Or is there more to network architecture than just a connection to a NOC?  As “The Cloud” takes over more and more of the roles traditionally handled by on premise networks, the modern network architect needs to understand how these systems integrate together.

Today there are three IT services provided by the cloud. 

• Software as a service (SaaS)
• Platform as a service (PaaS
• Infrastructure as a service (IaaS)

SaaS - I had a chance to spend time working with Microsoft’s BPOS (Business Productivity Online Services) offering.  The primary offering was a hosted Exchange system.  There was a Standard environment which was a multi-tenant hosted email system.  This is an example of an SaaS system.  A person of a business can obtain enterprise quality hosted software services.  In the BPOS example over 2 million SMB, Enterprise and Government email accounts are hosted on exchange servers that integrate seamlessly with the organization’s on premise network. 

Paas – PaaS facilitates the deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers.  Platforms let systems administrators and developers write applications that can run from the cloud without the capital expenditures required when deploying in an on premise network.

IaaS – On premise network typically run with 85 – 90% availability in the SMB world.  This can mean a month or more in lost down time for each employee affected.  Managers often spend 2 hours of every week putting out IT fires.  An IaaS system guarantees 99.9% availability or better.  This works out to less than 15 minutes of down time per year. 

Companies of every size are replacing their on premise infrastructure with SaaS, PaaS and IaaS infrastructures.  The trend is just continuing.  Consider the accounting life cycle of a server is about 5 years.  During the depreciation cycle of the server, a little money is saved each year to pay for the replacement infrastructure.  What if that cost could be recovered? 

Cloud infrastructure does not require the purchase or maintenance of hardware, the support infrastructure and the people to support that infrastructure.  Suddenly that money being saved for the new server is available for other business focused projects. 

Expect that over the next 5 years to see a huge migration from on premise networks to cloud networks that support software services, platform services or Infrastructure services.

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.