Category Archives: MIS

I love Visio! I hate Visio!

I love Visio.  It produces so many great diagrams with great detail and clarity.  You can’t build, manage, operate, or support a data center without Visio.

There are a few things I really hate about using Visio with MIS organizations (especially MIS management.)

The main thing my clients hate about Visio is the same thing my previous employer hated:  the licensing cost combined with the closed file format.  The more good VSDX files you have circulating in an MIS organization, the more people are clamoring for a licensed software copy so that they can even see the danged diagrams.  Microsoft has shrewdly used some of their traditional product packaging techniques to make it so that your typical end-user can’t see the contents without thinking he or she needs the full Visio software package.  (Yes, there are a couple of solutions for your more experienced user.)  Circulate an updated diagram of the data center floor plan and suddenly everybody in the MIS organization and in the data center building will be clamoring for Visio on their laptop or desktop (or both.)

The most amusingly annoying thing I hate about using Visio is “architect elitism.”  Due to the licensing cost, many organizations choose to distribute Visio licenses only to the few people actually expected to be producing VSDX diagrams.  The assumption is that the producers will distribute PDF copies to the diagram viewers.  At IBM, licenses were only distributed to a short list of IT architects.  This quickly established a concept of elitism connected to who had or did not have the software.  I attended many design meetings where the “peons” would complain about not being able to see the design and the favored few responded “You must not be an architect.  Only architects use Visio, and architects only use Visio.”  I truly believe that if software was still distributed in boxes, some of these guys and gals would have carried around the empty Visio product box so that everybody could tell they were one of The Chosen™.

One quick way to embarrass yourself in front of clients is to distribute VSDX files at an Executive-level design review.  Executives don’t tolerate the attitude that they would be able to appreciate the brilliance of your design if only they had the foresight to load Visio on their laptop.  Executives have long loved Powerpoint.  Naturally, this leads to large populations of Partners, Managers, and IT Sellers wanting to see everything in Powerpoint.

After spending enough tedious hours stuffing Visio diagrams into Powerpoint presentations, I concluded that most diagrams should start out as, and remain Powerpoint diagrams.  Visio is really indispensible when you need “everything on one chart,” such as a data center floor plan, a rack elevation diagram, or some network diagrams.  However, many presentations and discussions either take a semi-abstract view of the big picture, or only need to show the details about one small aspect of the big picture.  For drawing IT diagrams, Powerpoint has the features that Visio designers use 80% of the time, and about 60% of Visio drawing tasks are essentially the same as in Powerpoint.  Frankly, the best rack elevation diagrams that I’ve seen were built in spreadsheets.  (Which would you rather revise 5 times per day during a deployment project: a cabling spreadsheet or a cabling diagram?)

I believe that there are really only a few situations when you really need Viso:

  • If the diagram will be physically plotted on giant paper and posted on the wall for everybody to review,
  • If the client demands detailed network, cabling, or elevation diagrams that must be simultaneously complete at the large scale and the small scale.
  • If the client demands detailed diagrams that much be dimensionally accurate (such as floor plans and some rack elevations.)
  • If you are preparing high resolution detailed diagrams for publication.

In my dad’s day, quality detailed diagrams were the work of skilled draftsmen and graphics artists, but that is a topic for another day.  May all your diagrams be true and clear, and may your graphic arts skills ever increase!


(Historical image courtesy of NASA.)

 

Advertisements

Outsourcing and Joint Ventures

[This is part of a series of posts describing how IT contracting compares and contrasts with  the structure described in the PMBOK.]


Business application owners may dream of hosting everything in a heavenly cloud.  However, somebody somewhere must own the tangible infrastructure elements.  For large enough applications, there can be economies of scale or competitive advantages in owning your own infrastructure.  In some industries, privacy, security, or regulatory issues dictate that an organization host its own infrastructure.  If your organization or client is large enough, this may be part of your project.

Hosting your own infrastructure means making decisions about how that infrastructure will be managed.  Historically, organizations that owned their own infrastructure also maintained their own IT staff to manage and operate that infrastructure, with augmentation from specialized contractors when needed.  (Please see the accompanying article about procuring IT support services.)  In the modern era, organizations have additional options for managing IT operations and infrastructure.  In order of increasing complexity, these options can be summarized as:

  1. Managed Services
  2. Outsourcing
  3. Joint Ventures

