BT SpringOne Talk: developer first and a willingness to learn and change as needed – Notebook

BT SpringOne Talk: developer first and a willingness to learn and change as needed

A keynote given by Rajesh Premchandran, BT

BT wants to get better at how their do business, through software. Their strategies are, of course, operational excellence, but also getting software that improves the customer’s experience. This means they need to simplify how business is done, which they did by transforming the way they do software: IT underpins this corporate transformation, Rajesh says.

His approach to telling this story is to talk about how BT questioned some initial assumptions. On some of their initial plans, they pivoted (adapted) when they discovered new needs and realitis. On others, they persisted when they really needed the change. For example, at first, they thought that having a PaaS would be good enough for all development and app needs.

A pivot example: they discovered that more fine grained control was needed for some apps (esp. legacy ones), so they added in kuberntes. Here. PCF/TAS and TKG.

A persist example: security had to move from security by static IP. Because they were moving to AWS and microservices, things needed to be more dynamic. There was no way to achieve their tech-stack transformation otherwise. So, they persisted.

The third area he describes is their approach to removing ops toil from application developer’s agenda. As ever, they want apps developers to focus on…apps! And have time to explore and innovate making the apps better to deliver on customer service goals. (You see several example from Comcast on this with their new TV apps and improving customer service with ChatBots, and even in-home wifi coverage calibration, etc.) He also comments on a discovery, or validation of a predictable state, in my rewording: developers aren’t good at production ops and don’t really realize all the new tasks they’ll need to do – responisbilities they have! – in a DevOps model. So, they had pivot to training them and putting in place tech stuff to make it work better for them.

He has some fantastic framing: "instead of letting [developers] grapple with operating model choices, we adopted a more human-centric approach to educating teams."

He touches briefly on some portfolio modernization strategy. The benefits of doing, I think, were that they spent their time wisely, modernizing apps that were feasible and valuable to modernize instead of all of them. I could use more detail here, but I think the point is made – I mean it’s a five or six minute talk, so it’s fine. For a lot more, check out the ever excellent Rohit explaining this kind of portfolio app modernization analysis.

There’s another, long BT talk that I haven’t fully dissected yet.

Raw(er) notes

  • BT business – Fixed line, mobile TV, and networking.
  • Goals:
    • Lead in converged activity by simplifying business.
    • Build scalable platforms for growth.
    • Creating leaner business models.
    • IT underpins this corporate transformation.
  • "The challenges arise from our ways of working, process, account policies, security postures, and even we inventory software assests."
  • Three challenges and how they worked with them:
    1. Strategy.
      • A PaaS, PCF/TAS with Spring – time to deploy from 2 months to 2 minutes. Also, microservices.
      • But, people wanted kubernetes for finer grain control, and needs for non/fuzzy cloud-native apps. Used TKG for this.
      • Listening to devteam
    2. Security.
      • Moved from static IP to static IP, public IP addresses.
      • AWS networking needs, i.e., elastic IPs and REST endpoints.
    3. People.
      • "They also were not fully aware of the [new] shared responsibilities of managing infrastructure as code, or how their roles changed when adopting the cloud."
      • E.g., with a more DevOps approach, "their responsibilities did not end with a cf push."
      • Enterprise architects looked through portfolio to bucket apps into legacy, strategic, SaaS, PaaS, and IaaS to plan out the way of working, priorities, app modernization tasks.
      • Drives concensous on "application treatment" and how to educate teams on their roles and new skills.
      • Also, this eliminates scope overlap in our budgets and app modernization plans, allowing the PaaS team to focus on executation, [instead of work that wasn’t applicable to the various apps strategies and bucketing].

InfoWorld interview

Also, an excellent InfoWorld interview with Rajesh where he talks about several of these points, even more stridently.

Some highlights:

  • Rajesh: "What really happens is you’ve got to tease out what is containerizable"
  • "To overcome this challenge, BT has established a platform team, dedicated to helping application teams identify these containerizable elements and find the best environment in which to host them, be it in the public cloud or on a platform-as-a-service (PaaS)."
  • Rajesh: "You have to handhold them, otherwise they will take the biggest unit they can handle, put that into a Docker container and then lo and behold you’ve got the same monster on better infrastructure — that doesn’t solve your business problem."
  • "This is a constant tussle," he admits, "where people want Kubernetes by default, but I think you’ve got to be a bit more prescriptive in the beginning to developers and then as you see them maturing, have them make those independent choices."
  • "the next task is to scale it out via documentation and word of mouth buzz, both for in-house engineers and with external partners."
  • Rajesh: "If you look at how standards are democratized, you’ve got enterprise architecture that looks at the overall architecture standards and policies, then you have solution architects, who are a level down and are specific to a product, and finally we have distinguished engineers — we call them expert engineers — who are also key influencers for other developers, who look up to them."

