A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
Imagine a situation where you have 6 projects running simultaneously that are between them building several hundred physical data feeds between ~40 source systems (that are mutating) and ~20 target systems (which are also mutating).
We want to avoid each project building its own version of each feed, because we know there will be many (expensive) duplications and we know that individual projects don't have the bigger picture. So the target is to standardise the feeds into logical buckets so that we can assign each bucket to a specific project and a completion date.
Should we adopt a top-down approach, where 2-3 architects with good IT and business skills get into a room together and build this target picture? This would be a straw man diagram that would then be passed to the individual project architects for validation.
Or should we adopt a bottom-up approach where we go to each of the individual project architects to ask what feeds they're planning to build, and then create the target picture based on their input?
Which approach is faster? Which approach is better?
Friday, February 18, 2005
Do you need live updates or are you doing bulk feeds? If it's bulk feeds, then I'd suggest building either a view or an intermediary system to hold a published feed.
So all 40 source systems would publish a feed each. Each feed would be required to contain certain information at a minimum which covers all current data needs for the subscribing systems. Each of the 20 subscribing systems then references the published feed as needed.
When a source system changes it only needs to make sure that the published version of it's feed is compatible. A subscribing system only needs to adapt how that published information is stored in its own system. By defining an interface between all systems you prevent each system from having to be aware of each other system.
Friday, February 18, 2005
I would conclude Top-Down.
When herding cats, it does not do much good to ask all the cats where each wants to go. Each will answer based only on their own limited self-interest. And each will probably answer differently. You've got to get them all moving in the same direction somehow. If you ask them, 99% will just be pissed off that you ignored their answers.
Herding developers is better than herding cats, because SOME of the developers have a more global view of their own self-interest.
So I conclude a top-down straw-man of the sharing architecture, put together by a few people, will be more likely to have good results. Give your developers some lattitude to provide input, but at least put a boundary around acceptable solutions.
Tuesday, February 22, 2005
Thanks, Lou and Allan.
We actually went with both approaches. We started with a top-down approach, shoved the results into a database, and now we're busy adding the bottom-up details to the same database and then cross-linking.
Sunday, February 27, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz