Mark'd up

Migration to cloud is a continuously unfolding journey. I compare it to a marathon, not a sprint. By now, most enterprises have at least one public and one private cloud and are beginning to realize the many benefits of cloud computing: operational efficiencies, cost savings, agility and improved productivity. Not surprisingly, they’re hungry for more.

We are now at a crucial turning point. A decade after cloud adoption began, 80% of enterprise workloads are yet to be migrated – many mission-critical, security-dependent workloads are still to come. The real enterprise value of cloud has yet to be realized.

To accelerate and simplify application modernization, companies are evolving toward a hybrid, multicloud approach that uses a mix of public and private across a multitude of cloud platforms and vendors. It’s definitely complex, but also full of promise.

It could take another decade or more for enterprise workloads to be fully migrated to cloud. That’s the reality. As you continue the journey, how can you ensure effective, efficient communication across a complex multicloud environment – and what are the best practices and strategies that can take you from complexity to simplicity?

First, let’s define hybrid cloud, multicloud and hybrid multicloud

Hybrid cloud: Hybrid cloud is a mix of public and on-prem private cloud that is orchestrated to run a single task. An “encrypted highway” enables data sharing of mission-critical data between two on-prem and public cloud using standardized interfaces. This allows organizations to deploy secure and mission-critical workloads on-prem, while using public cloud for new workloads, and to build and test new applications.

Multicloud: Wikipedia defines multicloud as “the use of multiple cloud computing and storage services in a single heterogeneous architecture.” Unlike hybrid cloud, a multicloud environment always uses more than one public cloud. I like to differentiate between multiple clouds and multicloud.  The first is what too many have – islands of cloud technology, with no clear strategy or governance that determines which cloud, for which workload, or why.

True multicloud is the thoughtful use of cloud resources so that systems work together in a way that maximizes value, minimizes cost, and is managed proactively. 70% of enterprises claim they will be implementing a formal multicloud strategy by the end of 2019.  Why? Organizations choose public cloud to avoid vendor lock-in while gaining access to the best features and latest functionality offered by public cloud providers such as Amazon Web Services (AWS), IBM, Microsoft Azure, etc.

Hybrid Multicloud: Fuelled by open source technology with its built-in data portability and interoperability, hybrid multicloud lets customers fully leverage the data services in the cloud: containers, VMware, public cloud, private cloud, services, etc. The ability to connect public cloud to on prem or move workloads to a different public cloud lets you quickly realize the benefits of “build once, deploy anywhere.”

The situation today is a little like the islands of automation that were created in the early 1980s when minicomputers were introduced. One department would buy Digital, another HP and a third one IBM. Each had its own separate network protocols and ways to communicate. When personal computers (PCs) were added, they didn’t communicate with any of them at first. While it was possible to build connections between them, it was always easier if the connections were considered upfront.

So, how do you go about realizing ‘build once, deploy anywhere’ simplicity – and avoid the complexity and islands of disparate systems? 

Solving for complexity and cost in a multicloud world

Regardless of which cloud environment you adopt, success lies in being able to holistically manage your cloud resources as if they were in one location. That’s one of the main challenges that IT organizations are facing today. The ongoing maturation of cloud computing platforms — as well as the constant movement of both workloads and data — means complexity is virtually guaranteed.

I believe this is the reality you must manage and plan for. Trying to manage resources in one cloud without considering the rest of the environment will result in wasted capacity and budget. It is estimated that business is wasting millions on unused cloud services.

What’s needed to achieve business goals is deep visibility and insight into your hybrid, multicloud environment. We need to solve the complexity problem now, before it morphs into operational failures.

Tools can help (but there is no magic solution)

Before cloud, if a problem developed, standardized escalation procedures were followed, either on site or at an outsourced data centre. Businesses had full control of the service levels they set. It is more complex in the world of multicloud. Each of the cloud providers – whether IaaS, PaaS or SaaS – have different benefits, service levels, reporting processes and escalation responses. The benefit of standardization of the service is lower cost for you, but the flip side is you must fit their model, not the other way around. So, your team needs to know: which cloud, and which container? Is the restart automated (yet)? Is it a router issue in your network, or with the cloud provider, or with an application inside the cloud?

You can see how difficult it is stay on top of an effective management function internally. As our clients go deeper into this multicloud world, they see the need for a management layer – “cloud ops” – that provides consistency and cost control in operations. Tools like Multicloud Manager and services like IBM “AppOps as a Service” tie everything together into an integrated operations centre (SOC) and help clients use the various cloud providers to maximum benefit. It acts as a level 1.5 help desk and manages the operations and escalation process so that IT – and business – have a common view of all clouds.

Although the strategic use of tools and engaging a trusted third-party services provider can help you manage this environment, there is no magic tool; indeed, too many tools can make a complex cloud environment even more difficult to manage.

To optimize cloud use, start with planning

As you migrate more workloads to the cloud, you must decide which workload should go on which cloud and how to track usage. Here are the first few steps that will provide you with the key metrics needed to make informed decisions.