Spring Survey 2020 – Highlights

Survey highlights:

  • Download the report after some light leadgen.
  • “The research effort included a total of 1,024 individuals, all of whom have a role that involves daily use of Spring.”
  • 77% of the respondents have been using Spring Boot for 3 years or more. So, these are people very familiar with Spring and Java.
  • Industries: technology companies (30%) and financial services companies (20%). All major sectors are represented, including retail (8%), services (6%), and healthcare (5%).
  • 37% work at organizations of 5,000 to 10,000+ staff. Of that, 28% from 10,000+ orgs.
  • So, a bit heavy on tech companies, but good enough on both industries and diverse spread of organization size.
  • “52% of developers surveyed use Spring boot as their only or primary development platform.”
  • No slow-down in use: “75% of respondents expect Spring Boot usage to grow over the next 2 years.”
  • Uses, lots of API use, interesting: 
Types of Spring Boot apps.
  • Lots of public cloud only use: “When asked where they deploy their Spring Boot apps, 57% of respondents were either deploying exclusively to public cloud (21%) or in a hybrid mode with both on-prem/private and public cloud deployments.” 
  • – Most running in containers – 65% containerize their apps, 30% planning to.
  • …to run in kubernetes: 44% already running in kubernetes, 31% plan to in the next 12 months.
  • [This should make us ask the question: how does Spring Boot support kubernetes? Cf. Spring docs entry, another write-up.]
  • So, what do people use in Spring. If APIs are one of the top problems to solve with Spring, it is as you’d expect:
    • 83% are using a microservices “development style.”
    • 56% use Spring Cloud.
    • 34% Spring Cloud Gateway (77% interested – big spread).
    • 22% using Spring Cloud Data Flow (big spread again with 69% interested).
  • See also Dormain’s coverage.

If you’re interested in more, we’ll be talking about this next week, September 21st at 5pm Amsterdam time over on Tanzu TV.

Air France KLM modernizes their payments service, SpringOne 2020 talk – Notebook

Air France KLM modernized their payments service recently, EPASS. This is a 12 year old system that provides the backend for processing purchasing airline tickets (and other things, I guess) from numerous front-ends: the web, mobile app, and social apps as well. The system was difficult to scale, it required manually adding new servers and had a long development cycle. As more and more people want to interact with Air France KLM through software (phones, online, in WhatsApp, or whatever other “channel”), they want to be able to evolve their software quickly. They want to use software as a core innovation tool for improving customer experience and, thus, business. So, here we see one of their first experiences modernizing their backend and transforming how they do software.

Talk presented by Oya Ünlü Duygulu and Patrick Zijlstra.

Highlights

-Rick in intro: transformed payments platform in 6 weeks.

– [Corporate vision] is to provide good, “our purpose as an airline group is create memorable experiences for our passengers. 

– So, they want to (1.) focus on customer centricity, (2.) innovation, and, (3.) efficiencies in our processes.

– “Digital” as the primary channel is on the rise. People want to interact through apps and such. So, KLM needs to meet the customers there… “As an airline, we want to be where our passengers are” (~3:00)

– Some examples of digital features: “‘About 10 percent of the ideas actually end up on the market. A recent example of this is the hand baggage check in the KLM app. Through augmented reality travelers can see whether their hand luggage meets the set dimensions. This function went live last month. ‘ Six months ago, a 3D rendering of the business class seats was also shown when checking in online. ‘This with the idea of ​​stimulating the sale of these chairs.”

– For example, listening and interacting with customers in social media [something I’ve done many times – it’s great to chat with someone (or a bot?) in WhatsApps, Twitter, etc. instead of a phone call]. (~3:40) Social media is now “our closest connection to passengers.” And in China: “For instance, Chinese travelers rely immensely on mobile devices. How can these personal devices be used for authentication – identity management, payment etc. to streamline the journey wherever possible? In China, the whole landscape is different, and we need to ensure we aren’t relying overtly on drawing customers only to our touch-points.” 

