Building the Technical Support Organization

                 

 
Special Edition Using Microsoft SharePoint Portal Server
By Robert  Ferguson

Table of Contents
Chapter  20.   Example Scenario 1 ”Planning a Deployment


A number of forces drive the size and scope of the organization tasked with designing, building, and supporting the SharePoint Portal Server solution. Indeed, a support organization will likely revise itself after a SharePoint Portal project goes "live" (go-live), but for purposes here, we will focus on the following "pre “ go-live " requirements that drive staffing the portal support organization:

  • Functional or "capability" requirements

  • Accessibility requirements

  • Availability/High-Availability requirements

  • Performance requirements

  • Scalability requirements

  • Security requirements

  • Administration requirements

  • Other requirements

We have seen each of the requirements listed previously mentioned in different chapters throughout this book. Astute readers will also note that these requirements also map to different technology and functional areas covered in Microsoft-provided or hardware-vendor-provided SPS sizing questionnaires. In the next few pages, we'll take a closer look at each of these.

To see the SharePoint Portal Server sizing questionnaire in action, see "The Sizing Questionnaire," p. 586.

Functional Requirements

Functional requirements drive the configuration of the dashboard, and therefore typically involve technical specialists focused on designing effective layouts, as well as technical specialists experienced in configuring the dashboard (developers, also generically referred to as programmers). For our purposes here, defining the functional requirements in terms of the following will provide enough information to drive the development of our technical support organization:

  • Number of organizations

  • Types of organizations (almost exclusively financial in the case of ABC Company, although limited manufacturing, warehousing, and other folks would eventually benefit from sharing some of the data)

  • Sensitivity of data which will reside in the portal

Accessibility Requirements

Accessibility refers to the ability to actually acquire or get to the data. Some users may be limited in terms of the connection speed they will enjoy with the portal (such as 28.8 modems or slow WAN links). Others may be wired for 100 megabit switched LAN connections, but run slower desktop technology, have limited memory resources, or be saddled with older OSs. Yet others may have no native Internet or intranet browser capability. Therefore, early in the deployment planning process, it becomes essential to estimate and characterize the total number of end users, determining which of these will be accessing the portal via dial-up, WAN, or LAN-based links, and whether this drives changes to the desktop, the network links, or even the SharePoint Portal Server implementation itself. ABC Company simplified and documented this exercise by developing the straightforward "End User Client Matrix" illustrated here:

Figure 20.1. Sample illustration of an End-User Client Matrix. This particular example displays four connections types (<56kb, 56-128kb, WAN, LAN) and five client machine attributes (OS, CPU speed, RAM, Browser Version, and Outlook Express Version).

graphics/20fig01.jpg

Another area of accessibility involves addressing the special needs of people who are deaf, hard of hearing, or otherwise challenged in terms of getting to the portal data. Microsoft is committed to making its products ”from OSs through applications ”available for everyone, as evidenced in the following:

  • Features and hints for customizing Windows 2000

  • Online and audio-based Microsoft software documentation (plus cassette, floppy disk, and compact disc [CD] formats)

  • Third-party utilities that enhance accessibility

  • Special Microsoft services for the deaf and hard-of-hearing

Availability Requirements

Like functional requirements, availability requirements are also driven by user needs, though they are most often addressed by traditional IT organizations staffed with providing operations, maintenance, and specialized high-availability support. Often termed high availability requirements, or HA for short, these requirements refer to the need of the solution to actually be up and available for a certain percentage of total "wall-clock" time. This is where the infamous "3 nines," "4 nines," and "5 nines" of availability originate, equating to 99.9%, 99.99%, and 99.999% availability, respectively.

In reality, 99.9%, or 3 nines, is actually quite high for the majority of enterprise solutions deployed today. An implementation expected to be up 99.9% of the time ( assuming 24x7 availability and a 365 day year, which equates to 31,536,000 target seconds of availability per year) can only be down 31,536 seconds (525 minutes, or just under 9 hours per year). In other words, a 99.9% HA solution will be expected to be up/available 31,504,464 seconds of the year. Ask most IT shops out there if they can withstand 9 hours of unplanned downtime per year, and the answer is usually "Sure, sounds great; where do I sign up?"

Of course, some enterprise applications require even less downtime. There are companies today that can only withstand five minutes of unplanned downtime per year ”otherwise, lives might be put in danger (as in refineries, power plants, and so on), or millions of dollars might be at risk. Availability is all about money, in fact ”ABC Company hired a third-party systems integrator to assist them in determining their HA requirements. Their consultant started their HA conversation with "I can give you any level of availability that you'd like ”higher availability simply costs more money." The next step then became an exercise in calculating ROI, or return on investment. They quickly estimated the hardware, software, and resource costs to implement a SharePoint Portal Server solution capable of providing 3 nines of availability, and next determined that to "give back" an incremental hour of unplanned downtime ran up another $500,000. The question then became "Will you suffer more than $500,000 in lost revenue or productivity if you are down an incremental hour ?" As the answer was "no!" they determined that three 9s was good enough .

Ah, "good enough." A mantra at some companies, an anathema at others ”"good enough" scares the QPM folks to death! But good enough is all about getting 95% of what you need at only 20% of the cost of a solution that satisfies 100% of your needs. Confused?