1. Develop a clear strategy for your workloads. Think through which of your workloads fit best in which cloud: public, private, hybrid or multicloud. Which workloads are more data intensive, which more compute intensive? Which are more static, which will scale more? Which cloud providers offer the right mix of cloud services? Are you using the specific features of your IaaS / PaaS providers, or are you keeping your applications open? That’s first.
2. Know your costs. Build an economic model and business case to track the ROI on cloud adoption and workload move. Track what you are spending – is it what you expected, or more? Are you managing costs associated with moving workloads to the cloud?
3. Define your key governance metrics. What do you want to track? Availability, response time, and cost are obvious. What about time to create new environments, respond to new requests, or the ease of managing incidents? Are you tracking against the service levels the vendor committed to, or against your own corporate targets?
4. Refine regularly. The cloud is constantly evolving. You will need to think about how to respond to new capabilities and monitor which suppliers are exceeding your expectations. That can help you choose where new workloads go and whether it’s time to move existing ones. When you are confident that you can move a workload from one cloud to another seamlessly, then you’ve achieved true multicloud management.

 

Unlock new value – without lock-in

In the minicomputer era, the islands of technology gradually became better integrated as standards emerged: TCP/IP as the network protocol replaced proprietary solutions; Unix variants replaced different server operating systems, and so on. In the new cloud era, while open standards like Linux and Kubernetes exist, there are also customizations that can turn into the kind of lock-in that dominated the previous era. The question always needs to be, is the lock-in worth the value?

We can all agree that moving mission-critical enterprise workloads onto the cloud will unlock new value for your business. But how? By developing a strategy and an economic model, you can make the informed decisions that will optimize your workloads in a multicloud architecture. From there, decide on the tools (or services) that will help you achieve your objectives.

Only then will you know the changes you’ll needed in how you run your IT shop. But that’s a topic for my next blog. Stay tuned!

 

Read the blog Hybrid Cloud vs Multi-Cloud: What’s the Difference?

Read A Field Guide to Multicloud Management

Read The State of the Cloud Report

 30-Sep-2019

When cloud computing went mainstream a decade ago, early adopters quickly realized business value by migrating “easy” workloads to cloud and adopting a cloud-first strategy for new systems. Fast forward to today, when the top IT priority is to modernize existing, mission-critical applications on hybrid cloud for better business agility and faster access to data insights. To fuel that effort, cloud spending is growing at six times the rate of overall IT spending.

Yet, surprisingly, only about 20% of enterprise workloads have migrated to the cloud so far. What is slowing down the remaining 80% of workload migration? What are the obstacles on the migration path? And what steps can organizations take to realize the agility, innovation and digital transformation that is only possible on the cloud?

Why migration to cloud is a multi-year journey

Let’s look at some of the major obstacles to enterprise cloud migration.

• Organizations often encounter unexpected and discouraging costs and complexity, even during routine lift and shift migrations.
• Developing new apps across multiple vendors and clouds, each with their own propriety tools and management systems, has led to challenges in terms of security, compliance and governance.
• The larger the organization, the older the application suite. According to IDC[1] 47% of existing applications in Canada are more than five years old, which means they were probably not built with containers or microservices in mind. Migrating these legacy applications can be painstakingly slow because they first must be evaluated based on suitability, cost and feasibility.

All of this is going on while enterprises continue to make significant investments in traditional IT.

The reality is, for all but the newest companies, migration will be an incremental, multi-year journey. You won’t get there in one step. Modernized cloud native and legacy apps will coexist for the next 10-plus years, with business and IT value realized as each step is taken as part of a comprehensive digital transformation strategy.

Migration to cloud is a marathon, not a sprint. The question is, how can you accelerate and simplify that journey?

First, why migrate (and why not)?

Why migrate? Don’t move to the cloud because everyone else is, or you believe it could “automagically” save on infrastructure costs. However, if cloud is part of an overall change in how IT operates – creating more flexibility, agility, and the ability to respond quickly to changing business circumstances – you are on the right track.

Many organizations begin their migration efforts by rehosting an easy workload, but the highest value applications are in the functional areas where you want the most innovation and are the most amenable to change, such as client facing or internal business systems – or both.

Remember, not every application is a candidate for migration. Consider:

• Large, stable, existing applications are probably a lower priority, until or unless you need to refresh hardware or the underlying infrastructure.
• Security issues. Today’s hybrid, multi-cloud reality has IT leaders wrestling with how to move and manage workloads and apps between clouds efficiently without creating security risks. Sometimes this is more fear than reality, but in some cases, private cloud is the answer.
• The impact of network performance on the migrated application. If the application is not designed as cloud native, consider network latency (lag) when you’re designing the system. If you are not located in a larger metropolitan area, complex tasks may take long to be received or processed. Applications that use overlapping data probably should be moved together.

 