– (~3:10) merged together KLM and Air France backends to get less complexity in the back-end and a unified experience in the front-end for customers. Social media is now “our closest connection to passengers.”

– 350 agile teams. Using Scrun, Kanban. SAFe. See SAFe case study from ~2018, and some trip notes from someone at ACM Agile.

– The use SAFe release trains (which they call “release planes”), mapped to customer value journeys, e.g., sales, paid products, or airport.

– In the digital department, they have about than 50 product teams.

– Planning every three months, come together get a roadmap from the business, and all the teams plan together. Then they start sprinting bi-weekly.

– Also shared services and practices team.

– Their /goals: 

– (~5:50) “We are designing our products focused on time to market, innovation, robustness, and security.”

– Focusing on getting CI/CD in place.

– Also, reducing complexity and speeding up business value [realization], so we are moving towards a microservices architecture.

– [Business stuff:] EPASS handles payments from many places, created 12 years ago. Wanted to modernize [not sure why]. They worked with Pivotal Labs on modernization for a six wee project.

– EPASS app – made 12 years ago, handles about 37,000 payments transactions per day. Takes care of all online revenue.

– Six week engagement with Pivotal Labs. This brought expertiese from the outside, combined with their existing skills.

– “Six weeks is very ambitious for such a project, but getting this expertise from Pivotal and their dedication we made a success story at the end.”

– Modernization road-map for EPASS.

– We want to speed up with release cycles, which was then one month. [Move to single piece work-flow: whenever a user story is ready, then it can go live.] 

– In six weeks, all the could focus on was transforming the app and moving it to the new platform [PCF]. But, they could also modernize their skills by adding in TDD and pair programming.

– Switches to Patrick.

– (~10:55) – they go over their way of working. 

– Inception to set expectations. Outception to look back at what was achieved. Some blocker removal meetings. And the usual agile meetings.

– Two teams: one does modernization, the other delivers business features.

– Worked in one week iterations.

– Doing pair programming. “We noticed that this really increases the code quality that we deliver.”

– (~12:30) EPASS architecture. Was hosted on bare-metal Tomcat server. To scale, had to add new server and put EPASS software on it. This was becoming a hassle and fixing that was a motivation to move to VMware Tanzu.

– (~14:00) new architecture – five different components. Three in Tanzu Application Service.

– After, the majority of things were put in VMware Tanzu…

– [Picked some small things at first to test stuff out, hardcoded secrets but later fixed that – used CredHub – in long term will move to Vault.]

– (~16:00) Used Spring Boot, adding health check [this is good to highlight, that it gets instrumented/observable “for free”].

– “It was invigorating working to work with the  Pivotal experts and now there’s more confidence in the team to continue.”

– Used Bamboo, added in automation stuff for deployment…

– Problems: networking problems

– Benefits: response times improved by 10%; “all the power for scaling is within the product team itself” instead of having to work with other groups, file tickets, etc. Also, time to patch is within 72 hours (3 days).

– (~21:08) “The experience was very positive. It was invigorating to work with the Pivotal experts. And, now there’s more confidence within the team to continue to improve the application.”

– The projects have been finished for a few months. No more components in bare-metal Tomcat.

– “From the organization side, there is no more fear of big changes. If such an old application as EPASS can transform, then it’s possible for any application.”

– “So more and more and more applications will be moving to TAS [Tanzu Application Service].”

Forrester on developers, custom apps, and COVID – Notebook

