As architects, the most natural thing to do is to build systems. Building a system is a lot like building a sky-scraper. There is always a foundation and strong central core. Stuff around the core is a frame, and everything else is just eye candy - windows, walls, carpets, furniture, etc... The interesting distinction is that construction architects don't erect sky scrappers in the middle of Sahara, while system architects do. In all cases, all systems start in a vaccum and proceed from there. Once the system is built, the most rudimentary of neurons is spent on deciding how to integrate the system into an existing eco environment. In most cases, this means that the author slaps together a messaging bus or maybe some kinda of REST, WS, or maybe something new fan dangled like proto-buffers, etc... The system is still a big giant monolith with some little shitty input and output.
Now what if we decided to build a platform instead of a system - what does that mean:
1. User interface split into a Bloomberg like approach - I can jump to any screen directly by entering the right tag and parameters
2. Analytic & Calculators - segregated engines that can be called as libraries or services
3. Commons Core - all the technical generic plumbing libraries and services (calendar, security, etc...)
4. Modular controllers - business logic segregated by type
5. Physical services - compute farm, data storage, distributed locking schemes like Zookeeper, etc...
But you also need orchestration of all of this:
1. Workflows, schedulers, coordinators
Sunday, February 26, 2012
Subscribe to:
Posts (Atom)