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.....
All things computing, software engineering and physics related! Now also including retirement stuff.
Saturday, 31 August 2013
Saturday, 17 August 2013
The art of the impossible.....
cont' from Steep Curves post....
Not just solution architects but also ..... so far and counting;
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 .....
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 .....
Sunday, 4 August 2013
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.....
Thursday, 18 July 2013
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......
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......
Friday, 28 June 2013
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;
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
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.
If you believe all that you will believe anything - can we get some real scientist involved please.
Friday, 21 June 2013
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......
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......
Saturday, 8 June 2013
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!
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!
Subscribe to:
Posts (Atom)