The report goes over how software development needs and programs should adapt to the urgency that COVID brings. Highlights:

  • Obviously, teams are working from home more now. This exposes all of the face-to-face, undocumented processes that were happening (“manual processes address handoffs across departmental boundaries”). If there were too many, work can’t happen as well anymore when everyone is working from home.
  • “The trend catapulted use of Zoom, a videoconference service, from 10 million average daily users to 200 million during March 2020 and introduced us to our coworkers’ tastes in home décor.1 But it also separated millions of workers from the paper files they require to complete their missions, breaking millions of business processes. Paper files are an obvious point of failure, but manual processes based on desktop tools like excel and email lack visibility and tracking that are vital to remote workers.”
  • Paperless efforts are really on the front-burner now: “any enterprise relying on paper to advance its processes needs to automate just to continue to function.”
  • Also: “Topping the list for most now are tracking and tracing applications: tracking of employees, people entering hospitals and other sensitive buildings, equipment, facilities, patients, tests, research results, and on and on. These applications are not throwaways; they’re business-critical. and in the public sector, throw in new apps to manage new support, recovery, and stimulus programs or support existing programs straining under unprecedented volumes. Then in financial services, you have new servicing apps: servicing debt, defaults, new rescue programs, moratoriums, etc. (rather than new customers and new products and services). and any enterprise relying on paper to advance its processes needs to automate just to continue to function.”
  • And, more app types:
  • This urgency is driving business people to (finally) start getting involved more in IT/software: “as organizations scramble to fix processes and rapidly automate to keep them running, it becomes clear that businesspeople are the primary source of operations insight…. Bringing businesspeople closer to the development process through iterative, rapid prototyping and sometimes allowing them to develop solutions on their own offers promise for much faster and more agile responses to business needs.”
  • With apps being used remotely (as a SaaS, over the internet), organizations will likely discover new scaling needs – when the apps run outside the corporate network, and are home grown. “Scale becomes a vital focus. Many development teams are getting their first glimpse at what massive scaling looks like for their applications.”
  • Companies are overworking staff: “a us hospital network made Java developers scramble 24×7 for 20 days to create a visitor registration application to extend its hospital administration system.” [This isn’t sustainable and if done too much will leave a bad taste in staff’s mouth about “agile” and “digital transformation.”]
  • The authors really like and recommend low-code stuff. This probably makes sense to get a lot of line-of-business people to start putting together wizards and UI-driven workflows around databases, Excel/CSV, and APIs to ERP systems.

Source: May 20th, 2020 report “The Coronavirus Crisis Increases The Demands On Software And Developers.”

“Culture is a Lie,” Paul Czarkowski – Highlights

A good, and fun talk from Paul. He tries to refocus DevOps-y energy from “culture change” to more practical things for individuals to do.

Highlights:

  • You can’t change culture from the bottom. Leaders change the culture, they define it.
  • Culture is behavior.
  • If you want to change culture, you need to change your leadership.
  • Culture: as a practitioner, you can’t change it. And if you’re in a leadership position, you’re incentivized not to change it.
  • “If you choose to die on a hill, you’re gonna die on that fucking hill.”
  • Corollary: “If you don’t decide to die on a hill, you won’t die on that hill.”
  • Generative orgs can create microservices.
  • Others will make monoliths.
  • Most people spend more time justifying not working than working.
  • People who do good work will be pulled down.
  • Most people around you aren’t bad people, they’re just a product of their surroundings.
  • As soon as you start fighting the organization, it’ll start fighting back harder than you.
  • Often said: if your company is acquired by a larger company, leave.
  • Then, some examples of automating governance.

ABN AMRO’s kubernetes strategy – Highlights

The video for this talk at KubeCon EU 2020 isn’t posted publicly yet, but you can check it out if you login as a registered attendee.

The talk is titled “How ABN AMRO Switched Cloud Providers Without Anyone Noticing.”

Some notes and highlights:

  • Because of lack of skills, they setup a team (named Stratus) to centralize [and also market?] the new platform.
  • (~4:10) – Building a centralized, standardized platform is important for efficiencies (reducing duplicated efforts) but also governance and maintainability, long-term. “We are building a solid container platform. Why would a team not do it themselves? If you have about 600 teams that want to use containers and everyone would need to build their own unique container platform, it would become unmanageable as a company you cannot control it, and it would be a lot of reinventing the wheel.” MS-Word dictation transcription: And that’s something you don’t want because then things are wasting, the team’s time, the valuable time so therefore it would be good if one team would build a strong foundation or the other teams can build on top of that. Also need to enforce policies/governance/security on the team’s work.
  • They do the typical platform team stuff – building the platform, running it, evolving it, consulting for it, etc.
  • They basically use Azure, with some AWS it seems:
  • ~7:30 figuring this out all on your own can be very time consuming – maybe a couple years of learning, PoC’ing, [vendor negotiations], etc. We needed to do it in one. We started with the CNCF reference diagram.
  • [I didn’t pay attention closely enough much beyond to take good notes.]

Transformation case study

Jana Werner and Barry O’Reilly have a great case study and commentary of transformation at a couple organizations, primarily a bank. I was lucky enough to get Jana on for an interview on Software Defined Talk, talking about the case, information theory, and Nietzche. It should be in the podcast feed next week.

