Nine months before the start of the pandemic I was hospitalized for rhabdomyolysis, a serious medical issue caused by muscle tissue breakdown that impacts kidney function. Since my hospitalization, I have been trying to find ways to recover but recovery may take years due to the extent of muscle and organ damage. Without knowing the root cause of my rhabdomyolysis, I sheltered in place with my family when the pandemic started. Staying at home meant that my recovery process was left up to me and I uncovered a beautiful analogy between solving my own pain and helping organizations solve their own.

I came to discover that there were pain points in my muscles that I injured over 10 years ago. It was only after the last two months I realized I had been working my pain points all wrong. I was focused on the most painful trouble spots and never worked on the small connecting trouble spots. I also realized that this is exactly what happens to organizations. If you want to resolve the big pain points for good, you need to solve the small ones first.

As an organization goes through periods of stress, growth, or hardship many small pain points are created in the organization. These small pain points are often masked by much larger and seemingly more important ones. Perhaps the larger problem here is that people tend to spend their time concentrating on solving the biggest issue first. Think of how many times your manager focused on fixing the “loudest” problem only to find out later that the problem was made into the “loudest” problem by multiple smaller problems contributing to it.

So, how do you figure out what is connected?

First realize that asking will not work most of the time. If you were to ask me where my muscle pain was from I would without a doubt point to the most painful area, not knowing that there were four other small areas making it worse. The only way I could find out is by pressing on the trouble spot and methodically working to see which ones are connected to the pain. Once the first spot is found, remember to keep looking because there are going to be more.

How do you inspire your team to look past the big pain points?

Set small achievable goals that reward quick wins and small improvements. Having numerous more frequent achievements will seem tangible and also help to improve job satisfaction. Also, let them know that the focus is not the biggest trouble spot because fixing the smaller trouble spots will make the bigger ones easier to fix.

What are some ways to avoid problem spots in the future?

The Cloud Native movement as a whole is designed to continuously identify and work to fix problems for all organizations. It is important to note that a Cloud Native transformation requires all areas of the organization to change, not just the technical teams. This is especially true for Accounting and Finance departments re-thinking how they do financial projections and tie business value to cloud costs, but perhaps that is a separate blog. So, let us touch on a few specific concepts.

Agile & Scrum - While Agile & Scrum are two different methods, teams can interweave practices of each with current organization’s operations. Adopting these concepts, even in part, helps to create an iterative process that helps to identify and treat pain points as they happen. Concepts of Agile & Scrum can be incorporated into all types of teams regardless of what technologies are being used. It is important to note that practicing the textbook applications of Agile and Scrum is beneficial for learning purposes, however in practice it is typical for only some concepts to be adopted.

Continuous Integration / Continuous Deployment (CICD) - CICD together is a Cloud Native concept that can be incorporated into organizations with Cloud Native architectures. The two concepts together create a framework that finds and helps prevent pain points.

Microservice Architecture - Managing applications broken up into loosely coupled services or microservice frameworks helps make pain points smaller and easier to identify and fix. Getting monolithic applications refactored into microservice architecture will take effort and it may not be a good fit for your application or your team’s skill set There is also a vast ecosystem of Cloud Native tooling and content that enables microservice architecture it can be intimidating on first investigation.

Important Note: Adopting these and other Cloud Native practices do not fix pain points, cultural issues, or personnel issues. These practices give organizations tools that help resolve pain points more easily. Always remember forcing change without input often reduces job satisfaction and therefore productivity. High job satisfaction will increase productivity.

The post Resolving Organizational Pain – Fix Small Pain Points First appeared first on Stark & Wayne.

Cloud Native Transformations have been on the rise over the past decade but many of them get off to a rocky start or fail. We have consulted with scores of organizations who have taken on the Cloud Native journey. This article outlines some consistent themes that most of these organizations faced.

There are usually two forms of drivers for the transformation effort, a top down and a bottom up driver. Top down is where an executive, vice president, or board of directors mandates a plan to go cloud native. Bottom up is where individual engineers, a team of engineers, or teams of engineers decided to go Cloud Native without executive buy in.

Common motivations for the top down

• Cost save (Example: only pay for what you use in the cloud instead of buying more datacenter than what you need )
• Avoiding vendor lock in
• Reduced time to market
• Improved market responsiveness

Common motivations behind bottom up

• Flexibility
• Passion
• Learning
• Improved working environment
• More frequent feelings of accomplishment

Common reasons why Cloud Native is rejected top down

