EA in the Loops

Enterprise Architects are to jump across loops (Bruce Beasley)

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.