Recently a lot of attention has been paid to the book Wikinomics, by Tapscott and Williams:

Today, encyclopedias, jetliners, operating systems, mutual funds, and many other items are being created by teams numbering in the thousands or even millions. While some leaders fear the heaving growth of these massive online communities, Wikinomics proves this fear is folly. Smart firms can harness collective capability and genius to spur innovation, growth, and success.

A brilliant primer on one of the most profound changes of our time, Wikinomics challenges our most deeply-rooted assumptions about business and will prove indispensable to anyone who wants to understand the key forces driving competitiveness in the twenty-first century.

Based on a $9 million research project led by bestselling author Don Tapscott, Wikinomics shows how the masses of people can participate in the economy like never before. They are creating TV news stories, sequencing the human genome, remixing their favorite music, designing software, finding a cure for disease, editing school texts, inventing new cosmetics, and even building motorcycles.

This is hype, of course. Less breathless appraisals of the book than its blurb above point out some of the book's shortcomings:

A review of this book in the Harvard Business Review states "like its title, the book's prose can fall into breathless hype." A review of this book in Choice recommends the book for "general readers and practitioners," but cautions that the authors "present an optimistic overview of successful collaborations and business ventures", "use unique terms (e.g., marketocracy, prosumption, knowledge commons)", should have given "more consideration [to] the darker sides of human motivation as well as groupthink and mass mediocrity", and "primarily draw on their own observations of businesses and trends for the ideas presented."

Nevertheless, it seems clear that blogs, wikis, et al are helping to bring about a fundamental change in the workplace. They accelerate the process started by the Web itself, namely democratizing the publication of information. One could view such technologies as enablers for the Community of Practice idea that has been hovering on the fringes of business life for the last 2 decades.

Further, the widespread use of such powerful communication tools is helping people realize that communication is not the same as collaboration. In fact, many of the people spearheading this recognition are those keenest to promote the existing communication tools. They seek new collaboration tools to go with their wikis and blogs, since they know that for their beloved wikis and blogs to succeed long-term, there must be a way for organizations to manage the explosion of communication that is resulting from large-scale, one-to-many information publication.

Without some form of control applied appropriately at each level of the organizational hierarchy, the "wiki workplace" will simply descend into anarchy.

TAKE AWAY

The authors of Wikinomics are sponsoring the creation by the general public of an "unwritten chapter", via a wiki that will be transformed into a document for publication at key points. This wiki has some interesting ideas. In particular, the vision espoused therein for Enterprise 2.0 offers a compelling vision for the next generation workplace, suggesting that a "People-Oriented Architecture" (POA) is needed to go with today's SOA.

Regular readers of this blog will recognize a similarity between the "Enterprise People Bus" described therein and the knowledge bus concept outlined in some of my previous posts.

There is no doubt that wikis, blogs and the whole panoply of social software tools are changing the workplace. Whether or not this change is for good depends on how fast organizations take up the collaboration tools needed to bring order to the chaos.

Posted by keithhb in Management | Permalink | Comments (0)

Regular readers of this blog will be used to my promoting free and/or open source solutions to enterprise software problems. However, there is one area in which I struggle to do so - namely, databases.

Given the ubiquity and importance of relational technology in the workplace, and the array of features offered by open source databases such as MySQL, this may seem a bizarre statement. Yet for many organizations, the primary concern is no longer flexibility or performance, but security:

Many organizations struggle to find a sustainable way to meet global GRC requirements around financial reporting, data security, records retention, risk management, and more.

FACT: Industry analysts AMR Research expect organizations to spend nearly $30 billion this year alone, grappling with questions such as:

• How can we stay on top of increasing regulatory demands while controlling cost?


• How can we better manage risk to prevent business and compliance failures?


• How do we achieve better performance while ensuring accountability and integrity?

Oracle Security Solutions, p.4

In my experience, such concerns are becoming more and more important to CIOs. Yet, in this area, there are few offerings, and little indeed that is free and/or open source.

In particular, if you wish to secure data at row level - so that each row has different access permissions, a normal enough requirement in an enterprise environment - options are few. The best approach appears to be an optional Oracle database feature known as Oracle Label Security (aka OLS). Here is how OLS works:

• First, security policies are established to identify how the data needs to be secured by specification of security components for the policies.
• Next, user labels are established that define what row-level security policies are possible for each user.
• For each table that needs to enforce row-level security, a special column called a label column is built and populated.
• During data access, a process called access mediation determines which permissions are required to access the row, and what actions can be performed on the row once it's accessed.

OLS uses three sets of criteria to define both the set of user's permissions to access data in a row as well as the row's accessibility: levels, compartments, and groups.

Levels. As the first security dimension's name implies, a level defines increasing data sensitivity. A typical example includes the standard security levels (Unclassified, Classified, Secret, and Top Secret). Another example for most companies is human resources information. Just about everyone needs to know everyone else's first and last name and e-mail address (i.e. company-wide access). However, only the employee, her supervisor, and the Human Resources department should know salary information about the employee (hopefully!) only the human resources coordinator should know about an employee's participation in a company-sponsored anger-management class.

