The changing Development Organization

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

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

3. Typical Application Life Cycle approach adopted across the enterprises IT FTE Business Requests Feasibility Analysis Reqmts. Gathering Solution Design Solution Dev. Quality Assurance Post Dev. Solution Support PMO / PM Business SI / Vendor Packaged Applications eBusiness Solutions Integration Initiatives Infrastructure Initiatives

4. The current approach developing and deploying new capabilities, which over time shifts majority of resources to support – increasing the overall IT cost IT FTE Business Requests Feasibility Analysis Reqmts. Gathering Solution Design Solution Dev. Quality Assurance Post Dev. Solution Support PMO / PM Business SI / Vendor Packaged Applications 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 eBusiness Solutions Integration Initiatives Infrastructure Initiatives

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 IT FTE Business Requests Feasibility Analysis Reqmts. Gathering Solution Design Solution Dev. Quality Assurance Post Dev. Solution Support PMO / PM Business SI / Vendor Packaged Applications Composition Team Team focused on capturing requirements and wiring business assembly models Members: Business, Analysts, Architects eBusiness Solutions 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 Integration Initiatives Infrastructure Initiatives

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. Development Teams Support Teams Dedicated Project team to develop business capability Dedicated support team (preferably outsourced) to maintain applications Business Interaction (Portals) Number of Resources Required Dedicated small team to manage the Services layer. Services and business processed developed as part of each project Services (Business Logic) Enterprise Architecture team pull this all together Dedicated small team to develop and support shared data services (EII & ETL) that exposes Enterprise or Project Objects to the services team Data Services Large team size (preferably SI/Vendor) for initial implementation or upgrade Small teams (preferably outsourced) for supporting this layer Case-by-Case basis Legacy / COTS • 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. Implement the organization changes in phases and teams could be spread out across multiple locations • 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

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

9. SOA – Development Organization Yogish Pai