After a conversation with a work college of mine I was amazed to find that many people have not made the mind shift into a SOA way of thinking.
Most are in the 80’s with a pure OO paradigm; it’s a brave new world people, OO and its promise of reuse failed, no one ever reused pure business objects as is, ever.
The unit of reuse has moved from sharing code to delegation of functionality, the artifact of reuse has shifted from the object to the service. Don’t talk about sending objects around, rather keep the objects where they belong and send messages asking a service to perform actions on them.
They shout out, “but you have an Anemic Domain, it’s an anti pattern so you must be wrong”.
Are they suggesting distributed systems that pass around "real" objects, behaviour and all? You should cry out in terror at the thought of using such a system in production.
For an OO purist the domain model is the most important part, but for the enterprise the database is far more important, seen by the fact that many databases far outlive the applications built to access them.
In SOA land your OO business logic is not the only business logic involved here, your services are part of a large interacting web of autonomous services, some wrapping legacy systems, is their business logic any less important.
I say design your services right, services that are self contained, process/capability driven, have de-centralised data and which communicate via well defined messages will lead to deliverable architectures, nobody will care how elegant your business layer is if you never get it done on time.
Monday, July 28, 2008
Friday, July 11, 2008
What is maintenance?
I have been doing some work analysing some legacy systems, some old some brand new, yes it is possible to write a brand new legacy system!
I thought it would be good to define what maintenance is and what can be done to make it a less painful exercise down the road.
After a product has been released, the maintenance phase keeps the software up to date with environment changes and changing user requirements.
The earlier phases should be done correctly so that the product is easily maintainable. The design phase should plan the structure in a way that can be easily altered. Similarly, the implementation phase should create code that can be easily read, understood, and changed.
Maintenance can only happen efficiently if the earlier phases are done properly. There are three major problems that can slow down the maintenance process: unstructured code, maintenance programmers having insufficient knowledge of the system and documentation being absent, out of date, or at best insufficient.
The success of the maintenance phase relies on these problems being fixed earlier in the life cycle.
Maintenance consists of four parts.
Corrective maintenance deals with fixing bugs in the code. Adaptive maintenance deals with adapting the software to new environments. Perfective maintenance deals with updating the software according to changes in user requirements.
Finally, preventive maintenance deals with updating documentation and making the software more maintainable.
All changes to the system can be characterized by these four types of maintenance. Corrective maintenance is ‘traditional maintenance’ while the other types are considered as ‘software evolution.’
As software systems age, it becomes increasingly difficult to keep them ‘up and running’ without maintenance.
There is direct financial cost of not maintaining software systems, and in fact, a substantial proportion of the resources expended within the Information Technology industry go towards the maintenance of software systems.
In order to increase the maintainability of software, we need to know what characteristics of a product affect its maintainability.
There has been a great deal of speculation about what makes a software system more difficult to maintain. There are some program characteristics that are found to affect a product’s maintainability
Factors include system size, system age, number of input/output data items, application type, programming language, and the degree of structure.
Larger systems require more maintenance effort than do smaller systems, because there is a greater learning curve associated with larger systems, and larger systems are more complex in terms of the variety of functions they perform.
Older systems require more maintenance effort than do younger systems, because software systems tend to grow larger with age, become less organized with changes, and become less understandable due to staff turnover.
The factors that decrease maintenance effort can be summarised into the list below:
· Use of structured techniques
· Use of modern software
· Use of automated tools
· Use of data-base techniques
· Good data administration
· Experienced maintainers.
I thought it would be good to define what maintenance is and what can be done to make it a less painful exercise down the road.
After a product has been released, the maintenance phase keeps the software up to date with environment changes and changing user requirements.
The earlier phases should be done correctly so that the product is easily maintainable. The design phase should plan the structure in a way that can be easily altered. Similarly, the implementation phase should create code that can be easily read, understood, and changed.
Maintenance can only happen efficiently if the earlier phases are done properly. There are three major problems that can slow down the maintenance process: unstructured code, maintenance programmers having insufficient knowledge of the system and documentation being absent, out of date, or at best insufficient.
The success of the maintenance phase relies on these problems being fixed earlier in the life cycle.
Maintenance consists of four parts.
Corrective maintenance deals with fixing bugs in the code. Adaptive maintenance deals with adapting the software to new environments. Perfective maintenance deals with updating the software according to changes in user requirements.
Finally, preventive maintenance deals with updating documentation and making the software more maintainable.
All changes to the system can be characterized by these four types of maintenance. Corrective maintenance is ‘traditional maintenance’ while the other types are considered as ‘software evolution.’
As software systems age, it becomes increasingly difficult to keep them ‘up and running’ without maintenance.
There is direct financial cost of not maintaining software systems, and in fact, a substantial proportion of the resources expended within the Information Technology industry go towards the maintenance of software systems.
In order to increase the maintainability of software, we need to know what characteristics of a product affect its maintainability.
There has been a great deal of speculation about what makes a software system more difficult to maintain. There are some program characteristics that are found to affect a product’s maintainability
Factors include system size, system age, number of input/output data items, application type, programming language, and the degree of structure.
Larger systems require more maintenance effort than do smaller systems, because there is a greater learning curve associated with larger systems, and larger systems are more complex in terms of the variety of functions they perform.
Older systems require more maintenance effort than do younger systems, because software systems tend to grow larger with age, become less organized with changes, and become less understandable due to staff turnover.
The factors that decrease maintenance effort can be summarised into the list below:
· Use of structured techniques
· Use of modern software
· Use of automated tools
· Use of data-base techniques
· Good data administration
· Experienced maintainers.
Subscribe to:
Posts (Atom)
