Brilliant Thinking

My background in the Internet stretches back to 1996, and since then I have observed many trends start, develop, and come to an end. Looking at the evolution of an organisation and its web presence (in a similar sense to the SW-CMM - software capability maturity model), we can abstract a generic model for the “maturity” or evolution of a company’s web presence. This model can be mapped onto a simple graph which can be used as an indicator to highlight the level of complexity (and thus cost) of the required web solution. I call it the Internet Maturity Model and it looks like this:

Level 1: Organisations generally start with email as their first involvement with the Internet. It is a business critical system and relatively straightforward to set up.

Level 2: The next step is usually to create a marketing website - an on-line brochure - advertising the companies services and providing a means to contact them.

Level 3: Some companies need to trade on-line, providing catalogues of items which visitors can purchase with their credit cards. Trading can take a number of forms, but on-line shops are the most common.

Level 4: The fourth step is to start to automate some of the company’s processes and translate them to the web. These can range from accounting processes, to recruitment, to property management, in fact almost anything that can be done in a series of steps. There are many challenges here - including the nebulous change management - which is why it appears as almost the most complex step on the chart.

Level 5: Business transformation - or finding new ways to solve old problems - is the most complex step on the chart because it can often require the use of new methods, technologies or techniques that may not be fully proven.

A third dimension to the Internet Maturity Model

The above presents a very black and white view of where an Internet solution sits along the spectrum of maturity or complexity, but there is a third dimension (or vector) which needs to be considered when designing a solution - the people who are going to use it.

The technical ingenuity that can been built in by the creators or developers of the system quite often baffles the person who is going to be using the system which creates negative results. You only have to ask these same users about blogs, podcasting, RSS feeds, wireless systems, blue tooth and edge devices and you can watch their eyes glaze over in terror!

This “People Maturity” (their awareness of and comfort with technology) needs to be taken into account before designing a solution. If their “maturity” cannot be accommodated in the desired level of application, it may be better to reduce the desired level until the users are ready for the next step.
(This article was originally published around the turn of the century on our main website and has been moved to the blog for posterity).

Part of my early career was spent in Quality Assurance (QA) looking after divisional software and hardware procedures and auditing very large private and public sector projects. Before moving on to lead similar software development projects, the time in QA taught me much about the benefits of standards and the importance of appropriate processes. Later in my career - as a business consultant - I was to revisit this when I spent some time as a Software Capability Maturity Model (SW-CMM) assessor.

From an objective viewpoint, the body of knowledge that has been refined in the IT industry is invaluable to how we should build systems for the Web and, although the Web presents us with additional challenges, many of the principles from the body of knowledge are as applicable today as they were 20 years ago - just because the Web appears to be different, it doesn’t mean we have to reinvent the body of knowledge, just refine it further to encompass the additional challenges.

Looking specifically at Web applications (i.e. websites, whether Internet, Extranet or Intranet), the greatest risk for any organisation using them is one of security.

Open Source software is potentially more vulnerable to security attacks than proprietary software because the code is openly available to everyone - including hackers who can find and exploit security weaknesses to their benefit (I think of these people as “test teams gone bad”). However, one of the benefits of Open Source software is that there is a wide community of supporters who find, report and fix any problems that are found, and so resolutions for security problems are usually quickly implemented but require regular upgrades to benefit from them. This is not to say that Open Source is a bad choice - it is often an excellent choice - but clients (and agencies) need to understand and balance the risks before making decisions about which systems to use. Unfortunately, there does not appear to be a uniform standard for assessing the maturity of a web application.

In the SW-CMM there are 6 levels of maturity, from zero (meaning none) through to five (being the highest level). The level of maturity is applied to the organisation that develops the software applications, and is based on the processes that are followed and the systems that are in place. The theory being that the more mature the organisation on the scale, the more robust the application should be. However, this is not a direct relationship, only an implied one.

If we were able to apply the principles of the Capability Maturity Model to software applications (in general) and Open Source Software applications (more specifically) we would be able to develop a solid foundation for assessing the maturity of the software product itself. We could then compare this with our own requirements and so decide if the product is a suitable fit to the overall project aims.

Projects such as Sourceforge.net provide an indication of a product’s development stage (release status) by indicating whether the product is in planning, in development, at alpha release, beta release, etc. To the casual observer, it is unclear exactly how products on SourceForge reach these status levels (I only spent 10 minutes looking for it, but I would have expected to be able to find it quickly). Unfortunately, the release status does not tell us how secure the product is, and since security is the greatest risk on the Internet, it should be embodied in a product’s maturity rating, or be a separate rating in itself.

