Blog News and events about Polaris Solutions!

Azure Dev Day

by Clint Edmonson on April 03, 2018


Microsoft is working Polaris and other partners around the central US region to put together free workshops focused on App Modernization and are designed to help developers get hands-on with Azure.  These events will focus on the most popular Azure PaaS and DevOps offerings. Each technical session will be followed by a whiteboard design exercise to encourage attendees to take what they’ve learned and design solutions in Azure.

This 1-Day workshop will focus on most popular Azure PaaS and DevOps services. Each technical session will be followed by a hands-on Azure lab and a whiteboard design exercise. This workshop will help you gain a thorough understanding of the components of Azure and how you can take advantage of them as a developer.

Key Topics:

  • Understand the fundamentals of Microsoft Azure Cloud Computing platform
    • Short overview of the services provided by the Microsoft Azure cloud platform for developers
  • Build Enterprise Web, Mobile and API Apps using Azure App Services
  • Use Azure Serverless Computing to build highly scalable application and services, with a transactional cost model and without requiring any infrastructure management
  • Develop and Deploy Microservices using Azure Services Fabric and Azure Container Service
  • Make the DevOps process easier, faster, and more cost-effective with Azure



Register for the St. Louis event Today!


How do we measure?

by Joshua King on March 27, 2018


Metrics and measures are always on the agenda when I work with organizations new to agile. We're bringing in a new way for them to get work completed, so it would make sense that the old ways of measuring wouldn't necessarily make sense anymore. The unfortunate thing is that you get what you measure, so you really have to think about what you want, what do you want to achieve?


If your goal is to get more stuff out the door, velocity is a great measure, but it is extremely easy to abuse and manipulate. But, you might ask, what value is getting stuff out the door if it's not the right stuff? How do you determine if you're building the right stuff? There are a bunch of different tools available to come up with a value or relative value, Weighted Shorted Job First (WSJF) is popular because of the popularity of Scaled Agile Framework (SAFe), but it can be complicated for people just starting out. Affinity estimation is a good tool for finding relative value to determine what you should be working on.


So, theoretically, you now have a way to know what stuff is the right stuff, and determine if you're actually developing it on a predictable cadence. In order to ensure you’re not trying to go too fast, if you’re measuring velocity, you should look to something that counteracts that measure, like quality. Using a counter-measure like this helps ensure that you aren’t taking anything too far. You’re not pushing the team to deliver too much, and you’re also not pushing for gold-plated code at the expense of quantity delivered.


Once you are delivering the right things on a regular cadence, you can move on to second level problems. The first of these is to examine if you are delivering optimally. Do the metrics we have allow you to determine that? I’d argue that you don’t have that information with the information you’ve got on hand. There are a few new things you can keep an eye on in order to better understand your system. As your organization matures, you can measure the efficiency of the system by measuring flow via flow efficiency. While this is a Kanban idea, that doesn’t mean it’s not applicable outside of Kanban systems.


To get to flow efficiency you need to track two new metrics, lead time and overall work time. Lead time is the time from the customer request to the time it’s delivered to the customer. Think of this as the time from when you order the pizza to when it shows up on your doorstep. Overall work time is measured by the time working in any states. Taking the pizza analogy further, this would be from the time the store starts making your pizza until it is ready to deliver. If it takes 30 minutes from order to door, and 10 from start of making to ready to deliver, then the flow efficiency of that system is 10/30 = or 33% efficiency.


Armed with this information, you can start looking at the process to determine if there are any bottlenecks or other places where it can be streamlined and improved. Starting to look at the process of building things will allow you to increase the amount you’re delivering, and with the other metrics you’ve already been capturing, you can ensure that it’s all quality. Starting with these metrics should get you through your first year of agile development.



Streamlined infrastructure for Pharmacy PaaS

by Joshua King on March 05, 2018


The question of buy vs build is often a very difficult one. On the one hand, you get everything exactly as you want it, on the other, you have to compromise, but implementation cost and support is lower. This is the dilemma one of our clients was experiencing. They had a home-grown deployment and release tool that worked exactly as they needed when they built it, but it was starting to show some signs that it was in need of an overhaul. The current architecture wouldn’t support some of the newer features that were in industry-leading products, and they were spending a lot of time supporting and maintaining it instead of building new features to move them forward. In addition, their aging infrastructure was pushing them to evaluate if their solution would support cloud deployments. It was time to re-evaluate the situation and determine if it made sense to continue with their solution.


