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

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

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

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

10. 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)