Many vendors will give you a consolidation solution that looks good on paper. One single contract, that’s good, right? But the reality is, many times this is nothing but a mirage.

 Why? Because these vendors, even with their single contract, are still implementing several disparate tools, having different OSSs, different databases and no unified presentation layer. Sure, they can string this all together, but does this really reduce costs? What the single contract doesn’t take into account is Total Cost of Ownership (TCO), speed/cost of deployment, and resources needed to maintain the infrastructure.

One2One Ep. 5 of our video blog shows that the only path to reducing cost structure is to utilize a unified infrastructure management solution having one common database, one common rules engine, and one authentication engine that lets you do all the things you did previously using several different tools.  That solution is Monolith Software. (Just ask Oracle.)

View the video to learn how to maximize your game plan to reduce your cost structure. You can also see another real life scenario of how we did this with a customer here.

We have an in-depth TCO modeling tool that can help predict your ROI with Monolith. Contact us if you’re ready to see some numbers.

Cheers,
Jeff

At last year’s TM Forum, Monolith unveiled the benefits of a unified, single code base approach to infrastructure management. Since then, many vendors in our space have jumped on the bandwagon of claiming a unified approach. There’s a big difference between talking unified and delivering unified. And, when it comes to the creation of meaningful meta metrics, this distinction becomes increasingly important.

Episode 4 of our video blog One2One covers these topics and what Monolith will be demonstrating at TM Forum 2012, May 22 – 24 in Dublin. Also if you happen to be at Management World, visit us in the Expo Hall, Booth 16.

View the video below to learn about our approach to meta metrics. You can also check out our data sheet on “The Impact of True Unification.”

 Cheers,

Jeff

The Custom Action Policy Engine (CAPE) is one of the ways we do correlation within Monolith Software.  It provides a “virtual operator” type capability that automatically recognizes an event type, and automatically takes remediation actions.

Episode 3 of our video blog One2One reveals a real world scenario where the world’s largest international IP network provider uses Monolith’s CAPE to automate scenarios such as advanced security determination for devices and looking for two conditions within the same device.

View the video to see how CAPE works, and how it can make your life easier. It’s your own caped crusader for event correlation and remediation (sorry, couldn’t resist). You can also check out our data sheet on “Correlation & Enrichment,” or our tech brief on Automated Runbooks enabled through CAPE.

Cheers,

Jeff

Often, service providers are forced to wait several months for software updates needed to roll out new services. They tell us – “This is a big issue.” We agree, it’s a big issue. What are service providers looking for? An engine that allows them to adapt, be agile, and not be beholden to a software company.

We’re frequently asked how we handle device certification. The answer is stunningly simple. Monolith has an open process that supports literally every device in the marketplace, both EMS- and device-based.

Ep. 2 of One2One explores how open device certification gives service providers unprecedented speed, flexibility and agility in their infrastructure management and monitoring. View the video to see how Monolith can liberate service providers from the vicious cycle of traditional device certification. You can also download our white paper “Why Open Device Certification is the New Best Practice.”

Cheers,

Jeff

Here we move forward to discuss the next evolutionary leap in service assurance.  In other words, how the industry (enabled by Monolith Software) is moving from event-based service assurance to proactive, KPI-driven, metric-based service assurance.

Event management has dominated the management landscape in Service Provider NOCs (Network Operation Centers) for well over a decade now.  SPs have also come to realize the need for augmenting their event management capabilities with availability and network performance management solutions.  Unfortunately, when they made the decision to add these capabilities, there was not a vendor that offered an integrated solution.  This meant adding more disparate components to the monitoring architecture.  That proved to be an awkward solution, but still doable.  Why awkward?  Because for many SPs, the event management realm is owned by the NOC or Operations staff, and the performance management tools are owned by the engineering and network capacity planning folks. On top of this, new business drivers began to complicate things even further.

The Customer Driven SLA – Blessing or Curse?

In order for SP sales teams to be competitive and to land new customers, they’re now required to meet specific SLA commitments. This is challenging!  If you go back 5 – 15 years you’ll find SLA language in SP contracts that endeavored to provide the customer with a SLA.  The problem from a customer perspective is that these SLA commitments – because they could not be managed from a meaningful metrics perspective – were virtually toothless.

An organization could lose millions of dollars if network connectivity isn’t up and running.  Think about a trading company, an Amazon, a credit card company, etc.  Downtime is very costly.  The SLA would typically offer this customer a credit off on their bill based upon a percentage of the downtime for the given month that the outage occurred.

