Got Legacy?

Now program languages and their types are more centralized in the TLM Repository! Your Programs will be thrilled! When you write parsing rules for languages, you can upload your scripts and rules directly to the repository!

• First, write your Program language parse rules in an SVN repository.
• Direct the TLMR to that SVN repository.
• Then, add a type and attach your respective language to it.

You can even update your language or type from SVN: just a single click!

See you in Version 6,
The product development group.

Share on Facebook

Today MAKE brings you the inspirational story of COREY the robot. Click HERE to read the entire book! Suitable for children and adults alike.

Share on Facebook

With the TV programming spectrum being so spattered by reality shows I thought of making a simplistic analogy between the work we do here at MAKE and the “Makeover” series that you can find on different channels about so many different things that need to be modernized, improved or renovated for whatever reasons.

Legacy MAKEover?

I have to admit the one I like to watch is Restaurant Makeover. If you haven’t seen it yet, it kind of goes like this: The owner of a beat up and dull restaurant realizes that it’s time for a change, time to modernize and transform this joint into a five star restaurant. Wow! Sounds brilliant, but the task is not an easy one, especially if the owner in question has run this business for years without really adding much value to his/her customers. Suddenly, the owner needs architects, construction workers, designers, and of course, the restaurant’s chef also needs to learn new tricks, so there is a learning curve to go through and knowledge transfer that has to happen. Otherwise, what’s the point of doing all this? So, what does the owner do? He calls the experts! And the channel’s seasoned experts are a team that includes an interior designer, a crew of construction workers, and a chef. The team, of course, is not always the same but they are really good because they almost always deliver with the client’s complete satisfaction. They also seem to have lots of fun while they’re at it. Oh, and one more thing: The channel matches dollar for dollar the owner’s contribution for the makeover. Once the owner is convinced to move forward, the project starts.

In the early phases of this makeover, the construction crew smashes counters and walls, rips electrical fixtures, wrecks floors, shatters mirrors, pretty much destroys the place entirely. Then they bring in the poor owner just to check out how things are going. Their eyes almost pop out, jaws drop, and sometimes they even cry. Others just smile nervously (I imagine this morbid part is the one that scores the highest ratings). The process continues by re-building, re-painting, re-decorating and putting all the new fancy stuff in the right place.

It is really interesting to see the owners’ reaction once they see the transformation after completion. But that’s not all; besides the new modern look, the place now serves top notch food which is now prepared by the local chef who at this point should have learned a lot from the channel’s mentor. And the most incredible thing is that everything is done in one week.

Ok, so what are the similarities with our methodology for modernizing a Legacy System? Well,

1. A client decides it’s time to change an expensive to maintain aging system and chooses MAKE to modernize it.
2. We don’t match dollar for dollar the client’s contribution unfortunately. Hear that mighty TV networks?
3. The seasoned experts are assembled (Project Manager, Data Modelers, Architects, Business/System Analysts, Developers, etc)
4. We don’t smash, rip, wreck nor shatter the old mainframe (although sometimes we’d love to… juuust kidding) but we ask, listen, watch, parse, collect, analyze, model, document, draw, organize, and basically capture everything about the legacy system and put it in a data repository.
5. We have lots of fun while we’re at it. If you don’t believe this get in touch with me and I’ll bring you to one of our status meetings so you can attest.
6. Our clients have access to see the evolution of the entire process without the drama, which means no tears so far (that I know of).
7. We don’t re-build, re-paint, or re-decorate. However, once we are confident about our knowledge of the old system, we design and develop it putting fancy stuff in the right places. We call this streamlining and enhancing.
8. We transfer our knowledge to the client’s staff so that they can take over when we’re done.
9. We also deliver with client satisfaction (yes, including oohs and aahs) but…
10. We certainly don’t do the work in a week. Although we’re pretty fast for software development standards.

Conclusion: There are some approximate similarities between a Restaurant Makeover and a Legacy System Modernization. However, if there is any network out there who wants to cash in with yet another reality show please contact us, although I’m afraid we won’t help making your audience ratings soar. Oh well.

- Alberto Rodriguez

Share on Facebook

The client was reviewing the Modernization Proof of Concept and wondered if this is how the final system will be implemented in the area concerned. As we discussed the things that the client discovered I realized that I hadn’t been clear about what to expect of the POC. Yes, it should look and act like the real system will be expected to act. No, it isn’t cast in stone and might end up being somewhat or quite different in the real system.

We both agreed that the POC’s ability to represent the new system’s look and feel would help with the “Transformation” of many of the users. We also agreed that it would help identify the next level of refinements necessary. The client felt that the overall POC had met the objective of implementing most of the functionality of the narrow area within its scope. It did have its problems.

What do we do now? We don’t refine the POC to get the bugs out, instead we go back to the requirements and update them to drive the Real solution in the right direction. While we might not totally throw away the POC, we mustn’t feel obliged to keep any particular part of it. If we end up starting (almost) from scratch has the POC failed?

On the contrary, in fact it has given us all we could hope for. We have moved everyone a good way down the road toward the new system; we’ve proved that “Adequate” vs. “Detailed” modeling during the Design phase achieved a good approximation that can be refined during the Build phase. We’ve also started the melting of the current state that will allow movement to the future state. Everyone is again on the same page.

From the technical side we’ve achieved the all important objective of proving that the architecture supports the functionality. Let’s not forget that no attempt should have been made to tune or optimize the solution. That of course must wait for the real system in its near final state.

Lessons learned:

1. Before delivering the POC review with the users the goals and objectives along with the constraints of the Proof of Concept;
2. Reap the benefits of greater clarity from the users’ perspective and don’t seek perfection yet.

- Rod Brindamour

Share on Facebook