Good to go

When is good enough - good enough?

When its Just Barely Good Enough, of course!

JBGE - I find - is the term used on agile projects to make sure you don't 'guild the lily' (GTL). Once you have something that can reasonably be built and tested the plan is to go for it in a 'sprint' development to get early sight and feedback on what you are building. Helps developers, helps users, helps produce a more targeted end product. You may have to go round the loop a few times refining and changing - but that's the nature of the beast anyway in the software development arena.

An excellent view of how this fits into agile developments can be found on the following link

www.agilemodeling.com

The issue comes when you try and introduce these techniques into organisations who are steeped in the more tradition waterfall approach to software development. Lets get the requirements - all of them - can't be doing with a bit of uncertainty, therein lies risk - write them all down then tick them all off as we grind through the design and development cycle. Trouble with this approach is - and don't get me wrong it does have its uses in certain arenas where you need to have full control and visibility - in a fast moving business environment, you will be overtaken by the opposition if you are not fleet of foot. If you are not careful the waterfall will simply be a cliff edge!

What the more agile approach provides are mechanisms for accelerating a project other than simply chucking bodies at it. You can shorten the 'sprint' - build intermediate releases, for example - which can help accelerate testing and user acceptance. You can re-evaluate what is JBGE for the development - does it really need to be all shiny and new?

Of course you need to make sure that what is produced is fit for purpose and doesn't fall into the NJCP category (Not Just Crap Programming).

Onward and upward ;)

Picture on the box

I have recently been party to issues around problems where a word has meant one thing to one person and another thing to another person. Both then plow on doing what they each believe the 'word' was an instruction only to discover at a later stage they were working to slightly different scopes of work. Resulting in a bit of a gap in what was expected. Which has started me thinking, is there a better way?

A picture is worth a thousand words, as the saying goes.

You think - yep I agree with that - and move on. However, can you actually communicate serious concepts across a range if individuals simple using pictures? What a great idea, no more reports, more importantly no more reports to format - what font size was that again!

Taking a project as an example, what would you need to do?

1 you would certainly need an organisation chart - that's OK that's a picture - tick.
2 you would need a project plan - high level, summary can be produced in a bullet milestone format for management, the workers can make do with a Gantt chart - they are pictures- tick.
3 you then need to convey what you actually want doing on the project - tough one this one - but then again how many meeting have you been to where when the going gets tough someone gets up and draws a picture? you could capture these somehow and 'Scoop' them - OK you would need a bit of commentary - but essentially a storybook format could be produced - picture based - tick.
4 you would also need to have a way of identifying all the various touch-points on the project - all those interfaces with the project that need managing - probably best done through a diagram anyway - tick.
5 you also need to manage risks - OK may need a spreadsheet at the back - but a heat-map type diagram is the norm - picture - tick.
6 how will the project management office function - process diagrams - pictures - tick.

you get the idea - for us dyslexics this is Nirvana - plus I believe it would go a long way to accelerating communication across a project team.

Prince 3 anyone?

Pip pip old chap.

How about this one then?

I think we should replace the PID with a PIP!

PID - Project Initiation Document
PIP - Project Initiation Period

Never heard of it - what does a PIP look like?

Well its a period of time that is dependent upon the size of the projects - could be days, could be weeks - which is set at the start of the project by the Steering Group but crucially it is not communicated to the project team. Its a period where the team are allowed to get to grips with the project. Verbal instructions are given to the team on what needs to be done on the project - key deliverables, timescales, that sort of thing. Selected individuals are put in charge of producing these deliverables and told to get on with it. This does assume the project team are highly skilled in the subject matter and have delivered on projects in the past. You wouldn't want to put a novice in charge of any of this. But then you wouldn't do that under the PID type arrangements either.

Chaos can then ensue for the period of the PIP. Who's doing this bit, where's that bit, there's a bit missing, nobody is accountable for the other bit. Regular daily meetings control the chaos somewhat. Eventually the situation settles down (hopefully within the PIP) with everyone aligned.

What this would do is remove the illusion that somehow the PID and its controlling board sessions allow you to systematically manage a complex, multi-interfacing project. You have let the complexity emerge in a natural way and allowed the team to get to grips with it in a manner that facilitates delivery.

What you haven't done is drive the project (yet) - which is the usual approach to project management, beat the thing into submission, cost, time, resources. However, what you have done is avoided driving it off the rails before its even got underway ;)

Et Voila ..... an agile PID .......

Mobilizing the immobile.

Big companies are tough to get moving at the best of times but when you need to sprint rather than jog the frustration is gasket blowing.

Bogged down in process and governance frameworks, in which you need a PhD in jobs-worthiness to understand, the whole setup feels sclerotic. There must be fast track approaches that can enable the vast resources in these companies to mobilise without the need to fill in forms and tick boxes?

Don't get me wrong I fully understand the need for governance on projects, but the type of governance needed relates to actually control over whats being done. Not the sort where the easiest decision - usually by people remote from the project who just don't know what its all about - is to say no. Big companies are full of layers of such checking. I just wonder at the value adding. I suppose it keeps people in a job?

Even when up and jogging these businesses seem to have difficulty getting everyone on the bus and working in the same direction. Enter the power of the PID (Project Initiation Document - see PRINCE). Big business like these types of document - ah at last, something to tell us what to do, who is in charge and when we need to do things! Not unreasonable, but if you know what you are doing on an agile type development, not really a great help in delivering the project or creating the momentum and focus needed to deliver to tight timescales.

But great for ensuring a few boxes ticked .....

Tunnelling through.....

To summarise;


A Roadmap is all well and good
But the end game is well understood

Short timescales, detours, you wont make it on time
What to do, well, follow this rhyme

Straight line, via a tunnel, through to the end
Is the only thing without a bend

Assurance is key to this tunnelling spree
To make sure you don't destabilise things

Beware this may become, a more permanent route
A highway to heaven or hell

Just check with the Roadmap, the end is what matters
Then close your eyes and dig, dig, dig

;)

Following the 'Roadmap'

OK so you produce the 'roadmap' for how to start to integrate the new systems into the old - could be cloud based, could be crowbar into the internal setup, could be complete new redesign of internal. All of which make for good roadmap's - people like this roadmapping - you can explain what you are up to with a roadmap. The interesting part is what you start up the engine and begin to drive using the 'roadmap'.

What you find is that it is difficult to run a programme/project just using a 'roadmap' - the signposts are there but the details of what awaits you on the roads is what is needed when you drive. Bends, hollows, potholes (just driven down a few of them), pedestrians, cyclists all sorts of hazards that can only be negotiated on-the-fly. No amount of project (re)planning will help you much either - though you will probably be able to frighten yourself with how much all this dodging is costing you.

Sounds like you need to be 'agile', particularly if you have a strict deadline looming, but what does agile mean? Can a large programme actually be agile? Haven't we been there before with Rapid Application Development (RAD), and other associated methods?

Or is it the other definition of RAD - Rapidly Approaching Disaster - that will be the norm?

The drive continues.....

The art of the impossible.....

cont' from Steep Curves post....

Not just solution architects but also ..... so far and counting;

• Enterprise architect
• Solution architect
• Data architect
• System architect
• Software architect

once upon a time all you had to do was write the code!

All these architects are in place to try and manage the complexity and poorly connected nature of all of the various applications and corporate systems that have grown up over the years without any thought for how they fit or flex within a changing business environment. Not to mention the disparate data sources, multiple systems, multiple variants of the multiple systems.

Or maybe it has all been through design? ..... I doubt it.

This landscape is changing rapidly though.

Do you bother even trying to engineer something into your current IT environment given the issues related to implementing new systems  into this complexity? With all the architects in place making sure you don't mess with the business, it can take an inordinate length of time to get anything up and running. That's before you hit any 'stuck bolts' in the new system built itself. There's always a thousand reasons not to bother.

Enter the Cloud. Vanilla environment, vanilla interfaces, vanilla support, vanilla politics, vanilla risk, vanilla .... I can now see the attraction.


What is needed is a 'roadmap' so we know where we are going and a driver to get the bus moving .....

Silent type

Not been very blog active over past few weeks.

Sensitive job and holidays got in the way of typing. Job now sorted so normal service will be resumed. 

It's been an interesting few weeks - have learned a tremendous amount. Think by brain is about to explode!

Just how do you get to grips with complicated IT, massive business change and distributed data of varying quality?

To be continued.....

Steep curves.

Learning curves that is!

Related to big data - in real companies with old legacy systems (COBOL - are you kidding me!), system variants (are you running V10 or V10.1?), a plethora of home grown (and I hasted not to call them) packages as well as multiple and complex processes for getting systems onto the company infrastructure (to make sure you don't muck up the current operations of course). Add to this time pressures of day-to-day business activity and the need to maintain existing system issues and upgrade in line with user expectations.

The very definition of complexity.

HELP - how do we get control over the big data - can we start again!

The answer of course is yes - but. How do you start to get a grip of this landscape?

Do you drive new business change projects into it to flesh out issues and interfaces, or take a global view of the mess and plan a grand strategy around what needs to be done. Or indeed do both simultaneously. Can you initiate 'agile' projects to get buy-in from stakeholders - indeed can you use agile in this type of environment?

Bring on the 'Solution Architects'.

We will see......

6-Sigma twaddle

Diversion - I've wandered into a management quicksand as part of my asset management explorations.

Lean Six Sigma: Combining Six Sigma Quality with Lean Speed - WHAT - is this stuff? 

Read more: http://www.ehow.com/about_7296799_difference-six-sigma-six-sigma.html#ixzz2Wy5Rw5Zp

This surely is management twaddle gone mad! Brown belts, yellow belts - do we really need all this - not very agile and looks a bit old school. I'm sure its all very well for improving what a business does but do we really need all the associated scientific psycho-babble.


Quote from my font of knowledge;

"Hence the widely accepted definition of a six sigma process is a process that produces 3.4 defective parts per million opportunities (DPMO). This is based on the fact that a process that is normally distributed will have 3.4 parts per million beyond a point that is 4.5 standard deviations above or below the mean (one-sided capability study).^[6] So the 3.4 DPMO of a six sigma process in fact corresponds to 4.5 sigma, namely 6 sigma minus the 1.5-sigma shift introduced to account for long-term variation.^[6] This allows for the fact that special causes may result in a deterioration in process performance over time, and is designed to prevent underestimation of the defect levels likely to be encountered in real-life operation.^[6]

The role of the sigma shift is mainly academic. The purpose of six sigma is to generate organizational performance improvement. It is up to the organisation to determine, based on customer expectations, what the appropriate sigma level of a process is. The purpose of the sigma value is as a comparative figure to determine whether a process is improving, deteriorating, stagnant or non-competitive with others in the same business. Six sigma (3.4 DPMO) is not the goal of all processes."

If you believe all that you will believe anything - can we get some real scientist involved please.

Agility fragility

Everyone says they are but are they really?

I'm talking about - agile - that's in the systems development sense of course. Though when I think of agile my analogy is of a footballer who has the ball and is running down field avoiding tackles changing direction etc. That's agile in my mind - making changes and looking for opportunities to gain an advantage on-the-fly.

In software and systems development the term agile seems to be cropping up everywhere I look. Agile development, agile design, agile management, agile this, agile that. However, the question in my mind is, is the systems engineering industry really ready or 'real' agile.

A few worrying issues are appearing. Firstly the industry is developing an 'Agile Standard', certificates the lot! Doesn't seem to fit very well with the concept. Having worked over the past few months with leaders in system development. There is a willingness to embrace the concepts of 'agile' but we are all struggling letting go of our background in structured approaches to systems development. Which now, given the speed at which things are changing definitely looks like an 'industrial era' approach to design.

When I check my font of all knowledge Wikipedia its not much better - a thousand and one versions of what people think agile is - very well presented though! High level concepts fair enough but where the rubber hits the road not much cop.

The journey continues......

When do you stop....

So when do you stop?

That's requirements gathering and defining and modelling and verifying and ...

At some point you need to get on with it and start designing and building. But when is the right time to begin - we just need to check we have the requirements in from planet zog and then we are good to go!

There is also a bit of Parkinson's law going on in this phase of the systems engineering lifecycle. A bit of of well we have a few months (years) left to go lets have another cup of tea and think about some more requirements. Just when do you have enough requirements?

What's the answer - nobody knows! There will be a tipping point in every project and then the muck hits the fan and off we go - then its - what requirements - I'm too busy building stuff!

You would almost be better off starting by creating a 'Compelling Event' milestone in your project plan - by plan I mean a high level plan - not the Primavera I've planned everyone's tea break's for the next 5 years type plan. The 'Compelling Event' might be something like when we reach 100 requirements that's it we are going into build or it could be if you don't have something working by now then you are all sacked.

Either way, this would provide a point of reference for everyone to sign up to and then focus on. There obviously needs to be an incentive scheme associated with the CE or it will be just a 'so long thanks for all the fish' point in people's lives ;)

Sort of on optimised Parkinson law!

Top of the pops......

Well the Top 5 focus activity reported in the last post seems to be working very well indeed - surprisingly given the shaky start to it all!

Focus, focus, focus in all areas is paying dividends and  we all finally know what is needed to deliver the Top 5 in all areas including;

1. Planning arena around development of the programme plan,
2. Data modelling, what, when type questioning,
3. Process modelling activity, business change etc related
4. Contract-ITT developments, what's in and what's out of the contract,
5. Business benefits, what and when released by the Top 5 areas.

all starting to align in terms of the overall approach.

So its looking pretty good for this equifinality approach - much to think over - can we get to an end game with it though?

Only time will tell.....

Complexity is .. er.. complex!

I seem to be mired in complexity these days - very exciting though must admit - closet (or not) problem solver at heart you see.

In past posts have focussed on how on the current project we are going about defining the requirements for a very complex revamp of an asset management system. This has used the concept of 'viewpoints' to build up the requirements and ensure as comprehensive a coverage of system functionality as possible. What was than new word I learned - ah yes - equifinality!

All well and good but then the question was asked - what does all that mean - which seemed reasonable to me. What do I get and when do I get it? Which means having to think through the outline design and high level system architecture - to answers the "what I get" question- and production of an outline programme plan - when to I get it. Logical again!

But - where do you start? How do you then start to put an outline design together? The design team all have different views on timescales and exactly what can be delivered when. Data team running ahead of architecture team running ahead of process modelling - not to mention how are we going to control and manage acceptance of whatever it is is produced! Just where DO you start?

The answer again - equifinality - starting to like this word even more! This time though used in a different context. This time used as a focussing tool - a lens as one of the team explains it - to help focus in on particular aspects of the system design and build. Trying to specify the design of the whole system in one go or even think about how the whole works just blows your mind - yes, but, if this, and if that, and if the other - people disappearing up their own exhaust pipes left right and centre - others sat there fish like, mouth open, eyes agog, what does it all mean, anyway what's on the telly tonight.

So to drive the thinking a Star Trek Management decision was made - a Top 5 would be selected for the team to focus on - make it so number one. A Top 5 what though? The Top 5 'things' of course - go and find out what they are! This has cause a lot of hand wringing, what Top 5 - that's the wrong Top 5 - we don't have the right priority Top 5. However, miraculously, running numerous workshops over the past could of weeks has shown that there actually was a consensus on a Top 5! Key items and dependencies drove everyone to the same set of Top 5 'things' - you could have written them on the back of a fag packet in Top 5 minutes but the real value I have seen is in rallying the team around some common themes - driven by a final outcome - equifinality focussing in action!

So we are now up and running putting together outline timescales for delivery of our Top 5 and drawing boundaries around what can and can't be delivered in these timescales.

There could of course be another Top 5 next week ;)

