The changing Development Organization Yogish Pai A structured blog by Yogish Pai

2 Following is an example on how the IT projects are categorized and funded. This approach is not expected to change in the near future and is reflected in the IT organization. eBusiness Solutions: Portal Applications for both internal and external users Packaged Applications: For providing point best of the breed solutions Integration: Ability to integrate applications, portals and data across the enterprise (LOB) Infrastructure: Data Center, Networks, servers, Software Platforms, etc.

3 Typical Application Life Cycle approach adopted across the enterprises Business Requests Reqm ts. Gathe ring Qua lity Ass ura nce Sol utio n Dev. Sol utio n Des ign Feasi bility Analy sis Pos t Dev. Sol utio n Sup por t Packaged Applications eBusiness Solutions Integration Initiatives Infrastructure Initiatives IT FTE PMO / PM Business SI / Vendor

4 The current approach developing and deploying new capabilities, which over time shifts majority of resources to support – increasing the overall IT cost Business Requests Reqm ts. Gathe ring Qua lity Ass ura nce Sol utio n Dev. Sol utio n Des ign Feasi bility Analy sis Pos t Dev. Sol utio n Sup por t Packaged Applications eBusiness Solutions Integration Initiatives Infrastructure Initiatives IT FTE PMO / PM Business SI / Vendor End Result: As resources get diverted to support new capabilities, the more IT delivers the less they are appreciated, especially as the cost of developing new capabilities keeps going up over time SOA Development Organizations Objective: Allocate resources as an as need basis, whether it is new development of support

5 Following is an example of organizations change that facilitates an Agile IT and the same model could be applied to applications once they also adopt the Services Component Model Business Requests Reqm ts. Gathe ring Qua lity Ass ura nce Sol utio n Dev. Sol utio n Des ign Feasi bility Analy sis Pos t Dev. Sol utio n Sup por t Packaged Applications eBusiness Solutions Integration Initiatives Infrastructure Initiatives IT FTE PMO / PM Business SI / Vendor Composition Team Team focused on capturing requirements and wiring business assembly models Members: Business, Analysts, Architects Development Organizations Organized by their specific functions they performs and can work independently of each other – based on the model developed by the composition team UI Team: Develop the front end – SI/Vendors Services Team: IT FTE developing business logic Data Team: Model and develop the data QA / Performance Team: Build, test and deploy services No dedicated application support teams required

6 Following is an alternate view of the development organizations with IT – typically the high cost of development is for Business Interaction (Portals) and Data Services. Legacy / COTS Data Services Services (Business Logic) Business Interaction (Portals) Development Teams Support Teams Large team size (preferably SI/Vendor) for initial implementation or upgrade Small teams (preferably outsourced) for supporting this layer Dedicated small team to develop and support shared data services (EII & ETL) that exposes Enterprise or Project Objects to the services team Dedicated small team to manage the Services layer. Services and business processed developed as part of each project Dedicated Project team to develop business capability Dedicated support team (preferably outsourced) to maintain applications Number of Resources Required Case-by- Case basis Enterprise Architecture team pull this all together  All development is based as per the model put together by the Composition team consisting of Business, Analysts, Architects and Project Managers  No dedicated development or support team – they work down the priority and bugs (wrong logic) take higher priority over developing new capabilities of the same priority

7 Phase 1: Focus on the Service Orchestration and Management  Adopt the Shared Data Services approach and dedicate a small team to develop and provide the shared data services to the project teams  Project teams eliminate the need of developing entity beans/repository layers  As number of services grow – adopt the Enterprise Service Bus Phase 2: Focus on externalizing Business process  Leverage COTS for business process provided out of the box  Project team to implement custom shared business process (create shared business process development team, if required)  Upgrade/Migrate packaged applications to standards (JSR-168 & WSRP) Phase 3: Create a dedicated Portal team  Configure role based portals to create a personalized user desktop/workbench/portal Phased approach to deliver capability over time Implement the organization changes in phases and teams could be spread out across multiple locations

8 Benefits of adopting such an approach reduced overall cost while enabling IT agility Entire team focused on items that business identifies as top priority  Eliminate support teams working on low priority enhancements Phased approach reduces risk and enables enterprises / LOB adopt SOA  Shock treatment not required to migrate organization to this model Leverage COTS for Business Capability and Platform for pulling it all together  Adopt similar model for COTS wherever possible, to enable organizations flexibility Lower cost as fewer highly skilled resources required

SOA – Development Organization Yogish Pai