Let’s take an example of this.  Suppose your company is paying $10,000 per month for a DS-3 circuit.  A two-hour outage could cost your company millions in lost business.  You call your SP in an extreme state of agitation, and let them know you expect a significant credit because of this.  Most of the contracts were written to reflect event performance, which was the way it was done at the time, however this often didn’t line up with the customer’s metric expectations.  The rationale was something like this:

• There are 744 hours in the month in question
• We had an outage of only 2 hours (as reported by the customer; though many times the SP doesn’t have the data to validate this)
• 2 divided by 744 equals  .26% of the available time for the month
• .26% times $10,000 equals $26
• We know that if we offer them a $26 credit they are going to be furious
• Let’s ask the sales team what credit amount we can offer and keep them as customers

Not pretty, but pretty accurate in terms of how this actually happens.  Manual credit negotiations are how situations like these were historically resolved.  Is this approach changing?  Absolutely.  Consumers of SP services are becoming less tolerant of these types of arrangements and for good reason. Simultaneously, SLA management solutions have emerged (e.g. Monolith Software) that empower the SP to monitor metrics.  This is an important breakthrough that allows them to manage KPIs proactively. The key here is to create a technology infrastructure management approach that avoids outages in the first place. SPs that achieve this solve endless headaches and enhance their ability to retain happy customers.

The Revolution Begins: Mobile Operators and Cell Tower Backhaul

Mobile operators made a decision that this approach is going to change.  To my knowledge the one that really drove this concept was T-Mobile.  They recognized that they were not as large as their U.S.-based competitors.  In order to effectively compete, they needed to be smarter or more efficient.  For those that don’t know this, mobile operators are huge consumers of bandwidth from the traditional landline providers.  Cell phones communicate with Cell Towers.  Cell Towers backhaul that traffic to Hub Sites.  Hub Sites connect to MSC’s (Mobile Switching Centers are responsible for routing voice calls and SMS as well as other services).  T-Mobile was the first mobile operator that I was aware of that actually created their own SLAs.  These SLAs basically stated that if you are going to provide backhaul services to our cell towers, then you are going to guarantee certain performance levels around things like one way frame delay, frame loss rate and jitter.  If you do not meet levels specified in the SLA, then there will be ‘real’ penalties associated with SLA breaches.

It’s my understanding that this approach proved to be very successful.  Since that time I have seen very similar SLA requirements come out from other mobile operators.  This has had significant impact on the backhaul providers (e.g. traditional Wireline carriers).  They’ve had to re-tool their infrastructure monitoring to give them the ability to measure these new data points, validate that these data points are meeting contractual commitments and provide an interface (or reports) to the mobile operators to prove, defend, and validate backhaul link performance.  This has caused a flurry of activity on the part of the backhaul providers.  Most have begun to actively embark upon projects to figure out how to capture, measure and present this data to mobile operators.  This has created a sizeable opportunity for companies like Monolith Software to help SPs meet these challenges, which, of course, are actually tremendous opportunities.

Bigger than Backhaul

If you are T-Mobile, AT&T, Sprint, Verizon, US Cellular, etc, then this ability to demand strict SLAs, have measurable accountability in contracts, and gain visibility into how well the SP is delivering their services is a very good thing.  But why should this just apply to Mobile Operators?  Imagine you’re a data center company with multiple locations, or a Content Delivery Network provider, an offsite data back-up company, or a large enterprise with many locations.  Why shouldn’t this same concept apply to you and your business?  The answer is, it should.  Many such companies are now issuing RFPs to SPs that specifically require SLAs with teeth and portal requirements to see how well the SP is providing those services.  Today you might be able to argue that this is a competitive differentiator.  Very shortly it will be considered a cost of doing business – a requirement if you want to even compete.

Moving to Metric-Based Service Assurance

This perspective on Service Assurance moves us well beyond traditional event management, business service management (as described in my previous blog post) or the event-based service trees that we saw years ago.  We’re now talking about how to manage the performance of a service real-time (or near real-time) and proactively.  Service Assurance and SLA management can only be realized in the world of metrics.  Metrics are values that represent some form of measurement.  Metrics are values that change over time.  Events do not play a role in determining how well a service is performing.  A NOC may receive an event when a service attribute in a SLA hierarchy is breached, but that’s about the extent of it.

