Monthly Archives: July 2009

The problem with automated provisioning (II of III)

The second of my articles on the macro-level issues with (automated) provisioning and focusing again on the theme of complexity as a result of “No. of Instances” x “Freq. of Change” described in the previous article “The problem with automated provisioning (I of III)“, but this time comparing an Enterprise Data Centre build-out versus a typical “Web Scale” Data Centre build-out.

Having built out both examples demonstrated I find the below a useful comparison when describing some of the issues around automated provisioning and occasionally why there are misconceptions about it from those who typically deliver systems from one of these ‘camps’ and not the other.

Enterprise

the-problem-with-provisioning-0.1-enterprise

Basically the number of systems within a typical Enterprise Data Centre (and within that Enterprise itself) is larger than that in a Web Scale (or HPC) Data Centre (or supported by that organisations), and the differing number of components that support those systems is higher too. For instance at the last Data Centre build out I led there were around eight different Operating Systems being implemented alone. This base level of complexity, which is then exasperated because of the Frequency of having to patch and update this (as demonstrated by “Automated Provisioning Complexity = No. of Instances x Freq. of Change” equation) significantly impacts any adoption of automated provisioning (it makes defining operational procedures more complex too).

Web Scale

the-problem-with-provisioning-0.1-web

Frankly a Web Scale build out is much more likely to use a greater level of standardisation to be able to drive the level of scale and scaling required to service the user requests and to maintain the system as a whole (here’s a quote from Jeff Dean, Google Fellow, “If you’re running 10,000 machines, something is going to die every day.”). This is not to say that there is not a high level of complexity inherent in these types of system, it’s just that in order to cope with the engineering effort required to ensure that the system can scale to service many hundreds of millions of requests it may well require a level of component standardisation well beyond the typical you’d see in an Enterprise type deployment (where functionality and maintenance of business process is paramount). Any complexity is more likely to be in the architecture to cope with said scaling, for instance distributed computational proximity algorithms (i.e. which server is nearest to me physically so as to reduce latency versus which servers are under most load so as to process the request as optimally as possible), or in the distributed configuration needed to maintain said system as components become available and are also de-commissioned (for whatever reason).

Automated Provisioning Complexity = No. of Instances x Freq. of Change

At the most base level provisioning a thousand machines which all have the same OS, stack and code base, with updated configuration is easier to set up than a thousand machines which use a mixture of four or five Operating Systems, which all have differing patch schedules and patch methods, with a diverse infrastructure and application software stack and multiple code bases. I suspect that upon reading this article you may think that it was an overtly obvious statement to make, but it is the fundamentals that I keep seeing people trip up on over and over again which infuriates me no end, and so, yes, expect another upcoming article on the “top” architectural issues that I encounter too.

HPC, or High Performance Computing, the third major branch of computing, build-outs usually follow the model above for that of “web scale” ones. I have an upcoming article comparing the three major branches of computing usage, Enterprise, Web Scale, and HP, in much greater detail, however for the time being the comparison above is adequate to demonstrate the point I am drawing to your attention; that of complexity of environment exasperating implementation of an automated provisioning system. Hope you enjoyed this article, it is soon to be followed by a reappraisal and revised look at Enterprise and Web Scale provisioning.

The problem with automated provisioning (I of III)

Referring back to my previous article “The problem with automated provisioning – an introduction” once you get over these too human of issues into the ‘technical’ problem of provisioning then I’d have been much nearer the mark in my initial assessment, because it is indeed an issue of complexity. The risks, costs, and likely success, of setting up and maintaining an automated provisioning capability is integrally linked to that of the complexity of the environment to be provisioned.

There are a number of contributing factors, including, number of devices, virtual instances, etc., location and distribution from the command and control point, but the two main ones in my mind are “Number of Instances” and “Frequency of Change”.

And so ‘Complexity’, in terms of automated provisioning, at a macro level, can be calculated as being “Number of Instances” versus “Frequency of Change”.

No. of Instances x Freq. of Change

By “Number of Instances” I mean number of differing operating systems in use, number of differing infrastctrue applications, number of differing application runtime environments and application frameworks, number of differing code bases, number of content versions being hosted, etc.

By “Frequency of Change” I am drawing attention to patches, code fixes, version iterations, code releases, etc., and how often they are delivered.

The following diagram demonstrates what I frequently call ‘The Problem with Provisioning’; as you can see I’ve delineated against three major architectural “levels”, from the lowest and nearest to the hardware, the OS layer which also contains ‘infrastructure software’, the Application layer, containing the application platform and runtime environment, and the “CCC” layer containing Code, Configuration and Content.

the-problem-with-provisioning-0.1-overview

In a major data-centre build-out it is not atypical to see three, four or even more, different operating systems being deployed, each of which is likely to require three or six monthly patches, as well as interim high value patches (bug fixes that effect the functionality of the system and security patches). Furthermore it’s likely the number of ISV applications, COTS products, and application runtime environments will be much higher than the number of OS instances, and that the amount of “CCC” instances will be even higher.

I find it important to separate the system being provisioned into these three groupings because, typically they require differing approaches (and technologies) for the provisioning thereof, something I mentioned in the previous article when organisations mistakenly believe that the provisioning technology that they have procured will scale the entire stack, from just above ‘bare metal’ to “CCC” changes (I’ve seen this issue more than once, even by a Sun team who should of known better, albeit it was around three years ago).

