During the last step we began scratching the surface of the needs of the enterprise. Clearly it was too broad a description to make any significant architectural decisions. Agile practices provide us a simple and effective approach to address this... "involving the customer". As we begin assembling the architecture we need to repeatedly, on might even say incrementally, engage the many representative communities the architecture is intended to support. But how best to do this? How do we create something light-weight and easily consumable by application users, Project leads, IT managers, and CO's? Personally I am a fan of the "Boxes and Lines" model so lets run with that for now.
For a macro level architecture a "Boxes and Lines" presentation might look something like this;
When we use Peer to Peer and the intent is to make every participant equal. Or maybe this;
a Centralized approach where all the participants share a single core but don't interact with each other. Another alternative might look like this;
A federation of participants comprised of mixed communication networks. Most participants work autonomously but choose one or more relationships within the federation.
Lets look at each and how well it does or doesn't support the enterprise. In our fictional organization, Message2You we have a few guiding comments to consider;
To this lets add a few more things learned during our on-going conversation with individuals throughout the enterprise;
So, are we looking at a Peer to Peer, Federated, or Centralized Architecture for Message2You?
Peer to Peer is a contender but isn't a great fit for an implementation that needs to propagate changes quickly to all points. It would however be a good choice for a highly reliable system and spreading the processing load may also prove and excellent way to scale without negatively impacting user perceived performance.
Centralized looks great on the surface. Most of the control, monitoring, and performance issues are quickly settled in a centralized system. It presents fewer moving parts and limited deployment issues. Centralization fails to support multiple independent customer organizations.
Federated addresses the multiple customer organizations by allowing each participant solution to work as independently or as connected as it might but fails terribly on rapid dissemination of change as well as it's increased management and monitoring complexities.
If none of the macro architectures work what do we do? Well there are two possibilities; first we can address the requirements and scope. It ay be possible to negotiate with our customer and re-define success in such a way that it will better fit one of the macro architecture patterns. Second we can look at combining the macro architectures and into a more problem specific composite architecture.
I'm lean strongly toward the composite architecture. One that provides the autonomous support of the federated architecture with the ease of management and responsiveness of a centralized architecture. I do not see the need for a peer to peer implementation with the requirements as we know them, but that may well change as we discover more. For now lets use this as a starting point;
This approach is centralized in that all the participating organization are required to use a centralized "core" to interact with any other organization while it has traits of federated allowing each participating organization to operate with some degree of autonomy.
It's still not enough to engage the customer in discussion. For that we need to go down another level of detail and really begin to make it address the specific issue of the Message2You enterprise.
Next step: Further refining the architecture