Software Factories: Part 2 – Types of Factory

[Software Factories Series]

There are a number of ways to implement the Software Factory Principle (Remember the principle says that any method to enable mass-production of software (especially standardized non-functional requirements) at a lower cost and in a shorter time constitutes a software factory of sorts.

Here are a few of the more common approaches:
Continue reading

Posted in Technology, Trends | Tagged , | Leave a comment

Avoiding Clutter in Systems Management

Software Factories: Part 2 will be coming along on Monday, but for now a change of topic onto Systems Management

Out-of-the Box Systems Management Tools
There are numerous systems Management tools out there and a lot of corporates own a lot of diverse instances of these. Each one has its place in the market and plays to its particular strengths and has certain weaknesses. For example one might come already configured with everything you need to manage server harware, but may not be customisable to manage routers at all. Another tool may be completely generic and may be able to manage any device or system, but it comes preconfigured for almost nothing and you have to put the time and effort in to configure all the threshholds and metrics that you want to measure for each item in your environment.

Where is the Value?

The question is loaded of course and the answer is: “It depends”. If I am a Mail administrator and I want a system management console to tell me how my mail-system is doing then I would see little value in buying a completely generic tool and customising it to tell me how my mail system is doing. I would have to do extensive research and determine what the metrics are that I should typically be concerned about and what there respective threshholds should be in my particular setup. Over time I could tweak these until they are just right for me. Yuck. What a waste of time. I could just buy a specialised monitoring tool that tells me exactly what I need to know about mail-systems with all the threshholds already set. WRONG.

If you bought a specialised mail-monitoring system you would still have to customise all the threshholds and metrics for your specific environment because your servers may be scaled differently, your mailbox structures may be configured differently etc. If you make the mistake of leaving all that up to the manufacturer of the monitoring tool, then the chances are you will be ignoring most of the info the system produces and eventually say “This thing is always wrong” and untimately it will fall into disuse. Ok that’s a worst case, but my point is you need to KNOW YOUR ENVIRONMENT. There is definite value in researching what metrics are relevant for YOU and what the appropriate threshholds are in YOUR environment. So am I saying there is no place for specialised tools. Not at all. As long as you recognise the responsibility stays with YOU to manage YOUR environment, and cannot be delegated to a tool.

Where is the Value?: Part 2
If I were a departmental manager or executive, my requirements of a management system would be completely different. I would want a very general overview of the state of affairs in the organisation. In fact I would want period summary reports and would probably never look at a realtime console. So the requirement is completely different. If the underlying monitoring systems contributed their information into a centralised warehouse, I could draw a report off that and get what I needed.

Caution: Information Overload in progress!
The question is WHAT INFO DO I NEED? That is the RIGHT question (see iRobot – the movie) to start with. Too much information can be as useless as no information, except that now you have spent money on tools (and support staff for those tools) to produce that information that you never look at. Exactly the right balance of information is critical, especially in large environments.

I used to look after all the servers for a medium-sized corporate and after about six months of harassing the systems-management guys I had exactly the reports that I wanted. I sent a monthly report to the senior IT managers exhibiting the outages and incidents that occurred with a comment from myself on each. I also had a weekly report summarising the top 10 major potential and real issues across all servers. Each week I tried to deal with the issues on the top-most-unhealthy server. I also had a daily report on the configuration and health of each server, which I archived and kept for 3 months, which I only looked at if I needed to research something later (reading that report daily would have been overload).

It shouldn’t be easy
My parting comment is that you need to get to grips with your environment and do the investigation and research into what it is that YOU need to manage in YOUR enviroment. It is extremely unlikely that someone can do that for you. You need to make the time to do it. It will save you (I say that deliberately – it may save YOU) in the long run.

Technorati Tags: ,

Posted in Challenge, ITSM, Management | Tagged , , | Leave a comment

Software Factories: Part 1 – An Introduction

[Software Factories Series]

I have been aware of the Concept of a Software Factory since about 2003. The Principle is very simple: If you are producing software, tool-up in order to produce good quality software that meets your requirements, at a very low marginal cost (cost of delivering one more business requirement) and in a very short marginal time (time to deliver one more business requirement).
Continue reading

Posted in Technology, Trends | Tagged , | Leave a comment

Don’t ride dead horses.

My post “Dismount!” last Friday (goodness it’s already almost a week ago!) left an open question about how you may have found yourself riding a dead horse (in the figurative sense).

Now in the context of this blog and on the topic of IT, a dead horse would most likely refer to a system that is either not being used, or is being used but is extremely unpopular within the organisation.

Very often these systems are not necessarily bad systems, but rather something has occurred that has effectively “killed” that system within a particular organisation.
So it may have died because:

  • It is a bad system that has no business case and is not fit for purpose – (very unlikely)
  • There is no buy-in from the users when the purchase decision is made – (fairly likely)
  • There is no buy-in from the technical team who are required to support it – (extremely likely)
  • It is too complicated and the users don’t understand it – (unlikely)
  • It has not been properly implemented and is barely usable – (very likely)
  • Key Stakeholders of this system change roles, and it is unpopular with, or unfamiliar to their successors – (quite likely)

These likelihoods are not based on any research, but are simply my personal opinions based on my experiences within a number of organisations.
Let’s unpack these and see how easily they can happen. If any of the following list of things occurs during a product evaluation or solution design process then we may end up with one of the situations above:

    • A Vendor approaches senior managers directly and convinces them that the organisation needs this product, which then leads to …
    • A manager bypasses the governance process to implement a particular product
    • The Business Analysis is poor
    • The Technical team implement the newest pet-technology, ignoring the business requirements
    • The governance process for making purchase decisions is not aligned to business objectives or is in some other way broken
    • When a key support person or Business Champion changes role and the succession plan does not exist or is poorly executed

Do any of these sound familiar? It is almost guaranteed that at some point, one or more of these will occur within any organisation, and this list is by no means complete.

The inconvenient truth is that it is seldom the product that is at fault. There are usually two basic processes that have failed in these situations:

  • The IT Governance process around product decisions
  • Succession planning

A sound IT Governance process will ensure that business requirements are met and that solutions align with business objectives and desired behaviours.
Good Succession planning will ensure that the healthy parts of the status-quo are not compromised during a change of “rider”

The bad news is that “when you discover you are riding a dead horse, the best strategy is [still] to dismount”

The good news is that if you are careful about these two processes (IT Governance and Succession Planning) it is possible to keep a healthy stable of IT solutions.

The basic message is:

Don’t let healthy horses die
– Do pay attention to Succession Planning, and
Don’t buy dead horses
– Make sure Governance Mechanisms align with business needs and IT circumstances and then don’t bypass them

Technorati Tags: , ,

Posted in ITSM, Management | Leave a comment


I was reminded yesterday of an old American-Indian saying that says when you discover you’re riding a dead horse, the best strategy is to dismount, but a colleague pointed out that there were other options available.

So I quickly Googled “How to ride a dead horse” and found a few sites quoting alternate strategies, which are worth a read.

They are all fairly similar and very funny… and unfortunately too true.

I began to wonder how those horses died. The proverb says “When you discover you are riding a dead horse…” , but there are several possible ways you got into that situation:

  • Maybe the horse was dead when you got it
  • Maybe you rode the horse too hard
  • Maybe you forgot to feed and water the horse
  • Maybe the horse got sick and you didn’t get it to a vet who could help
  • Maybe someone shot the horse, because it had a broken leg (which you should have noticed if you are riding it)
  • Maybe some enemy shot the horse to further his own causes
  • Maybe the horse died of old age

bears some discussion…

Posted in Challenge, Management | 1 Comment