Onward and upward.....

Not quite there yet ...

This week has been a bit of a reality check on all things connectivity related - so beware you Cloud computing evangelists.

Having said that, this past week has seen me use a remote desktop service from Microsoft pretty effectively. Well in fact I wouldn't have been able to complete the job I was working on without it. Essentially I can't load anything onto my work computer - locked down tighter than a duck's ..... - anyway safe to say it makes  Apple look almost developer friendly. However, through the wonders of the internet and the RDS service all was well, Microsoft Project, Visio you name it I could use it. Impressive, bit slow where I was due to internet speed, but full functionality at the click of a button. Only problem was the client had the same problem as me, they don't have Project or Visio loaded as standard either - convert to pdf saved the day. So all that was worked swimmingly.

The problem came when I had to go into London which involved moving hotel. From my usual cheap 'Lodge' to some very expensive place. I have to say it - the room didn't have any windows either - not sure if that's even legal? Anyway, issues began to arise around wifi connectivity. I was trying to meet up with a friend, who doesn't have a mobile phone (now there is a learning point) only a laptop for communicating via gmail. So we had set a time to check email's in order to plan meeting up one evening. However, I couldn't get onto the wifi at my hotel - life is too short to find out why, one minute it was working the next poof it had gone! So what was the backup plan for communication - well we didn't have one - so I thought, Costa's or McD's and free wifi. Off I trundle with brick of laptop looking for the nearest free connection. Made it thanks to Nero's only to find no message from my friend. What I didn't realise at the time - he was staying in another hotel - and having the same connectivity problems. So he had gone to even greater extremes to connect up. Not knowing this I thought the best plan would be to just walk to his hotel and sit in the foyer and wait for him to pass by. Long story short - we passed each other in the street - he had the same plan and was heading for my hotel foyer! Now that would have been funny.

So the lesson - don't bet your business on ropey internet connections and always have a tested business continuity plan ......

Herding dogs!

I was going to say this week has seen the herding of cats but its been more like dogs - bit easier to herd than cats but if you get it wrong you get eaten!

Its all been about a senior management workshop the focus being to pull together the structure and details to go into specification of contract wording. I wasn't running the thing - lucked out there - just a participant. Everyone else (if you read this - you know who you are ;) had run for the hills as the unleashed pack can be pretty ferocious! Anyway I though this could be fun, in a voyeuristic sort of way, as running these event is not easy at the best of times. However, shock, horror it all went pretty well, I even managed to contribute!

What made the difference? Well it was the use of a technique I came across 20 years ago, part of the now old looking SSADM toolset, but now reinvented as a six-sigma activity called SIPOC. What are all these acronyms doing in here. SSADM, in case you don't know as it was a long time ago, is Structured Systems Analysis Design Methodology - probably why it never really caught the imagination come to think of it. SIPOC stands for Supplier, Input, Process, Output, Customer - e.g. how to define an activity in the SSADM process modelling world.