Managed Services

In the Managed Services approach, the management of specific parts of the infrastructure are turned over to an outside organization.  The ownership of the infrastructure generally remains with the contracting or “owning” organization.  The Service Provider provides day-to-day “care and feeding” of the servers, storage, networks, databases, middleware, and other components of the infrastructure.  The management services are likely to be delivered remotely (frequently from India.)

From a procurement perspective, the Managed Services are generally contracted on a unit price basis.  The Service Provider generally charges these services for a specific price per server, per network port, per device, per unit of storage, per data center, and by other units of measurement.  The actual contracting is somewhat more complicated, as described further below.

Managed Services provide the IT organization with considerable flexibility in what parts of the infrastructure and operations the organization wants to continue to handle directly, and which parts should be contracted out.  The result may still be significant complexity in how IT is managed and measured.  With this approach, the owning organization still makes major decisions about how things will done, but “farms out” the work.  In the Managed Services approach, there can be an unwritten assumption that the contracting organization has superior (or adequate) skills and experience in effective IT management, but seeks to move routine work to another party that maintains a collection of superior technical skills and special tools (or adequate skills at an attractive price.)

Outsourcing

The Outsourcing approach moves more responsibility to the Services Provider.  There are a range of options, overlapping both the more simple Managed Services and the more complex Joint Ventures.  With this approach, the owning organization moves many decisions about how IT operations will be managed to the Services Provider.  The contracting organization will likely retain IT Executives above a certain level, but the Services Provider will be utilizing all of their own IT Management and technical staff.  The infrastructure may be housed in a data center owned by the Services Provider.  The infrastructure may actually be owned by the Services Provider.

From a procurement perspective, the Outsourcing Services are roughly and conceptually based on a unit price basis.  The Service Provider generally charges these services based on the size and complexity of the infrastructure.  However, there are likely to be additional contractual incentives for cost savings and risk management.

Outsourcing provides the business considerable isolation from the operational aspects of IT services and the decisions made in support the IT operations.  In the Outsourcing approach, there can be an unwritten assumption that the Services Provider brings superior IT management than the contracting organization chooses to sustain.

Joint Ventures

If the first organization has transferred enough business opportunity and risk, then it ceases to be merely the “owning” or contracting organization.  If the second organization is providing business services at a high enough level, then it ceases to be merely an IT Services Provider.  As the business value, complexity, and bilateral nature of this relationship increases, then the relationship becomes more of a partnership or joint venture.

The details of these kinds of joint ventures exceed the space here, and the contracting details far exceed the kind of procurement contemplated in the PMBOK.

Pricing

Both Managed Services and Outsourcing are typically procured using a kind of complex unit pricing.  The contracts are usually individually contracted using semi-custom pricing.  The pricing is usually structured as a rate per unit per month, invoiced monthly.  Customers may initially want a simple monthly unit rate price, but suppliers frequently use a more complex rate structure.  These structures may include rate adjusters called dead band, contract band, “arcs,” and “rooks.”

For example, if a reasonable market rate for supporting a specific device is $10 per month, and the customer has 500 such devices, the Services Provider may structure the contract price around a $5,000 monthly rate.

A dead band of plus or minus 2% would allow the customer to add or subtract 10 devices from their infrastructure without a change in the monthly rate.  An Additional Resource Charge (ARC) of $8 would add an additional (discounted) unit price for each additional device above the base rate, once the number of such added devices exceeded the +2% dead band.  A Reduced Resource Charge (RRC) of $6 would provide a customer credit for each removed or unused device below the base rate, once the number of such removed devices fell below the -2% dead band.

A contract band of plus or minus 20% would allow the customer to grow or shrink their infrastructure by up to 100 devices and continue to be supported and billed according to the base rate, ARC and RRC rates.  Once the customer’s infrastructure grew or shrunk by 20%, a contract re-negotiation would be triggered.

These contracts typically include different rates for different levels of service, such as how quickly different kinds of technical issues will be resolved.

For contracts of more than a year or two, the base rate is likely to include an annual rate reduction based on the assumption of future economies of scale, improved tools, etc.