Know your technical debt
One of the major challenges in moving to cloud is dealing with your organization’s ‘technical debt.’ If you’ve ever put off a project with the intent to finish it later, you have incurred technical debt.  If you are behind on software versions, you have technical debt. And if you took short-cuts like hard-coding variables to get code to work ‘for now’; you definitely have technical debt!

Today, many enterprise workloads are drowning in technical debt. Migrating or refactoring workloads and applications to the cloud is probably the best way to pay off that technical debt – while improving flexibility and agility. Understanding software currency, release levels and requirements for underlying middleware, database and operating system are crucial before you begin.

Lift and shift, refactor or modernization?

Business growth in a digital world requires innovation and the ability to leverage data for competitive advantage. Cloud makes that possible by removing infrastructure costs and transforming enterprise processes. There are several approaches to take:

• Replace: When considering the “build vs purchase” question, decide if you really need to build a proprietary, cloud-based solution – for things like CRM or ERP — or if you can leverage a “born on the cloud” packaged solution? (If a package does most of what you want, why re-invent the wheel?)
• Rehost – Lift and Shift: This is the easiest way to migrate to the cloud. Recently developed applications are often “cloud ready” and can be easily moved to the cloud using a container or virtual machine with no modifications required.
• Refactor: Refactoring (or redeveloping) an existing application to take advantage of cloud-native functionality can make it more efficient, scalable, maintainable or reusable. Or you can make minimal changes by removing some dependencies on mainframe while avoiding the cost of completely rewriting the program.
• Rebuild – Application modernization using microservices: Leverage microservices and containers to build a cloud solution based on an existing application.

The American Airlines modernization story

The reality is, you will use all of these techniques, depending on your application mix and how you intend to use them going forward.

Take American Airlines, who used this combined approach to save money and improve customer service. Most of us have endured a flight cancellation due to weather events. IBM helped American Airlines build a mobile Dynamic Rebooking app on the IBM Cloud to vastly improve the customer experience. Behind the scenes in parallel, using the agile, product-focused Garage method, American Airlines migrated core VMware applications from its legacy environment to IBM IaaS in just four months. The result? Major capital cost savings while ensuring secure integration with back-end systems.

This is a great example of a large enterprise leveraging cloud to digitally transform their business quickly, through a mix of cloud-native innovation development, lift-and-shift migration and modernization of important business functions with microservices.

How to evaluate application readiness

To determine the complexity of moving legacy applications to cloud, ask questions such as:

1. Is it mission critical?
2. How complex and time-consuming will the move to cloud be?
3. What is the value generated to the business by being able to scale the application? The greater the need to scale, the higher the migration priority.
4. How frequently are you changing or innovating in this business area? The greater the innovation required, the more value there is in moving to cloud.
5. How secure is the data and where should that data reside? If your application is linked to other high priority applications, it is advisable to move it as a bundle.

Determining migration priorities

IBM doesn’t use a one-size-fits-all approach to cloud migration. With a focus on enterprise innovation, data privacy, security, and your specific business priorities, IBM uses a matrix that evaluates complexity, time to value and frequency of updates to create a cost-benefit analysis showing which applications should move to cloud first, be retired, or kept on traditional IT (for now).

The evaluation of migration priorities is stored in a database that can be queried, revisited and revised on a regular basis. As the centre of “data gravity” shifts in your environment, priorities will also shift, so data and database dependencies are identified to ensure that all complimentary tools/datasets are migrated to the same cloud to optimize integration.

 

Take the next step in the journey 

One of the main reasons that companies accrue technical debt is that their IT departments are already overwhelmed with everyday tasks. An experienced cloud migration partner can accelerate your switch to cloud and help you avoid costly mistakes along the way.

If your company’s application portfolio is more than five years old, not built for the cloud, nor optimized for containers, yet digital transformation is your top priority, it’s time to think about taking the next step in the multi-year journey of migration to the cloud – and the path from complexity to simplicity. 

Watch the video Tips for a Successful Cloud Migration

Read the blog Cloud migration checklist: 5 steps to a successful journey

Explore the benefits of Moving your applications to the cloud  

Experience the Garage

 

 

[1] IDC Canada’s PaaS Ecosystem Research Program’s 2018 survey on PaaS Adoption in Canada, January 2018),

No doubt you’ve heard the buzz about microservices, and you are probably wondering what all the excitement is about. Far from just being another IT buzzword, microservices are absolutely crucial for application development on the cloud. I’d like to explain how microservices architecture can create new value for business – often in ways you had never previously imagined.

 I’ve been in IT a long time. The ability to reuse code has been the holy grail of application development my entire career. Subroutines, object-oriented programming, object libraries, SOA – these were all supposed to be the magic bullet for reuse. We may not have reached the final answer, but microservices is one of the biggest steps forward in years.

Think of microservices as the logical extension of long-term trends in the evolution of software development. It’s a simple, yet powerful concept that is making all the difference for cloud-native application development.

