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].
Also, an excellent InfoWorld interview with Rajesh where he talks about several of these points, even more stridently.
- 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."