IJIS Factor Blog   |   Contact Us   |   Sign In   |   JOIN US!
IJIS Procurement Innovation Blog
Blog Home All Blogs
Search all posts for:   


View all (10) posts »

Defining and Articulating the Problem

Posted By Robert Shumate, Thursday, May 14, 2015

This is the fourth of an eight-part series on procurement practices in information technology. This series is authored by Bob Shumate, a Member Emeritus of the IJIS Institute and the chair of the IJIS Institute’s Procurement Innovation Task Force. The material in these articles covers the findings of the Procurement Innovation Task Force and offers some insight into the problems and solutions in procurement evident in today’s information technology markets.

Past approaches to technology procurement have emphasized the use of inflexible RFPs within which the buyer attempts to define, in detail, the technical solution that he expects and limits any deviation from the specifications. The problem with such an approach is that it assumes that the buyer is sufficiently knowledgeable, understands current technology, and knows how it should be applied. This is rarely the case since modern technology is evolving at ever-increasing speeds, making it difficult for the buyer to be cognizant of the latest and best technical solutions.

Avoid inflexible RFPs wherever possible. Inflexible RFPs force suppliers to limit what may be better-quality approaches to the problem in order to remain compliant under most current procurement rules. Avoid trying to describe how the technology should be applied to solve your problem and stick to describing the problem for which you want a solution. Rapidly changing technology may have made the approach you proposed obsolete or less desirable by the time the RFP is in the hands of solution suppliers. If, because of legal or administrative requirements, you must use a restrictive approach in your RFP, at least try to make the inclusion of alternative approaches to the problem an option to suppliers. Procurement documents that attempt to define how the problem should be solved and that contain rigid response requirements often discourage some of the best-qualified suppliers from bidding on your project because your approach may not be realistic. Further, it may limit your receiving a more cost-effective solution to your business problem.

Concentrate on defining the problem rather than the solution. Buyers understand their business processes far better than they understand the technology that may best be applicable to the results they wish to achieve. Concentrate on describing the business process(s) involved and what you want to achieve in improving the way they are handled rather than trying to specify the solution. This is an exercise that will require a significant effort to understand and describe your business practices. Describe how you want to change the business process to make it more efficient. The effort may lead you to a much better understanding of your business practices and thus make you more aware of how processes must change to accommodate technology. For example, it is a real change to avoid the manual keying in of data that could be electronically forwarded and added from another source without intermediate action, which may involve eliminating work positions as well as changing the entire way the in which the transaction takes place.

Structuring your RFP around a problem definition is by no means a short cut; in many instances, it is far more difficult since it forces the organization to take a detailed look at its business process and consider how they need to be changed to achieve efficiencies and provide better service to consumers. Remember throughout the process that technology is a means to and end and the business process is the important factor. Often the business process must undergo change to create the most effective adaptation with an IT solution.

Consider what standards should be included. This is the time to consider how and what standards requirements you should include in the procurement document. All IT systems today should be viewed as a single node on a global network of information sources. You must be able to serve as either a consumer or a supplier of information from other systems and be able to exchange data with other systems. No matter how carefully you have designed your Enterprise Architecture, or whether you do not have architecture in place, no one can foretell the future and additional requirements for data exchange will inevitably occur and your system must be able to add both consumers and suppliers in as seamless a manner as possible. Your system while remaining locally independent should have the ability to exchange and use information from heterogeneous networks, applications, or components while maintaining the integrity and independence of your system.

Standards such as the Global Reference Architecture (GRA) based to a large part upon the OASIS Reference Model for Service Oriented Architecture (SOA) defines at the abstract level how such architecture should be applied in defining standards. There is a difference between the architectural concept and the technical requirement that have been developed in support of SOA. Procurement requirements, by their nature, deal with technical needs because they specify what a service or a product needs to provide. We have to look to those requirements specified in SOA that translate into terms suitable for use in a procurement document.

(We will discuss in more detail how you should express these standards in the procurement document in our discussion on Preparing and Disseminating the Formal RFP.)

Consider your approach to hardware and operating system infrastructure. In the past, this usually meant you would request the provider to specify the hardware, operating systems, and database system needed to support the proposed solution. Today the options available are much more complex and require considerable thought to select the best approach to meet your needs at the most effective cost performance level. There are currently three approaches that should be considered in addition to the option of you purchasing and maintaining the required hardware, network connections, and operating systems at your site. Most of the approaches described below are provided on a subscription basis under which you pay only for the services utilized.

  • Infrastructure as a Service (IaaS): The Cloud Service Provider (CSP) supplies and manages the networks, servers, data storage, and the customer provides the rest, which includes the operating system, software applications, development tools, and related services.
  • Platform as a Service (PaaS): The CSP provides and manages everything including the operating system, development tools, servers, data storage and hosting to provide the customer with a development platform within which he can develop and deploy his applications.
  • Software as a Service (SaaS): The CSP procures and manages everything, including the software applications and related services. Some common examples widely used today are email services, document preparation applications, and accounting applications.

There are several ways in which each of these services may be deployed.

  • Public Cloud: The service infrastructure is remote, connected through the web and provides services to multiple clients using a shared infrastructure. Usually two types of services are offered, dedicated, and shared. Dedicated service means that the entire physical server(s) is dedicated to a single customer and is shared with no one else. Shared services mean that physical server(s) are shared among several clients with resources being allocated based upon demand.
  • Private Cloud: The service infrastructure may be located on your premise with the equipment owned and serviced by the CSP or at an offsite location on servers designated for and used only by you. Most CSPs offer private (dedicated) cloud facilities for IaaS and PaaS.
  • Community Cloud: The service infrastructure is used by several related customers such as other agencies within your political subdivision. The infrastructure may be located locally at one of the participating agencies with equipment being owned and serviced by the CSP or at an offsite location on servers dedicated for use only by the group.
  • Hybrid Cloud: The service infrastructure is a combination of different kinds of clouds (public, private, community) that exchange data and applications. You might for example have your applications running on a private cloud while part or all of your data storage is in a public cloud.

Decide whether you want to produce separate procurements for the IT solution and for the infrastructure hosting. Solution providers have becoming accustomed to serving as an interface between their customers and CSP and have become increasingly proficient in understanding the various tradeoffs between different approaches to infrastructure hosting. Depending upon your organization and the technical skill levels available to you it may make sense for you to negotiate directly with a CSP to get the best possible approach for your IT requirements.

Please feel free to add your comments on this topic below.

Next: Preparing and Disseminating the Formal RFP

Future Posts:

  • Evaluating Responses to the RFP and Selecting a Supplier
  • Negotiating a Contractual Agreement with the Selected Supplier
  • Contract Oversight and Management
For further reading: http://www.ijis.org/?page=Procurement_Resource

Tags:  Cloud Sevices  GRA  RFP  SOA 

Share |
Permalink | Comments (0)
Membership Management Software Powered by YourMembership  ::  Legal