ITsourcing

Principle Components Analysis (PCA)

During most of the selection work I have done you end up having to select from a short list of around three or four solutions with some dozen criteria. PCA uses eigenvector and eigenvalue techniques on the covariance matrix of the scores. With a short list of three or four the statistical significance of the solution is going to be extremely poor.

 

A case history weighted tree is shown below.

 

 

 

There are four strategic options being marked against eleven criteria. I normalised the scores to zero means and used ViSta to run a DCA. It refused to run with only four sets of marks; ViSta requires at least a square matrix before it will calculate results i.e. more options than parameters. I forced a calculation by adding dummy options with zero scores and it scored the options:

1     -1.9

2     -0.6

3     -0.1

4 1.1

 

Actually, the same order as the client weighted scores!?!

 

The PCA criteria weights were:

1.1   .03

1.2     .3

1.3    -.31

 

2.1 .35

2.2 .35

2.3    -.39

 

3.1    .32

3.2    -.01

3.3    -.39

3.4    .02

3.5    -.31

 

Comparing these weights with the row scores in the table above gives:

- Criteria with high spread of scores get a high PCA weight.

- Criteria with low spread of scores get a low PCA weight.

All as you would expect from PCA.

 

The central limit theorem comes to our rescue at with, say, ten options to score and statistically significant results should therefore be generated at this level.

 

However, I feel that DCA cannot be used in a typical short list situation because of the significance issue.

 

Ian Richmond

Email: ‘About’ and ‘Email Me’ link.

 

 

Principles

Principles are a great tool with which to document difficult decisions during strategy development. A principle is a belief of an organisation. It can be documented as a simple statement or as a page capturing the description, rationale, implications and dependencies (if appropriate).
A Principle can be developed when it is more important that a decision be made rather than what the decision actually is. This can be used at any stage in the development of a strategy. Only a few Principles will be developed; you hope. They are good for resolving technical arguments between opposing camps in a large organisation.

Also, sets of Principles can be used to link business goals to the IT strategy. This linkage can be explicitly documented by creating a pair of spreadsheet tables:
Documented business goals against IT Principles.
IT Principles against IT strategy elements.
The set of Principles and the linkage tables become part of the IT Strategy document.

In both situations, the Principles are developed in a facilitated workshop environment with the clients technical and business stakeholders.

Application Architecture – Patterns

There are different definitions of a pattern, these include:

• An abstraction from a concrete form which keeps recurring in specific, non-arbitrary contexts.
• A recurring solution to a common problem in a given context and system of forces.
• A named "nugget" of instructive insight, conveying the essence of a proven solution to a recurring problem in a given context amidst competing concerns.
• A successfully recurring "best practice" that has proven itself in the "trenches".
• A literary format for capturing the wisdom and experience of expert designers, and communicating it to novices

Despite the differences, they all come down to ‘let’s not reinvent the wheel’. My own pattern for helping development of an application architecture is shown below:

 

The main elements are:

• Simple Core – these are the services for the main functions of the business, probably COTS packages to create a stable basis for the business.
• Special Functions – the COTS packages in the Simple Core do not cover 100% of the main processes and therefore specialist software is required to fill the gaps.
• Market Facing – different channels to market will require specific solutions and high agility is nearly always required. These services need to be separated from the Simple Core.
• Bulk Data – all major external feeds in and out of the other parts of the systems lie in this area.
• Management Information – this creates the separation of MIS from operational systems. A mix of MIS solutions can exist, some long lived others quick responses to business needs.

Clearly, different principles apply to each of these domains and the application architecture, with its underlying pattern, greatly facilitates the understanding of these issues.

A large organisation with different lines of business will require more than one application architecture. The links between or overlaps of services across the architectures depends on the level of integration in the organisation.

Application Architecture

An organisation may accept that it needs an application architecture as part of its strategy but often a discussion follows about what such an architecture should comprise. Many of the technical people do not want to include vendor names in architecture drawings; it is OK to have a box labelled ERP but not one marked SAP.

My view is pragmatic; once a company has adopted, say, SAP, this will be a major element in their strategy for many years to come. Having ‘SAP’ as part of an application architecture is more realistic that just labelling the box ‘ERP’.

A top-level application architecture shows the major applications and the interfaces between the packages. A case history example is shown above. This diagram was the key figure in a corporate strategy proposal; the document included business case and cost/benefit costs. The key concept was a single ERP solution for the global business. The main board accepted this strategy and a single active instance of SAP, supporting all of the operations, resulted. The Chairman’s motive was not the potential cost savings but the harmonisation of the global businesses after a major merger – a single chart of accounts drove the business change desired.

How to Fail With SCRUM Adoption

When we adopt a methodology, is it reasonable to ‘pick and mix’ the major elements of the technique? A large UK corporation claims it has adopted SCRUM but, when pushed, agrees that it has adopted parts of the methodology, rather than the complete approach.

The software development had been off-shored to India; the Product Owner is in the UK. This means the SCRUM meetings had to be substituted with conference calls, severly cutting down on personal interaction and threatening the integrity of the SCRUM meeting. I have found that virtual teams can work provided there is a sensible mix of telephone conference calls and physical meetings. Doing strategy development, I found monthly physical meetings and weekly conference calls worked very well. For SCRUM based development, I feel that the Sprint reviews need to be face to face to achieve the goals of the meetings.

A core principle of SCRUM is to deliver incrementally, slices of usable functionality; ideally the first Sprint should deliver this first slice. Our large corporation had dropped this basic element. Does it matter?

My experience of reviewing runaway projects is that most failing projects fail because of non-functional performance, rather than lack of user functionality. Arguably, we can add more programmers to a project to add more functionality. However, fixing failed non-functional performance is far from trivial.

Creating a slice of (end-to-end) functionality using SCRUM drives the development team to address the non-functional issues very early. One project I reviewed was three years into a two year programme; the functional specification was agreed but the non-functional requirements were yet to be agreed – it got cancelled.

The end-to-end slice explores many of the grey areas. The early stages of a programme should be clarifying these poorly understood areas.

My conclusion is that dropping a key element of a methodology destroys the integrity of that methodology, putting at risk any ability to enjoy those benefits intended by that technique.

Ian Richmond

Email: ‘About’ and ‘Email Me’ link