This model brings to the fore the increasing level of complexity, both of components at each layer, and the frequency of changes that then occur, and although the model above is a trifle simplistic, it is useful when describing the issues that one can encounter with implementing automated provisioning systems, especially to those with little knowledge or awareness of the topic.

links for 2009-07-28

Gartner Highlights Five Attributes of Cloud Computing – The five attributes of cloud computing according to Gartner are (1) Service-Based, (2) Scalable and Elastic, (3) Shared, (4) Metered by Use, and (5) Uses Internet Technologies. …..

The problem with automated provisioning – an introduction

I was going to start this short series of articles with the statement that the problem with provisioning is one of complexity, and I’d have been wrong, the predominant issues with provisioning, and specifically automated provisioning, are awareness and expectation.

Awareness and Expectations

The level of awareness of what can actually be done, and often, more importantly, what cannot be done, with automated provisioning, or even what automated provisioning actually “is” is a significant barrier, followed by the expectations set, both by end users with a hope for IT “silver bullets”, who may well have been oversold, and Systems Integrators, product vendors and ISVs who sadly promise a little too much to be true or are a trifle unaware of the full extent of their own abilities (positivity and confidence aside).

For instance I was once asked to take over and ‘rescue’ the build out of a data centre on behalf of a customer and their outsourcerer (£30M+ to build out, estimated £180M total to build and run for the first five years).

Personally I would say that this data-centre build out was of medium complexity, being made up of more than five hundred Wintel servers, circa three hundred UNIX devices, and around two hundred ancillary pieces of hardware including network components, firewalls, switches, bridges, intelligent KVMs and their ilk, storage components, such as SAN fabric, high end disk systems, such as Hitachi 9900 range, high end tape storage, etc., and other components.

One of the biggest problems in this instance was that the contract between client and vendor stipulated using automated provisioning technologies, not a problem in itself, however an assumption had been made, by both parties, that the entire build out would be done via the provisioning system, without a great deal of thought following this through to it’s logical conclusion.

Best to say here that they weren’t using Sun’s provisioning technology, but the then ‘market leader’, however the issues were not to do with the technology, nor functionality and capabilities of the provisioning product. It would have been as likely the similar problems would have been encountered even if it had.

This particular vendor had never implemented automated provisioning technologies before on a brand new “green-field” site, they had always implemented them in existing “brown-field” sites, where, of course, their was an existing and working implementation to encapsulate in the provisioning technology.

As some of the systems were being re-hosted from other data-centres (in part savings were to be made as part of a wider data-centre consolidation), another assumption had been made that this was not a fresh “green-field” implementation, but a legacy “brown-field” one, however this was a completely new data-centre, moving to an upgrade of hardware and infrastructure, never mind later revisions of application runtime environments, new code releases, and in-part enhanced, along with, wholly-new functionality too. AKA this was not what we typically call a “lift and shift”, where a system is ‘simply’ relocated from one location to another (and even then ‘simply’ is contextual). Another major misconception and example of incorrectly set expectation was that the provisioning technology in question would scale the entire stack, from just above ‘bare metal’ to ‘Code, Configuration and Content’ (CCC) changes, something that was, and still is extremely unlikely.

Sadly because of these misconceptions and lack of fore-thought predominantly on behalf of the outsourcerer no one had allowed for the effort to either build-out the data-centre in entirety and then encapsulate it within the provisioning technology (a model they had experience of, and which was finally adopted), nor allow for the time to build the entire data-centre as ‘system images’ within the provisioning technologies and then use it to implement the entire data-centre (which would have taken a great deal longer, not only because testing a system held as system images would have been impossible, as they would have to be loaded into the hardware to do any testing, either testing of the provisioning system, or real world UAT, system, non-functional, and performance testing).

Unsurprisingly one of the first things I had to do when I arrived was raise awareness that this was an issue, as it had not fully been identified, before getting agreement from all parties on a way forward. Effort, cost, resources, and people, were all required to develop the provisioning and automated provisioning system in a workable solution. As you can guess there had been no budget put aside for all of this, so the outsourcerer ended up absorbing the costs directly, leading to increased resentment of the contract that they had entered into and straining the relationship with the client, however this had been their own fault because of lack of experience and naivete when it came to building-out new data-centres (this had been their first so they did a lot of on the job learning and gained a tremendous amount of experience, even much of this was how not to build out a data centre).

This is why I stand by the statement that the major issues facing those adopting automated provisioning is one of awareness of the technology and what it can do and one of expectations of the level of transformation and business enablement it will facilitate, as well as how easy it is to do. The other articles in this series will focus a little more on the technical aspects of the “problem with provisioning”.

Disqus and Twitter integration to get even more improvements

You’d imagine Twitter integration in Disqus couldn’t get any better, however speaking with Daniel Ha at Disqus I hear even more improvements are on the way.

If you haven’t seen how Disqus integrates with Twitter (and incidentally what Disqus integration looks like with blogs.sun.com, or any other Apache Roller Weblogger based blog system) have a look at this blog entry which has generated a few traditional comments, but quite a few tweets, and see how Disqus displays them all as part of that conversation too:

http://blogs.sun.com/eclectic/entry/reasons_projects_and_programmes_fail