These contracts frequently include incentives for component up time and penalties for component down time.  Pages of terms and conditions will describe how up and down times are measured.

Outsourcing contracts are likely to include additional elements, such as incentives for cost reductions, process improvements, etc.

Transition, Transformation, and Steady State

Both Managed Services and Outsourcing contracts will include pages of dense text with definitions of Service Level Agreements (SLAs.)  These represent commitments of technical and business responsibility that the Services Provider will stand behind.  For various reasons, the contracting organization and the Services Provider need a “get acquainted” period at the beginning of the service period.  During this initial period new monitoring tools are being installed and both party’s staffs are getting their processes integrated.  One name for this period before the SLAs are effective is Transition.  Once all the tools and processes are in place, a formal handshake takes place. At this point, the SLAs (and their incentives and penalties) become effective.  The services contract enters the main contractual period, which can be called Steady State.

There is an important distinction between the kind of work that is and is not included in a Managed Services or Outsourcing contract.  In a traditional self-governed IT organization, a typical staff specialist will spend various proportions of his or her time building, testing, researching, changing, monitoring, fixing, and tweaking things.  Within Steady State, these kinds of contracts generally only cover the monitoring, fixing, and tweaking activities.  An IT infrastructure is usually a continuously changing and evolving entity.  However, these kinds of contracts are generally focused on the things that are not currently changing and not expected to change much over the life of the contract.  For Services Providers, infrastructure undergoing changes is said to be in Transformation.   Service Providers are delighted to provide assistance with Transformation projects, but at a price additional to the Steady State supporting rate.


[I welcome your comments and feedback based on your experience managing or procuring IT services projects.  Feel free to contact me directly.]

(Image courtesy of stevepb at Pixabay.)

Friday the 13th

Today is Friday the 13th, considered a particularly unlucky day here in the US.  Rationalists tell us that this is just another Friday on the calendar.  Wikipedia tells us that the fear of this day is called “paraskavedekatriaphobia,” and that some scientific studies indicate that this may actually be a slightly safer day for accidents.

This can be a light-hearted day for MIS systems administrators, as the superstition provides an excuse for deferring major activities until another day.

May all your systems be stable, and all your data secure, on Friday the 13th!


(Image courtesy BlueGarou at Pixabay.)

Time to Toss the Tarnished Tapes?

I’ve been getting a slow stream of calls from CIOs caught in the same bind. The CIO’s firm is involved in some kind of litigation. E-discovery has been underway, and somebody has found a shelf or box full of dusty old backup tapes. Somebody responsible for servers, databases, or operations had preserved these as insurance in case of unspecified problems. (No doubt based on bitter experience recovering from one of the common causes of data disruption.) Now the attorneys are calling for an inventory of exactly what is on the tapes, with expectations that MIS will eventually be instructed to produce some of the actual records on the tapes.

The CIO is caught in a bind, because a court may generally expect that producing records from a tape is similar to producing papers from a file. However, the CIO’s shop will likely no longer have the right hardware or software for reading the tapes, or the right software for recreating the information from the stream of bytes on the tape. There can be a long technical journey between having some random tapes full of data in backup format, and reproducing an e-mail or a database query from 1992.

Every system administrator knows (and can be summoned to testify in court) that good system administrators will keep a private collection of backups in readiness for the day when a heroic system recovery will be required. Likewise, every database administrator knows (and can likewise testify) that good database administrators will keep a private collection of backups in readiness for that day when a heroic database recovery will be required. (Once while implementing a new backup solution, a DBA told me that he didn’t care if we took hot, cold, daily, weekly, full, or incremental backups of his database.  In a real recovery situation, he planned to restore his database from a private backup on a flashdrive in his desk.) An experienced CIO could be expected to know that these private backup collections exist. To the sysadmins and DBAs, they are a bulwark against Murphy’s Laws. To opposing counsel, they can be treasures from Alladin’s secret cave. To corporate counsel, they are a liability, and to CIOs they are a possible future migraine.

This may be the time for a prudent CIO to establish policies on authorized and unauthorized data repositories, and policies on purging media when applications, systems, or staff are retired, replaced, or re-purposed.