What I would like to see is some form of Security Maturity for released products - particularly Open Source - but also proprietary (Windows is well known for its vulnerabilities yet the source code is not openly available to the general masses). The question is then one of how to measure it.

Websites such as Security Focus provide long lists of security vulnerabilities of Open Source software produced by a myriad of organisations. However, there is no abstraction of this information into a relative score that can be used as a tool for pre-selection of applications based on project requirements.

In my opinion, the metric does not need to be complex.

The key piece of information is the list of bug reports for an application. These would need to be classified as “security related” and “non-security related”. Security related bugs would then need to be quantified against a standard list of security errors, for example cross-site scripting vulnerability, SQL injection vulnerability, code injection vulnerability, filesystem vulnerability, authentication vulnerability, etc. Each one of these classifications would have a defined impact according to the SMM standard. By counting the number of vulnerabilities of each type we would have an idea of the current security status of an application. However, if there are no current vulnerabilities, this does not mean the application is not vulnerable. It just means we haven’t found the next weakness.

Consequently, we should factor in both time and the number of installed versions of the application into the formula.

When the number of security vulnerabilities increases over time, this suggests that the application is more vulnerable and so the security maturity would decrease. If the number of detected vulnerabilities decreases over time, we would infer that the application is more secure. The reason for this is that if we are detecting less vulnerabilities across the installed user base, we can assume the system is more stable and less open to security vulnerabilities.

When an application is young - ie only recently launched and/or with very few live installations - it would be difficult to assess the security maturity accurately because it would only take a few vulnerabilities to radically alter the security maturity score. For this reason, young applications (defined as, for example, less than 1 year and/or 500 installations) would only warrant a bracketed rating as an indication of the potential security maturity because of the potential fluctuations that a few vulnerabilities would cause in the value.

I think a methodology of this nature would give much greater confidence for teams or organisations looking to select an off the shelf application, but it relies on software producers being open about the security maturity of their application. For professional organisations, this should be a benefit and a unique selling point, and for Open Source organisations it helps people make a decision between the Open Source system and a similar proprietary one.

By creating a level playing field (an equal Security Maturity Model standard) for all applications, Open Source and proprietary alike, we cut through the misinformation that we often find in the Internet. Open Source applications often have much higher numbers of installations compared to proprietary rivals (for example bulletin board software), plus the Open Source versions are discussed at length (both good and bad) in public forums. However, the proprietary products have smaller user bases and often don’t have the public presence. Consequently, searching for information on bulletin board software can easily bias a decision one way or the other because there is no way we can measure either product equally.

Contents

The infrastructure is the glue that links all the systems together – it includes the pointers to make sure your domain name points to the web hosting, the set-up of your internal systems used to access email and any other links that may be needed between the website and your back-office systems.

Website Infrastructure

Aside from the hosting itself (covered in another post), the website infrastructure consists of:

• The domain registrar
• The hosting company (can be the same as the registrar)
• The server and network configuration
• Email service provision
• Data backup

The domain registrar is the first link in the chain and care should be taken to select a good registrar who offer a fully featured control panel that allows you full control over your domain name(s) so that you can fully manage the DNS, lock and unlock domains, update details, and transfer domains in and out. There are still a number of registrars today who don’t offer these features and some of these registrars can be very slow in responding to emails or faxes to update information about your domain. The end result of using a less capable registrar can mean delays in launching or updating your website. It took over a month for me to transfer a domain from a well known UK registrar recently because they only responded to email support requests and took 2 weeks to do so, usually with a question which required more email correspondence and another 2 weeks “in the queue”. Furthermore, some ISPs won’t even talk to the web developers because they are not officially a contact for the domains and so every communication has to go via the client.

Even if it costs slightly more (and we’re only talking a pound or two), choose a registrar with a fully featured control panel. We recommend 1&1.

For most businesses starting out, you will probably take up a virtual hosting account with your registrar. This will either be a Windows or a Linux server, and this will influence the type of programming you can do on it. If you have appointed a web design company (like ourselves) prior to setting up your hosting, ask them what they need before picking a package. We have had to change platforms from Windows to Linux and add additional services in the past - this takes time, introduces delays and can add cost.

We run our own Linux servers in a London data centre, so we usually point the domains registered with the registrar to our name servers so that we can fully manage the hosting and email on behalf of our clients. This is why the DNS management is important in the registrar’s control panel as there are no delays in updating the settings and getting the site running. Even though you may use your registrar’s hosting facilities initially, you may want to change this in the future. DNS management is also essential if you want to do something called “delegated subdomains”. What this means is that you can host www.mydomain.com on one server and clients.mydomain.com on another. Without DNS control this may not be possible as some ISPs won’t allow you to do it.