Today’s Service Assurance requires you to align your thinking much more closely with what your customers are looking for. And for that, the magic is in the metrics. At Monolith, we’re in a uniquely valuable position to offer perspectives on this, given our experience in implementing metrics-based solutions in many different environments. In my next blog post in this series, I’ll take you though the key considerations required to deliver Service Assurance within your organization or to your customers.

Cheers,

Jeff

Episode 1 reveals our secret to slashing implementation time when system upgrades involve non-standard equipment. Recently we encountered this during a POC with a large client. As is often the case, our challenge was to prove how fast Monolith Software can be implemented. The client had a variety of equipment in place, and the vast majority of their equipment, we got up and running, no problem. However there was one specific vendor device that, when we tried to poll some statistics from it via SNMP, the result returned in a non-standard way. The device just choked in response to our data request. We learned that the equipment was not yet up to SNMP standard – this would’ve stopped any software update, from any vendor.

Based on our experience in this space, this kind of issue can take one, three or even six months to resolve in the typical scenario of waiting until the equipment vendor brought their device up to standard.

So how long did it take us to conquer this challenge? Monolith, because of its flexible rules-based code did it in ONE DAY.  View the video and find out how:

And by the way, One2One is not just a conversation amongst us here at Monolith. Send us your comments, topics and issues you want to see covered. One2One is even better when it’s a conversation with YOU.

Cheers,

Jeff

 Standish Findings By Year. Updated for 2009 report.

http://kinzz.com/resources/articles/91-project-failures-rise-study-shows

This is sobering news for IT managers who embark on in-house software development projects. Documentation that warns against this approach is voluminous. So, why are so many organizations still attempting these projects, and why are we discussing them?

First, it’s important to understand that three criteria must be met to set the stage for successful in-house development. These are: 1. Unique new functionality is required, 2. No Commercial Off The Shelf (COTS) solution is available at a lower cost, and 3. Belief that in-house expertise can support and maintain the solution. If all three of those criteria are not present, then an organization should avoid pursuing an in-house development project. Why are we revisiting a topic that has been discussed and researched for decades? Because we still see organizations that deploy in-house projects without all three criteria present.

Deciding on the right path begins with consideration of a fundamental principle of business.  What is the core function of your organization? Success comes to organizations that keep their focus squarely on the core business. If your organization provides a service for a fee, then the argument is that you should focus on delivering that service more predictably, with higher quality, and at a lower cost than your competitors.  If your organization can do this, your likelihood of success and of generating profit is much higher. Conversely, organizations that allow resources to be applied toward tangential pursuits compromise attainment of the core business goals. Keeping your eye on the ball then, is key to winning the game.

Let’s suppose that you’re in the business of providing connectivity, dial tone, Internet access, remote backup services or any of the other myriad services for which you can charge a monthly fee.  We all know that customers are not incredibly tolerant of disruptions of service or poor quality of service.  They are quite likely to jump to another provider if they think they can either:  a) get the same quality of service for less money from another company, or b) get equal or better quality for the same amount of money as they are currently paying your organization.

Due to this focus on minimizing customer churn, smart organizations have implemented software to manage and monitor the infrastructure gear that’s necessary to be able to deliver these services.  Historically, Telcos and SPs have been very device-centric when it comes to monitoring and managing equipment.  There’s a movement afoot to focus more on monitoring the service (think the ‘basket of technologies’ require to deliver the service) versus monitoring the individual devices.  The most appropriate terminology for this concept is Service Assurance.  This is a topic that we discuss in a number of other blog posts, so I will not elaborate on it in this post.  The question is, how do they do this?  If you break it down to the most fundamental level, organizations have a choice of building this capability themselves or buying software that already provides this functionality (e.g. COTS software).

Earlier I mentioned the risks of the in-house approach. Let’s examine this a bit further by looking at a typical scenario – I’m sure this will sound familiar to many of you.

In-house development is typically done as a side project.  A decision is made that something can be put together in a couple of weeks or a month that will fulfill a particular requirement.  Once that’s done, more functionality is added to address more needs and more requirements.  Pretty soon, instead of doing this on the side, it becomes quite consuming.

Does the software do everything needed?  Typically not.  Do other folks request new requirements for the functionality? Absolutely. Can the in-house proponents respond to these requests quickly and efficiently?  Typically not  – remember, this is a side job.  Does the in-house team have the experience and expertise to turn this software from being a point tool to an integrated system that can tie into inventory, provisioning, billing software, CRM software, etc?  Not really, but sometimes they try.

