Best Practices for Successful Legacy Modernization: Security

This month, Sony completed restoring the PlayStation Network only to receive another security breach in its entertainment distribution branch. The attack was reportedly preformed by using a single SQL (Structured Query Language) injection. The data breach compromised one million users’ personal information.

Legacy systems generally are being modernized using SQL databases with access using JSP (Java Server Pages) or JSF (Java Server Faces). Statements sent to JSP/JSF are processed by the servlet, which in turn calls a DAO (Data Accessor Object) to query the SQL database. A SQL injection takes advantage of bad practices of allowing any input text to be directly used in the translation of an SQL query.

This could have been prevented during the design phase by providing key constraints to fields, using Dynamic SQL calls from stored procedures and checking statements for validity before issuing the call to the DAO. During testing phase, the input fields should have provided significant testing for ensuring that a user would not be able to place SQL commands in any of the input fields. Instead, programming errors occurred and best practices were not followed, which caused a massive data leak of personal information.

When modernizing a legacy system, one must remember to be wary of the people who are accessing the system and safe guard them from any illegal attempt aimed at retrieving personal data. In order to create a successful and robust system, using the best practices in both the design and testing phases of a modernization project can prevent situations like this from occurring.

Link: http://www.thewhir.com/web-hosting-news/060311_Hackers_Attack_Sony_Pictures_with_Single_SQL_Injection


Posted on Thursday, June 23rd, 2011 at 3:19 pm and is filed under Legacy Modernization.

« Previous Entries

By: Raymond Shum

— »


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.

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

« Previous Entries

By: Computech

« — »


Those who ignore history…

Let’s dive into the good stuff — the first of three posts dedicated to legacy modernization best practices.  Credit for this insight goes to Larry Fitzpatrick + Stuart Tweed (our Legacy Modernization practice leader currently supporting modernization efforts at the Department of Homeland Security’s Customs & Border Protection).

1. Learn from the past 
Whether client or service provider, do the homework. Learn about the history of the project:

  • Why was the application created?
  • What led to its success?
  • What drove modifications? 
  • Most importantly, what other efforts preceded this one to rebuild or replace the application? 

Past efforts will have produced valuable artifacts that you can leverage, or can illustrate pitfalls and bad choices. Most important of all, the history will help you learn the stakeholder terrain. Be aware of who will ally and who will repel change, and why, and who has the most knowledge useful to a replacement activity.

2. Re-evaluate the business goals 
Know what problem you are solving and re-validate the business case and get clarity around the business goals. This is a corollary to the carpenter’s dictum: measure twice, cut once. There are many valid reasons to replace a legacy system and some not so good ones. Frequently, the perceived urgency to replace the application or the money to be saved is dramatically overstated. Oft heard is “I won’t be able to find these skills in a few years.” A small investment in salary and training to attract fresh skill is a drop in the bucket compared to the cost to replace a system. You really must answer the question “Why now?” Never underestimate our ability to preserve the status quo.

3. Don’t underestimate the complexity 
Eager to proceed, project managers or engineers often mistakenly assume equivalence between software metrics from old and new systems. Their sense of metrics has been calibrated against systems they have recently created. Thus, they think they know what 100 KLOCS, 500 KLOCS, and 1,000 KLOCS feels like. But they’re wrong – a legacy KLOC and a new-code KLOC are not the same. Old applications have almost always lost architectural integrity, have had man-decades of enhancements that address increasingly complicated exceptions to business process. Logic becomes so complicated that it in critical places it’s impossible to hold even small fragments of code in ones head. Underestimation puts the plan at risk, as well as, all the expectation management that goes along with the plan. Underestimation is sure to alienate the current users and support staff. They will think (rightly) that you are so obviously ignorant that you will fail, so why should they waste their time to help you? You will need their support.


Posted on Friday, October 30th, 2009 at 7:46 am and is filed under Legacy Modernization.

« Previous Entries

By: Computech

« — »


A history lesson

Yesterday, we started to talk about the challenges organizations face as their mission critical custom applications morph into legacy systems.  Today, we’re going to take a step back and share something of a history lesson in terms of modernizing these vital applications.

“A Contractor’s Fable”
Larry Fitzpatrick

Like so many good stories, the legacy modernization one draws inspiration from historic fact. For many years, large systems integrators framed a modernization effort in technology terms. After all, they reasoned, the required replacement stemmed from obsolete technology. Consider the support costs for the underlying commercial platforms: exorbitant they extolled. And your code: far too complicated to modify for legitimate business changes. You need to manage your risk! As production outages hamstrung the business, old technologies precipitated calls — both internal and from these vendors — for radical change to this proverbial house of cards.

To begin the painful legacy modernization cycle comes with a simple declaration: if the system is large, the solution approach must be large, too! After decades of change and growth of the business, lines of code numbered in the millions, transactions processed each day may exceed tens of thousands, budget line items for support are a noticeable percentage of the business expense, and because most of the business staff interact with the application almost every day, the MCCA has become a tolerated way of life. For very large solutions there is only one answer – a large contract with teeth, awarded to one of the big boys, a integrator with the initials sure to appease risk managers and lawyers alike. After all, who else can staff the hordes of programmers required for this massive project?

Who else has the experience solving these problems (they run lots of these applications every day), who else will be so invested in the outcome that failure isn’t an option? Because the modernization activity is a technology problem, the solution can be isolated from the day-to-day of the business. The large vendor stands up a new team skilled in the new technologies that form the target architecture. Because this project is so big and will take a while, vendor and client agree to add lots of features during the replacement. Additional staff is required. Finally, a contract mechanism is created to ensure that the new system does what the old system does – requirements documents. The vendor starts hiring immediately and builds a team ready to work together for the first time. The legacy team isn’t needed for this activity (or even consulted); after all, they are the ones who let the existing system get into such a state! The project managers build glorious schedules with infinite detail that show the first release just three years away. Programming begins. Exuberance dominates the ethos as the excitement of starting a new project infects everyone.

But as the years grind on and the deadline for the first release approaches, doubt emerges. There has been no sighting of working code. Or at least anything that behaves like the existing system. Eventually the deadline looms without a prayer of a delivery and the obvious cannot be hidden anymore. The date needs to move. But, it’s just a matter of planning. We need more planning. Project managers are replaced and new, better ones arrive. You can tell where this ends. The project was framed incorrectly, a number of starting assumptions weren’t validated, a number of clues along the journey were missed, and expectations are now wildly out of whack. No late fourth quarter drive can rescue this campaign.


Posted on Thursday, October 29th, 2009 at 7:53 am and is filed under Legacy Modernization.

« Previous Entries

By: Computech

« — »