Which is scarier to a CIO: an outsourced sysadmin leaving and taking his private collection of backups with him? Or a sysadmin departing and leaving his private collection of backups on a back shelf to be discovered a year or two later?


(Image courtesy pixel2013 at Pixabay.)

Seven Levels of Disaster Recovery Protection

In 1992, the SHARE user’s group defined seven levels of disaster recovery capabilities. These seven levels have been widely embraced by the industry and are commonly used by MIS organizations, vendors, and consultants for planning and discussing recovery capabilities.

These seven (actually eight and sometimes nine) levels are frequently referred to as DR “tiers.” However, the numbering of these DR levels is reversed from the traditional numbering of MIS service level tiers. Level 1 has the lowest DR capability, as well as the lowest cost and complexity. Levels 6 and 7 have the highest DR capabilities, as well as the highest costs.

Disaster Recovery Tiers

The seven levels assume that MIS operations take place in a primary data center, with the availability of an alternate data center for use in a disaster. The seven levels concentrate on how data and how application transactions are transferred from the primary data center to the alternate data center. The seven levels describe the technologies and investments needed to provide faster recovery following a disaster. Recovery times are conventionally measured as Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO.)

One of the most important concepts of the Seven Levels is that a specific desired recovery level must be designed into the specific architecture of each application. Achieving faster recovery times requires designing applications and infrastructures using specific technologies and methodologies.

One of the greatest recurring problems in Business Continuity planning is disconnection between DR expectations and the level of investment in DR designs and infrastructures. It is extrememly common for CEOs, CFOs, and business unit managers to have expectations for fast recoveries (usually corresponding to DR Levels 3-5,) while actual infrastructures have been implemented at DR Level 1 based on the available DR budgets.

As presently defined, the seven levels are tied to specific server and storage technologies and recovery methodologies, particularly technologies and methodologies popular in the 1990s and early 2000s. There have been some important new technologies (particularly server and storage virtualization) which are not directly addressed in the seven levels. It is possible that, in the future, the definitions of the existing levels will be more generalized, or there will be a few additional levels defined.

As seen in the following diagram, moving to a higher level provides faster recovery times, but requires a significantly higher investment in hardware, software, telecommunications, facilities, training, services, and management overhead.

Recovery Time Versus Cost

The seven tiers have been described as follows:

Tier 0 – No data is preserved off-site. No recovery is expected.

Tier 1 – Data is preserved off-site in backup format.

Tier 2 – Data is preserved off-site in backup format, with a DR hot site available.

Tier 3 – Data is preserved off-site in backup format using electronic vaulting.

Tier 4 – Data is duplicated off-site as point-in-time copies of primary data.

Tier 5 – Applications are customized for transactional integrity across two (or more) data centers.

Tier 6 – Data is duplicated off-site as continuous copy of primary data.

Tier 7 – Data and applications are duplicated off-site, with automated recovery.

Meeting specific recovery requirements is heavily dependent on leadership, organization, documentation, staff skills, and practice exercises. At the end of the day, only DR testing will ensure that any enterprise and infrastructure is capable of meeting specific recovery requirements.

Living in Interesting Times

In the US, we have an overused old story about an ancient Chinese curse that threatens “May you live in interesting times!”  In some versions of the story, this is part of a three-fold ironic curse of escalating intensity:

  • May you live in interesting times!
  • May you earn the attention of those in authority!
  • May you find what you are seeking!

Chinese historians tell us that this is an American myth. However, there is no question that we live in interesting times.  This very day’s headlines describe financial, electoral, military, governmental, and ethical crises.  These are proving to be tumultuous, unpredictable times, with uncertain dangers for business, and for MIS operations.  These are the times when one wants to sleep well at night knowing that one has a well-tested plan for business continuity, reliable operations for data protection, and that one has access to the kinds of facilities and equipment needed for rapid response to unforeseen problems.

Having been involved in the resolution of a number of MIS crises, I can assure you that human ingenuity, determination, and collaboration will usually find a solution for almost any kind of crisis. I invite you to a dialog here about modern threats to MIS and about how leadership and teamwork can disarm those threats.

Perhaps these are the times to keep in mind another overused American myth about ancient Chinese wisdom.  The other myth says that the Chinese glyph for the word “crisis” contains within it the glyph for the word “opportunity.”