When you have full control over the DNS (either at the registrar or through your own name servers) you can also manage the provision of email services. Most ISPs offer POP3/IMAP by default, but with DNS control this can easily be replaced with your own internal Microsoft Exchange server or a any other third party email system. Having this level of control also allows for the introduction of spam and virus checking on the email service.

Data backup is also recommended just in case something goes wrong; for example hardware (disk drives) can sometimes fail and the system needs to be restored. Virtual hosting companies may not offer this as an option (see related hosting post).

Client Infrastructure

This is the IT set-up required to access and use your website.

Some larger businesses host their own website on their own internal website servers. Such businesses often have their own internal IT teams to set up and manage such servers, or outsource this function to an IT support company.

A client’s internal infrastructure includes the set-up and management of firewalls to provide security on their network, as well as the deployment of email software to the desktop or via a server (e.g. Microsoft Exchange). The email system either downloads the emails periodically from the POP3/IMAP accounts on the web server, or act as a full server where the email is delivered to directly. Often, virus and spam protection software is installed in the client’s infrastructure.

The other component of client infrastructure is the provision of business logic (programs) that access information on the website itself. These can be simple import routines which enable downloaded information to be imported into internal systems and software (for example financial data imported into Sage), through to more complex systems which fully integrate the website systems with the internal back-office systems ensuring a seamless transfer of data both ways between the business and the website. On our Internet Maturity Model, this is Level 4. Such business logic does not include content management systems which are considered part of the “site engine“.

I have been reading the Transcending CSS book mentioned in an earlier post - it’s an excellent book - and it’s nice to know it’s not just me that struggles with the outdated ideas of some clients that the presentation of a website should be identical across the main browser platforms (including Mac IE5.5, although this is largely considered an obsolete platform by most agencies). My own view is that the presentation should be as close as possible, but, with so many browser variants and no actual control of how the site visitor sets up their viewing configuration (using their own fonts, different screen widths, etc, etc) we need to accommodate this fluidity and not attempt to override it. Writing on this subject back in February, Nate Koechley of Yahoo! puts it very succinctly:

Support does not mean that everybody gets the same thing. Expecting two users using different browser software to have an identical experience fails to embrace or acknowledge the heterogeneous essence of the Web. In fact, requiring the same experience for all users creates a barrier to participation. Availability and accessibility of content should be our key priority.

– Nate Koechley
http://developer.yahoo.com/yui/articles/gbs/gbs.html

Koechly’s article makes it clear that it is neither possible nor desirable for people accessing Web content using different browsing technologies or devices to expect the to receive the same design. After all, a person will have a different experience browsing the Web using a large desktop monitor than someone using the small screen of a handheld PDA or mobile phone. Extending that notion to browser versions is only one small step.

The challenge when creating a brief for a project is to be as inclusive as possible, but also realise that the range of support provided for various devices is something that needs to be defined and not an assumption that all devices will be supported by default once the site is developed. Each viewing platform will require its own considerations in the CSS and mark-up to ensure suitable presentation, and assuming that a potentially infinite array of viewing platforms will all be supported is unrealistic (not to mention expensive). Most of our clients work on the basis of “it should work on Macs and PCs” which often includes FireFox and Internet Explorer (on the PC) and Safari and IE5.5 (on the Mac). But what of Opera? And which version of IE on the PC (now that IE7 has been released and is a mandatory download)?

Fortunately, the major browsers listed above are similar in their interpretation of the fundamental styling capabilities of a web page and this can allow us to create the client’s desired homogeneity across the platforms, but the CSS specification goes much further and allows us to create a better experience for people with more compliant or capable browsers. Unfortunately, these features are rarely used as clients are often looking at the lowest common denominator instead of a graceful degrading approach that allows us to create the preferred experience which also degrades nicely so that people using other configurations can still access the content.

If you want the best solution, make sure you find an agency or freelancer who understands the principles of CSS from both a visual and a technical viewpoint. It’s one thing to be able to recreate a design using CSS from a technical standpoint, but it’s another to be able to understand the visual goals and bridge the gap between concept and representation. Remember that even the design itself should encompass the capabilities of the underlying (CSS) technology and not simply assume that the design can be translated.

Contents

The hosting is the space where the website lives. It also includes the provision of email services and webmail facilities so that you can check email wherever you may be. Although we prefer Linux for reliability in the web environment and offer our own hosting facilities, the choice of hosting should be dictated by your business requirements - performance, scaleability, etc.

Please also refer to our longer article: Types of Hosting.