When things are good, they are really good.  When do problems start occurring? When the inevitable happens: the person who architected or wrote the code gets a better job offer elsewhere.  We see it all the time. At one of the biggest credit card companies.  A large optical backbone provider.  We’ve seen it at InterExchange carriers.  All it takes is one other company in the world to offer your guy a modicum of a raise and the company is left holding the bag.

As Service Providers place more focus on Customer Experience Management and Service Assurance they have begun to acknowledge that they don’t have the software that they need.  The question is, do you build or do you buy? We’ve observed that building is too often a short-cut to a dead-end. Buying is the only way to mitigate risk and keep your resources keenly focused on core business activities that grow your bottom line.

Build it, and you’re done. Done-in, that is. The only fast track to infrastructure management nirvana is acquiring a proven and supported software solution built from the ground-up to deliver quickly on your current needs, and grow with those in your future. And with buying, the future is yours to keep.

Cheers,

Jeff

It Wasn’t That Long Ago…

I started my professional career working for Motorola in 1990. On my desk there was no PC.  I had a 3270 terminal whose primary purpose for me was to access and utilize the MRP (Manufacturing Resource Planning) software. I also had a terminal on my desk that allowed us to perform word processing and spreadsheets. We didn’t run applications locally.  They were run off of a Unix server maintained by IT.  No one had email addresses or Internet access.  That came to Motorola in 1994 if I recall correctly.

Why am I telling you this? More than anything, to paint a little perspective. Most people take PCs, the Internet and email for granted. We forget how rapidly things have evolved.  Here’s one more thought to consider. Back in 1990 most people did not have cell phones. Those that did carried around what were called bag phones. They were about the size of a woman’s purse. That was mobile voice communications back in 1990.

Connections: Seeds of Need

It was probably the 1995 to 2000 time frame when companies started rolling out PCs to employees and building LANs (Local Area Networks). AppleTalk, LANtastic, Banyan Vines, Netware were some of the prevalent choices back then.  I really can’t recall selling monitoring or management software back in that time frame. We were all more focused on trying to figure out how to make this stuff work so our users could take advantage of the productivity-enhancing capabilities of PCs.

Once we got through ‘The Year 2000’ crisis (or as it turns out, lack of a crisis), this Internet thing really started to take off in a big way. Our networks were all interconnected. We were interconnecting our remote offices to headquarters. I was at Cisco at this time – a fun time to be there. We not only had our computer systems able to talk to our other company offices, but we were also connected to the Internet. This allowed us to communicate with other companies via email and attachments.

This is where the early drivers for monitoring and management began to take root.

Early Monitoring and Management: Reactive and Event-Focused

It was during this time frame that we really started selling monitoring and management software. Prior to 2000, IT systems were very much monitored by all of the vendor specific EMS’s (Element Management Systems). Micromuse came along with their MOM (Manager of Managers) approach and sold a boatload of software offering the promise of a Single Pane of Glass to NOCs (Network Operations Centers). Prior to 2000 this was predominantly sold to large telcos and service providers.

The MOM concept was good. Instead of having NOC operators looking from console to console to try to determine what is wrong with their networks, they can look at a ‘single pane of glass’ and thereby minimize the swivel chair effect. Make sense? Absolutely, it’s more efficient. Organizations had a better chance of identifying coincidences (early correlation) of disparate events if they are all in one screen. Life was good. A lot of Micromuse Netcool was sold. But still…organizations were highly reactive and event-focused (waiting for traps or syslogs to come into their event console).

Event + Performance Management 

In parallel to this event-based MOM movement occurring, there were other transformations taking place in the monitoring and management space. Organizations understood that it not only made sense to react to specific problems when they occur (interface down, device down, card failure, loss of signal, etc.), they also realized that it might make sense to monitor the performance utilization of these devices. Along came the performance management niche. In it you saw companies like Concord, InfoVista, Quallaby, INS, Trinagy, etc. These companies were essentially SNMP polling software companies. The software would run on a centralized server(s) and send SNMP requests to network devices asking them questions such as, what is the current utilization on this interface, what is your temperature, what is your CPU utilization, what is your memory utilization, etc. Why? Pretty straightforward. If I can identify devices or interfaces that are pegged out, then quite naturally I can take corresponding action –buy a more powerful router, procure more bandwidth for my WAN circuit, add more memory to the device. (Are we ready to talk about Service Assurance yet?  Almost.  There’s one other area I’d like to cover first…)