Here’s some of my highlights:

  • “In one Financial Services organization we’ve been able to implement an increase to contactless card payment limits in days where the previous increase took months. We stood up a work from home solution for call centre staff, automated processes and relieved pressure on teams having to manually capture customer data over the phone in 3.5 weeks—a record for service delivery and a credit to the teams and individuals who made this possible.”
  • Focus on the outcome, not following the process, or working a lot: “The subtle yet powerful shift to outcome-based measures of success — reducing and resolving customer issues — over traditional output-based deliverables of being on time, budget and scope had a pronounced impact on productivity and employee satisfaction.”
  • When the meeting (the bureaucracy) becomes the product: “Slide decks, paper proposals and steering group sessions all take a significant investment to prepare, avoiding “difficult” conversations by socializing and re-socializing in advance of exec meetings, deferring decisions, requesting a raft of meeting minutes to document, correcting, amending and signing them off—the majority of which few people read.”
  • This effects how the entire organization runs, and, indeed the pace of delivery: “The speed of these cycles determines the heartbeat of the organization.”
  • Management starts asking different questions: “Responses can now shift post-release from ‘How could you have got this wrong?’ to ‘What is our next best action?’ Seeing how shipping smaller slices allows us to iterate, also means leaders can set direction and monitor metrics over setting targets and failing anything but perfect results.”
  • Often, management has failed to build a system (vision, strategy, norms, “culture,” etc.) that makes staff’s job clear. That’s a problem! “Test your strategy cascade methods to maintain the clear purpose, problems and outcomes teams are working towards. Ask teams if there’s a clear line of sight between the objectives, and how their work contributes to achieve your shared success. If they can’t see it, fix it. Maximising both organizational alignment and autonomy can be the biggest accelerant for sustainable pace, employee engagement and amazing customers experiences.”
  • And: “The biggest hurdle to change is people not believing it’s possible.”

There’s a lot good in there. Check out the case study.

Lunch notebook – 20200129

Sometimes you eat the bear, and sometimes the bar eats you.

Where does the time go? It’s especially hard when your mind betrays you and you go a little crazy. My mornings often start well: sitting and reading with some coffee before everyone else wakes up. Just like my dad!

Then it’s the rodeo to get the kids off to school, the source of much strife and a potential leap into a bad day if things go poorly. But then there’s a bike ride back home, and with that coffee and the day ahead of my, my mind races with possibilities and ideas.

And, back at the desk, if I don’t dive in and start on work immediately, I loose track and get distracted. I have to maintain discipline of just not reading emails and Slack and all these things that want my attention.

Kubernetes for developers

I’m speaking at QCon London coming up. After seeing Paul’s talk on kubernetes and, well, being part of a LoB at VMware to sells kubernetes, I want to give a “how to put together your kubernetes strategy, for developers.” Really, what it amounts to is putting together your DevOps stack, but you’re not supposed to talk about DevOps as if it’s tools and actual products.

I think that’s mostly bullshit, at best, misunderstood: us IT people throw too much worth into the sacredness of culture and process things – and then we wonder why enterprises find it so hard to adopt the practices – to get better – when we keep saying it’s not about using tools but fundamentally changing how you think and operate.

So, was I supposed to get that abstract written up by now? Yes. Perhaps this afternoon.

Tongue “cheese”

Lunch notebook – 20200128

It’s lunch time here in Amsterdam, so it’s time to clear out the ephemera:

  • I rewatched this modernization webinar from AirFrance-KLM. There’s lots of good tips on putting together your modernization strategy and program. They have a portfolio of over 2,000 applications, the oldest from 1968! The airline runs well, but they wanted to add in more agility and be ready for running on new types of infrastructure, clouds. So, they’ve started small and slowly been doing projects, learning along the way, and then scaling up once they know better how to proceed. It reminds me of that line from a US Air Force slide: you can’t scale agile until you can do agile well on the small scale. I’ve got lots of notes and will hopefully write it up soon.
  • After hunting down links for the podcast with Paul, I was reminded of Not.ist. It looks like a good service for hosting my speaker’s profile. Now, I need to go through and add my past talks and stuff. It certainly looks more pretty than what I could do on my own.
  • The Moldy Peaches – that song from Juno came up on Kim’s playlist last night and I remembers how much I liked this album. “Let’s go to the beach. Let’s talk about movies. Let’s get a bite to eat.” What was I doing in 2001? Boy, that’s three of four life-times away. I barely remember, but I think I was there. And who can forget: “THESE BURGERS ARE CRAZY.”
  • Pivot podcast episode – Scott suggests throwing in the towel when it comes to composting with Amazon: sell your retail business and buy Amazon stock. Is that a valid strategy? I suppose Berkshire Hathaway does that, other holding companies.
  • Looks interesting: The Long Road to Cloud Native Computing
  • Maybe it’s not such a good idea to “be a tech company” – many unicorn IPOs drop value of the company.
  • “At some point I wondered if that comfort was an obstruction to getting to new places.” – it’s always good to let yourself be sloppy with notebooks.
  • Kubernetes takes over – on Docker and Mesosphere.

