Archive for October, 2009|Monthly archive page
Is it Out-of-The-Box or Pre-Assembled? Try before you buy!
Filed under: Best Practice, Industry | Tags: Architecture, business
Leave a Comment 
Pravin Kothari
I hope I made it clear in my last blog the difference between true OOTB and Pre-Assembled applications, which often require development to meet your needs. Sometime it is very difficult for a customer to tell the difference during the product selection process. Applications requiring customization can be made to look very slick, like a movie trailer. It’s amazing what a good sales engineer can do – they are not any less skilled than Hollywood artists. 
So how can you determine if a vendor is selling OOTB or Pre-Assembled application? The easiest way is to just go with an authoritative source if available. In the IT GRC space, take a look at reports like Gartner’s MarketScope for IT-GRCM. If you want more details, place an inquiry call with the analysts that wrote the research. In Gartner’s case, you would want to talk to Paul Proctor. Remember that analysts like Gartner will never outright endorse a vendor for a number of reasons, however, they can help you determine what type of technology is best for you, whether OOTB or something else. They can also tell you which vendor is really in which category. As part of their research, they talk to many customers who have actually used the products and can give you examples supporting their recommendations. If you have access to these analysts, you should not hesitate to request for an inquiry call.
The most bullet-proof way to validate this is to get your hands on the product. There are many different ways you can do this as well. Proof-of concept (POC) is a popular way. In a POC the customer gives vendors use cases and ask them to come back and show that the tools can meet the use cases. It is debatable how useful is a POC if a vendor is willing to invest in building customization for the POC and represent it as standard product functionality. Another approach is a Sand Box. This requires a vendor to provide an environment to the customer where they can play with the software without the vendor looking over their shoulder. This can be effective if it is done correctly. There are two wrong ways to do this. If you give a vendor detailed use case and other data so they can provide you a custom sand box, then you are not that better off than just a POC. If you just ask for the generic product and play with it without any training, you will likely get frustrated and not be able to explore some of the more advanced functions. Anything you can use without any training probably doesn’t have enough flexibility to meet your needs. The recommended way of doing this is to go through the vendor’s standard training course and ask for a generic evaluation copy for two weeks. Go through a fruit-fly version of the deployment experience on your own and see what exactly is OOTB. Allow a vendor to hold your hands along the way and even make recommendations on how to do things, but don’t let them do anything for you. Some people call this the “touchless POC”. You may have to pay to attend the training and you will have to have technical resource available to support this, but it’s a pretty small price to pay if you see how much effort some customers put into their RFP and POC processes.
Another good acid test is to look into upgradability of the product. We’ll discuss that next time.
Earl Perkins of Gartner Talks About Justifying Security Projects
Filed under: Best Practice, Industry | Tags: business, compliance, enterprise risk, Gartner, risk, Risk Management
Leave a Comment Pravin Kothari
Early Perkins of Gartner wrote a blog yesterday about the challenges of building business justification for identity management products (you can just broaden the whole discussion to security technologies in general). In his point #3 he pointed out that if security folks want to be invited to the Big-Boy table, they need to link security to justifications that business understands, such business risk, compliance and business process improvement. Make sure you read the response from Ed King, one of our resident identity management geeks here at Agiliance. He built on Earl’s thoughts a bit further and offered some concrete examples of risks that can be measured and provided as business justifications for security technologies.
A Hammer Factory
Filed under: Technology | Tags: Architecture, Development, Humor
Leave a Comment Pravin Kothari
All this discussion about OOTB and PDP reminded me about this post from Joel on Software. It is simply hilarious. It also does a nice job of boiling down my last 2 blog entries to “Are you looking to buy a hammer or a hammer factory?” A little humor before the weekend.
Out-of-The-Box vs. Pre-Assembled
Filed under: Industry, Technology | Tags: Architecture, Framework
Leave a Comment Pravin Kothari
In my last blog entry I made the claim that “a product cannot be both OOTB and RDP”. Some of my readers objected to that claim and used SharePoint as an example of a product that is both OOTB and RDP. This deserves some more explanation.
Yes, it is absolutely correct that a software product can be both OOTB and RDP. SharePoint is a great example. Others examples are Lotus Notes, ERP, identity provisioning, and help desk products. With these products, you have lots of rich features you can use OOTB with great configurability. These products also offer you a RDP framework and tools to extend and build your own implementations.
Note that “configurability” is different from “customizability”. All enterprise-class products, including OOTB products, are required to provide configurability and personalization (all via the user interface) to adapt to customer needs and environment. While the ‘customization’ term indicates deeper changes, expensive services, or even programming to build your own implementation that is typically more difficult to maintain and upgrade.
There are many shades of gray here about how OOTB really is OOTB? On one end of the spectrum there are products that many customers use with just configuration to meet their business needs, never have the need to use the RDP capabilities. SharePoint is such an example. On the other end of the spectrum, you have ERP applications that almost no one uses OOTB – almost all ERP applications in production have heavy customization that takes months and years of services to deploy and then again to upgrade. So what should we call products that have a lot of OOTB capabilities but almost all customers still have to “enhance” them using RDP functions? I would rather use the term “Pre-Assembled” products to make the distinction clear from OOTB products. A Pre-Assembled product is simply a starting point for you to build on or finish off (depending on if you are a glass-half-full or glass-half-empty kind of person ).
An analogy here is like buying a storage shed for your backyard. You can go to your local hardware store to buy a shed in a box. There are inexpensive ones that are pretty basic and there are nice ones with more features and options. People buy the ones that fit their needs and budget. More often than not the shed you buy doesn’t have every feature you would like to have or every feature designed just the way you like it, but it meets 90% of your needs and wants without a lot of hassle and effort on your part. This is buying something that is quite literally OOTB. I have 3 of these OOTB sheds in my backyard. The other way is to go to a local custom shed shop and buy something that is tailored to your needs and wants more precisely. The shed shop has many pre-fabricated parts and assemblies you can choose from to make your final shed. They even have sample designs that you can use as a starting point or get ideas from. Most customers use one of these suggested designs as a starting point for their grand design. The shed that ends up in the backyard is customized for you. This is buying a RDP product that is Pre-Assembled. Now, can you go to a custom shed shop and buy a Pre-Assembled model as-is without any customization? Absolutely! Do most people who buy a shed from a shed shop do that? No.
Fortunately in today’s IT GRC world, there are not that many shades of gray in terms of “OOTBness”. You basically have the true OOTB products and RDP framework based Pre-Assembled products. As I said in the last blog entry, there is no single right technology, as long as you understand the pros and cons of each approach and make an informed decision based on your needs and resources. You should always look for “configurability” for flexibility, but you don’t want to involuntarily end up owning a “customized” one-off implementation.
BMC Viewpoint’s Special Issue on IT GRC
Filed under: Annoucements, Best Practice | Tags: compliance, risk
Leave a Comment Pravin Kothari
BMC’ Viewpoint magazine’s latest issue is all about IT GRC. It has some interesting articles from contributors inside and outside of BMC. I wrote an article titled “The Big Picture: Beyond Compliance to Risk Management”. You can check it out by request a free copy from BMC here: BMC Viewpoint
Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization
Filed under: Industry, Technology | Tags: Personal Identifiable Information, privacy
Leave a Comment Pravin Kothari
I ran across this fascinating paper today on privacy by Paul Ohm of University of Colorado Law School. It does a wonderful job of describing landmark researches on the techniques of “reidentification” and their implications on privacy laws, with real-life case studies on AOL, State of Massachusetts and Netflix. The fundamental assumption of the effectiveness of de-identifying data and removing Personal Identifiable Information is now questionable at best. As data mining technology and social networking database continue to develop, as well as computing power become cheap and endless with the development of cloud, it is not difficult to see that current de-identification techniques can become virtually useless. PII will eventually cover every piece of data that can remotely contribute to a “digital fingerprint”.
With such information and technology at our finger tips for good and evil, it is increasing difficult to imagine our privacy to be ever completely safe. From an organization standpoint, it is also evident that privacy protection will become an increasingly difficult challenge. Privacy event/breach is virtually inevitable, so “effort” becomes the key differentiation between whether that privacy event becomes a disaster or a slight incident. Organizations that cannot demonstrate investment in and due diligence for a privacy protection program is simply gambling with their brand reputation.
What exactly is “Out-of-The-Box”?
Filed under: Industry, Technology | Tags: Architecture, Development, Framework
Leave a Comment Pravin Kothari
In Gartner’s latest MarketScope for IT GRCM in Q2 2009, Gartner did a great job identifying the two very different approaches taken by vendors in this space. Gartner called these two approaches OOTB (Out-of-The-Box) and Rapid Development Platform. Here is exactly how Gartner described them in the document:
“OOTB products are designed to work without significant customization or configuration beyond entering the control, asset and risk content specific to the enterprise. OOTB products are characterized by vendor-provided content for templates, workflow, sample controls and mappings.”
“Rapid development platform products are characterized by flexibility, which means they may be more-closely aligned with customer requirements, but they may also require services to customize and configure…. Organizations should beware of products that can do ‘anything’ except for very little OOTB without consulting assistance.”
The leading vendors in this space are evenly divided in the two camps. In case you are wondering, Agiliance RiskVision is in the OOTB group.
Like so many things in enterprise software, all is well until the marketing folks started to abuse the words (I can already hear my marketing VP coming down the hallway… he reads my blog ). If you go through the various vendor’s web sites and product literature, practically every vendor is claiming their products are OOTB, because it sound so good to the customers. In fact, many of the RDP (Rapid Development Platform) vendors have gone out of their way during the sales cycle to make their product demo like OOTB, while still touting the infinite flexibility of their product over the “other” OOTB vendors. Oh yes, they’re trying to have their cake and eat it too.
There is not a single right approach. You can’t say OOTB is better than RDP or vice versa. It’s all a matter of fit. Each customer must first determine what type of organization are you? In order to determine which approach is the right fit for your organization, ask yourself these questions:
- How much technical resource do you have to build and maintain the solution?
- What is your budget for both initial deployment and on-going maintenance?
- How much time do you have for delivering the results?
- How often do you expect to upgrade and patch the system?
- How extensive is your deployment? How many integration points do you have?
- How much flexibility do you need from the product?
- Do you have any flexibility to adopt best practices or do you have to replicate your existing manual processes (or legacy processes) exactly?
While there is a no universal “right” approach for all customers, there is a universal truth: A PRODUCT CANNOT BE BOTH OOTB AND RDP”. These are mutually exclusive approaches to product design. In the next few blog entries, I will drill down a little bit into this topic and would love to hear your feedback on this topic.