Availability Management Provides Needed Balance

I have covered event management. I have touched on performance management. Let me address availability management (and then we can start to talk about Service Assurance). Think about a three legged bar stool for a moment. One leg is event management. The second leg is performance management. The third leg is availability management. It’s kind of hard to stay balanced on a two-legged stool. That third leg comes in quite handy. (Yes, I know.  What about Config, security, change, inventory, topology? All good and important, but I’d argue they are ancillary to the big three that I have just mentioned when the focus of the discussion is network monitoring and management.)

Devices want to tell us when they are having problems. They speak languages like SNMP traps and Syslogs to communicate these problems. IT & Operations personnel like to try to be a bit more proactive; thereby installing performance management systems to try to identify utilization issues. But I want to know right away when something is down and not working.  A device cannot send a trap or a Syslog if it is down. A performance monitoring package (in the traditional context) cannot let me know immediately when there is a problem (is the data really missing, was a packet dropped). That is why there has been a market for availability monitoring software. When I think of representative early packages in this space I think of WhatsUp, Big Brother, HP NNM. I’m really talking about software that would ping a device to see if it would respond to the request. If it responded, then it must be up. If not, it must be down. Useful information to know. The idea went from understanding device availability to also understanding interface availability (devices can have multiple interfaces right?). Why not take it a step further?  What about letting me know if a server process is up, running and responding (think about a Unix process or a Windows service). A nifty company called SiteScope came along. They built software that would tell you if a service running on a server was up or not.  Think DNS, DHCP, HTTP, HTTPS, FTP, SMTP, IMAP, etc. This took us a step closer to understanding what purpose a server actually serves versus just doing typical device monitoring. The idea with network monitoring up to this point was to monitor all of your network devices and servers. The software didn’t really understand that certain servers or network devices were more critical than others.

Business Assurance: Aligning With Business Needs

Back in April of 2002 I first heard the term Business Assurance applied to the monitoring and management space. I worked for a company that was a big Micromuse partner at the time. Bill Cannon (with Micromuse at the time, he’s now with us at Monolith) and his crew built a sales pitch focused on helping their sales team move out of the ranks of only calling on the IT/Operations Directors. They wanted to figure out how they could align their software to the mission critical needs of the business. The term Business Assurance was utilized. The idea was to understand that all of these routers, switches, and servers don’t exist for their own merit. They exist to allow employees to utilize applications that run over networks. Somewhere a light bulb went off that said, “What if we can start to map devices to services (or applications). We could then start selling our software to business owners that need to make sure mission critical applications are working the way they are supposed to. This approach can likely lead us to getting funding in a more rapid fashion than our traditional approach of selling to IT or Ops where we are viewed as a cost center.”

And so it was done. If you view how Micromuse attacked this problem, then you can understand completely what they did, why they did it and how they did it. They didn’t own a performance monitoring company at the time. They did have their Internet Service Monitors (ISMs) that purported to do what a product like SiteScope did. Based upon the market and the inventory of tools that they had available to them they took the obvious approach. Develop integrations to the performance monitoring packages on the market to have them forward threshold violations into the Netcool Event system. Have the ISMs forward similar events in. Effectively turning everything into an event. That way Netcool Omnibus can speak its language. Once that is done we can then put a new capability on Omnibus to allow organizations to create service buckets.

This was initially done in dashboards utilizing WebTop. Since you can create your own event based dashboard. And you can turn everything into the lowest common denominator (events), then you can create a dashboard showing only the events tied to a specific sub-set of the overall devices in the infrastructure. Voila, Business Assurance. All was good and a lot of this was sold. The next instantiation of this was “how can I enhance this further?”, what if I could build a service tree whereby the branches of the tree represented specific technology assets required to allow the service to run. An example might be the WAN, the LAN, the servers running the application software. A simple, three branch tree. Now in order for the service to be considered to be running, all three branches have to be running. I could then go ahead and have an overall status indicator for the service that would show a green status of the three branches.

Enter Service Assurance

By George, I think we just moved from the concept of Business Assurance to Service Assurance. Albeit, an event-denominated service, but a service nonetheless. BTW, for those of you who go back far enough, this was called SLAM or Service Level Agreement Manager. I sold what I had believed to be the first SLAM sale in the Midwest to a large healthcare Integrated Delivery Network provider in Chicago in 2003.