The existing platform was managing the build and deployment of their Platform as a Service (PaaS) to over 80,000 individual physical nodes, each one potentially having its own configuration. The configuration being unmanaged and uncontrolled made it nearly impossible to support and troubleshoot all of the possible issues. Our expert in DevOps looked at their problems, what they were trying to achieve, and created a proof of concept (POC) for them to try out. The POC involved using Azure to manage the build and deployment process that would span the cloud and on-premise nodes, but it would also allow them to build and deploy configurations. He created release process templates and run books to allow easier management of the process and provide a graphical representation of what was happening. The deployment tool would periodically audit the environments for compliance with the configuration templates and fix the problems it discovered without user intervention. If they wanted to change the configurations, they only needed to update the template and it would blast it out to all of the subscribed nodes nearly instantly.


The Azure deployment system would allow them to manage not just the potential cloud environment, but it would also allow them to better manage their existing infrastructure as they started the transition. They could immediately start building their standard configuration and deploy that to the entire environment, giving them a base with which to start for support. Configuration management was vastly simplified and compliance could be all but guaranteed. An as of yet untapped benefit is that this will enable them to migrate to a cloud environment that can be scaled based on actual need, not worst case scenario. They can now choose based on actual computing need rather than having to buy the biggest server they think they’ll need, leaving lots of unused potential untapped and driving up the cost of implementation.


95% Reduction in Deployment Costs with Octopus

by Joshua King on January 08, 2018


A national airport offsite parking company was outgrowing their build and deploy process. Deploying software to each location manually was proving costly and time consuming. Each deployment was taking over 40 hours to configure and deploy, followed by 20+ hours of follow-on work. They needed a new solution that would supplant the capabilities of their existing solution as well as scale with the expected growth of the organization, while still providing detailed information about the success or failure of deployments to every location.


Polaris Solutions worked with key stakeholders to identify the problem, determine the capabilities required from the build and deploy tooling as well as the reporting granularity that was necessary. Based on the familiarity and robustness of the existing build tool, it was decided that this tool would continue to work, with a few configuration changes and enhancements. The deployment tool was replaced with Octopus, an industry leading automation platform that provided the deployment metrics, granularity of control, multi-tenant abilities, and scalability that was needed. The new solution greatly reduced the time and cost of each deployment while increasing the success rate of all builds and deployments.


With the implementation of Octopus to manage deployments, the organization saved an estimated 85% annually on deployments, and as much as 80% on configuration and maintenance of the deployment process. Configuration time required by the teams to perform a deployment decreased by over 95%, and drove more consistency in implementations. Configuration of each new facility for deployments reduced by over 90%, an estimated annual savings of nearly $80,000 per facility generating an ROI of 530%. Instead of taking days to deploy code, or implement a new facility, this new process takes minutes, allowing them to deploy more often and stand up new facilities more quickly.


1,2,3…NOT IT!

by Joshua King on December 18, 2017

"If only the team would take ownership, we wouldn’t be in this mess. I need someone to be accountable for this project!"

As a leader, how many times have you thought about the idea of accountability, and wished your team would take accountability for things? How many times have you thought about the issues you have and wondered why you’re not getting the engagement you want? Have you ever googled “getting people to be accountable”?

Odds are good if you’ve asked any of these questions, you’re the only one (or few) that’s owning things. It’s also likely that you’re sick of being the only one to do so. It’s equally likely that you don’t realize the reason people aren’t taking ownership is because of how you and other leaders act.

The unfortunate truth is that you cannot ‘make’ someone take accountability for something. You can cajole. You can incent. You can even make their bonus contingent upon it, but at that point, what are you trying to achieve?

You need to ask yourself, “how have I created a culture where people don’t want to own things or be accountable?”, “how have I acted when people took accountability and things weren’t perfect?”. It is possible that there are a couple of people that don’t innately take ownership of things, but to have a whole team, or  organization perform like that points to a bigger issue, an issue within the system, the system being the organization and culture.

So how do I get more engagement? How do I get my team to want to take accountability? The first step is realizing that the team’s lack of engagement falls squarely on the shoulders of the leadership and the culture that you’re creating. Think about the last time you had someone from the team take on something and decide to own it. If it didn’t go well, how did you act in that moment? Did you assign blame? Did you seek to understand and move forward? Was punishment on your mind? This moment, this tiny space is your opportunity to create, or crush, accountability within your organization. If you touch the stove and burn yourself, you’re not going to be as likely to touch that stove again in the future, this is the same kind of situation! You need to reward the behavior you want, and discourage what you don’t. If your default mode when things go wrong is to look for someone to blame or punish, you’re encouraging the kind of behavior that leads to no one taking accountability.

So next time things don’t go exactly as planned, take that opportunity to approach the situation with curiosity, understand everyone is doing their best with what they have, and coach the person/team on how things could have gone better. Most of the time, you can’t be any harder on people than they already are on themselves, so help them move forward and be more successful next time. This kind of behavior will encourage people to take ownership, take risks, be innovative, and help push your organization forward.