In the last step we decided that a combination of federation and centralization will suit the enterprise best.  So the underlying question is; what parts are centralized and what parts are federated?  The answer is ... it depends! There are a variety of factors that go into the choosing.  Lets go over a few of the big ones.  Remember, we don't need to 100% right, just close enough to engage the rest of the team in the conversation.

Question: How tightly or loosely coupled should the parts be?

Coupling is a subject tossed about at all levels.  Components, applications, services, and architectures all debate when some is ok, more is better and too much is, well, too much.  I do believe the consensus is to limit tight coupling within the architecture to allow for future changes in the enterprise.  There are any number of good patterns to accomplish this.  Edge services and providers comprised of Brokers, Plugs, and Adapters to monitor and react to the current state of things, some variant of Bus can provide an architectural channel separating participating parts as well as creating a mechanism for implementing canonical semantics, or simple facades could be used to present and transform on a boundary.

For Message2You, the choices are driven by the current environment.  Organization defines architecture.  As a small company Message2You is setup as a light weight hierarchy.  Cxo level managers have regional manager as direct reports.  This is important.  The architecture for an enterprise organized round business units tends to be strongly centralized with each business unit using most if not all shared corporate capabilities.  Enterprises that are organized around geographies tend to be largely self supporting in each region and only lightly touching the corporate core.  Here is an example of an enterprise that supports business units with shared corporate resources;

compare that to a more regionalized enterprise;

 This second view looks like a good place to start. 

The enterprise architecture has three major components areas to refine;

• Shared services such as Security, logging, and Client update or patching are technical in nature and centrally controlled.  Nothing but chaos comes from allowing each region to dictate is own version of these services.  Next we have
• centrally provided services such as Directory, Service Discovery, Broad resource management (hire/fire etc...), Broad Budgeting and Finance.  These differ from the shared services in the way they are implemented.  Shared services are created centrally and implemented in each region as well as the core while centrally provided services are created and reside in the core with regions implementing a mix of client access and region extensions.  Last are
• regionally specific services.  These are unique to the region implementing them.  They may or may not have any interaction with the core.  Examples of regional services might be local payroll or workflow and rules engines.

Next step: Select specific implementation architectures for each interation within the enterprise.