Microservices architecture is a new approach to software development that creates very small modules containing data and functionality that can be easily combined, reused and scaled in various ways. Application services are broken up into small, independent functions, allowing developers to rapidly build applications, add new features, or launch new services. When combined with containerization, microservices can scale up and down depending on the need of the moment.

An analogy for non-techies

I like to explain microservices architecture using the analogy of a house. Think of your house as an ‘application’ or business system. In traditional, monolithic application development, the front door and back door of the house are the only ways to get in or out. Accessing ‘functionality’ in the house, such as the kitchen, meant following the floor plan – through the front door, down the hall, and so on.

With microservices, the house itself is radically redesigned, so that individual functions such as the dishwasher or a bedroom are available in any quantity you want, in one simple step, from wherever you are. Having a weekend party? Get instant access to five dishwashers and three extra bedrooms, then scale back to normal operations when you’re finished. Reuse or recombine functionality in any way you want!

That’s the power of microservice architecture.

Why microservices are here to stay

Complex applications built from a set of modular components are faster and easier to develop, adapt, and scale to meet demand, and take up fewer resources. Developers have the freedom to focus only on their piece of the project, which means continuous integration and development are built into microservices architecture, while virtually eliminating infrastructure risk. If one component fails, it’s easy to isolate and fix it while the rest of the application keeps on ticking.

 To recap:

• Microservices architecture splits large applications into (much) smaller pieces that exist independently of each other.
• Each microservice does one thing and does it very well.
• Microservices offer a fast, flexible and efficient approach to building, deploying, and updating individual parts of an enterprise application, streamlining application development and updates.
• Security based on industry standards is built into each microservice, so it’s already there when you recombine or reuse the component.

A word about APIs and containers

Microservices are most powerful when they are  containerized. Think of a shipping container, which is used to quickly and efficiently load and transport cargo around the world. Putting microservices into a container lets you build a powerful system that gives you all the functionality you need, since the container gives you both scalability and replicability. The most common way to implement this is using Docker containers and using Kubernetes to orchestrate, monitor, manage, and scale microservices.

Microservices use application program interfaces (APIs) as gateways to access an application’s data or use an application’s functionality. APIs are how the world’s electronics, applications, and web pages are linked up to work together. It is the combination of microservices (public and private) plus containers that gives developers the scalability needed to rapidly add new value, features and functionality.

Why microservices are revolutionary

The 2019 IDC FutureScape Report says that the digital economy is driving the shift to modular, distributed, cloud-native technologies. It predicts that by 2022, 90% of all applications will be using microservices architectures.

That’s not surprising, when you consider what microservices can do for businesses.

Consider a very simple example. Not too long ago, company web sites contained static maps that showed their location. To get there, you needed a paper map. Today, a single mapping app such as Google Maps (a third party, microservice-based API) shows the company location along with dynamic, real-time suggested routes and predicted travel times for walking, driving, or transit. Not only is this revolutionary, it’s a win-win-win: it saves developers the effort of reinventing a mapping app every time; it gives consumers fast, customized information; and it is a huge win for the company who developed the product.

The opportunity is enormous

I believe that many organizations have not yet grasped the breadth of opportunity awaiting them with microservices architecture. They hear the buzzwords, but they aren’t clear on the value it brings to the business. Let me elaborate.

Not only are microservices at the frontier of cloud application development, they are the most powerful way to move the valuable functionality in your legacy applications onto the cloud. No need to move your 50-year-old legacy payroll solution to the cloud all at once to experience the benefits. Take out the piece that is scalable and reusable for other business needs, turn it into a microservice, then build or refactor the rest of the system over time.

Imagine taking a great idea from your finance application, combining it with another idea from your HR application, and creating a new, powerful solution that nobody had thought of before. It’s possible with microservices architecture.

Business leaders ask us how they can get the same kind of competitive edge. We have been thrilled to help large enterprise clients rapidly gain new functionality and create new business models using containerized microservices architecture on the cloud.

In one sense, microservices is just a new word for reuse and scalability in IT, but these days, multi-million-dollar business are stitching together publicly available microservices with their own solutions and ideas to disrupt and topple entrenched industries. Who knows what the next industry disruptor will be?

Next up: Migrating applications to the cloud

Most companies are starting to build cloud-native apps using microservices architecture, but it’s also a key component of a good strategy to migrate legacy applications to the cloud. Everyone’s journey has its own twists and turns, but to reap the greatest benefit, you need to refactor and redesign your application as you migrate it and modernize it for the cloud.

I’ll be talking about cloud migration in my next blog. Stay tuned!

Want more detail on this topic?

Read this helpful overview of microservices.

Watch the video “What are microservices?”

Explore the benefits of application modernization.

IBM offers Cloud Garage workshops, assessments and more.

 

 

 

 

I got two pieces of advice when I first started canoeing with friends. The first was “expect wind in your face and rain every day ‘, which was the starting point of this blog series. The second item that has stayed with me all these years and is relevant to projects was to “stay calm on the last day.”

