The Homestretch

Just like a jockey rounding the corner and riding into the homestretch, we are close to the finish line in terms of our legacy modernization posts. We’ve touched on IP issues, iterative replacement strategies, and learning from the past in previous entries. Now, we’d like to round out our thoughts on modernizing your mission critical custom applications. Again, credit goes to Larry Fitzpatrick (with an assist from Stuart Tweed) for providing these final three best practices:

7. Respect the planning phase
The beginning of the project should be a time-boxed planning phase of slightly tight duration. The goal of this planning period should be the coalescence of a core team and to map out the retirement strategy. For maximum risk mitigation, the core team should have four ingredients: the highest level of skill, sufficient experience to ensure utmost respect for the beast before them, smallest possible size that still has working leadership for each functional domain, and legacy knowledge.

8. Concentrate on the existing business process
Technologists like to concentrate on the system, but the business activity that the system supports is the main point. If you can pick only one set of documents to have, it better be the business process models. A large replacement smells like something “new” to somebody, and is subject to getting hijacked as leverage to change the business. Don’t! A good mantra especially in the beginning is: no new features. Adding features and trying to change the busienss are major risk factors. After the replacement is complete, there will be ample opportunity for enhancement. That said, in reality, the team will discover that the legacy system is failing to meet the business needs today, in some areas. Where it is incomplete, ad hoc business processes and supportsystems will have grown up to compensate for the deviation between business practice and the application. Of course, it doesn’t make sense to re-implement features that aren’t used or inject inefficiency, so go ahead and allow the new system to support the actual business process. But keep a close eye for signs that you’re getting trapped on the treadmill of defining new “wish list” features to add to the new system. If you take the approach that it’ll be cheaper while the patient is open7, you may never close the patient.

9. Address user change management head on
Personnel who support the legacy system are often threatened by a replacement activity and defend the status quo in subtle ways. This antipathy must be co-opted. Get senior buy in. Engage and include stakeholders and actively manage change. Do not overpromise and under deliver, or you will be giving naysayers reason for criticism8. One key user can add years to an already lengthy project by obstructing change, always out of a sense of protecting the business. If the system is already the victim of one or more failed replacement attempts, then you are likely dealing with a jaded set of users who may already have honed their skills of obstruction and change management is even more important.

##
What’s next for Concomitantly? Dashboards, dashboards, and more dashboards. Starting on Friday, we’ll begin sharing thoughts on how data-driven dashboards are transforming business. Why Friday? Simple. The University of Maryland’s Smith School of Business will host its 10th annual CIO Forum, and we’ll be there sharing our thoughts on how the “new” generation of Web 2.0 technologies, including social networking and online communities, are rapidly transforming the face of business and government. With our president, Larry Fitzpatrick, leading a panel discussion on Business Models and Sector Transformation, and me introducing the FCC’s new chief strategist, Paul de Sa, we will be well represented. If you can make it down to the Reagan building, I’m sure you’ll find the conversation lively, the crowd engaged, and your time, well spent. Can’t make it? No worries; our marketing manager, Lauren Modeen, will be there blogging and tweeting (#cioforum) for us. Be sure to follow her via Computech’s twitter feed.


Posted on Wednesday, November 4th, 2009 at 9:27 am and is filed under Data Driven Dashboards, Legacy Modernization.

Next Entries »

By: Computech

« — »


Falling back into good habits

Last night’s time change serves as a great reminder to “fall back” into good habits.  One that we’re trying to establish?  Regular posts to Concomitantly (at least twice/week).  With more than 30 years of corporate experience building mission critical custom applications, a long queue has already formed around IT-related thoughts/ideas.  From data-driven dashboards to automating auction processes, we’re excited to share our insight in this forum.  Before we do, though, we owe a few more entries on modernizing legacy systems.  With so many federal agencies still relying on COBOL-built systems, we’re pleased to share three more “best practices” from our president, Larry Fitzpatrick.  Be sure to check out recent posts on the history of legacy modernization, the contractor’s fable, and ignoring history.  Expect to see the final three up on Wednesday.

4. Are you sure COTS will work? 
We believe a default position should be custom rewrite, not COTS package replacement. In the decades since the original system was created the software industry has created many new products. There must be a commercial off-the-shelf software (COTS) package that can more effectively address this need. At least, that’s how the reasoning goes. While this may indeed be true, your mindset needs to be: prove to me that we shouldn’t do a custom rewrite.

5. Keep the Intellectual Property
A software system is a body of code and a team of people. Without the people who currently operate and know (at least some of) the system, you will pay dearly to relearn it. Our experience replacing knowledge-depleted legacy systems tells us that it takes at least two years for a new team to really understand the system and business context. The knowledge of code can be relearned relatively easily, but the intimate knowledge of compensatory and surrounding business processes, which is most often with the legacy support staff, is only relearned by making mistakes — that is a costly way to relearn lost knowledge.

6. Iterative replacement is the safest strategy 
There is no one strategy that works for every system, but there are some strategies that guarantee heartache, if not outright failure. All or nothing replacement, aka Big Bang, is a high-risk strategy. There may be a system that can’t be replaced in pieces, but we haven’t seen it yet. The benefits of having the stakeholder and team see a part of the old system retired and replaced by something new are numerous. Small victories build confidence, processes improve with the practice of delivery, the surprises (and there are always surprises) are smaller and more manageable, and the knowledge learned by delivering offer opportunities for course correction. We would like to share a word of warning, though. The first piece to release to production will be painful and underperform. It’s a new team, change management is immature, and requirements will be missed.


Posted on Monday, November 2nd, 2009 at 7:05 am and is filed under Data Driven Dashboards, Legacy Modernization, Online Auctions.

Next Entries »

By: Computech

« — »