EA in the Loops

When push comes to shove, deciding on a development process is to decide between instant or delayed returns, namely focusing on users needs with agile development, or taking extended features into consideration and weighting the benefits of reuse against additional costs, e.g.:

• Designs to be reused as patterns.
• Profiling configurations.
• Structuring business process models so that they could be designed as business functions.
• Formatting business logic for automated code generation.

The intricacies of stakes and decision-making processes can be set forth by applying the Observation-Orientation-Decision-Action (OODA) loop to the four views of changes: enterprise, business domains, business applications, systems:

At enterprise level the loops are triggered by changes in business environments pertaining to business model and objectives. They are supposed to affect different business domains.

1. Observations: Business opportunities
2. Orientation: Assessment of business opportunities with regard to business objectives.
3. Decision: Committing resources to changes in organization and processes
4. Action: Achieving changes in organization and processes

Changes initiated from business domains can be derived from enterprise level or the result of more specific objectives. They are supposed to affect different applications.

1. Observations: Business analysis
2. Orientation: Functional feasibility and assessment of transformation benefits.
3. Decision: Committing changes in functional architecture.
4. Action: Development, integration, tests

Changes at application level are initiated by organizational units, business or otherwise. They are supposed to be self-contained.

1. Observations: Users requirements
2. Orientation: Engineering feasibility and assessment of development options.
3. Decision: Choice of a development model.
4. Action: Development, integration, tests

Changes at system level are initiated by organizational units, including business ones (quality of service). They are supposed to affect different applications.

1. Observations: Process mining and operational requirements
2. Orientation: Operational feasibility and assessment of configurations.
3. Decision: Development model.
4. Action: Deployment and acceptance.

Given that sizeable companies with differentiated organization and business have to manage these different threads continuously and consistently, old fashioned imperative processes can only lead to paralysis. Hence the need of a declarative approach to EA workflows.

FURTHER READING

• Enterprise Architect Booklet
• Agile Architectures: Versatility meets Plasticity
• Digital Transformation & Homeostasis
• Entropy & Homeostasis
• Knowledge-based Models Transformation
• Focus: Data vs Information
• Modeling Paradigm
• Views, Models, & Architectures
• Abstraction Based Systems Engineering
• EA & MDA
• EA: The Matter of Layers
• EA: Maps & Territories
• EA: Work Units & Workflows
• Ontologies & Enterprise Architecture
• Ontologies as Productive Assets
• Models Transformation & Agile Development