Bookmark :              

Lies, Damned Lies, and Statistics, Benjamim Disraeli

Earlier this week, I was doing a little market research to determine the market share for operating systems and their various versions. I thought I could do a quick Google search and be done with it. In spite of the fact that there is a lot of information out there on operating system market share, most of it is either too broad to be useful (to me) or too specific.

The difficulty of obtaining the information I want is likely due to a number of things, some intentional and others perhaps not. First, companies such as Gartner Group, IDC and Forrester make a lot of money selling this sort of research. I can’t really blame them for not wanting to give that away.

Second, vendors are often times spinning the data in order to make themselves look better than they might otherwise look. (e.g. HEADLINE: WhackyWhidgets is the leading supplier of widgets! BURIED IN THE SMALL PRINT: WhackyWhidgets is the leading supplier of widgets for businesses in the process manufacturing industry with revenues between $20 million and $23.5 million.)

Third, it is easy to take data that is almost what I want and try to turn it into exactly what I want. The result is misleading or possibly out right wrong. Giving most of us the benefit of the doubt, I don’t think this is intentional really. We might not have asked, or received, all the information really needed. In this case, the information doesn’t exist. Or we might not have organized the data in a way that makes it useful for the current need. Or the data might be stored in different databases and impossible to combine in a meaningful and accurate way.

Obviously there are many more possibilities as to why data might be misleading or wrong. It’s worth reviewing, especially when the data is used to make strategic decisions or it is needed for audits. Reviewing the quality of your data will certainly require less time now then it will when you need to do the analysis. Then, it might also be too late.

Posted by Scott Johnsen At 08:07:22 AM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

Changes to an application design can cause many data integrity issues. For example, changes that resulted in a field being renamed can cause data to disappear, at least from a user’s perspective, and are virtually impossible to find unless you know they are missing. Similarly, orphaned documents are just as difficult to deal with. If you have a large database, it may be impractical to check each document manually, prior to deployment. As a result, these issues don’t even present themselves until they are in the production environment.

Data maintenance should be a primary concern when designing strategies. Make sure that application managers are involved in deployment plans and possibly even design plans. There should be functionality built into the application that can monitor data integrity issues. Relatively simple scheduled agents can be developed that can periodically check documents, or update older documents to conform to new designs.

Feedback for any potential usability issue causing data to be input incorrectly should be provided immediately. An easy way to prevent issues is to make it extremely clear what data is required for each field, and in what format it should be. Make sure your design requirements entail the use of input validation and input translation formulas. Not letting data errors be input in the first place is critical.

Posted by Scott Johnsen At 08:14:59 AM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

Considering the investment you have made in your Lotus Notes/Domino infrastructure, it is critical to promote data integrity to help maximize the return on your investment. In general, you can address threats to data integrity by implementing both preventive and detective initiatives.

Data Integrity Threat	Detection or Prevention
Perform Regular Data Backups	Prevention
Control Access to Data via Security Mechanisms	Prevention
Monitor Access to Data via Security Mechanisms	Detection
Design User Interfaces that Prevent the Input of Invalid Data	Prevention
Design Document Maintenance into the Application	Prevention
Monitor Updates to Documents and Record Change Histories	Detection
Use Error Detection and Correction Software when Transmitting Data	Detection
Scan Applications Regularly for Common Issues such as Broken URL Links	Detection

Within the Lotus Notes/Domino environment, general threats can occur as well as Notes-specific problems such as save/replication errors, poor replication strategies, broken links to documents or Lookup Views, or users simply in the wrong application.

Posted by Scott Johnsen At 03:29:10 AM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

It’s a fact. Every company faces risk. Whether you are concerned about regulation compliance, security, technology, privacy, fraud or other facets of risk, you are likely focused on risk mitigation and detection. This is absolutely critical to the long term success of your business. So I’m glad you are paying attention to it.

Risk management is usually thought of in terms of cost, particularly time and money. How much time and money has to be spent in order to manage risk at an acceptable level? It sounds simple, but I know this can be very difficult to do in practice. But it has to be done.