When I asked what my friend Graham meant by that or why he was saying that he highlighted:

• The last day is often the toughest day of the trip. You are tired, you have a full day of paddling, repacking the cars, plus a long drive to get home.
• You’ve will have been together with a group of people who you have different relationships, some you don’t know very well, for a long time
• You will be tired, dirty, want some clean clothes, and a chair with a back and legs, something better than a log to sit on. Maybe a craving for something as simple as cold milk in a glass.

It’s easy in that scenario to let tensions or frustration get the better of you and say or do something you might regret in the long-term (even if it feels good in the here and now).

At the end of a trip it is particularly easy to let something slip if you’ve been holding it in for a long time.

In the same way, we all need to be able to keep our emotions in check when we get tired or the going gets tough on a project.  I confess that this is much easier for me to say than to do. Particularly on the big troubled projects that I’ve been brought in to, to help get them back on track. But the same thing process is at work. You get tired and easily triggered. It goes back to getting the frequent micro breaks, taking a deep breath… and staying calm on the last day.

When I started this sequence of blog posts on ‘paddling and projects’ it was the middle of winter. Now my canoe is back in the water, its time to do real paddling!

Here’s the complete list of ‘Paddling and Projects – Lesson’s Learned’ in summary form that we’ve explored in these blog posts:

1.    Expect wind in your face and rain every day	Plan for problems; have contingency
2.    Make sure you have the right experts on your project	Its not about ‘all senior’; its about balance in the team.  Do you have ‘just-enough’ expertise?
3.    Everyone has a role, Know your role, do more, carry your fair share	Understand your role; take on more when you can
4.    Do you trust the person planning the route; –      if I had seen the video, I wouldn’t have come; –      The group moves at the speed of the slowest person	Understand the plan & whether the resources are capable of achieving it; provide constructive criticism to fill the gaps
5.    Innovators are often mocked before they are copied. So are the people who resist change.	Embrace change; look for the benefit of change
6.    Take planned and unplanned breaks	Take opportunities to recharge
7.    Be the early warning system	Don’t assume everyone else sees the risks you see; don’t be afraid to highlight risks; bring a solution
8.    If you want to see the beautiful sites few have seen, You have to carry a heavy load & you have to go off the beaten path	No client pays us $20m to go for a walk in the park; if it wasn’t hard it wouldn’t be transformative
9.    Don’t watch the end of the lake, you see progress by what you pass	Make sure that there are frequent meaningful milestones to measure progress
10. Any fool can be uncomfortable in the woods	Methodology is important; follow a method to achieve maximum benefit
11. A leatherman is the wrong tool for every job	Get and use the right tools to execute your project
12. Don’t take cheap chocolate or mediocre wine into the woods	Know your trade-offs -Understand what’s most important, when out of time / money; what’s the best thing for the client / /for the business
13. Maybe someone moved the hydro wires	Usually the simplest answer is the correct one; test your assumptions regularly
14. Stay calm on the last day	Don’t let stress get you down; find ways to reduce stress (like canoeing!)

Two short lessons in this blog.

• First, test your assumptions, the simplest explanation is usually correct
• Second, know what your most important tradeoffs are

This story gets repeated every time there is a question of exactly where we are.  The first time the canoe group went to Quetico, a park in the north-west of Ontario near the Manitoba border, the lakes were bigger than we were used to, and by the time that we had crossed a lake, they weren’t sure which Bay they were in.  The portages in Quetico aren’t marked, so you really need to figure it out from the map and your surroundings.  That didn’t stop people from having strong opinions about where they were.

One person was insistent that we had to be in a bay that the map showed power transmission  lines running across.  There were no wires to be seen.  He was so confident he was right he argued that ‘maybe someone moved the hydro lines’.

Which is the most likely:  that the wires were moved in the middle of nowhere, or that some one isn’t where they think?

We all get blinded by our assumptions. We need to validate them constantly; we need to take in new information, and we need to admit that the most simple answer is usually correct.  And when we are lost or wrong, we can’t keep justifying our position with more and more outrageous assumptions. Instead we adjust our position as new data comes to light.

Tradeoffs – don’t take cheap chocolate into the woods

On the canoe trip,  we eat (expensive) Lindt Chocolate as a treat after dinner.  The cheeses we snack on at lunch are double smoked gouda,  or 10—year plus aged cheddars.  I couldn’t believe it one time when we pulled out a hunk of cheese – the same size as a large cheddar you might buy at the supermarket – and someone remarked it was $50 worth of memolet.  It is delicious, by the way, and we take it with us every time now.

The pancakes get real maple syrup.

After camp is set up, we’re more likely to drink Vodka or single Malt scotch than wine.

When you have to carry everything in a pack on your back, the ratio of weight and size (or density) to pleasure and/or utility become the most important tradeoffs.  A trip is only 4-5 days so splurging on more expensive, smaller items won’t break the bank.  And if you want to relax with a drink at the end of the day, it is better to drink some Vodka and water (or Tang) from the lake than lug five times the volume of wine or even worse – beer. There are space limitations in the canoe, too.

