Contact Us
Partner Portal
Help Desk

Motio’s Cloud Experience

Motio's Cloud Experience

What Your Company Can Learn From Motio’s Cloud Experience 

If your company is like Motio, you already have some data or applications in the cloud.  Motio moved its first application to the cloud around 2008.  Since that time, we’d added additional applications as well as data storage to the cloud.  We’re not the size of Microsoft, Apple, or Google (yet) but we think that our experience with the cloud is typical of many companies.  Let’s just say that if you are a company who can buy your own cloud, you may not need this article.

Finding the Balance

Just like knowing when to buy or when to sell in the stock market, it’s important to know when to migrate to the cloud.  Motio moved its first applications to the cloud around 2008.  We migrated several key applications and the motivation differed slightly for each. You may find, as we did, that the decision often depends on where you want to draw the line of responsibility and control between yourself and your cloud vendor.

Technology Stack

Accounting

The key motivator for migrating to the cloud with our accounting software was cost.  It was less expensive to use Software-as-a-Service instead of buying the physical CDs to install.   Online storage, backups, and security came along for no additional charge.  It was also more convenient to have the software managed and always updated to the latest version.  

 

As a bonus, instead of emailing or physically mailing we could easily share reports with our offsite accountant.

Email

In addition to our accounting software, we also migrated corporate email services to the cloud.  Again cost was a contributing factor,  but the formula was more complex.  G Suite

 

At the time, we maintained a physical Exchange server in a climate controlled server room.    Costs included air conditioning, power and backup power systems.  We managed the network,  storage, server, operating system, active directory and exchange server software.  In short, our internal staff needed to carve out time from their main functions and core competencies to manage the full stack.  In moving to Google enterprise email we were able to outsource hardware, software, security, networking, maintenance and upgrades.  

 

Bottom line: significant cost savings in hardware, maintaining the physical space, power, as well as, the time dedicated by internal staff for software maintenance and identity management.  Our analysis at that time – and historically since – was that it made more sense to “rent” than to buy.

 

If you don’t have a massive dedicated IT team, your experience may be similar.

Source Code

As you can see, each service is a stack:  accounting, email, and in this case, source code repository.  Because we are a software development company, we maintain a secure repository of code which we share between developers.  We decided to draw the line between Source Code internal and external in a different place than the other two applications; with “internal” being what we are responsible for as a company, and “external” being what our vendors are responsible for.  

 

In this case, we decided to move only the hardware to the cloud.  Our key deciding factor was control.  We have the in-house expertise to maintain the software for the repository.  We manage the access and security.  We manage our own backups and disaster recovery.  We manage everything except the infrastructure.  Amazon provides us with temperature controlled, redundant, reliable power, virtual hardware with guaranteed uptime.  That’s Infrastructure-as-a-Service (IaaS).

 

Besides our people, the thing we value most within our organization is our digital assets.  Because these ethereal assets are so important, you might make a case for calling us paranoid.  Or, maybe it’s just being conservative and super careful.  In either case, we try to do what we do well and stay within our competencies and pay someone else to do what they do well – that is, maintain the infrastructure.  Because these assets are so valuable to us, we trust only ourselves to manage them.  

Software in the Cloud

Because the main business Motio is in is developing software, we also need to decide when to invest in the development effort to move our software applications to the cloud.  Perhaps obviously, this is market driven. Software In The Cloud If our customers need Motio software in the cloud, then that’s a pretty good reason.  The key driving force for MotioCI Air was the need for a lower cost alternative to the full-featured MotioCI software.  In other words, the entry point is lower for the Software-as-a-Service (SaaS), but the feature set was limited.  This is perfect for smaller organizations who do not have the infrastructure or the in-house expertise to maintain MotioCI on an internal server.  

 

MotioCI Air is positioned as a little brother to the full MotioCI application.  It can be provisioned quickly, making it perfect for POCs or short-term projects.  Importantly, it can be perfect for organizations that do not have a dedicated IT team.  Similar to our discussion on source code above, one compromise you make is in control.  With any Software-as-a-Service you rely on the vendor for access to the underbelly if that is ever necessary.  In Motio’s case, we use Amazon cloud to provide the infrastructure on which we serve up the software.  So, the SLAs are dependent on the weakest link. Amazon provides a religion-level SLA  to maintain monthly uptime of at least 99.99%.  This works out to about 4½ minutes of unscheduled downtime.  MotioCI Air’s availability is therefore dependent on Amazon’s uptime. 

 

Another factor we had to consider in moving MotioCI to the cloud was performance.  Performance doesn’t come cheaply.  Beyond the efficient code itself, performance depends both on the infrastructure and the pipe.  Amazon, or the cloud vendor, can always throw additional virtual CPUs at the application, but there is a point where performance is limited by the network itself and the connection between the client’s physical location and the cloud.  Using cloud services we were able to design and offer a cost effective, performant solution.

Takeaways 