You’ll need to scroll down to the bottom of the page, but as you can see Disqus has captured a lot of the tweets and retweets about the article, which I think is pretty cool. Disqus also does the same for Facebook and a host of other social networking platforms as well.

Talking to Daniel he said that tweet and social networking metrics and “count” was on the way as well as other advancements, so I am firmly looking forward to those when they arrive.

The great thing about Disqus is that it is firmly becoming a conversation catcher and conversation engine, which is really what I want, to capture disparate conversations about what I write in an aggregate manner.

If you are interested in integrating Disqus with your Sun blog or any other Apache Roller Weblogger based blog, I have a tutorial and overview over here, along with the code and code examples you need to use:

https://horkan.com/2008/09/09/disqus-integration-bsc-roller-weblogger

Bill Vass’ top reasons to use Open Source software

You might not have seen Bill Vass’ blog article series on the topic of the top reasons to use and adopt Open Source software; and as it’s such an insightful series of articles I thought I’d bring it to your attention here.

Each one is highly data driven and contains insight that you probably haven’t seen before but is useful to be aware of when positioning Open Source to a CTO, a CIO or an IT Director, because of Bill viewpoints (having come from a CIO and CTO background). Often when you see this sort of thing written it can be rather subjective, almost ‘faith based’, so I’m always on the lookout for good factual information that is contextually relevant.

Bill Vass’ top reasons to use and adopt open source:

    1. Improved security

    1. Reduced procurement times

    1. Avoid vendor lock in

    1. Reduced costs

    1. Better quality

  1. Enhance functionality

And before you mention it, I know Bill already summarised these articles in his lead-in piece “The Open Source Light at the End of the Proprietary Tunnel…“, but it was such a great set of articles it seems a shame not to highlight them them to you!

Jakob Nielsen: “Mobile User Experience is Miserable”

Latest research into mobile web user experience says that overall the experience is “miserable”, and cites the major issues with Mobile web usages, as well as looking at overall “success” rates which, although improved from results of research in the mid-1990’s are much lower than typical PC and workstation results.

It is well worth a read for those looking at optimising for mobile readership and audience and the full report is available here: http://www.useit.com/alertbox/mobile-usability.html

This new report names two major factors to improving the aforementioned success rates; that is sites designed specifically with mobile use in mind and improvement and innovations in phone design (smart phones and touch screens perform best).

Jakob Nielsen, ex-Sun Staff member and Distinguished Engineer is famous for his work in the field of “User Experience”, and his site is a key resource to getting advice and best practice in terms of web, and other types of, user experience design.

The Reasons Projects and Programmes Fail

In this post I’ll be describing the five categories that I’ve identified of reasons that Projects and Programmes Fail, this categorisation has been built up from doing a large number of system, project and programme reviews and audits over the years, and this article follows on from the project review and programme audit framework which I wrote about recently.

Whatever problems are found in a project or programme in my experience they can be broken down into these five categories:

  1. Strategic / Alignment
  2. Contractual / Financial
  3. People / Politics
  4. Process / Procedural
  5. Technical / Architectural

For a number of years my categorization of reasons why projects and programmes fail did not include “Strategic / Alignment” as an area, and was a model made up of just the other four categories, but then I kept coming across a couple of definitive reasons why it should be added; more on this below.

So lets look at these five categories individually in more detail:

    1. Strategic / AlignmentA fundamental lack of strategic alignment to the Business has been made.

      Basically the project should never have been commissioned in the first place. It is either not required whatsoever (and yes, shockingly, I have come across this happening), or is no longer required (either because of a change of business circumstance, or functionality overlap with another system, i.e. something else does this just fine thank you very much).

      A lack of an Executive Sponsor is a good indication that this could be an issue, and even if the project or programme is some form of ‘Skunk Works’ you would expect the overall ‘Skunk Works’ innovation concept and framework to be supported by an Executive Sponsor, such as the Head of R&D;, and for a watching brief kept over costs versus potential revenues and benefits.

      Projects and programmes which are purely or highly non-functional, and provide limited, or unperceived business benefit, may also be an indication of this issue.

    1. People / PoliticsGetting people to work together can be complex and difficult, especially when their goals are not co-ordinated. Long term political enemies, people competing for resources, promotions and remuneration, are all potential issues.

      This magnifies up at a macro level into business units being in competition for talent, resources and even access to customers and partners. Programmes where multiple business units have to work together and integrate systems and functionality are almost always problematic, even when there are serious penalties if it not done.

      In general Governance compliance issues and management failings also fall into this category, as do business conduct issues, moral, etc.

    1. Process / ProceduralThe process is ‘broken’. Procedures are not in place or are not being complied with. It is either the wrong process to have been used in the first place, is not being adhered to correctly, or is not even being used at all.

      A process is in place but it is over subscribed and can not ‘scale’, alternately a process does not have enough people to service it, perhaps because of downsizing or such.

      The status of a capable Project Management Office (PMO), or of stable, authoritative, Document Repository are also indicators that there is a problem in this area, as is a lack of due diligence when managing and implementing change control.

      Governance in terms of appropriate operating model and related procedural items are here too.

    1. Contractual / FinancialFor some reason the financial arrangements of the project are having a negative impact on the ability to deliver that project. The contract is counter intuitive perhaps, or is weighted in such a way that means that the ends are not easily achieved, or does a poor job of defining the requirements.

      If you hear something like the “spirit of the contract” versus the “word of the contract” then this is a good indicator that there is an issue with the contract and that it doesn’t cover what is wanted or expected.

      Be aware that this is likely to be a problem shared by the client and their vendors as mutual understanding of what can be delivered versus what is wanted and needed by the business. This a re-iterative learning process as the business learns more about what can be delivered by technology and the system defined, whilst those involved in delivery learn the semantics, language and nature of the business and experience more of the challenges that the business has.

  1. Technical / ArchitecturalThis is last for a very good reason, and that is this is often the least contributing factor in terms of projects failing to deliver.

    When there are issues in this area in my experience it is often one of not having the appropriate people and skills at the right time, or not even identifying the key individuals you require accurately, rather than hard technology issues.

    Other issues are architectural and compositional problems (more on architectural issues in an upcoming article), access to resources at the right time, and the typical technology compatibility issues (i.e. “what works with what”) and access to vendor technology and knowledge bases.

    As a reviewer of projects and programmes which could be failing it’s likely that you will have come from a technology implementation background and that this area is well within your ‘comfort zone’, but I assure you that in the majority of cases technology may well be a minor contributing factor to the failure of an overall project, nor is the hardest problem area to improve upon (with good recommendations, of course), but it may be an area that you could potentially over focus upon and lose sight of more significant issues at hand.