Looking Forward

I’ve thrown a lot of history at you here, but the perspectives are valuable.  Understanding the migration from individual device management to business assurance to service assurance provides insights that foretell the future course.  In the next blog post in this series I’ll bring you forward to today (e.g. 2012) to talk about the next evolutionary leap in service assurance.  In other words, how the industry (enabled by Monolith Software) is moving from event-based service assurance to proactive, KPI-driven, metric-based service assurance.

Unfortunately, this does muddy the waters for our customers and prospective customers. Buyer  beware!  The imitators have only copied our marketing message, not the product’s functionality.

A friend of mine who is a technology director at a large financial company sent me the following message yesterday:

————————

Hey Jeff!

How are ya?  I’m sitting in a presentation from XxXxXxXxXxXx right now and it made me think of you…

…their opening pitch was about having a completely internal and unified code-base vs. the non-unified approach.  I swear they could have just taken some of Monolith’s stuff and did a search/replace on the company name.  : )

————————

About two and a half years ago, Monolith embarked on an exercise to try to narrow down our focus to really communicate our capability set and differentiators. We ultimately ended up with a tag line of “Simplification through Unification” and a value statement of “The First. The Only. Unified Infrastructure Management Software.”

Over the past year we have come across our competitors mimicking our pitch more and more. You can imagine our surprise when we see competitors offerings (which I know quite well from my days of selling their packages prior to starting Monolith) being touted as “unified infrastructure management” solutions.  I happen to know that their solutions are compilations of disparate code bases that are installed and configured as completely independent software packages.  Often, these “unified” solutions run on different operating systems and databases and have different user interface requirements.

Does that really sound like a unified, single code base solution?  Does it make any sense that the disparate approach is the path to operational efficiency and reduced mean time to repair?

What we have built is so incredibly obvious, straightforward and compelling. I guess that’s why everyone seems to be pitching it these days. “Caveat emptor” because ‘markitecture’ and architecture are two vastly different things.

When faced with one of these ‘markitectures’, I encourage you to compare and contrast that to our offering in detail.  We will take the time to explain, educate and differentiate our solution.  For some additional food for thought I encourage you to view the online presentation that I created discussing our single code base offering.

Cheers,

Jeff

• We made a big splash with our new booth, new marketing campaign and several news announcements at TM Forum Dublin. It was a little shocking, but a lot rewarding, to hear this question repeatedly: “Monolith – isn’t that too good to be true?”
• The unveiling of our new messaging – “The First. The Only. Unified Infrastructure Management Software.” – was well received by our audiences. And, apparently, admired by our competitors as well, several of whom adopted the Unified message in their own materials. While this claim can only be made by a solution built on a single code base (Only Monolith), we interpret this imitation as a form of flattery – confirming we’re on target with market needs and drivers.
• We were invited once again to participate in the Catalyst program at TM Forum Management World’s Forumville — a showcase of best practices for service providers. Along with IBB Consulting Group, we demonstrated new methods of assuring video service quality
• We participated in the Niche Cloud Vendor Showcase at TM Forum’s Management World Americas, where we delivered perspectives on monitoring and management of cloud services and how the unified approach to CEM promotes enhanced customer intimacy
• In partnership with Aricent®, a global innovation and technology services company, we launched a new joint solution that empowers mobile operators to deliver superior subscriber experiences
• As we continuously evolve our product, two significant new releases were unveiled: V 3.6 and V 3.6.2
• We continued to attract industry awards, including Internet Telephony’s BSS/OSS Excellence Award, Finalist in Network Products Guide’s Hot Companies and Best Products, and Finalist in Red Herring’s Top 100 North America and 100 Global Award
• Back in 2007 we were excited to receive our first piece of coverage by the media. These days we’re getting much more time in the spotlight with a dozen articles in high-profile publications such as CompterWorld, Light Reading, Pipeline, Billing & OSS World, Communications Technology, Connected Planet and Data Center Knowledge.
• Most important of all – our customer list has grown to include some exciting new clients.  Among them are:  CHR Solutions, National Institute of Health, Tele2, Equinix, Tympani, and Sovernet Communications.

Many thanks to all who recognize and embrace the powerful advantages offered by Monolith Software’s unified solution.

Cheers,

Jeff