• There is too much technical debt to transform
• Transforming will delay current goals
• Misconception of not being able to use existing datacenter or existing hardware
• Lack of knowledge on how to manage Cloud Native company or what metrics to look at
• Fear of the current talent’s inability to adopt Cloud Native Practices
• Fear of increased employee costs once they have “Cloud Native” on their resume

Common reasons why Cloud Native is rejected bottom up

• Resistance to learning new technologies
• Lack of desire for change or “I just want to do my job and go home”
• We will need less people if we go Cloud Native
• I am overworked already, doing this will be unbearable
• Our current solutions work just fine

But wait? What is Cloud Native? Oddly enough every person I have asked has a different definition of what Cloud Native is. So let us unpack that before we continue

Cloud Native is a practice, an ecosystem, and a set of standards. The reason why the definition of Cloud Native varies from person to person is simple, because it can. The best way to think about it is going Cloud Native means your organization is adopting as much of the Cloud Native best practices as makes reasonable business sense.

I’ll give a hypothetical example a financial institution who considers themselves to be “Cloud Native” has more than 40% of their business logic applications on mainframe or legacy frameworks. Why does this organization consider themselves cloud native? Well, because 90% of their front end customer facing applications adhere to most of the Cloud Native best practices. For this organization that is the mix that makes the most reasonable business sense.

This is a common practice with Cloud Native transformations. The front end customer facing or revenue generating applications go Cloud Native first in order to take advantage of improved time to market, market responsiveness, enhanced security, and uptime.

So back to why the corporate mandate fails

• The misunderstanding of what Cloud Native means to their organization
  • In some cases where the engineering team is resistant to change, it may be better for the executives to avoid saying “Cloud Native Transformation. Executives instead can look at what aspects of Cloud Native are going to be the most advantageous for their organization and align company goals and milestones to gradually bring them to these goals. It is better to gain one or two sustainable advantages of Cloud Native.
  • What to avoid? Instead of statements like “Everything on Azure by Q4” ask instead what applications are well suited to move to the cloud then “These applications on azure by Q4”

• Neglecting the culture change
  • A company cannot go cloud native unless they make some changes to culture. This often has to do with the way things are approved, deployed, tracked, and how work is shared. Most Cloud Native companies adhere to agile and scrum practices but what they do not tell you is that these practices need to be modified to fit the business needs and evolve over time. It is good to start out by practicing textbook agile practices in the beginning, but after the concepts and practices are understood they must be adapted in a way that the organization can sustain them.

• Lack of employee endorsement
  • People who feel excluded from the decision process and who feel they are being forced to change will often resist. The more employees inside of an organization that feel this way the easier it will be for them to procrastinate the transformation effort. Allowing employees to express their ideas, beliefs, and concerns before goals are set

• The cost
  • What it takes in time, resources, and money is often underestimated. The more people involved and the more processes that exist currently the more costly it will be to perform a transformation.

• Cloud Native Transformation is limited to technical teams
  • Other parties including finance, accounting, human resources, and operations will have changes in their processes due to a Cloud Native Transformation.
  • One Common pitfall on the financial side is budgets. There is a general lack of knowledge on the real impact Cloud Native will have on budgets. An example being consumption of IaaS vs fixed cost amortization of physical hardware.

Cloud native is not an intangible set of standards to be strictly followed but a choose your own adventure story that lets you find the standards that best serve your business needs. But just as any company wide effort there needs to be agreement from bottom up to top down. A great place to start is with small attainable milestones that will enable sustainable Cloud Native practices. These small milestones once achieved will help gather top down and bottom up for bigger future moves.

The post The Corporate Cloud Native Mandate and why it Fails appeared first on Stark & Wayne.

The keynotes, talks, user stories, and technical sessions at Cloud Foundry Summit this year prove that Cloud Foundry is still THE platform for developers. Kubernetes continues to be the best platform for building platforms. Eirini brings these two powerful ecosystems together.

As contributors to both the Cloud Foundry and Kubernetes ecosystems, Stark & Wayne is excited about merging these two universes together and continuing to create software that supports both. At Cloud Foundry Summit, we showcased our newest software and open source tooling that contributes to a healthy ecosystem.

Roughly 60% of the attendees were new faces. This year's Summit saw more technical, engineering, and operator attendees, and fewer sales and marketing representatives – a clear reaffirmation of the Cloud Foundry Foundation's commitment to its technical roots.

Click here to view our record presentations from the conferences.

The post Cloud Foundry Summit NA 2019 appeared first on Stark & Wayne.