A post from earlier this week discussed a less risky, dependency-reduced, stepping-stone transformation approach. It contrasted with the big-bang delivery model that’s often proposed on OSS projects.
Taking the same train of thought, have you noticed how often architects (including myself) come up with an end-state view of what an OSS, or IT, or networks will be? Have you also noticed that they often seek to demonstrate the cleverness of their architecture in the end-state?
To be honest, I’m more impressed with architectures that cleverly guide a reader through the minefield of complexity via multiple lesser steps and steer towards an intended end-state. To be equally honest, this type of architecture is probably part-roadmap, part-architecture. The journey often demonstrates the impracticality of an ideal end-state.
This may lead to an OSS with compromises but at least it’s not compromised.
The big-bang end-state might look really impressive on paper, but not be viable for the delivery team.
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words. And that’s
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
2 Responses
I agree on the blend of architecture / roadmap. My view based on having been part of various transformation attempts is that puristic approaches tend to fail because their emphasis is on conformance to a fixed method. End-state architectures are drawn up often based on functional / technical expectation or demand combined with vendor product input. When capital costs, currency fluctuations, competitive situations are added into the mix (particularly in countries where ARPUs are low in US$ / Euro terms), there are different choices to be made. Point is (in my view) an end-state architecture is a cognitive illusion, it doesn’t exist; there are only transition architectures together forming a roadmap to a business vision.
Seshan, I love your closing quote, “an end-state architecture is a cognitive illusion, it doesn’t exist; there are only transition architectures together forming a roadmap to a business vision.” Brilliant!