Enterprise Architect Booklet

Objective

Given the diversity of business and organizational contexts, and EA still a fledgling discipline, spelling out a job description for enterprise architects can be challenging.

So, rather than looking for comprehensive definitions of roles and responsibilities, one should begin by circumscribing the key topics of the trade, namely:

1. Concepts : eight exclusive and unambiguous definitions provide the conceptual building blocks.
2. Models: how the concepts are used to analyze business requirements and design systems architectures and software artifacts.
3. Processes: how to organize business and engineering processes.
4. Architectures: how to align systems capabilities with business objectives.
5. Governance: assessment and decision-making.

The objective being to define the core issues that need to be addressed by enterprise architects.

Concepts

To begin with, the primary concern of enterprise architects should be to align organization, processes, and systems with enterprise business objectives and environment. For that purpose architects are to consider two categories of models:

• Analysis models describe business environments and objectives.
• Design models prescribe how systems architectures and components are to be developed.

That distinction is not arbitrary but based on formal logic: analysis models are extensional as they classify actual instances of business objects and activities; in contrast, design models are intensional as they define the features and behaviors of required system artifacts.

The distinction is also organizational: as far as enterprise architecture is concerned, the focus is to remain on objects and activities whose identity (#) and semantics are to be continuously and consistently maintained across business (actual instances) and system (symbolic representations) realms:

• Actual containers represent address spaces or time frames; symbolic ones represent authorities governing symbolic representations. System are actual realizations of symbolic containers managing symbolic artifacts.
• Actual objects (passive or active) have physical identities; symbolic objects have social identities; messages are symbolic objects identified within communications. Power-types (²) are used to partition objects.
• Roles (aka actors) are parts played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents meant to be identified independently of their behavior.
• Events are changes in the state of business objects, processes, or expectations.
• Activities are symbolic descriptions of operations and flows (data and control) independently of supporting systems; execution states (aka modes) are operational descriptions of activities with regard to processes’ control and execution. Power-types (²) are used to partition execution paths.

Since the objective is to identify objects and behaviors at architecture level, variants, abstractions, or implementations are to be overlooked. It also ensues that the blueprints obtained remain general enough as to be uniformly, consistently and unambiguously translated into most of modeling languages.

Languages & Models

Enterprise architects may have to deal with a range of models depending on scope (business vs system) or level (enterprise and system vs domains and applications):

• Business process modeling languages are used to associate business domains and enterprises organization.
• Domain specific languages do the same between business domains and software components, bypassing enterprise organization and systems architecture.
• Generic modeling languages like UML are supposed to cover the whole range of targets.
• Languages like Archimate focus on the association between enterprises organization and systems functionalities.
• Contrary to modeling languages programming ones are meant to translate functionalities into software end-products. Some, like WSDL (Web Service Definition Language), can be used to map EA into service oriented architectures (SOA).

While architects clearly don’t have to know the language specifics, they must understand their scope and purposes.

Processes

Whatever the languages, methods, or models, the primary objective is that architectures support business processes whenever and wherever needed. Except for standalone applications (for which architects are marginally involved), the way systems architectures support business processes is best understood with regard to layers:

• Processes are solutions to business problems.
• Processes (aka business solutions) induce problems for systems, to be solved by functional architecture.
• Implementations of functional architectures induce problems for platforms, to be solved by technical architectures.

As already noted, enterprise architects are to focus on enterprise and system layers: how business processes are supported by systems functionalities and, more generally, how architecture capabilities are to be aligned with enterprise objectives.

Nonetheless, business processes don’t operate in a vacuum and may depend on engineering and operational processes, with regard to development for the former, deployment for the latter.

Given the crumbling of traditional fences between environments and IT systems under combined markets and technological waves, the integration of business, engineering, and operational processes is to become a necessary condition for market analysis and reactivity to changes in business environment.

Hence the benefits of combining bottom-up and top-down perspectives, the former focused on business and engineering processes, the latter on business models and organization.

Crossing processes and architecture perspectives

Enterprise architects could then focus on the mapping of business functions to services, the alignment of quality of services with architecture capabilities, and the flows of information across the organization.

Architectures

Blueprints being architects’ tool of choice, enterprise architects use them to chart how enterprise objectives are to be supported by systems capabilities; for that purpose:

• On one hand they have to define the concepts used for the organization, business domains, and business processes.
• On the other hand they have to specify, monitor, assess, and improve the capabilities of supporting systems.

In between they have to define the functionalities that will consolidate specific and possibly ephemeral business needs into shared and stable functions best aligned with systems capabilities.

As already noted, enterprise architects don’t have to look under the hood at the implementation of functions; what they must do is to ensure the continuous and comprehensive transparency between existing as well a planned business objectives and systems capabilities.

Assessment

One way or the other, governance implies assessment, and for enterprise architects that means setting apart architectural assets and business applications:

• Whatever their nature (enterprise organization or systems capabilities), the life-cycle of assets encompasses multiple production cycles, with returns to be assessed across business units. On that account enterprise architects are to focus on the assessment of the functional architecture supporting business objectives.
• By contrast, the assessment of business applications can be directly tied to a business value within a specific domain, value which may change with cycles. Depending on induced changes for assets, adjustments are to be carried out through users’ stories (standalone, local impact) or use cases (shared business functions, architecture impact).

The difficulty of assessing returns for architectural assets is compounded by cross dependencies between business, engineering, and operational processes; and these dependencies may have a decisive impact for operational decision-making.

Business Intelligence & Decision-making

Embedding IT systems in business processes is to be decisive if business intelligence (BI) is to accommodate the ubiquity of digitized business processes and the integration of enterprises with their environments. That is to require a seamless integration of data analytics and decision-making:

Data analytics (sometimes known as data mining) is best understood as a refining activity whose purpose is to process raw data into meaningful information:

• Data understanding gives form and semantics to raw material.
• Business understanding charts business contexts and concerns in terms of objects and processes descriptions.
• Modeling consolidates data and business understanding into descriptive, predictive, or operational models.
• Evaluation assesses and improves accuracy and effectiveness with regard to objectives and decision-making.

Decision-making processes in open and digitized environment are best described with the well established OODA (Observation, Orientation, Decision, Action) loop:

1. Observation: understanding of changes in business environments (aka territories).
2. Orientation: assessment of the reliability and shelf-life of pertaining information (aka maps) with regard to current positions and operations.
3. Decision: weighting of options with regard to enterprise capabilities and broader objectives.
4. Action: carrying out of decisions within the relevant time-frame.

Seamless integration of data analytics and decision-making.

Along that perspective data analytics and decision-making can be seen as the front-offices of business intelligence, and  knowledge management as its back-office.

More generally that scheme epitomizes the main challenge of enterprise architects, namely the continuous and dynamic alignment of enterprise organization and systems to market environment, business processes, and decision-making.

Further Reading

• Thread
• Enterprise Architectures & Separation of Concerns
• Where to Begin with EA
• EA: Maps & Territories
• EA: Work Units & Workflows
• Agile Architectures: Versatility meets Plasticity
• Models, Architectures, Perspectives (MAPs)
• Abstraction Based Systems Engineering
• EA & MDA
• Abstractions & Emerging Architectures
• Alignment: from Empathy to Abstraction
• Caminao & DoDAF
• Enterprise Governance & Knowledge
• Squaring EA Governance
• EA’s Merry-go-round
• EA Documentation: Taking Words for Systems
• Agile Collaboration & Social Creativity
• Governance, Regulations & Risks
• Events & Decision Making
• Operational Intelligence & Decision Making
• Data Mining & Requirements Analysis
• Business Agility & the OODA Loop
• EA: Entropy Antidote
• Business Agility vs Systems Entropy