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.
- 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].