Again, hope you enjoyed the article, will try and look at some other pieces, such as the top architectural mistakes made, how to identify possibly failing projects and suggestions for rescuing them.

Project Review and Programme Audit Framework – a simple example of it’s use

This is a simple example review utilising the project review and programme audit framework that I wrote about in the proceeding article. …..

links for 2009-07-20

Project Review and Programme Audit Framework

So this is the framework I have developed and use for reviewing and auditing failing projects, programmes and systems. As I might have said before this is a simple, effective, framework, based on my experience, and although you might have seen approaches like this before, this is one that I have personally used to great effect.

To an extent this framework is a description of how I document a review and the process steps that I take as well, the major difference is that the process itself is likely to be re-iterative and you well learn things during the review which generate fresh lines of inquiry.

I get asked to perform these types of review probably because I’ve done a large number of them and have become quite good at them, however originally I think it was because I have an analytical and inquiring mind, I am tenacious enough to chase down what is really happening in a situation, have a broad and deep appreciation of technology and it’s implementation, I have a great deal of project and programme experience across a number of Industry’s, and am good at getting people to tell me about the problems they are experiencing. I expect these are the type of qualities you would probably want to encourage to become better at this type of activity; an unkind person might say that being a pedant and didact can help too.

So I separate my reviews down into five simple areas:

  1. Problem(s)
  2. Fact(s)
  3. Result(s)
  4. Conclusion(s)
  5. Recommendation(s)