Similarly, in your project, know what’s most important to the team. To the business.  What can be traded off to get the maximum value within the budget.  Often businesses try to constrain everything.

I want it fast; I want it cheap; I want it great, and I want unlimited scope.  For a fixed price. Its not realistic.  There are always tradeoffs.

One of the great benefits of Agile techniques – and how these 2 lessons tie together – is the ability to constantly adjust priorities based on new information. Each sprint or iteration is an option to reset, refocus on what’s most important. But to do that, you need to be aware and not blinded by your assumptions, and you need to know what’s most important and what can be traded off.

 

 

 

This story happened before I joined this core group of canoeists, but it probably gets re-told every year.  Early in his camping experience, my friend Graham was surprised when someone brought out a down vest on a camping trip in the late summer. It was getting cooler as the evening came on and he wished he could have one.  When Graham asked about carrying winter clothing on a canoe trip on a summer day , the answer was ‘any fool can be uncomfortable in the woods.’

The down vest is light, it can be rolled up and used as a pillow.  It’s a great tradeoff.

The point here is that there are many tips and techniques that can make canoeing more comfortable. If you follow the process properly, you can be comfortable regardless of whether it rains or shines, regardless of the temperature.  Like you were born to it.

We’ve brought hammocks, inflatable couches, and enough tarps to keep the wind out and the rain off the kitchen area at the same time. Layers that allow you to keep warm or cool off.  We plan our route so that we avoid big open water or make sure we hit it early in the day when the wind is usually lighter.  There is a right way to pack your knapsack and canoe so that everything fits and is easy to get in and out.

 

 

The analogy in IT projects would be method.  We have methodologies that help make the journey easier.  Are we following them?  Or are we stumbling around, shivering in a t-shirt on a cold and rainy day?

Like method, the right tool for the right job is just as important in canoeing as it is in consulting.

When camping, we have dedicated stoves, pots and pans.  A saw that collapses into a tube to be carried easily in a pack.  A water filtration system that cleans the water before drinking.

Even our canoe. The Voyageur is an example of the right tool for the right job. It’s based on the  Prospector hull style and it is one of the most popular type of tripping canoe’s.  It has a high gunnel (the side of the canoe) which makes it great for carrying lots of weight and still be safe if the waves get high.  You can see it cut through the water more easily than the rentals we sometimes use.  A Voyageur can carry large amounts of gear while being maneuverable enough for rapids – which we mostly avoid. This makes it a superb large capacity wilderness boat. But those high gunnels also mean it can get blown around a lot if you are paddling by yourself on a windy day. No tool is perfect for everything.

Other people would choose the ultra-light 35 lb canoe.  But they are constrained in the amount of gear that they can carry and we’ve seen those boats with a hull cracked as they went over a beaver dam.

So make sure you have right tools for your project. And be wary of all-purpose tools that have breadth but no depth…. If they’re not the right tool for a single job, they are the wrong tool for every job!

 

Whenever I show pictures from a canoe trip, I invariably get the question “you were there?” with the tone implying a sense of envy. The lakes and rivers are so beautiful. Whether it is some cascade we are portaging around, the mist in the morning or a beautiful sunset, we see spectacular sites. Killarney, with its white rock and deep blue water, it particularly gorgeous in the fall when the colours are changing. We’ve been there when the colours deepen every day. It is glorious.

But these places are all off the beaten path.  It is hard work to paddle and portage to get to see this.  My back aches, my arms are tired. Sometimes I can get pretty grumpy.  But for me its more than worth it.

In the same way, the big achievements in IT projects or in consulting… an NPS of 10 on a difficult project, an external or internal recognition award, IDEA, completing a complex project on-time on budget for a client – these are hard work.  We all want to see the press release or be in the management meeting where a senior executive says “we couldn’t have done it without you.’  but that takes hard work each and every day.

An old friend and colleague of mine, Leslie Kulokas, who retired from IBM always said, “if it was easy, they would have monkeys doing it”.  Clients hire us for their projects because it is difficult.  When you do a great job in a tough situation, sometimes knowing that they couldn’t get it done without you is the only reward.  But just like in the canoe, the payoff is worth it.

One of the reasons a canoe trip is tough is that a canoe doesn’t really move very fast.  Certainly not compared to a motor boat or a car.  When you start out across a large lake or down a long river, it can look like you will never get across to the other side. Conversely, it is easy to look only at your hand on the paddle and your own contribution. Again it can feel insufficient to the task.

• If you keep staring at the end of the lake, it feels like nothing is changing.
• But if you look to the sides, you will see the scenery slide by pretty quickly.
• The view changes constantly if you are close to shore.

And then when you look back at the long view a few minutes later, it seems like you are much closer.

