Dovetail Software Blogs

"However, quality assurance works great in nice, sterile environments. But most organizations are messy affairs run by fallible human beings. In this blogsite, we often talk about the struggle to deliver good solutions and services against organizational inertia and hidebound thinking. Organizations that could benefit from SOA methodologies, for example, are not likely to be friendly to SOA."

"For standards-conscious service providers, Amdocs and IBM have used the shared information data model (SID), enhanced telecommunications operations map (eTOM) and NGOSS (next generation operations support systems) contracts standards. They also adhered to standards-based data structures, including service data objects (SDO) and service component architecture (SCA) to simplify integration and the way applications handle objects."

Regarding issues with Twitter: "I could look at this as an architecture zealot and say that they should of architected this right from the beginning but this is often a luxury that isn't obtainable in many of the new software services as speed to market, initial cost and feature function often more important. The architectural qualities such as reliability, scalability and maintainability are often overlooked due to the immediate drivers. So this begs the question, how do I address the immediate needs of my application or services while addressing the future concerns?"

"Change is a mixture of larger changes that are less frequent and smaller, more frequent ones and the degree of change tends to increase over time. The continuous change tends to be every few weeks, though it can even be daily - while new process versions tend to change every 2-6 months and have a more involved project to make the change. Interestingly almost all the cases had technology tightly integrated into their business - 'partner' or 'trusted supplier' types - the 'solid utility' mindset was not common."

"I felt I needed to expound on the topic of service versioning after I heard concerns from a few CIO level executives about needing to 'support' multiple service versions. The reason stated was that maintaining multiple service versions was expensive from both a hardware and on-going support perspective. [...] But then this is a case for having governance and not an argument against supporting service versioning policy."