Compartments. The second security dimension, a compartment defines the areas to which data access is restricted. In other words, compartments can be used to classify data. Typical examples of compartments include functional divisions within a company (Sales, Accounting, Human Resources, Information Technology).

Groups. A group is the third security dimension. It typically defines who is the owner of the data and provides yet another way to classify what type of access is permitted. However, groups have one important difference: They can be used to restrict access to data based on the owning organization's hierarchical structure. Business rules appropriate for group enforcement within a group include geographical areas (localities within states/provinces, and states/provinces within countries) and sales forces (regions that encompass several districts that themselves encompass territories). What's really great about this feature is that OLS allows me to restrict row-level access to specific nodes of the hierarchy. For example, I can grant a sales force's regional manager access to only sales generated within his region's districts; a district manager access to sales generated only within her district's territories; and a salesperson to only the sales generated within his territory.

Security Component Combinations. For each of the label security components, up to 10,000 different values may be established. OLS requires that, at a minimum, one value for the security level must be stored in each label column, even if it indicates unrestricted access is permitted. Note, however, that compartments and groups need not be included in the label column's value. Also, each row and each user can be assigned multiple access permissions for compartments and groups.

Oracle Label Security, Part 1: Overview, By Jim Czuprynski

Functionality such as OLS should really be part of every database that claims to be enterprise-strength. Perhaps I have missed something, but I cannot see how to achieve equivalent results using (say) DB2, let alone open source alternatives such as MySQL. I believe DB2 has some sort of equivalent to Oracle's Virtual Private Database (VPD - the technology underpinning OLS) in its mainframe edition. But, to my knowledge, that's it, although I have not done proper comparative research in this area.

Further, OLS has been around since 2003, and still has major weaknesses - for instance, support for use of J2EE, since use of OLS via TopLink is currently broken.

TAKE AWAY

I am bemused by the weakness of database offerings with regard to security - especially given the current worldwide focus on combating terrorist threats, the rise of cyber-crime, and the general acknowledgement that the most common threat to organizational security is from insiders.

Your comments are very welcome on this topic! If you have expertise in this area, please share it. I'd be very interested to know your thoughts.

Posted by keithhb in Open Source | Permalink | Comments (0)

Recently I have been doing some consultancy work around requirements analysis - in particular, for a large project that decided halfway through to postpone a large swathe of requirements until a later stage.

This move, intended to reduce risk, in fact replaced one set of risks (that the requirements could not be implemented as intended) with another set of risks (that the resulting system was not fit for purpose). Hence I have been attempting to de-risk the project by analysing the implications of the move - not only on users of the initially delivered system but also on the project itself at a later date. It is quite possible that, in order to deal with the absence of certain capabilities in the short-term, it may be necessary to introduce design features into the technical architecture that turn out to prevent successful retro-fitting of the missing capabilities later on.

This heart of this work is to analyse the patterns of behaviour that humans will adopt to work with each other via the system. As a result, it has an interesting synergy with a paper I wrote a few weeks ago, for the Requirements Networking Group. Here is the abstract from the paper:

In the end, software applications are only there to support human work. Even a low-level, highly automated software application for (say) car numberplate recognition or payroll calculation is only there to meet the needs of the police officers or HR staff who ultimately set its initial parameters and use its output.

Yet most approaches to understanding and modelling human work have a major weakness – they offer reasonable support for capturing H2S interactions (between humans and systems), but are extremely weak when it comes to capturing H2H interactions (between humans and humans). Further, mainstream modelling techniques provide little of the context required to understand what truly goes in knowledge work.

You can find the paper online. You have to join the RNG to access it, but membership is free.

TAKE AWAY

It is really quite startling that issues such as the above are still a problem for software requirements analysis, when you consider how fundamental an engineering task it is.

As another illustration of the immaturity of this aspect of software development, the open source movement is only just waking up to the need for a general requirements management framework (see Open Requirements Management Framework aka ORMF) and an enterprise-oriented application development framework to encompass it (see Open System Engineering Environment aka OSEE). Both these frameworks are only just getting off the ground.

Have you ever noticed how a root cause of software project failure lies in poor requirements engineering? If so, you may like to read the paper referenced above, and check out ORMF/OSEE for yourself.

Posted by keithhb in Requirements | Permalink | Comments (0)

If you have been following my recent blog posts, you may be interested to know that a consultancy client recently evaluated the effects of applying the techniques described in the post on hyper-productivity to fault fixing.

Their conclusion was that when using my techniques for fault fixing, faults were fixed in approximately half the normal length of time, or in other words, that developers were twice as productive as usual.

TAKE AWAY

Most literature on fault fixing estimates that the average developer spends over 50% of their time fault fixing. So if you are looking to improve the efficiency of your development staff, it must be worth considering techniques that double the productivity of this time.

Posted by keithhb in Management | Permalink | Comments (0)