So going on with this. I have seen cases where people have worried more about the future than about the current requirements (almost the polar opposite of throwaway) with odd effects such as the current requirements not being met.
So when should stuff be throwaway? Taking an example System A is an old and creaky blob which people want to move away from Project X is creating a new SOA replacement for A which does pretty much everything A does and quite a lot more. At the start of the programme they agree that they'll define the service interfaces based on what Project X will deliver rather than System A does, so if there is stuff in A which will become obsolete then the interface won't contain that functionality or data. So we've got a bunch of service contracts which represent the "to be" state of the enterprise. Now the challenge. Its going to take 2 years for Project X to build everything and the company needs to keep working and evolving. The policy therefore is that the integration to A is to be done based on the Project X interfaces to ease the transition and migration. Everything that connects from A to the Project X interfaces should be considered as "throwaway" and planned, costed and developed accordingly. Project X can then deliver and start switching over the services and decomissioning the System A pieces that are designed to be throwaway. When you shouldn't think throwaway is when you have the following You get asked to produce a "production prototype" and are promised that "we'll never ask for it to go live". Steve On 30 April 2010 02:33, reamon943 <[email protected]> wrote: > > > > > --- In > [email protected]<service-orientated-architecture%40yahoogroups.com>, > "LAWRENCE" <l.wil...@...> wrote: > > > > Well SOA is (to me at least) all about building agile architectures > > that can be quickly adapted to meet new requirements. > > Agreed. > > > > > > Throwaway or disposable architecture implies the building is simply > > trashed and replaced, as it is too costly to adapt. > > > > That may be true with physical buildings - where only the rubble is > > reused, not the 'components' - but doesn't have to be true with > > software, which with careful application of SOA and CBD principles > is > inherently more flexible and the elements of which can be > > 'reused' in a new instance of architecture, rather than replaced > > every time. > > True, but are there parts where it would indeed be better to simply start > over? Steve suggested in his blog that perhaps service implementations are > good candidates for this. Since "service implementations have an > architecture of their own" (per Gartner) then perhaps the SO aspects of the > overall architecture survive but the "sub-architecture" of the service > implementations can be replaced. > > In other words, at some point the evolution of the service implementation > reaches a point of negative return and it is better to start over. > > -Rob > > >
