Morgan McCollough Bridge360


1 Comment

Is Silverlight Right for Your Development Team?

by Morgan McCullough

Before making the choice to use Silverlight or any other development tool, it is always important to examine the requirements and trade-offs.

Because Silverlight is a Web technology that allows the creation of rich Internet applications, it is positioned to offer many of the same benefits as a traditional Web application. The application can be centrally located and managed, and because it is accessible over the Web, can be used through corporate firewalls and does not require installation on client machines. Also, there is less need to move data around between disparate systems and a single interface can greatly simplify data access and security management. In general, Web applications are more manageable, highly deployable, easier to secure, and very often less expensive overall.

In light of all this, the question becomes what Silverlight offers above and beyond a traditional Web application that uses a combination of HTML, CSS, and JavaScript to create the client experience. In a business environment where Web applications have become commonplace, the capabilities of Silverlight must be compelling enough to make it worth the cost of time and resources. As with any new technology, the reality is that working with it effectively takes an investment for the development team to become familiar with its capabilities and pitfalls. An existing development team may be able to produce a traditional Web application with many of the same features as a Silverlight application in a shorter amount of time if you factor in time lost to research and study. Continue reading


Leave a comment

How to Maximize ROI When Re-Facing Legacy Systems

by Chris Durand

Over the last few years we have completed a number of “legacy modernization” projects wherein we build a browser-based user-interface for iSeries (AS/400) and 3270-based applications while keeping the business logic in the host application (“re-facing”).  Here are a few things we’ve learned:

Re-facing without Extension is a Waste

The main reason a browser-based interface to an application is useful is because everyone knows how to use a web browser.  If all you are doing in your web interface is converting function keys to clickable links and adding eye-candy, you will struggle to find enough ROI to make it worthwhile.  If you are trying to eliminate costs associated with deploying green screen emulator software to user desktops, you are better off deploying a web-based emulator product instead of beginning a screen re-facing development project. Continue reading


Leave a comment

Minimizing Risk in an Agile Approach

by Phillip Smith

The discussion about which project management approach to use is irrelevant if the chosen approach is not implemented correctly. The IT industry, while relatively young, does have reasonably well thought out software development processes (SDP’s) that are mature and reliable. Taking shortcuts within an SDP is never a good idea.

Whether using agile or waterfall, always make sure your plan includes stable requirements, optimized design, and rigorous testing. You should never tailor out critical deliverables, breeze conditionally through tollgates, or attempt to support truly impossible timelines.  It is better to execute in a reliable and true fashion and finish the project the right way, with quality. Stated another way, project managers should never use a difficult timeline or a low budget to justify chaos.

For example: in an agile approach, if you start with a very large scope and parse it into smaller components, and then execute all of the SDP phases for a single component prior to going in to the requirements for any other part of the scope, you will be running a great risk.  The lack of definition of follow-on components, combined with the finality of having the first component implemented, will certainly lead to integration issues and rework.

Continue reading


Leave a comment

Options for Modernizing Legacy Systems

by Chris Durand

Say you have an existing iSeries (AS/400) or mainframe “green screen” application.  It’s been around for a long time and has a solid, reliable code base based on years (decades?) of testing and real-world use.  It generally works pretty well, and doesn’t change much.

That’s all great until you find that as the business is moving forward it is becoming increasingly difficult to update the application to support the future business direction.  Sure, you’ve found a few creative solutions to work around application limitations so far, but fundamentally you need something other than a short-term fix.

You basically have the following modernization options:

  • Rewrite it using the language/technology/platform of your choice.
    • Pros: Complete flexibility to keep what is working and rework what is not.
    • Cons: Expensive.  Risky (does anyone really know all the business rules buried in decades of code?).  Slow to implement.
  • Convert the code to a new platform using an automated tool.  I’ve not had experience with this, however, I suspect it is cheaper than rewriting, but still very risky.  Plus you probably don’t get the full benefits of a true rewrite. Continue reading