2012 Ernst & Young ShinNihon LLC. All Rights Reserved.

Transcription

1 Java EE architecture and Agile development that enable continuous business improvement Hiroyuki Wajima Financial Services Office (Advisory) Ernst & Young ShinNihon LLC Page 1

2 [Self Introduction] History - Sep 2009 : IT companies (Japanese company, foreign company) R&D for app server products and J2EE framework Consulting for J2EE/Java EE software architecture, system development methodologies and SOA / BPM Oct : Ernst & Young ShinNihon, LLC. Financial and IT advisory for financial institutions JavaOne and myself JavaOne 2000 in San Francisco : Java Licensee JavaOne Tokyo 2005 : General session speaker JavaOne Tokyo 2012 : General session speaker Page 2

3 [Agenda] Background Elastic architecture Service Oriented Architecture (SOA) Elastic methodology Business driven agile development Offshore development based on SOA and agile methodology Page 3

4 [Background] Current situation of companies Economic downturn Selection and concentration are necessary Core-context analysis Framework to decide businesses /areas to invest enterprise resources Core vs. Context Core : businesses that differentiate a company from others Context : other businesses Mission Critical vs. Non-Mission Critical Mission Critical : Customer impact is big if they fail Non-Mission Critical : Customer impact is small even if they fail Page 4

5 [Background] Core-context analysis (cont.) Page 5

6 [Background] Core-context analysis (cont.) Mission Critical Core Businesses Invest enterprise resources Custom system development is necessary Java would be preferred to other languages Page 6

7 [Background] Core-context analysis (cont.) Mission Critical Core Businesses Invest enterprise resources Key factors to differentiate a company from others Business : continuous improvement IT : Support business continuous improvement by custom development Java would be preferred to other languages Page 7

8 [Background] Requirements for enterprise Java systems Continuous business improvements can be realized Elastic architecture Service Oriented Architecture (SOA) Elastic methodology Business driven agile development Especially after systems go-live Introduce best practices acquired in a continuous improvement project of a mission critical core business in a financial institution Page 8

9 [Service Oriented Architecture (SOA) ] Service Oriented Architecture (SOA) Isolate GUI, business rule and model/integration logic GUI and business rule : Changed frequently Model/integration logic : Not changed so often Integrate with external systems via service bus Loose integration with external systems by web service => Minimize impact of changes Page 9

10 [Example of change] Initial state Page 10

11 [Example of change] Integrate with TEL / CTI server Page 11

12 [Example of change] FAX / scanner integration architecture change From direct integration to web service integration Page 12

13 [Integration architecture] Utilize asynchronous messaging Page 13

14 [Integration architecture] Merit of asynchronous messaging Improve user experience Shorten GUI response time Page 14

15 [Integration architecture] Merit of asynchronous messaging (cont.) Minimize impact of system issues Accept requests from customers even if external systems are down Page 15

16 [Integration architecture] Merit of asynchronous messaging (cont.) Load balance Page 16

17 [Agile development overview] Business driven agile development Enhance systems in a short release cycle (e.g. monthly) Pro Con Shorten Time-To-Market Improvement ideas from business people can be implemented in a short period of time Uncertainty Requirements are not fixed beforehand Page 17

18 [Agile development overview] Myth on agile development Release cycle period == development cycle period (requirements definition, development, QA and release) Page 18

19 [Agile development overview] If release cycle period == development cycle period Pro Process is simple Iterate mini-waterfall sequencially Con Workload of each role varies cyclically Waste of time/workload would happen Page 19

20 [Agile development overview] If release cycle period == development cycle period Pro Process is simple Iterate mini-waterfall sequencially Con Workload of each role varies cyclically Waste of time/workload would happen Page 20

21 [Agile development optimization] Constraints on agile development optimization Contracts to allocate development resources (with IT vendors) Time and material contract Flexible enough for changing requirements Project owner must take big responsibility Trust in IT vendors that provide best effort development service is required Win-Win relationship [c.f.] Fixed-price contract Requirements must be fixed beforehand IT vendors must take big responsibility Contract is most important Win-Lose relationship Page 21

22 [Agile development optimization] Solution not to waste time and workload : Initial approach Utilize items stock Page 22

23 [Agile development optimization] Solution not to waste time and workload : Initial approach (cont.) Utilize items stock Cons Difficult to manage release items Requirements and priorities are not up-todate Many place of stock are necessary Release target of an item is not clear at the time of development Just convert waste of time to waste of stock Page 23

24 [Agile development optimization] Solution not to waste time and workload : optimized approach Synthesize multiple release cycles Page 24

25 [Agile development optimization] Detailed example in a financial institution Release cycle = 4 weeks, development cycle = 10 weeks Business planning department: Requirements definition, user acceptance test and release preparation/follow-up System department: development Page 25

26 [Agile development optimization] Detailed example in a financial institution (cont.) Release cycle = 4 weeks, development cycle = 10 weeks Business planning department Requirements definition and release preparation/followup in parallel Page 26