I bet you’re thinking “well that’s obvious Wayne”, but simplicity is always an imperative when you set out, because believe me, the complexity of the issues you’re going to find can sometimes seem overwhelming. So explaining what I mean by these five headings:

  1. Problem(s)Or rather perceived problem(s). Because this is what the client thinks is wrong or at the very least is the effect not the cause (unless they know or think they know what the problem is and just want an expert to confirm their opinions). If in doubt this should definitely be why you have been commissioned.

    This section should not really be that large, because otherwise I would expect that items from the following sections have ‘leaked’ into here, most likely from the ‘fact(s)’ section. For instance if the MD of a company who has commissioned you to review a system starts telling you about all the individual issues that they are having then you are clearly in ‘gathering facts’ mode and much of this should end up in the next section.

    I would typically expect this section to be only a paragraph or couple of paragraphs at the most, if it’s running to half a page or more I’d be concerned because in a large review clarity will matter a great deal. Even in a large scale, complex review, be careful of this section because if it is too large it could point to being too over-focused on detail which should be drawn out further in the review or a problem with the level of abstraction used and the problem description.

    Examples of ‘Problems’ I’ve been asked to investigate include:

    • We’ve spent £10s of Millions on our IT supplier and the web sites which they have built are still not available when they are needed to be, what is going wrong
    • We’ve spent £30 Million plus to date on a data centre build out, which should be complete, and our IT supplier keeps telling us that it could be a month or a couple of months until it’s complete, but we have lost confidence in their updates.
    • We have spent over £70 Million on a large integration project, which has yet to deliver it’s first release to the business and I’ve just been told it’s going to need another £10 Million immediately and another £40 Million to complete
    • We are just under two years into a ten year, £300 Million pound a year contract, which has ‘ballooned’ up to £800 Million per year already, and yet our supplier still hasn’t delivered the ‘Transformation’ that they promised, what is stopping them
  2. Fact(s)Gather and document facts. This should easily be your largest section because data matters and you will need good data to make an appropriate diagnosis of the situation and to ensure you deliver a credible and believable review.

    Obviously there are many ways to gather data, especially technically i.e. gather crash dumps, read through code, measure network, processing and storage performance and capabilities, etc. For non-technical fact gathering you can review contracts, documentation, investigate online and offline document repositories, review authorised and freely given email and communication trails and other ‘digital echos’ as you see is appropriate, etc.

    By far the most effective means of gathering facts in a large scale and complex review is via interviews. In a large scale review you would expect to find the majority of fact gathering comes from interviewing. Inquiry, question development and delivery, structured interviewing and aware and active listening matter a lot here. Never lead an interview in case you are building a case for a theory or ‘pet’ view that you have. Remain impartial at all times.

    It is important to be empathetic enough to be good at relating to people and getting them to open up when doing structured interviewing and active listening; if you are too proud or arrogant you can forget interviewing as a method of gathering data because it’s unlikely anyone will open up to you enough, and this will seriously impact your ability to perform reviews and audits in any meaningful manner.

    People will be people in the interviews: they will be emotive, some may be reserved, stoic, cynical even, some will care, some won’t, a few may be objective, many are wittingly or unwittingly subjective, and all will have opinions.

    Remember interviewing is the no.1 manner in which good quality data gathering is done for system, project and programme reviews and audits, becoming fluent in performing interviews and capturing the data thereof is key to performing good reviews.

    Do not lead the data, nor start to analyse until a good body of data is gathered. Often once facts have been gathered and started to be analysed more information may be required to perform a good quality diagnosis. Be prepared to ask lots of questions and be prepared to meet people who don’t want to answer you. Document everything.

  3. Result(s)This is where you will be relating facts into results; although some analysis and thought will have been done considering which information to gather and how, much of the real analysis ‘foot work’ starts here. This section is where you relate the information so far presented and relate it to issues and problems that the client is experiencing. Hopefully you should now have information gathered and documented in the ‘fact(s)’ section which is causing or could be causing the problems that the client is exhibiting. It is likely that you will be sorting facts and the problems that they are associated with into a basic set of categorisations (and the next article in the series deals with those categories).

    A simple example result may be that a defined problem might be “the web server keeps falling over, we don’t know why”, whilst the related fact may be that “patches were not applied”, after more investigation it would probably be fair to link the two together thus “a result of not applying the appropriate patches leads to the web servers being unstable”. The reason you shouldn’t jump the gun and stop with the first thing you come across is that it may not be the root cause, it could be a contributing cause or even unrelated, the good reviewer is appropriately thorough, without needlessly wasteful of clients time, money or resources.

    An example of a conclusion might be “without implementing and maintaining change control the project will continue to move out of control and will be increasingly difficult to deliver to time and budget, never mind delivering the contractually required document deliverables”.

    If the facts and results do not map to the original issue for which the exercise was commissioned, you would need to consider gathering more data which is more related to the original problem and re-iteratively gathering more information, alternately perhaps testing the validity of the original problem description and politely questioning the original area you were asked to review with the sponsor of the review (secure a meeting and let them know of the concerns and issues you are having). Document any disparity between the originally identified problems, the facts gathered and the results given here.

  4. Conclusion(s)Defining conclusions is where you look at the Facts and Results and conclude what will happen if the situation continues. This is where you make rational predictions on a future state, suggesting what problems might occur in the future if no action (or what planned action) is taken. It would be dismissive to say that this is where any ‘scaremongering’ occurs, but it is important to inform, and, possibly even, warn the client about further problems and issues that they might experience if the situation remains unchecked.

    It is important that your conclusions address the original problem and although you may like to address any additional problems which have been drawn out during the review it is not imperative to do so; however I almost always do and this is because I feel an obligation to the client and I want to demonstrate my delivery focus too, you however may not find this something you have time, or want, to do.

    Again this will probably be a short section, and although you well may have been creative before, this and the next section is where your good ideas need to start to be. You need to ensure that you are not too fanciful, and personally I prefer not to be seen to be influencing any particular recommendation by ‘weighting’ any possible future state too negatively however I have seen a lot of of reviews which have lacked impartiality over the years.

    If things are bad you must be honest and deliver the difficult news; whatever you do do not attempt to ‘sugar-coat’ the news and detract from the important information and messages you are delivering to the business; although I heavily recommend that you ensure that you inform your sponsor verbally early on so as to ensure you do not deliver any surprises which could have a possible negative effect and lose or diminish their support.

  5. Recommendation(s)This is where you make suggestions in terms of trying to improve the situation; deliver recommendations which relate to the facts, results and conclusions, and the original problem. If other problems have come to light during the review and you have included them as part of the overall review then you should include recommendations which address those problems as well.

    Making recommendations could well be seen as being the easy part to an experienced ‘expert’ with a certain field, and it is always attractive to the inexperienced reviewer to dive in with recommendations before proper analysis has been completed (i.e. we’ve found these facts, therefore because the last project had a similar issue and we fixed it by doing X, Y and Z, we will try X, Y and Z here). This behaviour will likely lead to either the wrong problem being fixed, or worsening the current situation, all of which waste the clients time, money and resources.

    With recommendations I like to remember the ‘pareto principle’ (the “80-20 rule”), in that your principal recommendations should by mindful of this and have significant impact on addressing the problem space originally described by the client. Minor recommendations are all well and good, but if they don’t “fix” the problem in the mind of the client it’s unlikely that you will be being asked to review for them again or that your recommendations are implemented at all.

    Above all recommendation are given so as to improve a situation, not to push any personal agenda, and again it is key to be impartial and objective.

The biggest problem you will likely have in using a framework like this, or any other, is early on you will likely have content in the following or proceeding section to the one it should be in, as you become more familiar with the framework and more experienced at doing reviews and audits this should improve.

Also do not imagine that the only place that you bring value is in the ‘Recommendation(s)’, this is grossly incorrect, because the client may well have not gathered the data you have, analysed it in that same way, nor come to the same conclusions. Your work ultimately will improve their understanding of a situation and allow them to plan accordingly, and this is the genuine value.

Of course a good review document will contain more than the above, probably references, appendices, document control, etc., however the above is the absolute core of a good review in my opinion and experience. If you find yourself arguing with your co-reviewers about the document version control table you are way off the mark, because fundamentally the quality of the review is paramount as well as the effect it brings (hopefully a resolution to the issues for which it was commissioned).

My friend, Chris Loughran, of Deloitte, use a framework even more stripped down and ‘lean’ than this, delineating into (1) gather facts, (2) relate results, and (3) make conclusions, which is certainly punchier and easier to explain in short order to your typical senior executive or CxO who has very limited time. But of course Chris is one of the leading Business and Technology Consultants in the UK, so this is to be expected and he is highly effective using this approach. Personally, as I’ve written about in this article, I prefer to document the (perceived) problem and to ensure recommendations are distinct from conclusions.

As usual, I hope you have enjoyed the article despite it being a lot larger than I hoped, and to mention that the next one is looking at the categories of reasons why projects and programmes fail (although I’ve just decided to deliver and have subsequently written a short article documenting an example of the above review and audit framework too).

Reviewing, auditing and rescuing failing projects and programmes best practice

One of the things I’ve done rather too much of is be asked to review failing projects, programmes and build-outs for customers, clients and partners, and come up with solutions and recommendations to help resolve these problems, which is often followed in short order by being asked to help rescue them (often leading to Sun helping them too).

And over the years I’ve built up a fairly large body of case studies and examples, which when I make the material a little more anonymous and write up I will share, but for now I’ve put together a couple of articles that use this experience.

First one to follow this leader is an article on a project review / programme audit framework which is a simple, highly effective and yet generic method for setting out reviews.

Secondly is a piece on why project fail, at least the five macro-level reasons why projects fail, within which I’ve found all programme problems seem to fall. This is of an appropriately high level to be useful to those who review and audit problem implementations and systems, don’t expect to find items such as “it was a triple indirected pointer to a function in C / C++ that ended up at the wrong memory location”.

Anyway really hope you enjoy the articles, because, well frankly, there is a lot of time, effort, experience, and failing projects knowledge boiled down into these.

Web analytics used here at the eclectic blog

Thought you might be interested in the the web analytics used on this blog; in total there are five pieces of technology collecting data and then used for performing web analysis here. They are:

  1. SiteCatalyst / Omniture – http://www.omniture.com/ – Sun standard, embedded in blogs.sun.com (and monitors all Sun websites), produces the page hits total
  2. SiteMeter – http://www.sitemeter.com/ – you can access my results yourself by simply clicking on the SiteMeter logo on this page and here’s the link: http://www.sitemeter.com/stats.asp?site=s38horkan
  3. StatCounter http://www.statcounter.com/
  4. Google Analytics http://www.google.com/analytics/
  5. ClustrMaps – http://www2.clustrmaps.com/ – simple location counter displayed as a informative graphic here’s the link to my hit counter: http://www2.clustrmaps.com/counter/maps.php?url=http://blogs.sun.com/eclectic/

Why use more than one? Frankly web analytics is more than a shaky area, none of them ever seem to catch all hits just as I’d like, nor measure them in a similar fashion, so I use differing web analytic software to ‘triangulate’ the best view possible (for instance one will count some spiders traffic as hits, whilst another won’t, frankly I want to know the difference between humans and the web crawlers, etc.). Furthermore some have functionality which the others don’t and some produce quick to see ‘snapshots’ whilst others produce detailed ‘drill-downs’.

For instance Sun’s web analytics is the same as the corporate one, so it’s enterprise grade and highly flexible, sadly this means it’s extremely large scale and quite hard to manipulate because the amount of configuration you have to do is just horrendous (but it can give you the most detail).

So SiteCatalyst / Omniture is too much hassle to produce quick updates and ClustrMaps is really eye candy for users, therefore I only really use SiteMeter for quick updates without logging in, and StatCounter and Google Analytics for more detailed, but quickly available, reports on what constitutes readers favourite articles and pages.

For 2 to 5 above you’ll need to sign up for online accounts and add the tracking code yourself, this isn’t too hard, it just takes a little time.

For 1 it’s already there on all the Sun websites and blogs, however you need to request access to the corporate Omniture / SiteCatalyst web analytics system to get access if you are a Sun blogger, then you have to learn how to use it, then you need to use something else as well (see problems I describe above, because you might prefer a quick info ‘fix’).

Most of all this is about personal preference, and what works for you; for about two years after starting blogging I was a data demon, wanting to understand and interpret the stats, and now, well I’m a little more relaxed.

Hosting a BCS Enterprise Architecture event on EA Tools tomorrow in Manchester

Tomorrow evening I’m going to be hosting a BCS Enterprise Architecture (EA) speciality group (SG) event looking at EA tools in Manchester.

Details for the event:

Date / Time: Friday the 17th of July, 2009 / 17:45 for 18:00, expected to finish at 19:30

Location: Room E0.05, John Dalton Building, Manchester Metropolitan University, Chester Street, Manchester M1 5GD

More information and registration over at the BCS EA AG website page for the event: http://www.ea.bcs.org/eventbooking/showevent.php?eventid=esg0906

