Tried to reply with a comment to your blog but community server through a wobbly - here is my response:
..........
Rohan - agree here with you. I have been in the development and architecture arena for over 20 years - nearer thirty now. There is so much stuff out there, unstructured and undocumented that we pimp it all the time.
Worst thing is -- we pimp the software that was already pimped because we didnt follow standards when we pimped it in the first place.
Who suffers - the users, the client and the poor guys pimping the software.
Been there , got the badge, dont want to do it again - must admit though in 1999 we made buckets of money doing this pimping under the biggest pimp banner of them all - Year 2000 Compliance.
Have replied via your blog, but just for rest of the community here who might be following this thread.
You are correct, we spend to much time and effort when an analysis might show that the costs of re-engineering are cheaper than the patching. Taking this step a tad further we may also find that there is another option in freezing the code - thats to say - rather than rip and replace which we are advocating in re-engineering - we can wrapper and/or expose as services the existing software/component. Then rather than patch or enhance we create new services that exploit the wrappered service.
This gives us the opportunity to squeeze more life out of the existing software and create a new software generation based on new architectures and technology. This fits quite nicely with VSTS developement where such legacy services can be exploited by the team system.
We have just spent over a year working on a project using VSTS to do just this - the power of the Team System is enormous in this area as we can mask behind a service the legacy workings of the old software and allow the developers to concentrate on the new design and functionality of the services being created.
So to coin the mtv example - as I put in my comment to you on your blog. You can Pimp once and only once - this is the wrappering. From then on you develop new software and services to exploit the pimped software.
There are huge markets by the way open for us in this area. In Europe we only have to look at governments who over the years have developed millions of lines of cobol code on VME. These mainframe based systems are not going away - if we had to re-write the systems I think you and I would be dead before this happened. However they are stable.
The exploitation comes in creating new services running on the Intel platform to exploit these mainframe services - typically transactions. Then gathering the new services as a collection to assist the business in adapting new processes to achieve operational efficiencies and cost savings that previously were unobtainable due to the costs of mainframe development outweighing the achievable benefits.
Great exponents of this are people like Microfocus who are doing work with Microsoft technologies in this area.
Thanks for the thread by the way - have enoyed it.
regards
Eddie Hulme
Microsoft UK Architects Council Member
The above post is the personal opinion of the poster and not neccessarily that of the company or companies he is employed by.
Sorry about the blog comments, i will try to get it fixed asap.
It is true that we need to get the screwed up software working time and time again, this results is the software being bombarded with patches.
my point is, if the software is really that buggy, shouldn't we take a more drastic step and revamp the software instead of keep patching it Yes that would incurr a cost, but it would save a lot of headaches...
Pimp My Ride? Pimp My Software first...
kevin delafield
Rohan
Tried to reply with a comment to your blog but community server through a wobbly - here is my response:
..........
Rohan - agree here with you. I have been in the development and architecture arena for over 20 years - nearer thirty now. There is so much stuff out there, unstructured and undocumented that we pimp it all the time.
Worst thing is -- we pimp the software that was already pimped because we didnt follow standards when we pimped it in the first place.
Who suffers - the users, the client and the poor guys pimping the software.
Been there , got the badge, dont want to do it again - must admit though in 1999 we made buckets of money doing this pimping under the biggest pimp banner of them all - Year 2000 Compliance.
regards
Eddie Hulme
Jack Diamond
Rohan
Apologies - my email was/is eddie.hulme@(nospam)eds.com take out the nospam.
Have replied via your blog, but just for rest of the community here who might be following this thread.
You are correct, we spend to much time and effort when an analysis might show that the costs of re-engineering are cheaper than the patching. Taking this step a tad further we may also find that there is another option in freezing the code - thats to say - rather than rip and replace which we are advocating in re-engineering - we can wrapper and/or expose as services the existing software/component. Then rather than patch or enhance we create new services that exploit the wrappered service.
This gives us the opportunity to squeeze more life out of the existing software and create a new software generation based on new architectures and technology. This fits quite nicely with VSTS developement where such legacy services can be exploited by the team system.
We have just spent over a year working on a project using VSTS to do just this - the power of the Team System is enormous in this area as we can mask behind a service the legacy workings of the old software and allow the developers to concentrate on the new design and functionality of the services being created.
So to coin the mtv example - as I put in my comment to you on your blog. You can Pimp once and only once - this is the wrappering. From then on you develop new software and services to exploit the pimped software.
There are huge markets by the way open for us in this area. In Europe we only have to look at governments who over the years have developed millions of lines of cobol code on VME. These mainframe based systems are not going away - if we had to re-write the systems I think you and I would be dead before this happened. However they are stable.
The exploitation comes in creating new services running on the Intel platform to exploit these mainframe services - typically transactions. Then gathering the new services as a collection to assist the business in adapting new processes to achieve operational efficiencies and cost savings that previously were unobtainable due to the costs of mainframe development outweighing the achievable benefits.
Great exponents of this are people like Microfocus who are doing work with Microsoft technologies in this area.
Thanks for the thread by the way - have enoyed it.
regards
Eddie Hulme
Microsoft UK Architects Council Member
The above post is the personal opinion of the poster and not neccessarily that of the company or companies he is employed by.
Saila
Hi Eddie,
Sorry about the blog comments, i will try to get it fixed asap.
It is true that we need to get the screwed up software working time and time again, this results is the software being bombarded with patches.
my point is, if the software is really that buggy, shouldn't we take a more drastic step and revamp the software instead of keep patching it Yes that would incurr a cost, but it would save a lot of headaches...
Jonathan Caves MSFT
Sorry Eddie,
Tried contacting you but couldn't find ur email. Could you please do me a favour and check the comment on my blog it seems to be working fine...
Thanks,