The following link has a good description of what you do to fill out a SIPOC;

http://www.isixsigma.com/tools-templates/sipoc-copis/sipoc-diagram/

or check Wikipedia there must be something in there on it.

In fact, at the workshop, this process was followed very closely but with the addition of discussing the 'principles' of the contract area before launching into the detail of the 'process' part. Which provided a 10,000 ft introduction to what we were talking about and was a good feature to add.

So 10 out of 10 for SIPOC dog herding, and rock-on SSADM there is life there still ;)

Whole greater than the sum of the parts!

Realised I've been living a new word over the past few weeks and didn't even know it!

The word is 'equifinality' - what - well here is the Wikipedia definition:

"Equifinality is the principle that in open systems a given end state can be reached by many potential means. The term is due to Ludwig von Bertalanffy, the founder of General Systems Theory. He prefers this term, in contrast to "goal", in describing complex systems' similar or convergent behavior. It emphasizes that the same end state may be achieved via many different paths or trajectories. In closed systems, a direct cause-and-effect relationship exists between the initial condition and the final state of the system: When a computer's 'on' switch is pushed, the system powers up. Open systems (such as biological and social systems), however, operate quite differently. The idea of equifinality suggests that similar results may be achieved with different initial conditions and in many different ways. This phenomenon has also been referred to as isotelesis (Greek: ἴσος /isos/ "equal", τέλεσις /telesis/ "the intelligent direction of effort toward the achievement of an end.") when in games involving superrationality.

The previous post raised the issue of how to you start to define the requirements and projects for a complex system - essentially how can you make sure you have captured them all?

What you need of course is a very large dose of equifinality - you need to travel as many different paths through whatever it is the system is being designed to do as possible. These paths, of course, need to be both top-down and bottom-up and cover as many viewpoints of the system as possible.

So what sort of viewpoints are we talking about?

What about;

• Physical architecture
• Data - Information architecture
• Business Process architecture
• Security architecture
• Enterprise architecture
• Functional architecture 
• User architecture

However, you may therefore need a degree in architecture to fully complete ;)

Final thought from the complexity course I'm doing is that even if you take all these paths you will still have some emergent property that will take you by surprise!

Bottom-up and Top-down

No ..... not that sort .....

Validation and verification related of course!

The Question:
You have a brave new view of the future for you operations - big data related to big assets and all that new stuff is banging on your door. Why aren't you using this to improve efficiencies in the business? Everyone else is - just read about what you can do.

Issue:
You have an operation that currently runs not that badly, is very complex, and has lots of fragmented data. How can you start to introduce a new big-data type system into what you do?

The Solution:
You need to start by gathering requirements for the new system, have a look through these and then see which can be implemented and on what timescales - of course - simples!

Well that's all very good from the 10,000 ft management helicopter view of the problem. The next step in this world is a bit of Start Trek Management (STM),

'Make It So'  number one.

and off we go.

Meanwhile in a universe near you, requirements gathering has started, as the make it so at this level doesn't involve much thinking, just a bit of organising of meetings. This usually goes well, everyone wants to get their 'issues' out on the table, "and a want a yellow button in the top corner of the screen" type stuff along with "we would like to manage risk at an enterprise level". Result - one big bucket full of requirements! Yes, yes I can hear you requirements management types - structured approach, attributes blah, blah... Unfortunately, here in the real world the Captain wants progress, and NOW! So things happen, and the feedback is good, everyone is venting, carry on number one! More workshops - they work. Bucket gets fuller and fuller - big data gone mad. We need a management tool for all this, role out some requirements software to manage it all. Phew thank goodness that existed now we can relax can't we? But no - its just a fancy bucket - we shall have to engage (STM) brain to figure out what to do with all this data (sorry - poor STM jokes).

Number one, "where are we" - "we have a bucket full sir"

So, the problem with the bottom-up set of activities is that you end up in a position where you can't see the wood from the tree's. While the STM top-down view of the world ends up launching a raft of projects but you are never sure if they will connect with the real world. The conclusion so far is that, unless you do both BU and TD then you will never figure out if your big data related initiatives will be viable and add value to the business.

Not thought further than this yet ..... sits down and puts fist on chin .....

3D's of computing (Data, Devil, Detail)

This week has seen a flurry of activity under the banner of Big Data!

The finale was Friday evening watching a recording of this weeks Horizon programme on 'Big Data' - which I watched with 3 of my advisor's - sounded like geek heaven to us. Anyway the programme unfolded, blah, blah, big data, lot of 1's and 0's flashing over the screen to show you where the big data was coming from and going to. As it went on though, I personally, was having trouble keeping my face straight - to the annoyance of one of my advisor's who kept telling me to shut up. Having slept on it and having been immersed in a real live project for the past month or so directly dealing with Very Big Data (maybe that will catch on - VBD ;) the things that were bothering me boil down to the following;

