The Service Assurance Company


23 October 2013 by
Patrick Buttimer
Patrick Buttimer is CEO to Eirteic and Galileo Software. He is a visionary who uses his lifetime of industry knowledge to spot the trends of tomorrow and help CSPs to navigate their journey. A regular speaker and contributor at industry meetings and think tanks, Patrick’s current focus is on 5G - which is both a huge opportunity and a disruptive threat to the industry. Patrick began his career as a programmer in the Irish Naval Service before joining Telecom Italia. Here, he developed a passion for telecommunications and OSS prior to joining Micromuse, the Netcool company. Forming Eirteic in 2000, Patrick set the company on a course to deliver the future of service assurance and help their customers unify, simplify and enable growth and agility.

Replace current systems


The most positive thing I can think of is that the “replace current systems” project lets us see how the current solution the customer has, has grown by accretion over the years, and has many tight dependencies which they don’t realise. The “preparation” part of the project, which is basically “document what the customer has, so that we’ll be able to replicate the important parts of it” is showing the customer how much they don’t know about their system.

There are periodic scripts, and files transferred between machines, which tie together the many disparate parts of the customer systems — at least a part of the complexity is due to the customer having grown by acquisition more than once, and having the new system changed as little as possible (because it worked) but still needing to fit in to the corporate standards.

We (and the customer) can see that with Monolith, the number of different technologies drops significantly. There are still multiple integrations with the non-monitoring systems; but they are all consistent in the style of “talk to Monolith”, rather than there being very different things for talking to different parts of the current monitoring systems.

As the project progresses, the details of what is no longer necessary, and what will remain, should become clearer — and should be much more straightforward to document, for the next time a migration happens (if only to a new DR-system)