Event synopsis from the BCS EA SG:

The focus of enterprise modelling is now shifting away from purely technical and system aspects and becoming more holistic, thereby necessitating the use of comprehensive modelling tools to analyse and optimise the portfolio of business strategies, organisational structures, business processes, information flows, and services. Organisations would be ill advised to proceed with Enterprise Architecture without utilising a modelling toolset able to meet all the requirements. A central repository is vital to provide a common information source for everyone involved, also important is the ability to base the process on a framework and customise the models to fit each organisations own situation. The presentation will cover Enterprise Architecture tool evolution, key tool capabilities, and market overview.

We have secured Mark Blowers as the nights speaker; Mark has over twenty years experience in the IT industry, employed by end-users and software houses, working in a number of roles, from analyst/programmer to project manager and account manager, in the manufacturing, retail, and Independent Software Vendor (ISV) sectors. Mark joined Butler Group in August 2000, and is Enterprise Architectures Practice Director. He has worked on a number of strategic and architectural themes over the last few years, including Enterprise Architecture, IT Value Management, Enterprise Communications, and Mobility. Mark has been widely quoted in the press, including the Financial Times, Guardian, Computing, Computer Weekly, Internet news sites, and other trade magazines.

This should be an interesting and informative event, so I’m looking forward to being there already.

Innovation@Sun blog design and functionality update

Recently I helped update Hal Stern’s Innovation@Sun blog on behalf of Hal and Marianne Salciccia, the blog administrator.

Checkout the new design over at http://blogs.sun.com/innovation/

At first glance you might be mistaken to think that aesthetically not a great deal has changed, however Marianne and I did a great deal of work on the site under Hal’s direction (mainly, “Yea, I like that, go with it”, after he saw the staging site we put together).

So what has changed? Well it’s still got the same great content and articles about innovation and innovators at Sun, we just marshalled the content a little better, provided more in site functionality and better meta-data support for all those web robots and crawlers that consume sites ready for inclusion in search engines.

I haven’t listed out all of the changes to the Innovation@Sun site that Marianne and I made, because that would make a rather dull and long list, however I have included the review of the original site that I did for Marianne, along with the suggestions I made, almost all of which were implemented.

Probably shows a little of how I think and break problems down too…

I’ve broken the recommendations into three primary areas: Aesthetic, Functional and Non-Functional, you’ll get the idea.

===================================================================

1) Aesthetic i.e. Look and Feel / Design

1.1) First off I like the design of the site, especially the left and right bordering panels, but they aren’t particularly balanced, so perhaps more content on the right hand side to balance this out.

1.2) Secondly if I scroll down by pages all content in the right hand bordering panel is used up in the first page, and all content in the left hand bordering panel is used up in the second page. However the number of posts you have on the site means that it will continue to scroll down for circa 17 pages of blog entries. This means for the majority of entries on the page there is no supporting information to contextualise it (unless you scroll up). Solutions could be move to a single border (not recommended for now), more content down the borders, and less entries per page. I recommend the latter two options, more content down the borders and fewer entries per page (if your going to have fewer entries per page we need to improve how people can find older content too, more on this below).

1.3) Third, less is more, avoid clutter, and minimize, minimize, minimize; check out my blog at http://blogs.sun.com/eclectic/ which is actually an interpretation of Tim Caynes Sun Blog, you see I’m a technologist, got a graphic designer, but I do know when to get inspiration and help from other people.

1.4) Fourth, given the images on the banner I think it might be nice to link to those innovations, although this is a nice to have, rather than anything else.

1.5) Fifth, I’d look at how the post bodies are arranged them selves, and look at formulating a standard template model for the posts layout. The Innovation@Sun blog seems to contain one to four types of content per post (supporting text, optional supporting image, optional blog radio control, links). Personally I’d go with a model of Blog Radio control top right floating object, people will soon learn it’s always there, supporting text top left and under the blog radio control, any image on the bottom left hand side, followed by links / podcast links. I think this would provide a much easier to read page and thus one people may stay on a little longer and read other articles.

===================================================================

2) Functional i.e. How the site ‘works’

2.1) Jakob Nielsen, ex-Sun staff member, Sun Distinguished Engineer and proclaimed web usability expert first published a list of the top ten web design mistakes in 1996 http://www.useit.com/alertbox/9605.html

For the most part, his original list of mistakes are still problematic today, he has also published a list of top ten “new” web design mistakes in 1999 http://www.useit.com/alertbox/990530.html followed by 2002, 2003 and 2005 too.

As well as the top ten good deeds designers can implement in their web pages http://www.useit.com/alertbox/991003.html

All of these are valuable and relevant sources of good design and functionality information, have a look if you get chance.

2.2) Remove “Blah words” – redundant repetitive text – get rid of it, for instance the calendar used on the site has no entries for this month and so is a ‘dead’ calendar which doesn’t link to anything. Furthermore lots of dates and times for the entries themselves, none of which matters a great deal, because no.1 is the content.

2.3) Next, blog post title doesn’t link top the article, they should, it’s the number one way people link to the article, plus allows to display article with comments and other data and meta data.

2.4) Current navigation to old articles (“Recent Shows” on the left hand side) link to dates and not titles, this should be changed, so that Recent Shows links to the articles themselves.