12/24/19, 9:24 AM

New theory: in a service environment (hotels, restaurants, even retail) instead of worrying about the unknown, assertive people ask questions and demand to have things the way they want. They order coffee left at the door in the morning instead of questing for it in the morning or being satisfied with in-room coffee. What’s key to imitate is that they’re polite, smile, and are gently but clearly assertive.

Tips for Michaels

When Kim and I started living together, we had to figure out the shared rules of the house. Back in 2004, Kim provided a handy list for me:

  • General
    • Don’t stomp or “walk heavy.”
    • When you answer the phone don’t belt out a loud “HELLO!” directly into the caller’s ear.
    • Every item in the house has its place.
    • Don’t “flick” things off your fingers onto the floor or sink or any other place. Use towels.
    • Always keep the shower curtain spread out, across the entire shower, not bunched up on one end.
    • Never set drinks down on board games.
  • Fashion
    • Always wear a white undershirt.
    • Don’t wear your collar up.
    • In summer, wear light colored clothes. In winter, wear dark colored clothes.
    • When “dressing up,” your belt should match your shoes.
    • If you tuck any shirt into blue-jeans, you look like a cowboy. That’s not good.
    • Tucking shirts into khakis is OK.
    • Don’t stretch the collar of your undershirt, and don’t wear undershirts with stretched out collars.
  • The Kitchen
    • Never, ever, ever use anything metal (spoons, spatulas, sponges) on the pots and pans.
    • Don’t clean the stainless steel stovetop with a wire sponge.
    • Bag all your perishable trash in air-tight bags before throwing it away to prevent smells.
    • Don’t buy cans with dents in them.
    • Place knife blades up in the dishwasher. Forks should be upright too.
    • Don’t let one dish block another in the dishwasher.
    • Clean off dishes before putting them in the dishwasher.
    • Never wash your hands in the kitchen sink.
    • Don’t stab the cutting board with a knife, and leave it standing there.
  • Laundry
    • You have to separate lights and darks.
    • Lights: warm water.
    • Darks: cold water.
    • Check the tags on every item if it’s not yours and you don’t know how they should be cleaned, because several of my expensive clothes have been ruined because they’re dry clean only.
    • Put water in first, then detergent, then clothes.
    • Don’t put black clothes in the dryer. They fade faster.
    • Don’t let wet clothes sit in the washer too long before putting them in the dryer.
    • Don’t leave clothes in the dryer too long or they’ll get wrinkled.
  • Eating and Food
    • Don’t smack.
    • Don’t slurp. Even coffee.
    • Don’t kiss people with a wet mustache.
    • Putting hot sauce/bbq sauce/A1/ketchup on difficult to make meals may be seen as an insult.
    • When grocery shopping, give the produce a good look-over before buying.
    • Don’t put heavy foods on top of squish-able foods in the grocery cart or the refrigerator.
  • Social Stuff
    • You can’t ever leave without saying goodbye to everybody. If this is an issue, start saying goodbye 30 minutes before leaving.
    • You can call people just for short conversations. You don’t have to talk a long time with them. [Michael says: except your mother.]
    • Look people in the eye when you talk to them.
    • Don’t talk about work all the time.
    • Don’t mumble.
    • Don’t put your hand in front of your mouth while talking.
    • Smile and be friendly.
    • Don’t interrupt people.
    • Look interested in the conversation that you’re a part of.
    • Don’t be so stand-offish when people go to hug you.
    • Don’t be weird.
    • When invited to a bar, don’t worry if you don’t know everyone or are afraid it may not be a good time, because “drinkin’s drinkin’.” (Nick’s tip)
  • Personal Hygene
    • When you’re cleaning your ears with a Q-tip, lock the bathroom door.
    • Keep a fresh breath. Look into gum.
    • Trim nose hairs.
    • Keep beard and mustache nicely trimmed.
    • Keep toe and finger nails nicely trimmed at all times.

