Presentation on SE practices at Infy SPE, and my learnings from the experience. A deliverable for the CS5704 Software Engineering course at Virginia Tech.

1. So#ware Engineering Prac/ces
Finacle SPE, Infosys Technologies Ltd.
Sameer Ahuja

2. Infosys
• IT Services and Consul/ng
• US$ 30 Billion company
• Annual Revenues > US$ 4 Billion
• Growing at > 30% p.a.
• > 94,000 Employees
• SEI‐CMMI Level 5, CMM Level 5, PCMM
Level 5, TL 9000 and ISO 9001‐2000

3. Infosys
• Pioneered the Global Delivery Model
• Several Sub‐Companies: IBUs

5. Finacle
• Suite of enterprise banking applica/ons
• Infosys’ only product
• Codebase is as old as me (26)
• Massive codebase

6. Tools of the trade
• In‐house VB‐based /cke/ng system
• CVS for versioning
• Set of in‐house tools for scheduling and
running builds

7. Finacle SPE Software Performance Engineering
• Performance measurements, analysis,
op/miza/ons and research
• ~30 People
• En/re team located in Bangalore, India

8. Product
Development
Manager
Project Project Project Project
Manager Manager Manager Manager
TL SE SSE TL SE
SE SE
SE SE SE SE SSE SE SE
SE SE SE SE

9. Product
Development
Manager
Project Project Project Project
Manager Manager Manager Manager
TL SE SSE TL SE
SE SE
SE SE SE SE SSE SE SE
SE SE SE SE

10. Me @ SPE
• So#ware Engineer
• Worked for 2 years and 9 months

11. Performance Engineering
• The deal maker or breaker NFR for
Enterprise Banking Applica/ons
• Public compe//on for highest TPS
(Transac/ons Per Second)

12. Engineering Process
• Selec/vely Itera/ve
• So#ware versions are customer‐driven,
point releases signify independent
customer deployments
• Every ~3 years, new features released in
point releases are integrated into a new
base version

13. 9.1 9.3 9.2
Finacle 9 Finacle 10

14. Advantages

15. Advantages
• Individual processes run independent

16. Advantages
• Individual processes run independent
• Reduced risk on the base version

17. Advantages
• Individual processes run independent
• Reduced risk on the base version
• Each point release can instan/ate a
different internal process

18. Advantages
• Individual processes run independent
• Reduced risk on the base version
• Each point release can instan/ate a
different internal process
(But realistically, they are all waterfall instances)

19. A note on requirements

20. Requirements Gathering
• Requirement specifica/ons are created by
all‐star domain experts* from both sides of
the table
• Legal contract, detailed specifica/ons
• Takes ~30‐60% of the overall /me.
* >25 years of domain+IT experience

21. Requirements don’t change.

22. Problem #1

23. Peanut Bujer Performance Engineering
TM
• Performance evalua/ons are done in
parallel with integra/on tes/ng
• Like Usability Engineering, post‐mortem
Performance Engineering is risky and
superficial

24. By the time the performance evaluation is
done,
there is no time left to solve deep
performance issues

25. Mi/ga/on
• Inputs from PE Experts during
requirements specifica/on and design
• More sophis/cated evalua/on setup,
nightly performance evalua/ons of builds

26. Problem #2(a)

27. Change is hard (and slow) to propagate
• Individual instance code‐bases evolve on
separate repositories
• Propaga/ng feature or framework changes
amongst parallel lifecycles is painful

28. Problem #2(b)

29. The Bajle Of The Managers
Branch Integration
• Within one instance, most branches are
integrated only around the end of dev cycle
• By nature, the product’s individual modules
have high coupling

30. The Bajle Of The Managers
Branch Integration
• Design documents define module
rela/onships, but some/mes make false
assump/ons about system constraints
• Oh, and sh*t happens
• If your branch and mine conflict, is it your
fault or mine?

31. Possible Mi/ga/ons
• Regular Integra/on Cycles
• Test case driven development
• Ajack problems, not people

32. In essence...

33. In essence...
Finacle’s SE Process is protected against external change.

34. In essence...
Finacle’s SE Process is protected against external change.
But internal change happens.

35. In essence...
Finacle’s SE Process is protected against external change.
But internal change happens.
And the process needs to embrace that change.

36. In essence...
Finacle’s SE Process is protected against external change.
But internal change happens.
And the process needs to embrace that change.
Via Proactive Synchronization.

37. In essence...
Finacle’s SE Process is protected against external change.
But internal change happens.
And the process needs to embrace that change.
Via Proactive Synchronization.
And a defined protocol for propagating change.

38. In essence...
Finacle’s SE Process is protected against external change.
But internal change happens.
And the process needs to embrace that change.
TM
Via Proactive Synchronization.
And a defined protocol for propagating change.

39. Q/A