1. there's a 'smoke and mirrors' feel about a lot of this big data talk. Certainly there is vast potential for mining data, but, from what I've seen 'ordinary' companies are miles away from being in a position to exploit it fully. Enter the big data repository suppliers who will solve all your big data consolidation and mining problems for you. Off you go....
2. enter the mythical 'algorithm' - is having this central repository going to work. As in the Horizon programme, when you need to access the data all you do is create the algorithm to do what you need - simples! You have your data, you can access it from anywhere at any time (oh yes you can) what are you going to do with it (in my world you should have though of that beforehand but that's another story) you have your bucket of data and want to fish out some 'benefit'. What do you do, you write an algorithm to do this - most of this algorithm is just searching and filtering and displaying - not much algorithm about that. However, there could be an analysis element in this algorithm too - sounds like you need to dust of the old Fortran compiler to me! What's the problem, the problem is spreadsheets, everyone wants to run their own personal 'algorithm' dealing with their own specific needs - and quite rightly too! They take an extract of the big data, do some work on it, write the report and off they go. Well, probably a bit more than that but you get the idea! All this leads to fragmentation (again) of the data set as it is difficult to re-upload you work back into the mother ship. 
3. what's needed of course is a managed way of allowing access to the big data and development of local 'algorithms' - sounds like app development to me! These can use and refresh the big data appropriately. Sorry seem to have entered the smoke and mirrors zone again. Great aspiration but do 'ordinary' companies really have the quality of data to allow meaningful apps to be developed?

The thoughts continue, keep smiling......

Rain Cloud Computing

It all seems to be going pear shaped - rant, rant.

Maybe its the credit crunch finally starting to kick in but there seems to have been a rapid up-tick in the removal of freemium services, or worse still, a charge (now that's against the driving principle for me) starting to be applied.

Example that I have noticed this week - Google Reader (gone), Scoop-it shared curation (payment now required), LinkenIn book reader list (disappeared - along with all that bumph I wrote?).

All this puts a distinct shadow over 'cloud-based services' in my mind. In fact we don't really have a 'cloud' - as I've pointed out in previous blog's - what we have is a load of separate islands of adventure each with their own data store and application arrangements. Under total control of whoever runs the site. Sounds like a mainframe, operates like a mainframe, it is a mainframe - as they say.

So you get lured in on a cloud-like freemium offering and then once you have been locked in the squeeze is put on. Probably get this blog taken down now, just you see!

Some things you will probably think it worthwhile paying for others will fall by the wayside - what services do you really need? Don't give your data away without due consideration - that goes for companies too - you have been warned!

Why can't we build a proper cloud - rather than these islands - source data accessible by any means and not controlled by any one outfit - or is that a bit naive ;)

Compuplexity

Complex systems seem to be raising their head quite a bit these days - or is it just me noticing complexity now that I am into my MOOC!

Just had another example from my friend Ian from the BCS related to a paper on complex system failures - ref http://www.ctlab.org/documents/How%20Complex%20Systems%20Fail.pdf

What I have been thinking about is that the computer system I have been working on recently also falls into this complex system arena - see previous posts re-background. Some of the parallels are;

1. it is fundamentally composed of simple elements - spreadsheets (yuk) and simple calculation engines re used at the coal face,
2. it has grown by the 'system' taking the good bits and improving upon them and killing of the parts that done work well - though there is a lot of old code still lying around!
3. nobody really knows how it works - it just does
4. people are by far the biggest element of the system and make it work despite it running with flaws

So according to my MOOC that would put it in the complexity box - and thats without considering fragmentation functions!

So now the question is how do you go about improving such a beast? Well thats the job really, but it isn't so straightforward a question to answer now that I have had a look in the box. The simple - helicopter - view is to just simply consider it a box. Lets just buy a better box! However, some critical things hang off the back end of the output from this box. So you had better not muck those up - or you are in jail! 

Given the paper referenced above - even simple changes can have big impacts!

More thought required.....

Badge addiction!

I've registered on Foursquare - shock horror - have no idea why - got bored and was playing with it!

It reminds me of clocking on at the mill - yes I did work in a mill in a previous life - when we still had some in the UK that is!

However, I now have powers - I am the Mayor of the Travelodge Milton Keynes Central - wow! I can see how these badges become addictive. I'm going to try and become the mayor of my local ASDA next. Seeing as I seem to meet most of my work colleagues there doing the weekly Saturday shopping this could end up as a cross company Badge competition!

Its all a bit scary - you can see what others have been up to and others can see what you have been up to - useful for filling out your timesheet! Though I have discovered that connecting up with a work colleague that I wouldn't normally have much to do with has created an odd relationship. I know how he gets to work what he does for lunch and when he arrives home for the weekend. Is this a good thing - not entirely sure. There is something there, but it feels a little voyeuristic to be honest.

I can see that 'checking in' you could also meet up with new contacts - useful on a work front as well as social. I now feel obliged to check in at my mayoral residence(s) and I do feel sense of responsibility to these places weirdly!

Obviously something that needs a bit more investigation.....

Big Data and Fractals all in one post!

Data fragmentation was the topic of the last post - and this weeks meandering thoughts have also been on data fragmentation and measures of its complexity - now that is a bit of a mind bender - and whether the advent of Cloud Computing (aka mainframes) will help in sorting the fragmentation mess out?

The problem as I see it is everything starts with a plan of having a central 'Big Data' repository (aka Computing Centre) from which all decision making analysis can be driven. However, in reality - out in the field - individuals need some local, specific, analysis to be performed to help them do their job. So they take a data extract from the 'Big Data' and do what they need to do. The problem is, these extracts over time, can take on a life of their own, along with growth of all sorts of other associated ecosystems. This cycle of events can continue down to individual spreadsheet levels!

Aside: I have to come clean and confess that I have made extensive use of Excel (filter functions) this week - given my panning of Excel programming this does feel a little hypocritical - however - they have proven very useful - just illustrating the ease with which you can get drawn into this! Its not been real coding though - so I think I am still OK ;)

So, where is all this going? The question is, is it possible to measure the complexity of this fragmentation using some measure of the fractal dimension of the data sets - that's a thought from the MOOC course I'm taking! Can this be used to estimate the amount of effort required to consolidate the fragmented data? In fact, how do you calculate the dimension of a dataset? Will Cloud Computing help solve some of these problems going forward? The root cause of the fragmentation is people wanting something that corporate locked down system do not provide - will the new Cloud systems give people the freedom to build (under proper supervision) what they need locally or will it end up in this non-virtuous cycle again?  What is the probability of the fragmentation occurring again?

Need to watch the next lecture on the course - maybe there is no connection!!

Obviously more questions than answers here - the revival continues ......

Big Data fragmentation function ....

Got involved in 'Big Data' type activities this week then some 'physics from the past' emerged out of random thought processes!

Big Data Project (BDP names withheld to protect the innocent) started with - this is the system diagram 'someone draws a big system diagram with loads of connections'. Holy smoke how am I going to get my head around this one was the overriding thought! We are talking about a massive company with massive data requirements - a definition of 'Big Data'. Data has been replicated, re-used, added to across geographic and functional boundaries not to mention individual personal modifications down at Excel (yuk, yuk, yuk) level.

BDP's goal is to try and specify the core functionality of all of this. Well, we have started to plug away at unpicking it using process maps, system diagrams and data flows, so the fog is starting to clear.

The question in my mind though was how did it all get into this position in the first place all of the above was done for the right reasons - to get the day job done. Each core data element seems to have spawned a few siblings which in turn have spawned more. It would be useful to know if there was some measure of the 'robustness' for each and every data repository and what has been their history?

Data store's exploding into many fragments which then exploded even further like a palm firework were the images in my mind. That bizarrely made a connection to my particle physics past! This seemed a bit like the tracks we used to trawl though from the JADE central detector - on night shifts - burned forever into my memory bank!

Which then led me on to thinking about fragmentation functions - essentially how you characterise the cascade of particles from the central annihilation - electron and positron in the JADE case.

In summary (ish);

"Fragmentation functions represent the probability for a parton to fragment into a particular hadron carrying a certain fraction of the parton's energy. Fragmentation functions incorporate the long distance, non-perturbative physics of the hadronization process in which the observed hadrons are formed from final state partons of the hard scattering process and, like structure functions, cannot be calculated in perturbative QCD, but can be evolved from a starting distribution at a defined energy scale. If the fragmentation functions are combined with the cross sections for the inclusive production of each parton type in the given physical process, predictions can be made for the scaled momentum, x_p, spectra of final state hadrons. Small x_p fragmentation is significantly affected by the coherence (destructive interference) of soft gluons, whilst scaling violation of the fragmentation function at large x_p allows a measurement of ."
(ref; http://ppewww.ph.gla.ac.uk/preprints/97/08/gla_hera/node5.html)

so now you know!

I'm sure the data we have now started off as 'Big Data' in some form prior to fragmentation so, is there an analogy between particle fragmentation and data fragmentation, and thus a means of potentially predicting fragmentation of new Big Data repositories within an organisation?

Oh well it was nice thinking about it anyway.....

"Simples"....

This weeks missive relates to software design processes - again!

The question that has been put forward is what is an appropriate level of use of CASE tools. These are packages that help you design and build software. To illustrate the 'issue' here is the list of CASE tools from Wikipedia - and there are probably even more than this knocking around in some small corner of the office!

Ref: Wikipedia - "Types of tools are:

• Business process engineering tools
• Process modeling and management tools
• Project planning tools
• Risk analysis tools
• Project management tools
• Requirement tracing tools
• Metrics management tools
• Documentation tools
• System software tools
• Quality assurance tools
• Database management tools
• Software configuration management tools
• Analysis and design tools
• PRO/SIM tools
• Interface design and development tools
• Prototyping tools
• Programming tools
• Web development tools
• Integration and testing tools
• Static analysis tools
• Dynamic analysis tools
• Test management tools
• Client/Server testing tools
• Re-engineering tools"

If all you are doing is building some simple application, e.g. web site, some remote interface control, analysis of some business data, what do you do? You could easily spend all your time evaluating which tool to use rather than getting on with the job!

Well Occ-Bam this week has shown me how you can use a simple tool like PowerPoint to help capture requirements, prototype the design and develop the used guide for a simple app. Its so simple even I could do it without having to fork out thousands of pounds on one or more of the above packages - and I mean thousands and thousands in some cases (sorry couldn't resist).


All you do is;

1. storyboard the key user requirements on separate PP slides
2. build sample user input and output slides for step 1 slides
3. construct sample user interface slides based on step 2   
4. document in the notes on each slide the functionality that sits behind that particular slide
5. document in the notes on each slide what the user needs to do interact 
6. iterate steps 2 to 5 until happy!

et voila - you have created, a requirements repository, a functional model of the code, a set of use cases, defined the user interface, prototyped the design and created a user guide all in one go.

What a brilliant use of PowerPoint I say, simples ;)

More pieces of the jigsaw ....

Well my advisor's have been keeping me busy this week. The revival is gaining momentum I feel - just hope I can hang on.

Two areas of development for me emerged out of the chaos this week.

The first was back to basics  on software engineering processes courtesy of Occ-Bam - who has reintroduced me to the virtues of a simple approach to software development. You can make a meal of this documentation stuff can't you - and its tough to keep a 'linear' record of what you are doing up-to-date when you are iterating code development at a rapid pace! Just go away and let me code or nothing will work will it. Keeping the documentation as integrated into development activity as much as possible is the key. Also keeping the 'stages' of development at a fairly high level not only helps you better follow the 'story' of the development but also stops you getting lost describing a very nice looking weed!

1. project initiation
2. requirements capture
3. systems design
4. coding - with version control and design information integrated into the code
5. testing
6. final documentation - including user manual

Are all you need for most simple projects to ensure you are 'building the right thing, rather than just building something right' as a colleague recently pointed out. Steps 1 to 3 basically make sure you know what it is you are coding and stop you diving straight in to hacking stuff out. Step 4 lets you get stuck in and document as you progress the code. Steps 5 and 6 are a check to see it turned out as originally planned (or not ;). 

The second area of development for me has opened up another Pandora's box of stuff to consider. Bambofy has introduced me to Quora http://www.quora.com/ - well what to do with this? Its like a living Wikipedia, you can post questions on topics and get responses from 'others'. I have been on a bit of a quest for something like this for a while - to really give some depth to the LinkedIn group type discussions - how do you broaden the thinking on topics of discussion?  Well this site seems to offer that facility. I am just starting to play with it and have posted some Quality Assurance tester questions - so far I have been impressed.

Got to stop myself wading into answering physics questions though .....

MOOCing about.

Think I have now seen both end of the spectrum related to online learning! (MOOC Massive Open Online Courses by the way)

I started on Monday with an internal online training course - which will remain nameless to protect the innocent. This was a one hour course on one of the company business process support systems - newly implemented. I was sat at home logged onto the VPN with coffee in hand first thing in the morning (my best time) ready to be educated (my best skill). I fired up the training pack and then spent an hour trying not to eat my face. It was the most uninspiring hour I have probably ever had - an exaggeration I must have blocked the others out. The worst thing was I had to run the video's to their conclusion - monitored you see. What was so wrong with it? Well it turned out essentially to be an hour of how to fill out forms, "this is where your name goes", type of thing. There was a bit on which order to fill them out in which was mildly relevant but on balance not worth an hour of time - could have had another form that you filled out to show the order you need to fill out the other forms, if you know what I mean! On top of that when you actually get round to using these forms in real life they need to be printed out and filled in - using a pen - shock horror! 

This was an online 'course' that should have just been an instruction pack. It wasn't for the lack of polish when it came to the presentation side of things either. There had obviously been a lot of effort put into recording the course and in making it available. 

Having been the first online course I have ever logged onto it has kind of left me with a feeling of trepidation with respect to online training. 

HOWEVER

I was saved by the Santa Fe institute - thank you, thank you!

In my re-entry into all things computing I thought I needed to get re-skilled on where current thinking is on complex system dynamics. Big data, knowledge management, social networks blah blah - what is the thinking on modelling these types of systems. So I signed up for the 'Introduction to Complexity' course (even though I think I am living through complexity so may not need the introduction ;). 

Follow the link for details http://www.complexityexplorer.org/

The course is run by Melanie Mitchell - I have only done the first few modules but it is light years head of the form filling course - mainly because the content has clearly been well thought through. Getting the level of detail right, on what is a difficult subject, in a simple manner, is a skill in itself. I have now sat through an hour of this training and it has felt like 5 minutes - the power of engagement! 

As a result of my first encounter, however, I still have this niggling worry that future modules are going to turn into some trivial "complex systems are complex" format, but I doubt it!

So what does all this mean? 

Well I guess you can whack out YouTube video's to your hearts content but when it comes to online training - Delivery is important but Content is King!

The end of Gamification!

Gamification - just hate that word - has been the subject of some thinking recently - around whether it can be used to promote internal company 'experience' qualifications. Therefore helping drive training and development activities and foster a more personal responsibility for building up skills.

Previous posts have covered some of the issues that have come up. What I want to do here is summarise where we have got to and park the subject until some of these issues have been addressed.

So here we go on the issues;

1. Is collecting badges really a game? Why will people bother collecting them other than some of us OCD types who will collect any old rubbish - who will be energised to collect? The answer to this will need to be addressed within the company. The initiative will need some serious backing from the most senior management and will need to be followed up with 'proper' marketing. Leaving it to 'organically grow' I don't believe is an option - see comments on LinkedIn below which is much more visible to people but still has had difficulties.
2. Extensive research, i.e. me just watching what has happened to my LinkedIn skill endorsements, has shown that there are some who are just 'too cool to play'. Some people - engineer-techno-scientific'y types I must add - seem to find it impossible to click the endorse button. Probably some deep psychological reason here which I wont even bother tying to understand. Possibly throwing some confusion into the badge construction and selection arena?
3. How best to make visible the badges, internal company-only sites or external visible to all, a la LinkedIn? External is good for infrastructure - its all in place and maintained for you. In fact using LinkedIn skill sets would be a very easy way to start to roll out the badges. Using specific badge collecting sites would impose too much of a burden on people as it would involve everyone signing up for yet another site whereas almost everyone in the company has a LinkedIn account. However, these external sites are subject to the whim of the designer and we have seen recently unilateral changes to functionality of these sites and the removal of some facilities. Do you really want to rely on these sites for what would be a key business function? Internal sites would of course be under full control of the business but would require quite a bit of 'maintenance' - which would of course also costs money and is therefore at odds with my primary directive! I think the answer lies in both internal AND external recording. An internal central record could be kept but using the external site to advertise -  if the external site goes pear shaped then at least there is a backup. Internal - simple record and authorised rating body for the skill - external - visible and rateable by community - is the best way forward.
4. Others outside the business could mess up the ratings? However, I have left an internal training badge (AMP badge) on my LinkedIn site for a few months and nobody has tinkered with it. So the chances are this route for advertising badges will work - people tend to only rate skills that they are personally aware of - which of course is what gives credibility to the community ratings. but also means that they are less inclined to rate and therefore muck about with internal training course badges. 

For further reading on the upside, check out;

http://www.forbes.com/sites/nextavenue/2013/01/11/how-to-make-the-most-of-linkedin-endorsements/

and the downside

http://mashable.com/2013/01/03/linkedins-endorsements-meaningless/

So in summary, it looks viable to select a set of badges for internal skill's and make attainment of them visible on an individuals LinkedIn site. The mechanics are therefore fairly straightforward for getting something running. The difficult part will be raising the profile of this initiative within the business and in getting buy in from senior management.

Which is the next step in this journey!

Clouds - nothing new under the Sun?

I have had it confirmed by Microsoft (in a round about way) that we are returning to the age of the mainframe!

I attended a talk on 'Cloud computing' this week which was very informative but illustrated to me that we are indeed returning to the age of mainframe computing. Bring it on I say!

The talk was run by a Microsoft Partner organisation and the aim was to present the advantages of using Cloud computing in a business environment. Of course - the talk focussed on a Microsoft infrastructure that enables the 'Cloud' for you - and its very slick!

However, there were echo's from the past throughout;

• The description of the Cloud server end of things sounded very much like an old mainframe computing centre to me. Stand alone building containing a mass of computing power being cooled by some enormous plant. Looking to position these centres in places like Iceland to aid the cooling! Who remember the Cray cooling iceberg, http://archive.computerhistory.org/resources/text/Cray/Cray.Cray2.1985.102646185.pdf
• The description of the IT support provided with the Cloud services. They load your  applications and manage data allocation for users. Sounds suspiciously like Job Control Language wording to me. http://searchdatacenter.techtarget.com/definition/JCL
• You only pay for the Cloud service as you use it - well on a monthly basis anyway - and only for what you need. Paying for access was part of mainframe datacentre life - you couldn't afford to do anything else. Better make sure your code was as clear of bug's as possible or your allocated hour of use would go in a flash!
• On the Cloud data side - loads of the stuff produced 'big data'. There was lots of big data produced in the mainframe era - this was stored on dinner plate sized data discs - piles of them - if that isn't big data I don't know what is! All your data stored remotely and safe of course - just like in the Cloud!
• And finally, the Cloud is accessed by a 'dumb client' that sounded exactly like a 'green screen' monitor.

There is hope yet then. Onward and upward ....

Google v Microsoft ..... GvM

Just when I thought Google was taking over the world (last post), I have now come across - via my new personal business computing advisor (PBA) - that it will actually be Microsoft!

"What," I hear you say, thought they'd given up with the dinosaurs, Word and that hacker-prone Excel package.

Note to advisor's: I am getting worried I'm turning into a bit of a product salesman for all these companies and feel that I have gone down some rabbit hole of computing from which I will never return, but, one more post as the addict would say ....

The new word in the house this week was 'CRM' - conversation initiated by the PBA - followed by comments like 'what the hell is CRM'. So there was a bit of a struggle to get heads around what this was. CRM of course (thanks to Google!) was defined for the team as Customer Relationship Management. Wonderful. That's not computing that's management baloney, (actually we don't use the word baloney but we do use another 'b' word), which then resulted in diverting the conversation into discussing the difference between leadership and management, but that's another story? However, this did started me on a trail of finding out what Microsoft was up to!

And, low and behold, they are trying to take over by stealth. Hoovering up the bit of the market between social networking and business building - brilliant positioning! This is an extract from their CRM site;

"The surging popularity of social networking sites is indisputable. Yet many organizations still struggle to translate it into real business benefits. By acquiring tools that let them manage their social networking initiatives alongside traditional marketing, sales, and service activities, organizations can take advantage of social networking without losing focus on their core business. Ultimately, success will lie with those businesses that can integrate social networking’s wealth of customer data, unfiltered feedback, and informal conversations into existing customer management initiatives and processes. Microsoft helps our customers achieve this goal through the Social Networking Accelerator for Microsoft Dynamics CRM. This solution equips organizations with the capabilities to better listen, respond, and analyze social network activities. By applying that insight, Microsoft Dynamics CRM allows organizations to better integrate this emerging channel into existing business processes for a more holistic and effective customer management approach— something that will continue to be paramount for success."

ref. http://crm.dynamics.com/en-gb/marketing

Couldn't have said it better myself. I will obviously need to have a deeper dive into this the site basically says but this and all your problems are solved social to money connected in er. 10 easy steps. I've been there before though! With a little bit of digging it looks like the tools needs some 'configuration' for use in your business - oh yes - past experience has told me this usually means you will need to undertake a PhD in Process Mapping to get it engineered to your business properly - I am thinking SAP here though (Google it)!

Anyway, I remain intrigued and await further enlightenment in the coming weeks.

For the record; I do like the new Microsoft Windows 8 panes!

Cloudy management!

Google is taking over - think I'll give in! This is going to sound like a sales pitch but believe me, it isn't - I'm just interested in the cheapest quickest and most functional way to operate ;)

This weeks missive was prompted again by one of my trusted advisor's - Bambofy - who is dragging me back up the computing learning curve (as well as now beating me at table football). "Have you seen the new Chromebook" was the start of it. Given that this was from a Mac user I immediately though of a slick chrome looking thing that would cost at least a 1000 somethings. However, I have done some learning and then realised Chrome - ah - Google - OK let me have a look. Long story short is that this machine, I am convinced, has signalled the future.

Here is why.

The unit for a start only costs £199 in the UK - for us that's mega-cheap (Brownie Point no. 1) - all those wanting access to the internet line up now. Plus its fast (Brownie Point no. 2) and it looks sleek - we checked one out in PC World like you do. There's also a desktop 'Chromebox' too - now that just looks cool and is also cheap at £279! Definitely sounding like a sales pitch I know!

So what - aren't there are lots of other cheap machines around I hear you ask - yes - but this one opens up a World of Google to you. Now here for me is the interesting bit. I stated toting up what I do with my laptop/internet time. Here's my typical startup sequence;

1. Power up laptop (Toshiba) - now looking old and battered
2. Fire up Chrome browser (Google)
3. Fire up +Gary (Google)
4. Fire up gmail (Google)
5. Fire up Blogger (Google) 
6. Check my web site (Google sites)
7. Check the site statistics (Google Analytics)
8. Fire up LinkedIn 
9. Fire up Twitter
10. Check news feeds (Google Reader)
11. Share any interesting items with +Add This (Google app I think for Chrome toolbar)
12. Any interesting files I store on my G-Drive (Google) 
13. Edit any files with Google Docs, Spreadsheet (Google - obviously)

So I am Dr Google - by default - without even realising! (Brownie Points 3 to 10)

Not to mention the rest;

• YouTube - my music and entertainment site,
• Maps - can't find anything without that these days, and
• Chrome itself - which is light years ahead of the rest of them.

(Brownie Points 11 to 13)

So is this cloud computing made easy - if so then the Chromebook is geared to opening the door for you?


Maybe it is - for more thoughts on the subject check the following link?

http://www.computerweekly.com/blogs/cwdn/2013/01/what-is-cloud-management-software-anyway.html


Onward and upward......

Not much action ....

HAPPY NEW YEAR!

Life took over - so not a great deal went on over Christmas on the programming re-entry front! Much to my disappointment I must add. So just have a couple of musings from the various discussions and events that went on - we are a family of nerds so end up talking about this stuff for fun you see.

Social networking discussion topic - do you really need a web-presence as an individual?
Well this topic really polarised people - not being visible was preferable by half the group while - fully visibility was the call from the other half. Which is best though? Is there a best? I of-course fell in the full visibility group.  We are talking about a group of people who are experts when it comes to computing by the way - so no Luddite's here. Anyway, we ended up drinking too much and not coming to any conclusion, though  I still believe there is something a bit suss about not having a profile. However, it did start me thinking - could I remove my internet presence if I wanted to? Bit like those credit card companies who cancel all your cards for you from one call (usually just before you find your wallet again) - could you zero your profile and start again? I don't think I could. What if your 'personal brand' (oh yes - you do have one), is not what you want it to be - can you correct it? I know of one person who exited LinkedIn, closed his account, and then started again just because he wanted to lose all of the recruitment agents and ne'er-do-wells from his profile - bit extreme, but it worked - wrong or re-branding?!

Apple relia-maintaina -usa-bility discussion topic - Apple Computers taking a beating. 
Discussion sparked by the 3rd failure of my mates MacBook Pro hard drive while he was in the middle of writing up a crucial scientific deliverable due on 31st December(!) - a date not set by him he was at pains to point out.  So Apple took a beating - given that this was the 3rd one in the last 3 months - er my old Tosh-laptop has been more reliable than that and I've dropped it a couple of times! This also initiated comments on the programming of iOS front from my personal experts, who informed us that its a pain in the neck and to be avoided at all costs! Only the prevalence of iThings makes it something you have to do - otherwise come back Microsoft all is forgiven was the cry.


So - the thought for the New Year is - "things ain't what they used to be"

Have a good one ;)