It’s the same in a long project.  If you are constantly looking at the final destination, it might seem like you aren’t making progress. And it is sometimes hard to see how your individual contribution builds to the final goal. But if you have frequent milestones – and you know that those milestones actually lead where you are going – then you can measure your progress more accurately and have a real sense of progress. To me this is one of the biggest benefits of Agile projects – frequent milestones, frequent celebration of success, and an opportunity to both re-energize and re-assess your direction.

Whether it is the end of a portage, or out in the middle of the lake, we take lots of breaks during the day to re-energize. We plan our routes to so that there is time to set up camp, make dinner, clean up and still have time to relax before it gets too dark.

It’s easy to run out of steam when you are pushing hard and it is important to keep hydrated and your sugar levels up.

Similarly, on projects we need to take care of our people.  There is an ebb and flow to every project, and we need to make sure our team is getting the equivalent of a red licorice or a Werther now and then.  Whether it is disconnecting via training, vacation, or a mini break with a team pot-luck or evening event…. we need to make sure the answer isn’t always ‘more right now.’

 

One of the most important conditions for a successful project is matching the ambition of your goals with the capabilities of your team. It’s a lesson that a canoe trip really drives home.

If you look at the map extract above, it shows a section of Algonquin park that we’ve gone canoeing through several times. The red and black lines represent portages – where you carry your canoe, then go back and carry your pack – across the portage. The distances are marked in metres. With four adults, the minimum is everyone walks the route two times – ½ way with the canoe, ½ way back, then all the way with your pack and any other gear. The second person does the reverse – takes his or her pack all the way, then comes back ½ way and picks up the canoe.

So your ‘friend’ for example, could plan a circular route that started in the lake at the bottom centre of the map (which is Opeongo in Algonquin Park), takes a 2180 metre portage, a short paddle, then a 1330 m portage to Red Rock Lake, camp one night on Redrock, then a 3085m portage parallel to the Crow River another campsite. Then a final 1390m portage to complete the circle back to Opeongo. We’d practically be taking the canoes with us on hiking trip!

Did I mention that the canoes are about 25 kg (55 lbs) and the packs upwards of 35? When we need to rent canoes we pay extra to get the ultra-light 16 kg canoes. And of course, the reason you have to portage is that the river can’t be paddled – it has rapids, waterfalls, or un-passable swamps… that means the portage route has hills to climb, and often bogs to walk through too. (It could be worse – The black lines mean the portage is not well maintained, and usually even tougher.)

This route shown is actually tough but doable for me when it is just four strong adults. That first portage is very flat. But when you have young children, you can’t make them carry the canoe, and perhaps not even all of their gear. So now you’re doing each portage route at least three or four times. That’s why I say a group moves at the speed of its slowest person. The project equivalent of course, is the critical path.

One time, early in my canoeing tenure, my friend Graham planned a route so difficult that another friend said as he was trying to climb up and down yet another hill with his pack ‘you know, if I had seen the video, I wouldn’t have come.’

Similarly, on your project, everyone needs to know what the plan is, everyone needs to buy into the plan, and know where the tough spots are, and whether you have a team that can achieve all the milestones. A bit of stretch is great – it encourages the team to work, to learn and to improve. One of the things I like about a canoe trip is the feeling of stretching my skills and pushing myself to do more. But looking at a plan and thinking ‘no way we can do’ that is demotivating. And unlike a canoe trip, where once you are away from the shore you are pretty much committed, on your project, people who decide “if I had seen the video, I wouldn’t have come” actually do have choices.

Two quick ideas this week continuing my theme of lessons from my experiences in canoeing and how they apply to projects:

• Innovators are often mocked before they are copied
• Don’t assume everyone else sees the shoals that you see

 

Innovators are often mocked before they are copied

When I first started canoeing, one of the other guys on the trip brought a headlamp rather than a regular flashlight. It was the first time any of the group had used one. We all laughed, thought it was goofy, asked him if he was planning a career in coal-mining, and made similar jokes. You might be able guess the kind of things we thought he might need two hands free in the dark for.

The next year, three of the four of us had head-lamps and now I was the odd-man. I remember at one point the rest of the group in the evening all turned their headlights on, then blinded me by all looking me in the eye at the same time! The reality is that cooking, getting into a sleeping bag, fixing your tent or hammock… at night it is all easier if you have a light, and still have your hands free.

Two other big examples from canoeing trips followed similar patterns – someone brought it, we made jokes, then later we all bought in:

• The middle photo shows a Thermarest chair. A Thermarest is a self-inflating mattress that you sleep on top of. It provides both increased comfort and extra insulation when sleeping. They are mandatory for overnight canoe trips. But there is also an optional kit to turn it into a chair so when you are sitting around the campsite you are much more comfortable than just sitting on a log that happens to be there.
• The sleeping hammock has replaced the tent. With a tarp over it (not shown), it is just as rainproof as a tent. And you are off the ground, so it is better for your back. You don’t have to worry about finding ‘level ground’, which as far as I can tell is a myth in the wilderness. And a hammock is much lighter than a tent with all the poles and pegs. So, it is a big improvement over the tents that we used to carry.