Regardless of the type of business you have, a certain amount of risk mitigation must take place. You must protect customer information. You must file appropriate financial statements. You must maintain fair hiring practices. Managing these risks well is not going to ensure your company is wildly successful. Although managing them poorly might ensure your company will fail.

There is another side to risk management that is frequently ignored when creating risk management policies. Having a risk/reward view of risk management will help you see the opportunities that effective risk management can provide.

For example, you can’t do much about hurricanes, blizzards or floods. But you can put a disaster recovery plan in place that allows you to recover much more quickly than your competitors. What if you could recover in hours or a day when your competitors were taking a week or more to get back to business?

Now that’s getting the most out of managing risk.

Posted by Scott Johnsen At 01:51:50 AM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

Once an application has been deployed, the data that it stores must be properly managed. This includes the usage of the data as well as the data’s integrity. The application data must be managed in an ongoing fashion to ensure it is relevant, accurate and secure.

Your company’s data, especially as it pertains to customers, is your most valuable asset. The costs of unreliable data are derived from a number of events. Some of those events include; incorrect conclusions drawn from data analysis exercises, increased costs through a trial and error method to sift through data for accuracy, and providing customers with incomplete or incorrect information based on faulty data. In addition, unreliable data will encourage your customers, vendors, management and anyone else who has a stake in your enterprise to question your credibility. It only takes a small amount of faulty data to put the entire data set in question. If only 10% of your data is faulty but you don’t know which 10%, you can’t trust any of it.

In the IBM Lotus Notes/Domino environment, data integrity issues such as save/replication conflicts, disconnected links and hidden or lost fields are common. Searching for these errors is labor-intensive and typically occurs only when a problem is reported, if at all. As a result, the integrity of the applications and data is questionable and can put your organization at risk. In order to minimize these risks, policies that ensure the integrity of your data must be implemented.

Since many of the problems related to error detection and monitoring are difficult to do on a large scale, it is important to find ways that will help you do the work. Finding data integrity issues that already exist and being alerted when new errors occur is the best way to ensure you get the most from Notes/Domino. This will also avoid allowing you to get burned by failing an audit.

Posted by Scott Johnsen At 07:10:44 PM Location Beverly, MA USA | Permalink | Comments (2) | TrackBacks (0)

Bookmark :              

One of the topics that comes up frequently in conversations these days is web-enabling applications. I used to talk about adding a little bit of Dojo to your code to get a very appealing web interface. And then I saw XPages, which really addresses the notion of: 'what are you trying to accomplish by web enabling your application? XPages allows the developer to completely rethink how a user interacts with the data. Can you imagine trying to order something from Amazon if a Notes developer just web enabled that database?

Based on the articles, blog posts, and videos going around, it seems that XPages have been very quickly adopted by the development community. I know you are supposed to use the tool that is appropriate for the problem, but those frameworks were (see - I'm even talking about them in the past tense) hard to use. The Notes team has given us a tool in XPages that is a lot easier to adopt. So, is anyone still debating Dojo versus Ext.ND anymore?

Posted by John Kingsley At 02:45:53 PM Location Beverly, MA USA | Permalink | Comments (3) | TrackBacks (0)

Bookmark :              

Not who as in the Top Gear guy, but what. It's from the Department of Defense and stands for Security Technical Implementation Guides. One of these guides covers Application Security and Development. Just wondering if anyone out there in the yellowverse has come into contact with any of these, what the review process was like, and whether you uncovered any tools to help automate this review. John

Posted by John Kingsley At 02:36:45 PM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)

Bookmark :              

I think the most overlooked phase of application development, especially for Notes based applications, is the design phase. I’m sure there are a number of reasons for this, but one that I will discuss here is the timing of choosing the technology to be used for the application. I think most of you would agree that some technologies are better at some things than others. I think a lot of you would say that a good technology can be made to do almost anything you need it to do. But that doesn’t necessarily mean you should.

Regardless of where a new application idea comes from, the availability of a team to develop the application tends to garner the attention. In most cases, this occurs before the requirements are defined in enough detail to make a decision about the most appropriate technology to use for that application.