American Airlines is a good profile of enterprise cloud buyer’s needs, hopes & dreams – Notebook

While this is sort of a bummer story for Pivotal (we’d like to have this account), it has a good profile of American and their needs in it. All of which are representative of other large organizations, e.g.:

  • Application types: “The first result is that the airline will migrate to the IBM Cloud some of its critical applications, including the main website, its customer-facing mobile app and its global network of check-in kiosks. Other workloads and tools, such as the company’s Cargo customer website, also will be moved to the IBM Cloud.”
  • Managed data-centers/cloud: “The airline will be able to utilize the global footprint of IBM Cloud, which consists of more than 50 data centers in 17 countries, in addition to a wide range of application development capabilities.”
  • Long-term planning: “We wanted to make sure that the cloud provider would be using Cloud Foundry and open-source technologies so we don’t get locked in by proprietary solutions,” Grubbs said. “We also wanted a partner that would offer us the agility to innovate at the organizational and process levels and have deep industry expertise with security at the core.”
  • We want to do all the new meat-ware: “As part of this process, American will work with IBM Global Services to use IBM’s Garage Methodology of creating applications through a micro-services architecture, design thinking, agile methodology, DevOps and lean development, the company said.”
  • Legacy, it’s how you got here: “IBM Cloud will help enable developers to build and change application functionalities for the airline’s customers. These customer-facing systems will be on the IBM Public Cloud, while American will maintain backend connectivity to other on-premise legacy and third-party systems, for true Hybrid Cloud functionality.”
  • There’s a lot going on: “American Airlines and its subsidiary, American Eagle, offer an average of 6,700 flights per day to about 350 destinations in more than 50 countries. American has hubs in Charlotte, Chicago, Dallas/Fort Worth, Los Angeles, Miami, New York, Philadelphia, Phoenix and Washington, D.C.”

Source: American Airlines Heads for a New Cloud with IBM

Shifting IT spending drives sales-force changes – Notebook

Looking at how company’s arrange their sales (and marketing) organizations is an interesting view into the effect of “cloud” on how IT is used and consumed. This week Microsoft is re-arranging it’s sales force to make it more cloud-friendly, people say.

From what I can tell with my dilettante analyst, Microsoft’s theory appears to be that:

  • sales people need to be more technically savvy on cloud,
  • have more vertical knowledge (how does cloud apply to my industry?), and,
  • target larger accounts (where the top and bottom line revenue is worth having a big sales venture, and to bring in volume and cash to public cloud).

Also, with 75% being outside of the US, it’s a dramatic change internationally.

Here’s some excerpts from coverage:

Summarized by Nicole Henderson:

The company said it is implementing the changes not to cut costs, but to improve how it handles sales; specifically, it said it will use employees who are more knowledgeable about specific verticals so they can sell bigger packages, CNBC reports.

As Microsoft vies for more enterprise cloud clients, having better trained salespeople, who are knowledgeable about a specific vertical, will mean they are better equipped to meet client needs. To that end, Microsoft said in an internal memo that it would split commercial sales into two segments – one targeting the biggest customers and one on small and medium clients. In addition, Microsoft employees will be aligned around six industry verticals – manufacturing, financial services, retail, health, education and government.

See also coverage from CNBC, and The Register’s coverage, e.g.:

With recent changes to its enterprise agreement to exclude smaller companies, Microsoft is focusing on bigger deals that require fewer staff, while everyone else gets shifted onto a per-person consumption payment model for Microsoft’s cloudy services.

We also discussed this briefly in this week’s Pivotal Conversations.

Shifting spending

Meanwhile, while this doesn’t capture all of the market-shift (you’d also want to see the shift from COTS to SaaS, infrastructure software, and then *aaS spend), some recent charting from IDC shows one of the motivations for changing up your sales approach, i.e., IT infrastructure (hardware) money is shifting around to public and private cloud stacks:

In the above, you see the blue bar slowly decreasing in the out-years meaning less “traditional” spend and more “cloud” spend. The pricing dynamics and units shipping in public cloud are all whack compared to private cloud (Google, Amazon, and Azure’s hardware needs are much different than private cloud needs), but looking at the red bar gives you an interesting perspective on new build out at enterprises. And, thus, you can get a sense for shifting buyer behaviors in IT…and why you’d want to re-arrange how you sell to them. See more recent details from IDC.

Link