Be careful it isn’t the same on your project. Don’t discount a new idea because ‘that’s not the way we’ve always done it’. I remember the first time I worked on an agile project which was back in 2003. The objections we got… ‘no pre-set scope’? ‘no commitment except to finish something in a given time?’ … ‘we just add stuff to the backlog indefinitely?’ No way we’re going to agree to that! How would we do scope control? How do you know when you’re done?

And yet, because the results are there, agile is actually better in many situations and more popular than traditional waterfall for IT projects. What’s the next idea that you’re laughing at?

Here’s a quick way to check just how much you or your organization company new ideas. Think about some modern technologies: In 2019 the list includes A.I., Cloud, Blockchain, IOT.  How many are you using? Did your firm start working with at least some of these technologies five years ago, two years ago… or are they on the agenda for a small pilot next year?

 

Don’t assume everyone else sees the shoals that you see

The picture on the left shows the bottom side of my beautiful new canoe after three canoe trips. All of those white lines you see are the result of us ‘bottoming out’. Hitting a rock – big or small – a submerged stump or log, or just hitting the beach too fast. Sometimes in these parks you can see what we call ‘indicators’ … bits of paint left on a rock in the water where someone else’s canoe has scraped the bottom and left a trail. The person in the bow (front) is supposed to be looking for fast water, rocks or stumps, or the water getting too shallow. So that we can steer around them.

The photo on the right shows 2 friends of mine who thought that they could run up a small rapid… they took on more than they were capable of. The canoe dumped. They claimed that an invisible giant muskie hit the side of the boat!

Just like in consulting, you need to call out risks and shoals ahead. Any project can take some minor issues. My canoe doesn’t leak, and I could keep hitting the same types of rocks for many years without ever needing a repair. But don’t assume the person steering your project sees the same risks you do. Everyone needs to call out what they see and take the right steps to avoid the problem.

The picture of my friends dumping their canoe is a good example of risk mitigation. They tried to climb this rapid with the canoe empty. We had left our packs at camp and were going out to do some fishing. So, they got to try something new in a low risk scenario.

Its always important to understand the level of expertise on any project and the same is true in canoeing. In my work life I’ve been in leadership roles for more than 20 years, but I am in a quite different role out on a canoe trip.

I’ve been going canoeing with the same core of people for 25 years.  We all met through IT consulting.  On the left is my friend Graham. He is a great big data and analytics thought leader, by the way. But the most important thing is:  he’s been canoeing for 50 years. He actually built his own canoe in high school.  His summer job as a teenager was to work as a summer camp counselor where he was the ‘tripper’ – taking younger kids out on overnight canoe trips. I think he also worked 1 summer as a junior ranger –  then he took 2 years of forestry at university.

On the right is Ken.  Ken was a senior technical sales manager at Oracle for many years. Knows a ton about database and high-performance transaction management. More importantly, he has a bachelor’s degree in freshwater biology – or as he likes to say, a degree in fishing.  He did field studies on the impact of acid rain on the lakes in Killarney Provincial Park and then spent a winter the Hudson Bay Barrens doing other research before switching to IT.  He’s been canoeing longer than Graham.  On top of that, both of them do the majority of the cooking in their families and I consider them to be gourmet cooks.

With that level of skill available, we’re capable of taking on pretty much any trip.  Whether it was high winds and waves out on the lake, a tough portage, or some unexpected bad weather, there is nothing they can’t handle.

On a project, its not necessarily about having that level of expertise.  What is important though, its understanding the capabilities of your team, and planning your trip –  or your project – accordingly.

Similarly, about 6-7 years ago, I realized my son Alex, who is now our most common ‘4^th canoeist’, was better at sterning the canoe than I am.  The person in the back (the stern) is the captain, deciding the route across the lake, and steering.

Of course, you want the best person on the best job… so he is in charge our our boat.  But what does that leave me to do?  My friends are experts, my son has surpassed me… But someone needs to paddle in the bow (front).  Around the campsite, the gourmet chefs want to cook. But I can still do the dishes, be the sous-chef peeling carrots, filter the water, gather and cut-up the wood.  And carry my share in my pack and the canoe.

Its about getting the work done the best way, not about taking the most glamorous or fun job for yourself.  When we are packing the bags the start of each day before getting in the canoe, you can tell the people that you want to go canoeing with. They come up to the kitchen area and start taking food, the stove, pots and pans… whatever they can get into their knapsack.

The ones you don’t want to camp with are the ones who wait until you say ‘can anyone carry these final few vegetables that I can’t quite get into my pack’ ? and then it turns out that their pack is ½ empty.

It’s the same on a project.  Always try to do more than asked for. Look for jobs that aren’t being done and do them.   We all want the people on our team who are going to finish their own work, and then keep trying to take on more.

By the way, there are lots of times on a trip when I do cook , or stern the canoe.  You have to keep those skills sharp too just in case.