The current developer shortage is creating problems for IT businesses across the board. Despite the broad scope of the problem, one way for you to begin dealing with it is to identify the platforms your company will have to support. Then you can decide how you’ll organize your development staff to tackle the development engagements that you’ll send to them. But until you’ve decided how you will organize your team, you can’t begin recruiting or training your team members.
I’ve spent a lot of time in the last year working with companies on creative ways to re-architect their development teams. They’ve recognized that their current teams aren’t organized to deal with the rapid advances in development technologies and the continual dramatic changes in the available platforms.
Based on this work, I’ve discovered that you can choose to organize your development staff by product or by tier. Let’s look at each of these in detail.
Building a product-based development organization
Most traditional development organizations are composed of development groups centered on the product offerings for an organization. For example, the development shop for a financial institution would include development groups for:
- Tellers and bank managers (a.k.a. platform systems)
- Loan origination
- Bank card processing
- Private banking
Each of these development teams would also have systems analysts, software developers, software testers, and documentation writers. Each group would work together to support the currently installed system and design and deploy future versions of the systems for which their group is responsible.
Senior managers (CIO and vice presidents in information technology) would be responsible for sharing their vision and providing unifying architecture for the particular product groups. The biggest advantage of this type of developer team organization is that the company can capture the operations knowledge for a set of systems in one place. As team members change, enough members remain to keep retraining new recruits on the existing systems.
There are, however, several major disadvantages to this kind of organization. First, there’s more of a tendency to do things “the way they’ve always been done.” The longer someone is on one of these teams, the less likely they are to change to another team or learn a new skill set.
They will also see their career opportunity as being a “senior developer on the platform systems team” and be less willing to work in other development areas. The more tenure people have on the team, the more sedentary the team members become.
Second, there’s less of an emphasis on making sure systems work together instead of creating systems that are easier for each team to maintain. Even with senior management encouraging a common architecture, it becomes difficult to enforce in the face of pressure to meet code deadlines.
Building a tier-based development organization
Another way to arrange the development organization is to structure it based on application “tiers.”
At first blush, this may seem to be only significant in companies doing modern, three-tier development. But many existing mainframe shops are organized today with developers who write presentation tier code (COBOL), business logic code (CICS or IMS), and database code (DB2 or COBOL routines to manage VSAM files). In fact, you’ll find that these three “tiers”—presentation, business, and database—will be present in any development organization that organizes by tier instead of by product.
In these types of development organizations, you’ll group developers by skill set and have them working on multiple projects. For example, in a Microsoft shop, you may arrange your developers this way:
- Presentation tier: HTML, DHTML and XSL developers, Java Developers, VB developers creating client side components, ASP developers
- Business tier: Visual Basic and C++ developers writing COM Objects for business logic, Microsoft Transaction Server experts, MSMQ experts, SNA Server integration specialists, XML Schema developers
- Data tier: SQL Server architects and stored procedure developers, Visual Basic and C++ developers writing COM objects that supply data to business objects
Advantages and drawbacks
The greatest advantage to this type of organization is that teams have an incentive to re-use code across multiple systems instead of creating unique code for each system that’s developed. Developers also work on multiple projects across departmental boundaries, so they have a better appreciation for what their company does.
This type of organization can produce a more tightly integrated system with more code sharing than its product organization counterpart.
The main problem with this approach is setting priorities for projects. In order for this organization to work, the company still has to have “product advocates” or “product managers” whose jobs include dealing with tasks such as setting deadlines, managing budgets, and establishing user expectations. These product managers will work with “customers” (in most cases, company employees) to define the product and measure the effectiveness of the product compared to the initial expectations.
The best answer depends on your customers and systems
Whichever approach you take, you’ll certainly have elements of either strategy in your development organization. Product-based developer organizations generally have an advanced technology team or some other entity that focuses on issues arising from “tiering” of code.
Tier-based developer organizations have to enlist product advocates to manage schedules and expectations. Both organizations should work closely with their quality assurance (testing and help desk) and operations (deployment and systems management) departments to assure that systems can be deployed, managed, and supported properly. Once you’ve got your organizational panel in place, it’s time to recruit, create, and retain great developers.
Tim Landgrave is the founder and CEO of eAdvantage. His company assists small to medium enterprises in the development of their electronic business strategy.