Enterprise Architecture

Like the Winchester Mystery House, most enterprise architectures are built solution by  solution.  As described in the anti-patterns (Silos - Shadows - Silver Bullets - Shiny Objects) each solution tends to have its own User Interface, security, platform, and support language.  All  this leads to a more complicated support model and user  experience.  A consumer has to navigate the complexity of enterprise to resolve a problem; rather than the having an enterprise built around problem solving.

Perhaps there is a better solution.  One that is built around commonality and only  adds complexity as the business requires.  

What if Enterprise Architecture  always looked  like  this?

The overall approach maps to the Right Consumer (Consumers box), Right Tool (made up of Channels, Integrated Business Capabilities, Integrated Services, BI Services, Integrated Application Services, and BPM/Automation Services),  and the Right Time (Integrated Business Processes).  

What distinguishes any organization is its information (Integrated Business Services), its rules (Integrated Business Services), and its processes (Integrated Business Processes).  

All organizations have the same consumers, use the same channels, use AI/BI capabilities, and use the same common services. Non-organizational products (boxes) are made up of capabilities and trend to commodity  (even if you have the best UI today it is only a temporary advantage until the market catches up).  The same is true of all capabilities except for those thing that truly make an organization "unique".) 

The Right Strategy aligns the product  vs  project  paradigm.   All boxes become products which are made up of capabilities.  A product roadmap is a discussion of moving from a current state by  enhancing product capabilities.  This establishes a continuous improvement roadmap based on a solid architectural foundation (General Product Format).  Project delivery is accomplished  by coordinating across product releases (to complete a project I may need version 4 of Product A, and version 3 of Product B). 

Product owners are generally  empowered to make implementation decisions.  They are responsible for maintenance, support, and the alignment of resources.  They work with EA to assure they meet enterprise objectives (strategies, etc.).  For example, they  may  want to support a  new capability  by using  a feature in a legacy  product, where the  EA strategy is to use a cloud capability.  The benefits of each are measured.  The capability is developed in such  a way  that the implementation can easily be changed. The decision  may come down to time to deploy  and costs.  

The drill down of these products there is a consistent, comprehensive product breakdown.  See Product Roadmaps.