Using the old AI agent sidekick idea to take care of decision making. You still have a human face to walk you through stuff. Other roles are a person to sort out more complex things that a computer can’t do and the data scientists who monitor decision making and do new ML-stuff training.
“The productivity imperative for US life and annuities carriers,” McKinsey March, 2021
Life insurance companies have been looking for growth for a long time.
Cost cutting is a big priority: “In a proprietary McKinsey survey conducted before the onset of the COVID-19 pandemic, senior life-insurance executives estimated the industry needed to reduce its costs by 35 percent in the medium term, far higher than the typical 10 to 15 percent reductions realized in most cost-cutting programs.”
“How insurers can act on the opportunity of digital ecosystems,” interview with Markus Warg, McKinsey
Insurance providers looking for new revenue streams, also new ways to optimize/save money, inc. lesser payouts.
This guy is all about engaging with the “ecosystem” or partners and other people to layer on new features to health insurance. HealthKit on the Apple Watch is an interesting aspect. Why don’t more insurers do that?
Offering new features to improve the business: “Take, for instance, health insurance. Health insurance’s value is in covering financial risks. However, this product can be enhanced substantially through further services related to telemedicine or health management—resulting in better prevention and reduced costs through more appropriate care settings. This benefits both the customer and the insurer. Similarly, innovations such as digital care assistants prove that traditionally lengthy processes can be completed via an app in just a few minutes. At the same time, such services help to create touchpoints with caregivers along the way.”
Some pushing to getting faster develop lifecycles.
“The Time For Strategic EHR Workflow Is Now,” Forrester, July 2019
Electronic Health Records (EHR) are not delivering on the promise of optimizing. Doctors don’t like them, they spend too much time in them. The UIs haven’t improved that much: ‘Providers now spend approximately 2 hours in
the eHr for every hour spent engaged in patient-facing activities.4 in addition, providers report spending an added 1 to 2 hours of “pajama time” catching up on work each night after hours.’
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.
BT business – Fixed line, mobile TV, and networking.
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:
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
Moved from static IP to static IP, public IP addresses.
AWS networking needs, i.e., elastic IPs and REST endpoints.
"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].
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."
“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:
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.
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.
-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.”
– 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].”
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.
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.]
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.
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.
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.
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.
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.
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.”
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.
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.
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.
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.