You may not be in the software development industry, but it’s likely that you will face many of the same decisions.  When should we move to the cloud?  Which services can we take advantage of in the cloud?  What is important and what control are we willing to give up?  Less control means that your cloud vendor will manage more of the hardware and software as a service.  Typically, with this arrangement, there will be fewer customizations, add-ons, less direct access to the file system or logs. Control Room If you’re just using an application – like our accounting software in the cloud – you may not need this low-level access.  If you’re developing an application to run in the cloud you will want access to as much as you can get your hands on.  There are infinite use cases in between.  It’s about which buttons you want to push yourself.     

  

Of course, maintaining total control of your IT infrastructure is always an option, but it’s going to be expensive to keep it all in house.  If money is no object, or to put it another way, if you value the total control more than what it will cost to set up, install, configure, maintain, software, hardware, network, physical space, power and keep it all updated, then you may want to set up your own private cloud and manage it in-house.  At its simplest, a private cloud is, essentially, a data center in a controlled environment for sensitive data.  On the other side of the equation, though, is the fact that it’s hard to remain competitive if you are managing things outside of your key competencies.  Concentrate on your business and do what you do best.  

 

In effect, it’s the old question of should I buy, or should I rent?  If you have the money for the capital outlay, the time and the expertise to manage it, it is often better to buy.  If, on the other hand, you’d rather spend your time running your business and making money, it might make more sense to outsource the hardware and services to your cloud vendor.

 

If you’re like Motio, you may decide that it makes the most sense to have some combination of the above by maintaining control where you need it and by leveraging cloud infrastructure and services where they can add the most value.  We’ve also learned that moving to the cloud is less of an event and more of a journey.  We recognize that we’re only part of the way there.

Ready to streamline and automate your BI & analytics platforms?
Get A Demo
White Motio Logo Image
Solutions
Products
About Us
Resources
Contact
  • Tel:1 (972) 447-9595
  • Toll Free:1 (833) 855-3073
Follow Us
Youtube Linkedin Twitter
© 2024 Motio. All rights reserved
Scroll to Top
As the BI space evolves, organizations must take into account the bottom line of amassing analytics assets.
The more assets you have, the greater the cost to your business. There are the hard costs of keeping redundant assets, i.e., cloud or server capacity. Accumulating multiple versions of the same visualization not only takes up space, but BI vendors are moving to capacity pricing. Companies now pay more if you have more dashboards, apps, and reports. Earlier, we spoke about dependencies. Keeping redundant assets increases the number of dependencies and therefore the complexity. This comes with a price tag.
The implications of asset failures differ, and the business’s repercussions can be minimal or drastic.
Different industries have distinct regulatory requirements to meet. The impact may be minimal if a report for an end-of-year close has a mislabeled column that the sales or marketing department uses, On the other hand, if a healthcare or financial report does not meet the needs of a HIPPA or SOX compliance report, the company and its C-level suite may face severe penalties and reputational damage. Another example is a report that is shared externally. During an update of the report specs, the low-level security was incorrectly applied, which caused people to have access to personal information.
The complexity of assets influences their likelihood of encountering issues.
The last thing a business wants is for a report or app to fail at a crucial moment. If you know the report is complex and has a lot of dependencies, then the probability of failure caused by IT changes is high. That means a change request should be taken into account. Dependency graphs become important. If it is a straightforward sales report that tells notes by salesperson by account, any changes made do not have the same impact on the report, even if it fails. BI operations should treat these reports differently during change.
Not all reports and dashboards fail the same; some reports may lag, definitions might change, or data accuracy and relevance could wane. Understanding these variations aids in better risk anticipation.

Marketing uses several reports for its campaigns – standard analytic assets often delivered through marketing tools. Finance has very complex reports converted from Excel to BI tools while incorporating different consolidation rules. The marketing reports have a different failure mode than the financial reports. They, therefore, need to be managed differently.

It’s time for the company’s monthly business review. The marketing department proceeds to report on leads acquired per salesperson. Unfortunately, half the team has left the organization, and the data fails to load accurately. While this is an inconvenience for the marketing group, it isn’t detrimental to the business. However, a failure in financial reporting for a human resource consulting firm with 1000s contractors that contains critical and complex calculations about sickness, fees, hours, etc, has major implications and needs to be managed differently.

Acknowledging that assets transition through distinct phases allows for effective management decisions at each stage. As new visualizations are released, the information leads to broad use and adoption.
Think back to the start of the pandemic. COVID dashboards were quickly put together and released to the business, showing pertinent information: how the virus spreads, demographics affected the business and risks, etc. At the time, it was relevant and served its purpose. As we moved past the pandemic, COVID-specific information became obsolete, and reporting is integrated into regular HR reporting.
Reports and dashboards are crafted to deliver valuable insights for stakeholders. Over time, though, the worth of assets changes.
When a company opens its first store in a certain area, there are many elements it needs to understand – other stores in the area, traffic patterns, pricing of products, what products to sell, etc. Once the store is operational for some time, specifics are not as important, and it can adopt the standard reporting. The tailor-made analytic assets become irrelevant and no longer add value to the store manager.