As the Model points out, all enterprises have much  in common.  

In fact a significant portion of any enterprise technological landscape trend towards commodity.  Although an enterprise may get short term advantage, long term advantage comes from unique application and an organization's special sauce.  The products laid out  in the diagram that follow a commodity life cycle are  Consumers, Channels, Integrated Services, BI Services (the technologies), Integrated Application Services, BPM/Automation Services, and Delivery.

The special sauce of any organizatiodn is in their Integrated Business Capabilities (services),  API/Service/Capability Repository (including AI based on proprietary  information), and Integrated Business Processes.  Business Capabilities are made of the enterprises proprietary information and business rules.

All of the products in the diagram (sometimes combined) have a current  and  future state based on delivered and desired capabliites.  The roadmap is the bridge between the two.

Another thing all  enterprises have  in common is  Integrated Services.  All  enterprises have security, user  interfaces, collaboration software, content management, document management, communications, GIS, customer tracking, and correspondence.  With all of these, the  fewer solutions the  better.  How much simpler would support  and innovation  be if you only  had to consider or align one of each of these?  In fact, wouldn't your ideal future  state be just that?  An enterprise may never get  there, but  that is  the  trajectory it  should be  on.  

Implementation is not a major concern.  If you use a mapping product do your really  care how it is  implemented?  The major concern is functionality, the  detailed  implementation is  only a consideration in  that it meets the non-functional  requirements (response  time, up time, fail over, maintenance  schedule,  availability, etc.).  Keeping the focus on funtionality allows for changing implementations as the  need occurs (end of life of a product, cheaper alternative, etc.).  

BI Services can be looked at as the factory for creating AI/BI capabilities.  The value is in the easy integration of these developed capabilities into tools and processes.  The road map talks about how the created capabilities get turned into consumable assets.  This is a dynamic product space (from tools, platforms, skills, and business empowerment) which means a disciplined product approach is necessary.

There is a common strategy in this grouping.  The goal is support business empowerment and success.  The implication is that a COE/COP (Center of Excellence/Communities of Practice) structure should be considered.  Where the Center of Excellence (usually in IT)  is charged with building and enhancing the foundational platform(s) for AI/BI (standardized products, usages, test beds, investigating and standardizing new products, SDLC alignment,  features, etc.).  The Communities of Practice cross every business unit, and they  are charged with building the needed capacities required to improve tools and processes.  

The factory  concept is designed to increase agility, simplify integration, empower business, and optimize usage and support. 

(It should be noted that IT is a member of the Community of Practice, where several units may create assets that improve the performance of IT.  The IT opportunities include improving coding, optimizing testing (test data, test automation), and operations' monitoring agents.)

Integrated Application Services involve the components/tool of internal  application development.  Rules engines support application development, but in the best case empower the  business to develop, maintain, and observe their own rules. 

Reference tables is example of something every enterprise needs, but whose maintenance is distributed.  Some tables are universal (country, state, etc.), others require  strict control (tolerances).  Reference tables are ubiquitous; they are used everywhere.  So from the  same source the  same table may be optimized on many implementations and platforms (in memory, in  cache, different databases, etc.).

Data exchange components are used in systems as a way to independently configure service to service communication.  The  registered interface would include service implementation.  The tool would take the interface and generate different interfaces so  that the  service could be called "natively" from any  platform/application. "Write once, use  everywhere".  (This predated APIs, REST, etc. and  these interfaces were generated as needed).

Form Facility is probably more relevant in a government space.  It is a generic way  to generate, simplify,  and digitize the functionality of paper forms.

All of these components are  used  in  the application development cycle and are integrated into  the SDLC and migration processes.

BPM/Automation services  are  those that  simplify  business process  optimization  and  tool  integration.  

Worklist  integration is how  a consumer or  group of consumers  interact  with a  list.  A list item sets a context to a certain tool and tool signature.  A launching often establishes a claim so that the consumer now  has responsibility for the item.  There are traditionally three types  of lists: 

• a group list assignment: where everyone can pick their  work

•  a group list where a "manager" may assign the work

• a list where an employee gets the next best from the  list (e.g. high volume, call center, etc.). 

The  last  type  of  assignment is rule-based automated individual assignment rquires no consumer  list.

Worklist management is  how one works with  the  items on the list.  This interludes features like completing a workitem (with  completion  criteria),   route the  workitem, approve the  workitem, and escalate.

Automation, Business  Activity Monitoring, Business  Events,  and Process Management are collection of capabiities focused on the optimized implementation  of processes and monitoring performance. 

Delivery refers to the environments an enterprise uses in supporting their products.  The environments can be very complex crossing many types of hardware and software.  The essential thing to understand is that all environments can be thought of as plumbing.  Each of these environments has their own specific resources (or a shared strategy).

The  first thing to understand in the diagram is that there are two types of environments - Migrate-able and Deploy-able.   The difference is based on whether the formal control movement of "pieces" can move or a copy of the code from an existing environment.  Migration comes with the ability to track all movement of assets and to back out changes if necessary.  Migration not only moves code but  infrastructure changes, database changes, and configuration data.  

It may require database structure  changes and the refactoring  of data (offload/reload, movement of data between structures, etc.).  These  types of changes often make it complex  to  fix changes for production issues.  This often involves a different  support path  (development maintenance, user  test maintenance) whose changes have to be merged with the  development path.  The multiple paths (there may  be multiple  production  fix paths), all have to be retrofitted in the  development path before promotion to  production.  

Training and Stress Test tend to be replications of other environments (with their own data).  Training tends to be a copy of production or a copy of the user test environment  (if people are being trained on an upcoming new release).  

Integration is usually where  developers can test their  changes with other  existing  code.  This  has expanded to be considered a devleopers  zone where even partner developers  (outside of the enterprise) can test integrations.  For some developers, integration is  now part of the SDLC and is  leveraged as the source for migrations to a controlled user test environment.  

Modern technologies (cloud, virtual environments, etc.) have created many opportunities in supporting enterprise  usage of IT.  It  can be simple thing to  "spin" up  a test  environment.  AI can be leveraged to create test data and usage patterns for these new test beds.  AI can be heavily  used to monitor all environments.  AI can be used to create massive amounts of data needed to completely  stress test the solution.

The promotion process with its  controls and validations becomes even more critical.   

The descriptions and usage of environments all have a current and future  state.   It is important to be able to easily back out  a change when  results are unintended.  Not everything can be tested.  It has to be focused on good enough and risk.  After all "Production is the  ultimate  test enviroment".