27 [Agile development optimization] Detailed example in a financial institution (cont.) Minimize items stock Utilize bottleneck resources at the maximum [c.f.] Drum-buffer-rope (DBR) in theory of constraints (TOC) Page 27

28 [Agile development optimization] Detailed example in a financial institution (cont.) Summary By role/department Field users Items are released every 4 weeks, 2 months after requirements definition Business planning department Necessary to do tasks for multiple release targets in parallel => Task and time management skills are required System department Developers are kept busy with constant workload => Easy to contract because resource assignment can be fixed Overall => Planning and release items coordination skills are required Page 28

29 [Offshore development teaming and environments] Assign items to offshore sites according to module type Pre-requisite : Loose coupling between modules and items based on service oriented architecture (SOA) GUI, business rule : mainly assigned to offshore resources Many, mid-skill resources : 80% of entire workload Model / Integration logic : mainly assigned to onsite resources Little, high-skill resources: : 20% of entire workload Page 29

30 [Offshore development teaming and environments] 24-hour development based on offshoring Develop items in a short turnaround time by transferring them between offshore sites E.g. Item X Develop 8 hours in site A => Transfer to site B Develop 8 hours in site B => Transfer to site C Develop 8 hours in site C => Transfer to site A Page 30

31 [Offshore development teaming and environments] 24-hour development based on offshoring (cont.) Not adopted in this project Reason Solution in this project Avoid overhead of transferring items between sites A short turnaround time of items development is not a high priority requirement => High throughput of development and cost reduction are high priority requirements Assign each item to one site E.g. Item X : developed in site A Item Y : developed in site B Item Z : developed in site C Pre-requisite : Loose coupling between modules and items based on service oriented architecture (SOA) Page 31

32 [Offshore development teaming and environments] Environment for development, build, deployment and testing Page 32

33 [Consequences of agile methodology optimization] Improvements in development throughput and quality Metrics Development throughput Development resources utilization: target = 100% Development quality QA initial pass rate : target = 100% Page 33

34 [Consequences of agile methodology optimization] Improvements in development throughput and quality (cont.) Time series data of metrics Page 34

35 [Consequences of agile methodology optimization] Improvements in development throughput and quality (cont.) Average values of metrics : before/after optimization Development resources utilization : 128.6% => 95.6% QA initial pass rate: 70.1% => 87.3% Subsequent effect of stable release items management Page 35

36 [Summary] Elastic architecture Service oriented architecture (SOA) Isolation between GUI, business rule and model/integration logic Integration with external systems via service bus Integration architecture utilizing asynchronous messaging Shorten GUI response time Minimize impact of system issues Load balance Page 36

37 [Summary] Elastic methodology Business driven agile development Allocate resources based on time and material contract Levelize workload by synthesizing multiple release cycles Release cycle = 4 weeks, development cycle = 10 weeks But Task and time management skills are required for people in business planning department Planning and release items coordination skills are required Page 37

38 [Summary] Offshore development based on SOA and agile development Pre-requisite Loose coupling between modules and items based on service oriented architecture (SOA) Items assignment policy Assign items to offshore sites according to module type GUI, business rule : offshore, 80% of entire workload Model / integration logic : onsite, 20% of entire workload Assign each item to one site For high development throughput and cost reduction 24-hour development are not adopted Page 38

39 [Summary] Consequences of agile development optimization Development throughput Development resources utilization (target= 100%) 128.6% => 95.6% Development quality QA initial pass rate (target = 100%) 70.1% => 87.3% Subsequent effect of stable release items management Page 39

40 Ernst & Young ShinNihon LLC About Ernst & Young Ernst & Young is a global leader in assurance, tax, transaction and advisory services. Worldwide, our 152,000 people are united by our shared values and an unwavering commitment to quality. We make a difference by helping our people, our clients and our wider communities achieve their potential. Ernst & Young refers to the global organization of member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients. For more information about our organization, please visit About Ernst & Young ShinNihon LLC Ernst & Young ShinNihon LLC is a member firm of Ernst & Young. We are the leading audit firm in Japan, with the largest number of people, and with offices throughout the country. We are committed to providing the highest quality audit and assurance services, and to offering a range of other financial advisory services. Together with the Ernst & Young global network, we strive to ensure trust in our capital markets and improve their functioning to achieve the potential of the global economy and our wider communities, which surround Japan. For more information, please visit This publication and the materials referred to therein contain edited information in summary form and are, therefore, intended for general reference purposes only. They should not be used for specific purposes, or as a substitute for detailed research or the exercise of professional judgment. Neither Ernst & Young ShinNihon LLC nor any other member of the global Ernst & Young organization can take responsibility for the accuracy, completeness, applicability for purpose or any other aspect of the contents and nor shall they bear any responsibility whatsoever for loss occasioned to any person acting or refraining from action as a result of any material in this publication or the materials referred to therein. Page 40