« Don't Say I Didn't Warn You| Main | No I don't wanna do that »
Scaling Back: What Do You Need For A Small IT Shop?
It's good to help people, plus I thought I'd give the luggage a break.
One of the things I've found is that there are a LOT of small IT shops out there -- shops with 1 or 2 developers and a manager, or shops with 20 people and a couple of managers. These shops are tasked, mainly, with keeping the lights on and the bailing wire and duct tape all secure. Call integration management. But some folks are seeking to do greenfield development as well. One of the neat things I learned is that some of the local governments in Virginia are actually building new systems and then sharing among themselves. That way localities all over the state can have the benefit of hundreds of IT workers without huge budgets. Very cool.
So what do you need to run a shop like this -- bare bones? Let's say you got enough money for three people. I won't count management or network support. What kinds of hats should you have?
- Business Process Modeler/User Representative - Somebody has to keep an abstract view of what's the reason for doing anything in quasi-technical terms. More and more, shops are beginning to understand that by modeling and valuing the business processes, they are better able to make build/buy and insource/outsource decisions. Note -- this has to be done well, there is no room here for fuzziness. I like Use Cases because the model and the behavior are linked, plus the methodology allows me multiple ways to cross-check to make sure we aren't forgetting anything. Clear, mutually orthogonal use cases are the lifeline: and it's what you are doing anyway when you make business decisions and charter projects, just at a higher level of formalization.
Somebody also has to represent the poor user, and no, this isn't always the user. Yes, get the users in there as much as possible and bring them as close to the development as you can. However, reality is reality. While the team should always participate in requirements sessions (especially in small teams), somebody has to have the ball when it comes to making sure the user's interests are coordinated. Everybody should be looking out for the user, but somebody needs the onus to be the point of contact. The BPM is the best person for this.
- DBA/Enterprise Architect - Now that you understand why you are working, what's it going to look like? The connections, the classes, the physical structures -- this is the guy for all of that. Somebody has to champion EA, especially in a small shop! This person had better be making sure that all of the little applications use the same data store (if appropriate), the same standards, the same deployment pattern, etc. The most critical fractor in any kind of small-shop, do-it-yourself-programming is to make sure you have the money to maintain it once it is built. Development only represents about 10 percent of Total Cost of Ownership. Listen up! What's easy today won't be so easy when it is done 12 different ways on 40 different projects ten years from now.
It's also important for somebody to be looking forward to new technologies and paradigms of development. the EA/DBA spot seems most suited for this. Somebody should be figuring out what are the common problems in the currently deployed code, which is also an EA/DBA thing.
- Developer/UI Expert - This is the work most of us think of when we think of software development, which is strange. It would be like thinking building skyscrapers was mostly about carrying boards. Developers put the pieces together and frame up and fill out the structure. The architecture should already be done, the UI guidelines should already be in place, the data tier may have already been written. If your developers think of themselves like Picasso, then you may want to think about whether you are building an art gallery or a software portfolio for your organization.
The UI expert should also be concentrating on how things are supposed to consistently look and feel. A good User Interface experience means savings in training dollars (and the ability to temp out work if necessary), less strain on the users, and happy feedback. Everybody likes happy feedback! The UI guy usually gets stuck with reports too, since the UI and the printed result are so close conceptually. I like to think that the UI guy is the "face" of the organization -- their work makes the difference in perception of what's going on. Remember: perception is everything. You may have a top-notch tool configuration, standards, and environment, but if you don't have a good PR shop, you ain't got bupkis.
Having put down these ideas, everybody has to do everything! The worst thing possible is to get into a mindset of "that's not my job". The reason why I was able to skip over things like testing, CM setup, A&D, etc. is that I'm assuming that _everybody_ will be doing those things. Everybody is valuing business processes, everybody is building the architecture, and everybody is programming. It's mission-critical in small shops that you do not compartmentalize software development - -there is simply too much complexity in modern programming for the pizza-under-the-door approach.
These are some ideas to think about. You can work this a million different ways: I think it's fun to wonder what the fewest number of important hats you need, that's all. Got a better idea? I'd like to hear about it.
Leave a comment