Five Implications of “All Architecture is Local”

Dominos
In my earlier post I argue that to provide value quickly, architecture needs to be thought of in the context of local needs more than enterprise needs. Here are five implications of architecting locally:

  1. Solve a local problem, not the enterprise problem. Making the resolution of a line-of-business problem instead of an enterprise solution will provide more defined scope, focus, and potentially better sponsorship to the project. This will also improve the credibility of the architecture practice in the long run – pointing to tangible success stories and building advocates among stakeholders.
  2. Pick the right local problem. Picking the right problem space to go after can be challenging – part of our criteria is to go after those areas where the business is already focused and where they are investing. We try to keep the business problem in focus rather than the solutions we're driving. (i.e. resolving account planning instead of Microsoft Dynamics CRM). In general, also tend to focus on areas where there is a heavy dependency on process or system integration. I think integration is an area where the value of architecture becomes more clear.
  3. Build a roadmap with shorter execution milestones. Not too many business stakeholders will have the patience to wait a few years for your grand enterprise solution. They need a roadmap that provides results much faster. 
  4. Forego elegant solutions for short-term results. Often the enterprise solution has a lot of components and can't operate effectively until they are all in place. Accept that some pieces are just not going to work well as you build out the capability. This may even mean having parts that are *shudder* manual. Be upfront about those limitations but be clear about the value that is being delivered in the short-term. 
  5. Design for modularity. While trying to deliver the right local outcome, bear in mind that the solution may need to scale for other businesses or the immediate business itself may change. Don't design too tightly to the local need – bring modularity and flexibility to the design so that downstream change will be easier.