This piece is based on my experience working for big corporations but somehow, surprisingly applies to smaller establishments too.
Now for a while imagine a company. This reputable company with established business model has a portfolio of applications to support that business. From of-the-shelf Microsoft Exchange server and file sharing to customized boxed products to bespoken applications. Now this company has a system, let's system A, that helps with the core od the company business. Be it selling stuff, taking orders, managing customers. The system A is pretty hairy one - has been around for a while. As the company's employees come and go the company finds itself in situation where the core developers (and subject matter experts) have left the company but the company still needs to maintain the system.
First, they try to understand the system. But it's hard. Lots of these systems are a) quite complex b) poorly (if at all) documented c) written long time ago hence using languages and frameworks no longer used. All in all the most sensible approach is to actually rebuild the system from ground up.
To do so, the company hires managers. First, managers come up with business case. Sometimes they skip this step, but that's unlikely. Once business case is approved, they come up with things like governance, procurement et cetera. Obviously they also introduce planning and estimation. In most cases, no developer is involved. And all the reported indicators show green. One of the first steps in the process of superseding the system A with system B is to call in a consultancy company. This company quickly rubber stamps the need for replacing system A highlighting many shortcomings of it. Based on their findings a PowerPoint presentation is made and shown to the whole company (department) that clearly shows incompetence and ill-thinking of the authors of the system A. Many times the presentation contains analogies to old cars, houses, broken tools - you name it, so it's absolutely clear that system A is beyond repair and the authors should be punished. After the system is has been successfully humiliated it's time to build the new system B.
It all starts with requirement gathering. It's complicated. SMEs (subject matter experts) are hard to get hold of, and if you can get hold of them they sometimes don't remember everything, sometimes even contradicting to each other. But you do the best to figure out what's needed to do. After this painful exercise you move on to the development phase. All indicators are still green and everything goes according to the plan.
You usually pick the best developers with some experience with the system A. Any work on system A is put on hold in anticipation of the system B. System B will be coming soon so it makes no sense to improve it or dilute the effort. 3 months down the line and indicators go to amber. No matter what technology, the experience of your developers, there's always challenges, changes, unexpected complications. Your system B is much more complicated requiring new or hardly tested technologies. To add insult to injury users of the system A are really nervous and want their new ideas to be implemented into it. It's getting more and more difficult to explain the benefits of system B and why it is worthwhile to wait for it. So finally some developers or hired/diverted to support system A. That further slows downs progress of the development of the system B. First, you lost some hands, second you made the development of system B a moving target. As new features are added to system A you need to add them to system B as well.
At this stage many managers get nervous and start to go for compromises. No more TDD, no more free weekends, no more this, no more that. That's the disillusion stage. The hardest one. Also the breaking point. Decision made during this stage shape the delivery/not delivery of system B. It's up to the product managers, organization, processes and other factors if the system B is going to be delivered or shelved and people participating blamed.
There's a few things you should keep in mind when replacing some older core company system.
1) Even during the reimplementation phase it's the system you're replacing what pays the bill - so be considerate.
2) Never stop working on the system you're replacing. The replacement system may never be replacing the original one and you don't want to lose out.
3) Appreciate that the the replacement system will lack all the features and complexities the original system has.
4) Avoid any big bang releases. Shout when you here this "System B goes live on Saturday and we decommission system B the day after that". That smells.
5) It usually helps if you replace one aspect of the legacy system at a time. Just to prove the system can be replaced in its entirety.
6) Give user quick demo as you're building the replacement system every now and then. To keep the users in loop and engage. You going the need the users' support to get you through the teething problems phase.
7) Make sure there's sound reasons for replacing the legacy system and all other options have been exhausted. "Java is too verbose", "it doesn't support HTML5", "it's not an SPA" are hardly considered as sound reasons.
8) Before starting to implement the new system make sure it's the user who actually want it. Make sure it's them who make the IT team to write it.
9) Virtually all medium to large size corporations have their own bespoken or heavily customized systems. Be very suspicious when the rain sellers start to appear to sell you the of-the-shelf solution that needs to be tweaked a bit and will do exactly what you need.
10) I'm sure there's thousands and thousands more things you should be aware of.
No comments:
Post a Comment