For example, I’ve seen cases where the next application in the development queue was assigned to the Notes development team for no other reason than they were the group that was free. Any thought beyond that probably focused on the group’s ability to perform the business analysis or on their reputation, or both. Not that those are bad things to focus on, but shouldn’t the technology choice receive at least some of that attention?

At the highest level, this might mean you should question whether a new application was best delivered as a Lotus Notes/Domino application, or possibly C++, Java or so on. Granted, multiple technologies can and probably will be used, but the primary development environment should be decided. At a lower level, you might look at the components of the environment you are using. For example, you might find that Lotus Notes/Domino is fine with a combination of Lotus iNotes, Lotus Sametime and Lotus Quickr. You might even decide Teamstudio CIAO! should be part of this environment.

There are certain realities that do get in the way of making sure the technology choice is made first. For example, in smaller development environments (like Teamstudio), we have a small number of very good developers. But their skills are not infinite. We cannot expect them to learn a new technology because it fits an application better. We don’t have the time or the money to train everyone on new technology, acquire the appropriate supporting tools, etc. Nor does it make any sense to replace the existing team with a new team.

Instead, we take what we have and force an application to fit within that environment. We’ve created some excellent good practices for Design Specification as part of the Teamstudio Policy Guides. I encourage you to take a look at this document to get some tips for the next time around.

Scott

Posted by Scott Johnsen At 02:13:58 PM Location Beverly, MA USA | Permalink | Comments (1) | TrackBacks (0)

Bookmark :              

This morning I was reviewing a data breach study done by Verizon Business. There is a lot of excellent data there, and I would encourage all of you to check it out when you have a chance.

There were many interesting statistics reported, but a couple of the more interesting to me were:

42% of data breaches occur from either the database server (30%) or application server (12%). However 94% of data records breached are from these sources (75% and 19% respectively)

67% of records compromised was data companies didn’t know they had. They didn’t even know they had it!

According to Verizon Business, “unknown unknowns” are any of the following:

A system unknown to the organization (or business group affected)

A system storing data that the organization did not know existed on that system

A system that had unknown network connections or accessibility

·A system that had unknown accounts or privileges

The timing is interesting, because Teamstudio has a webinar this week (Wednesday, 2:00 pm ET) called Streching Your Domino Dollars. Although the primary focus of this webinar is to help you identify ways you can reduce IT costs, many of these tactics also serve to reduce company risks, especially as they relate to unknown unknowns. Of course if you cannot make the live event, the webinar will be available on demand. Just check out the events page on our website for availability.

Scott

Posted by Scott Johnsen At 10:06:28 AM Location Beverly, MA USA | Permalink | Comments (2) | TrackBacks (0)

Bookmark :              

I read an interesting report from Gartner this morning that says 85% of 274 end-user organizations surveyed are currently using Open Source Software (OSS) in their enterprises today, and the remaining 15% expect to in the next 12 months. I was very surprised by this high percentage. I was even more surprised when I realized this study was done in May and June of 2008.

Companies in the survey were from various countries and markets in Asia/Pacific, Europe and North America. Respondents were evenly distributed across manufacturing, education, financial services and services companies and included a cross section of small, medium and large organizations. They also excluded software vendors (sorry Teamstudio) and external service providers (ESPs).

Now for the shocker: 69% of these companies surveyed said that they have no formal policy for evaluating and cataloguing OSS usage in their enterprise. 69%! What kind of exposure do you think they have with intellectual-property violations alone? What kind of risks are they taking by adopting software without a support commitment from IT?

Given that one of the top reasons given for using OSS was the lower cost of ownership (TCO), I have to wonder what would happen to the TCO if they were sued for intellectual-property violations? The respondents did acknowledge that governance, or lack of it, was the number 1 challenge for them. This sounds like an area Teamstudio needs to address in the next round of Policy Guide edits.

You can see the full report here. But I warn you, it’s not cheap!

Scott

Posted by Scott Johnsen At 03:34:09 PM Location Beverly, MA USA | Permalink | Comments (0) | TrackBacks (0)