A proof-of-concept project lets you boldly go where you’ve never been before
7/25/2012 3:59:41 AM |
By Gabe Goldberg
Proof-of-concept (POC) demonstration projects can blaze a trail, doing something on a small scale, for the first time, but perhaps changing basic assumptions and potentially influencing an industry or the world. One recent example was the privately launched Dragon supply capsule reaching the International Space Station; the early mainframe Linux implementations represent another.
Closer to home, IT POC projects are sometimes called pilot studies or prototypes. In the data center development/rollout scheme of things, they come much earlier than efforts such as beta tests, the last bit of fitness evaluation and tweaking before full release or production. Of course, even though “proof” connotes assured success, POCs occasionally fail—but that can be good news, because a concept disproved at an early stage often prevents a large disaster.
Major mainframe changes often begin with POC projects. Sometimes they’re even off-radar “skunkworks” efforts, hidden until results are irrefutable and leading to game-changing successes. Linux on System z is frequently introduced with this toe-in-the-water approach, then scaled for huge server consolidation.
But in spite of being a simple concept, POCs require more than a rote idea-try-results-success progression. Detailed planning and careful implementation make projects much more likely to succeed. Specifically, keep the following in mind:
Your bright idea might tread on someone’s toes; don’t offer or threaten to make anyone’s favorite technology obsolete. Emphasize collaboration and synergies. Don’t be overly clandestine; managers might not appreciate being surprised, even by a good-news project. Watch for C-level changes that influence receptivity to your effort, because new players often bring different assumptions and biases. In such cases, be prepared to justify/sell your project again with compelling and objective information.
Be creative to solve real issues.
Anticipate how unused resources might be deployed to meet future demands or solve sudden problems. For example, having Linux servers already running allows quick response when new services are required or distributed servers fail. Seize opportunities when new technologies or insights arrive.
Scratch an itch.
Deal with a long-time technical frustration or address a business problem not solved by “business as usual.”
Find a sponsor with an itch.
Does an IT executive need a dashboard showing operational status or a scorecard tracking active projects? Are distributed servers growing out of control just because they always have? Listen for “If only...” conversations and make them real.
Set business-related goals.
Build on—don’t repeat—what’s been done. There’s no doubt that Linux runs on System z hardware, so don’t set out to prove that. Rather, demonstrate how mainframe Linux can improve your organization’s IT function, cost-effectiveness, customer service, flexibility, reliability, etc.
Don’t “boil the ocean”—or even, necessarily, the swimming pool. Set achievable but meaningful goals. Perhaps boil the bathtub by running a small-scale private cloud service in an LPAR, or by introducing a new Web service with a dozen lightweight Linux servers under z/VM. That is, start with small applications/services rather than the most complex and resource-intensive application, no matter how impressive the latter might be. Perhaps use a personal System z development tool such as System z Personal Development Tool (zPDT) or Rational Developer for System z (RDz) as an entry point for a larger concept. Success will come from scaling up results, and failure won’t consume much time or money.
When your POC succeeds, it might enter production without being re-implemented, let alone re-architected. That is, choose meaningful naming conventions for servers, file directories, users and such that can scale and be publicized, rather than being restrictive and embarrassing (e.g., Star Trek character-named servers or random data names). Follow industry standards and best practices, along with (especially) current installation policies.
Establish evaluation criteria and stick to them.
The concept you’re proving should be measurable, e.g., function, performance, cost, scalability. Focus on the initial goal and avoid mission creep, analysis paralysis and perpetual testing. If it’s not in production by the deadline, abandon it.
Compare alternatives fairly.
Don’t burden mainframe cost with other platform expenses or too much shared infrastructure and overhead costs. Include and apportion precise costs for servers, associated software and staffing. Beware of fudged numbers when requested for head-to-head comparison.
Things change, requirements evolve. Don’t hang onto cherished ideas whose time has passed, whether they’ve become irrelevant or are now commodities not needing validation.
Mainframe-only—even all-IBM—data centers are rare. But the System z platform is still the central server workhorse. So the more it connects to and supports other platforms and networks, the more valuable it is and the more enthusiastic other systems’ staffs will be supporting a POC and its full adoption. When appropriate, blend disciplines. Successful Linux on System z projects involve z/VM folks learning a little Linux, and the Linux team understanding a bit about z/VM. That develops a common language and framework. For each group, it’s like travel to a foreign country, learning enough of the language, terminology, customs and concepts to find the bathroom and order a beer. Heterogeneous computing supplements mainframe strengths with other similarly fit-for-purpose technologies.
Involve relevant vendors.
If you’re porting cross-platform, understand versions, support, licensing and contractual issues. Because vendors often perform and participate in POC projects themselves, you might receive quick buy-in and favorable terms by suggesting and enabling new market areas for them. But you might not want to nest POCs—that is, have yours rely on the success of a vendor’s—so tread carefully here. Negotiate realistic prices for ancillary tools such as server provisioning, backup, system management and performance management.
The best potential technology solution does no good if it’s a secret.
You might be driven by technology but financial issues will affect and perhaps dominate decision making. If you have an IT chargeback system, use it for the POC. If you don’t, provide management with cost/benefit information as compelling as your concept’s validation.
Understand and address financial issues.
Know what drives your organization—opportunities, hot spots, sore spots—and match your concept to them.
Remember that potentially vast scalability is among the mainframe’s traditional strengths.
A metaphor suggested is handling an open-pit mine with a massive hauler, rather than a fleet of pickup trucks. Start small and anticipate growth, perhaps avoiding or displacing a more expensive server farm.
Ultimately, your POCs—Linux on System z, private/public cloud computing, enterprise-wide encryption, streamlined business processes, whatever—will succeed or fail based on quantifiable organizational benefits, with perhaps a dose of politics. If you’ve adequately planned and executed, and maintained stakeholder buy-in, your reward may be scaling enterprise-wide.
Gabe Goldberg has developed, worked with and written about technology for decades. He can be contacted at firstname.lastname@example.org.