Unfortunately, many companies fail to do the "5 nines of availability" math, and simply request the highest levels of availability from their hardware partners . Their need for this level of availability is simply a perceived requirement. Once the budget and ROI numbers are worked out, this perceived requirement usually works its way back down to something that less than three 9s can address ”something closer to "good enough" (got it now?). But this practice certainly helps explain the abuse and over-use of the term "5 nines of availability" in today's information technology world.

Performance Requirements

Though availability is important, a minimum level of overall portal performance is critical as well. For our purposes here, performance requirements tend to drive the makeup of the technical support organization in one primary way ”the need for specialized technical resources becomes mandatory if "niche" performance-improvement products or techniques are employed. Some of the products and techniques include

  • Caching servers

  • Load balancing routers or servers

  • Software or OS-based load balancing

At ABC Company, the initial thoughts were that their performance goals could be achieved without the need for specialized performance options.

Scalability Requirements

Scalability requirements speak to how quickly the current solution can scale or grow to meet planned or unplanned increases in the number of users accessing the portal. For example, with the increase in users that ABC Company will realize after bringing Asia and Europe online, the solution to be implemented must be capable of growing without "trashing everything and starting over." This is where sound architecture planning becomes critical.

Security Requirements

Security requirements are perhaps more important than any of the preceding . As ABC Company has already discovered , once a security breach has occurred, things are never the same. That is, you just can't squeeze the toothpaste back into the tube ”it doesn't work that way! But an organization can learn from their mistakes, and ensure that both the design and implementation of the new SharePoint Portal Server addresses security as a primary consideration, not as an afterthought.

The process of introducing and managing change within the SPS environment also serves to maintain the security of the system. Change management (used interchangeably with the term change control) is addressed later in this chapter.

Paramount to the discussion of security is a discussion on the nature and sensitivity of the data that will reside in the portal. Payroll data, data related to benefits, data regarding customers or new product roadmaps , and so on are prime examples of "sensitive" data ”the kind of information that only hurts the organization or entire company when it is compromised. ABC understands this more than ever.

Administration Requirements

Administration requirements drive the composition of the technical support organization from a day-to-day operations perspective. It makes no sense at all to invest time and energy into a portal solution only to leave it un- maintained ”better to continue using your unorganized file shares and private mailboxes, and save your money! Many organizations fail to realize this fact, though, until they have already deployed an application into production. Then, the challenge becomes trying to retrofit and retool an existing operations team to meet the needs of the new application.

A question central to how existing resources would be leveraged to support the new portal project at ABC Company was "Who actually manages the data we have today?" That is, does a centralized IT organization or departmental-based IT organization manage the various forms of data and content? Or, rather, is data management the responsibility of local business group super users, distributed administrators, or another entity? Answering this question yields two great truths:

  1. The location, size, and breadth of data becomes apparent.

  2. Individuals with skillsets (or at minimum, a vested interest) in managing data come to the surface, representing potential technical support organization team members , or perhaps even barriers to the success of the project.

In the case of ABC Company, however, we were fortunate. ABC's Data Center Computer Systems/Operations Team consisted of long-time company-badged computer operators, specialized in maintaining a multitude of servers and systems running various flavors of Microsoft enterprise operating systems (NT Enterprise Edition, Windows 2000 Advanced Server, and an XP pilot project currently in progress), as well as a number of Unix variants. ABC's 24x7 operations team welcomed the challenge of learning how to best support a new application, and were positioned well to do so in staggered stages or phases, as three individuals worked 12-hour shifts, and all workers were divided into two teams (Sunday-Tuesday, Thursday-Saturday, and split Wednesdays).

Other Requirements

Other requirements that might drive the size and scope of the technical team include

  • Problems uncovered via the completed questionnaires, in terms of content provided, timeframes provided, and data formats provided, will drive business needs

  • Security concerns regarding ability of one group to view another group's documents will drive security needs

  • Inability to manage or track revisions of documents will drive traditional content-management needs across the business organizations

ABC Company quickly realized that they had no real content management expertise. They knew over time that they would develop this expertise; however, the need to get up to speed quickly became a driving factor. In the end, they elicited the assistance of a third-party consultant specializing in content management, with deep experience in Microsoft's platforms and products. The arrangement was such that the quality and speed of knowledge transfer provided to ABC's own technical support organization drove the billable hourly rate of the consulting contract ”within three weeks, ABC was not only well on their way to self-sufficiency, but also was in a financial position to take advantage of the consultant again, should the need arise.

ABC measured the value gained through introducing the consultant in a number of ways, including feedback from each team member tasked with eventually supporting SharePoint Portal Server, plus the ability of each team member to manage the portal from an operations perspective. Of course, other milestones could have come into play, like the ability to install and configure a particular feature or component of SPS. Each case would differ , underscoring the importance of identifying measurable success criteria at the beginning of each consulting engagement.


                 
Top


Special Edition Using Microsoft SharePoint Portal Server
Special Edition Using Microsoft SharePoint Portal Server
ISBN: 0789725703
EAN: 2147483647
Year: 2002
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net