After 10 years of EA/ IT strategy consultancy, I'm looking for a full time position.
Any lead to open vacancies in the states, will be appreciated.
Natty Gur.
|
|
Due to my better half.
Just go to her store and make your call if she's gifted :-)
Roni Gur Etsy Store
|
|
Natty's posts on SDN moved to separate tab - Thursday, April 19, 2007
Due to formatting problems I moved the SDN posts to another tab.
read more...
|
Wanted : Articles about enterprise architecture! - Wednesday, April 27, 2005
We will be happy to publish any article that deals with any enterprise architecture subject. simply send us a mail to editor@theeagroup.net.
read more...
|
Register users can add news! - Saturday, March 19, 2005
If you're registered user you can add your own news to the site home page.
|
Register for peers consulting over skype - Thursday, March 17, 2005
One of the ideas I would like to implement and promote here, within the frame of our EA user group is that of an ‘Instant Peers Consulting’. Whenever one of us faces an acute problem, by utilising our members’ database, we could link him/her with at least one other architect that works in a similar enterprise background, through free voice over IP tools (such as Skype). That way, not only we could benefit from one another’s experience and knowledge (staying faithful to one of the more purest principals of the internet, the gift economy), we could also locate points of recurring problems, study them and capitulate on our shared experience.
|
|
|
Current Articles
| Categories
| Search
| Syndication
| Thursday, September 10, 2009 |
 |
How to retire (respectfully) legacy systems
By Host Account (host) @ 8:46 PM :: Article :: 1 Comments :: 598 Views |
They served us for a long period of time, but (for different reasons that I wont cover in this post) now the time to say good bye and to retire them. Legacy systems exist in each and every enterprise and we all have the experience of retire them. The question is whether your enterprise have a predefine process to retire legacy systems or is just process that happened? In this post I'll try to share a retirement process for legacy systems.
From what I've seen so far in most enterprises, legacy systems are not going through a process of retirement they are simply abandon (from IT point of view). The users (or should I say most of the users) aren't using the system anymore but, batches keep on running, backup processes still running, they still take some place on the disk, their databases might still take space, etc'. It is worthless to say that if you're going through a process of mapping your IT assets you'll find most of (not all of) the legacy systems and you'll start a process of retirement.
The process, which I'm getting use to do, is composed from five main steps:
- Mapping: mapping of the legacy system components and their relations to other IT assets. Usually the mapping includes: Permissions, system services (and their consumers), system references from menus, system programs (PL1, Natural, Cobol, VB 6), databases or data files, batches, system data used by other systems, navigation to the system, usage of software or technology infrastructures, usage of other systems data, etc'
- Discussion: a formal discussion to approve the system retirement with participant from all relevant organization units (following the mapping)
- Writing shutdown procedure : Writing a detailed procedure of all the tasks, task owners and tasks order that needed to be taken when taking the system down. The shut down procedure should be sent to all related IT teams, users and support center.
- Neutralization : taking down system component, with the ability to restore them back to working state very fast. The neutralization includes : taking system references from menus, services and programs. Taking down system databases or renaming system files. Stopping batches. This step check if there are surprised users or unknown navigations or usage.
- Archiving : taking down system security settings, remove linkage from other systems, removing system components and achieving them. After a month of two if no access recorded to system components we can remove them and archive them for further use (how we handle complex IT/software issues in the past). When archiving system, we inform infrastructure providers that the system is down and it wont consume infrastructure services anymore.
|
|
|
|
|
| Comments |
By Stephen F. 'XTRAN_guru' Heffner @ 9/11/2009 4:23 PM
|
Step 1 may require extensive code analysis, to pull the information out of the code. For substantial systems, this requires automated code analysis, due to the sheer quantity of code to be analyzed. As the author of a rule-driven software engineering meta-tool that can provide that automation, I've thought a lot about how to perform this step of your process.
Of course, your process assumes that the legacy system is really moribund. If it's still actively being used, fits the enterprise's needs well, and is in reasonably good shape, it may be a candidate for a migration to a more modern language, DBMS, and platform. Again, automation is a major key to success. The meta-tool I have created provides that too -- both re-engineering and translation. |
|
|
|
|
| Post a Comment |
|
You must be logged in to post a comment. You can login here.
|
|
|
|
|