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

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.

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

Post Dev. Solution Support 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

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

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 Legacy / COTS Case-by-Case basis Large team size (preferably SI/Vendor) for initial implementation or upgrade Small teams (preferably outsourced) for supporting this layer 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

Phased approach to deliver capability over time 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

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

PRELIMINARY Year 1 Year 2 Role Based Portal (A) Sales, Services, Marketing (B) Customers, Partners (C) Support (A1) (A2) (B1) (B2) (C1) (C2) SOA Framework Components (1) Component one (2) Component two (3) Component three (1) (2) (3) Business Process 1 (4) Module 1 (5) Module 2 (4) (5) Business Process 2 (6) Module 3 (7) Module 4 (8) Module 5 (9) Module 6 (10) Module 7 (6) (7) (8) (9) (10) Business Process 3 (11) Module 8 (12) Module 9 (13) Module 10 (11) (12) (13) Business Process 4 (14) Module 11 (15) Module 12 (16) Module 13 (17) Module 14 (14) (15) (16) (17) Business Process 5 (18) Module 15 (19) Module 16 (18) (19)