2.5) Better Achieve / Old Article retrieval needed, recommend the work I did on creating a “Roller Weblogger Achieve Menu” which creates a year / month achieve list making legacy content very easy to find, and putting it in either the left or right hand border, here’s more info http://blogs.sun.com/eclectic/entry/roller_weblogger_archive_menu_macro

2.6) You may also want to improve the next / previous function and make it much more obvious and easy for the reader to find (making access to old articles easier to find too of course). Another one of the standard roller weblogger functions I replaced: the next / previous function. Basically I wanted this to be a little more informative, and host it as a menu list in the sidebar. Here’s my article on how to do that “Roller Weblogger alternative Next Previous function” available http://blogs.sun.com/eclectic/entry/roller_weblogger_next_previous_macro

2.7) You may want to try using a third party comment system, which can increase the number of people seeing your comments, have a look at “Integrating Disqus and Roller Weblogger on blogs.sun.com” which you might like https://horkan.com/2008/09/09/disqus-integration-bsc-roller-weblogger

2.8) Do you have lots of blog postings, possibly over a number of years? And do you suspect that despite embedding search and tag clouds into your blog that your readers are still not finding content related to that they enjoy? In fact do you have evidence of that very problem from your web analytics data but don’t know what to do about it? Yes? So did I, so I created this roller weblogger code to generate a list of the most related blog entries based upon tag and category relationships. This is my favorite and most productive functional enhancement to Roller. The article “Roller Weblogger Related Entries and Blog Post code” describes it in detail and shows an example, it really is good, http://blogs.sun.com/eclectic/entry/roller_weblogger_related_entries_macro

2.9) Tag display on individual articles, with links to other appropriate content aggregators. I would produce tag links to at least four popular tag destinations, your blog, blogs.sun.com, technorati and del.icio.us. It also ensures that the links are marked as tags, so that crawlers that look for and index tags and tag data will pick them up (microformat and semantic web focused applications, like the ‘Operator’ plug in for Firefox also pick them up of course). Article “Roller Weblogger blog post tag link code for blogs.sun.com, technorati and del.icio.us” over at https://horkan.com/2008/08/11/roller-weblogger-tag-technorati-delicious

2.10) Twitter integration

2.11) Flickr Integration

===================================================================

3) Non-Functional i.e. technology behind the site

3.1) Remember that good site design for attracting traffic is about designing the site for human and non-human visitors; a large number of your visitors will be web spiders and crawlers indexing your site for search engines, blog catalogs, directories and the like. So it’s important that as well as your human visitors you also design your site to be easily and throughly consumed and interpreted by these electronic visitors. My article “make Google notice your Blog” has lots of background info that can help here https://horkan.com/2009/01/20/make-google-notice-your-blog

3.2) My biggest problem with the Innovation@Sun site is it’s lack of semantic / meta data embedded within the main and other pages, this is a significant issue when looking at how this page relates to other sites on the web. The main page should have tag meta data at the very least. You could achieve this with a tag cloud, but frankly tag clouds are becoming rather ‘de rigueur’ and common place. Whether you want a tag cloud or not we should look at generating tag data for every page. For instance if you run a semantic / meta data analyzer on my site you’ll see there is a large amount of machine only readable data, all of which helps spiders index my site the way I want them to.

3.3) Make sure every article has tags and tag data and it is human readable once on the article only page (see 2.9 above which we could double to do this, also ensuring the sites above index it well too).

3.4) Standardise on tags, both format and content. I recommend that you standardize on a Tag format that is search engine friendly. Don’t over tag nor under tag, but try and match your articles tags with other similar articles, try and join in with the subject matter’s folksonomy if at all possible (i.e. the tags people are using when talking about that subject matter, technorati and delicious are both good examples). My article “Tic, Tag, Tow” here https://horkan.com/2008/01/08/tagging-tags-blog-tag-policy should help. Basically use tags which are already being used by the Sun blkogging community, this will also generate pages which display your content vis the main Sun Blogs interface.

3.6) Google’s PageRank algorithms work on links, inbound, outbound, number, and the PageRank of those inbound and outbound links. Link to sources, get inbound links from sources / reciprocal links if possible. Don’t forget to trackback articles that you reference, if the trackback fails try leaving a comment with a link to the article that references it.

3.7) Make sure you let sites such as Google know you’ve updated your site and that you’d like it re-“spider”ed, indexed and advertised. This is done by “blog pinging” search engines and blog directories so that they are informed that your site has been updated and to send over there spiders when they get chance (most search engines / blog directories want to do this quite quickly as they want to be first with any potentially newsworthy content that draws traffic). Personally I wanted a more granular level of control over this than offered with the standard blog ping functionality embedded in roller and so I wrote my own stand alone version, see my article “Free XML-RPC blog ping site submitter: “Blog Ping”” for more information https://horkan.com/2008/04/22/blog-ping-search-submitter-seo

3.8) Other things to consider…

* PageRank of your site and individual pages; how well does your article compete with articles of a similar nature.
* Have pages been bookmarked in del.ici.ous, technorati, etc., i.e. are they being shared.
* Improving site analytics and getting better visibility of visitor interaction with the site and using this to plan the next round of enhancements.

===================================================================

And don’t forget you can become a fan of the Facebook Fan Page and follow Innovation@Sun on Twitter too @InnovatingatSun.