Enterprise architecture guidance

Our company wants to standardize apps across the enterprise on the .net stack. We're building an enterprise style guide. We have a solutions architect helping us with the design of our enterprise architecture. His recommendations include an enterprise services layer and also an enterprise UI layer with reusable components.

I completely agree on having an enterprise services layer that will be used by most if not all web apps for data. However I'm not convinced about the enterprise UI layer.

Many of our existing applications display the same information eg order details. His argument is that our company has spent money to build the order details UI multiple times for each application when it shows have been built once and reused in other applications. He wants to build reusable UI components on angular and bootstrap that can be dropped into future applications built or rewritten on the same stack.

I like the idea of having reusable components but I think it should be limited to the structure and styles and not include the UI framework. Adding the UI framework adds complexity to each control and also costs more and we'd be essentially building a cms. Besides that I feel we'd be locked in with angular which is not necessarily bad but what if another framework like react was better suited for a future application?

My questions are -
1. Has anybody built or worked in an environment that had a similar architecture? What was your experience?
2. What do you see as the pros and cons of this architecture?

Thanks in advance for your help.

Regarding the provided recommendations:-

1. Enterprise Service Layer: of course this is necessary where you can unify and standardize the way you interface with backend systems, data layer and 3rd party systems. This is what we call it usually Enterprise Service Bus "ESB"

2. UI Integration is different that UI re-usability. You can use UI integration in several ways

   2.1 Some framework can provide you tools and APIs to bring several UI components "screens" from running apps into one screen. Microsoft has a framework and a commercial product for that purpose.

   2.2 Some technologies like Java Portals allow you to include portlets "reusable UI components with it's business logic" into any other portal page and provide API to communicate between Portlets.

3. Reusable UI components is of course obvious but this is development practice not really impacting the architecture. It has its own overhead and governance, depends on your projects size. If you have one UI team to serve all project this might be effective to ensure there is high re-usability.

Using ESB is definitely the best way forward but it will change the way you are used to. There are some areas to consider

1. Application Mapping to processes, re-engineer applications based on the findings
2. Securing the Enterprise Service Layer and develop Role Base Access Control.
3. Review your operations workbook to make sure after having a Enterprise Service Layer, you can identify problems, isolate it and reduce the impact on other systems which use the service layer.
4. One error or failure in the service layer will impact all systems, so you have to increase the quality and use "if you are not already" some methodologies to increase quality like Continuous Integration (CI) with full test automation.
5. You need to review the hardware and do a capacity planning to make sure that the Enterprise Service Layer will perform well and can scale enough to support all applications. A performance test here will be very useful. One of the main tasks for the enterprise architect is to make sizing for all apps and recommend the specification for the Enterprise Service Layer environment.