Thread: Enterprise Architecture

If the primary objective of Enterprise Architecture is to provide a shared framework for problems and solutions at enterprise (business processes), systems (supporting functionalities), and platforms (technologies) levels, concerns and boundaries of the corresponding architectures are to be consolidated within a shared conceptual framework  that could make the whole of EA greater than the sum of its parts.

Architecture Capabilities

Architectures can be defined as structured collections of shared assets and mechanisms whose purpose is to support the sustainable activity of functional entities: houses for dwelling, factories for manufacturing processes, office buildings for administrative ones, human beings for living, etc. Enterprises combine at least two of those blueprints as they have to support operational and administrative processes while keeping their corporate self alive and kicking. Their architectures must therefore secure the continuity of their corporate identities and the consistency of their business processes within their regulatory and business environments.Whatever the supporting technologies, from clay tablets to holograms, that could not be achieved without information systems whose capabilities are to be assessed.

Taking a leaf from the Zachman Framework, those capabilities can be organized around five IT-independent pillars:

• Who: enterprise roles, system users, platform entry points.
• What: business objects, symbolic representations, objects implementation.
• How: business logic, system applications, software components.
• When: processes synchronization, communication architecture, communication mechanisms.
• Where: business sites, systems locations, platform resources.

Those capabilities should meet enterprise objectives across all architecture layers.

Enterprise Architectures & Separation of Concerns

Whatever the terminology, there is a broad agreement regarding core architecture levels (aka layers):

• The enterprise (aka business) level deals with objectives, assets and organization associated with the continuity of corporate identity and business capabilities within a regulatory and market environment.
• The systems (aka application) level deals with the continuity and consistency of the functionalities supporting business processes.
• The platforms (aka technical) level deals with the feasibility, efficiency and economics of systems implementations.

Yet, and contrary to simplistic views, those levels are not congruent with objectives but orthogonal, because processes are to be supported across levels:

• Business processes deal with interactions between enterprises and their environment. They are supported by systems functionalities and executed on the associated technical platforms.
• Engineering processes deal with the development of supporting systems, through business requirements, functional specifications, and software development.
• Operational processes deal with the deployment and service of supporting systems, from business locations to systems management.

The aims of governance will be set on two perspectives: on one hand, monitoring, assessing, and improving processes with regard to supporting architectures; on the other hand planning for architectural changes at enterprise, systems, and platforms levels, and managing the business, engineering, and exploitation processes that will realize those changes.

Enterprise Governance & Knowledge

From an architecture perspective, enterprise governance is about managing people, equipment, and symbolic (aka information) systems. From a process perspective, governance is about the assignment of three kinds of tasks:

• Authority: deciding how to perform processes and make commitments in the name of the enterprise. That can only be done by human agents, individually or collectively.
• Execution: processing physical or symbolic flows between the enterprise and its context. Any of those can be done by human agents, individually or collectively, or devices and software systems subject to compatibility qualifications.
• Control: recording and checking the actual effects of processes execution. Any of those can be done by human agents, individually or collectively, some by software systems subject to qualifications, and none by devices.

Assuming the main objective of EA is to strengthen enterprise governance, a primary success factor would be the way information systems support decision making, and more precisely how data sources (enterprise, systems, platforms) feed processes (business, software engineering, services management) with relevant information:

• Information processing begins with data, which is no more than registered facts: texts, numbers, sounds, visuals, etc. Those facts are collected by systems through the execution of business, engineering, and servicing processes; they reflect the state of business contexts, enterprise, and platforms.
• Data becomes information when comprehensively and consistently anchored to identified constituents (objects, activities, events,…) of contexts, organization, and resources.
• Information becomes knowledge when put to use by agents with regard to their purpose: business, engineering, services.

With regard to governance EA would provide for timely, relevant, and accurate data collection and its processing into information that could be pulled by decision makers or pushed to processes according to contexts (business, organization, platforms) and governance level (assets, user’s value, operations).

Architectures and processes being orthogonal descriptions respectively for enterprise assets and activities, meeting those objectives will depend on the conceptual hinges connecting processes and architecture capabilities.

From Processes to Services

Architectures are by nature documented so it’s safe to assume that models are available respectively for business processes and architecture capabilities, and the role of EA is to map the former to the latter. Considering processes’ descriptions:

• At business level, i.e disregarding supporting systems and platforms, processes can be defined in terms of symbolic objects, business logic, and the roles of agents, devices, and systems.
• At systems level, i.e disregarding the technologies, processes should be defined in terms of business functions and operational constraints.
• At platform level, i.e disregarding the symbolic contents of interactions between systems and contexts, processes are characterized by the nature of interfaces (human, devices, or other systems), locations (centralized or distributed), and synchronization constraints.

As it happens, service oriented architectures typify the functional perspective by factoring out the symbolic contents of system functionalities, establishing a symbolic bridge between enterprise activities and architectures.

Introducing services in terms of customers, messages, contract, policy, and endpoints could therefore be used to map business processes to architectures capabilities.

EA Documentation: Taking Words for Systems

As a discipline, Enterprise Architecture is to provide a comprehensive and coherent description of present and planned enterprise objectives, assets, and organization. That can only be achieved through a set of reasoned documentation:

• With regard to corporate environment, documentation requirements are set by legal constraints, directly (regulations and contracts) or indirectly (customary framework for transactions, traceability and audit).
• With regard to organization, documents have to meet two different objectives. As a medium of exchange they are meant to support the collaboration between organizational units, both at business level (processes) and across architecture levels. As an instrument of governance they are used to assess architecture capabilities and processes performances. Documents supporting those objectives are best kept separate if negative side effects are to be avoided.
• With regard to systems functionalities, documents can be introduced for procurement (governance), development (exchange), and change (storage).
• Within systems, the objective is to support operational deployment and maintenance of software components.

The next step for EA would be to integrate documentation pertaining to actual environments and organization (brown background) with those targeting symbolic artifacts (blue background), and in particular to manage two kinds of models:

• Models of business contexts and processes describe actual or planned objects, assets, and activities.
• Models of symbolic artifacts describe the associated system representations used to store, process, or exchange information.

That could be achieved with MBE/MDA approaches.

EA & Model Driven Engineering

OMG’s Model Driven Architecture (MDA) is a systems engineering framework set along three model layers:

• Computation Independent Models (CIMs) describe business objects and activities independently of supporting systems.
• Platform Independent Models (PIMs) describe systems functionalities independently of platforms technologies.
• Platform Specific Models (PSMs) describe systems components as implemented by specific technologies.

Since those layers can be mapped respectively to enterprise, functional, and technical architectures, the MDA framework can be neatly fitted into EA:

1. Requirements: at enterprise level requirements deal with organization and business processes (CIMs). The relevant part of those requirements will be translated into system functionalities which in turn will be translated into platforms technical requirements.
2. Analysis: at enterprise level analysis deals with symbolic representations of enterprise environment, objectives, and activities (PIMs). Contrary to requirements, which are meant to convey changes and bear adaptation (dashed lines), the aim of analysis at enterprise level is to consolidate symbolic representations and guarantee their consistency and continuity. As a corollary, analysis at system level must be aligned with its enterprise counterpart before functional (continuous lines) requirements are taken into account.
3. Design: at enterprise level it deals with operational concerns and resources deployment. Part of it is to be supported by systems as designed (PSMs) and implemented as platforms. Yet, as figured by dashed arrows, operational solutions designed at enterprise level bear upon the design of systems architectures and the configuration of their implementation as platforms.

With architecture reinstated as the primary factor, MDA can become a pivotal component of enterprise architecture as it provides a clear understanding of architecture divides an dependencies on one hand, and their relationship with engineering processes on the other hand.

Change: Planned vs Emerging Architectures

Enterprise architectures are seldom the direct outcome of planned designs but more often emerge from a mix of cultural sediments, economic factors, technology constraints, and planned designs. Hence the importance of understanding the factors governing changes across architectures.

As far as enterprise architecture is concerned, the best option is to chart changes across the documentation of actual contexts, organization and processes on one hand, the description of their symbolic counterpart as systems objects on the other hand. On that basis the first question would be to pinpoint the origin of changes: actual (governed by legacy artifacts and organizations) or symbolic (governed by plans and models).

Then, changes should be qualified with regard to their level:

• At enterprise level models are used to describe objects and activities from a business perspective, independently of their representation by system components. Whatever the nature of targeted objects and activities (physical or symbolic, current or planned), models are meant to describe business units (actual or required) identified and managed at enterprise level. Changes must therefore ensure the continuity of business operations (customers, suppliers, contracts, etc.)
• At system level models are used to describe software components. Given that systems are meant to represent business contexts and support business processes, changes must therefore ensure the continuity of systems functionalities.

Assuming that functional, persistency, and execution units must be uniquely and consistently identified at both enterprise and systems level, their respective models have to share some common abstract units. Definitions of those abstract units will provide the backbone of enterprise architecture (a). That backbone can then be independently fleshed out with features providing identified structures of objects and activities are not affected (b).

From the systems standpoint the objective is the alignment of system and enterprise units on one hand, the effectiveness of technical architecture on the other hand. For that purpose abstract architecture units (reflecting enterprise units) are mapped to system units (c), whose design will be carried on independently (d).

Assuming that enterprise architecture entails some kind of documentation, changes in actual contexts will induce new representations of objects and processes. At this point, the corresponding changes in models directly reflect actual changes, but the reverse isn’t true. For that to happen, i.e for business objects and processes to be drawn from models, the bonds between actual and symbolic descriptions have to be loosened, giving some latitude for the latter to be modified independently of their actual counterpart. Specialization will do that for local features, but for changes to architecture units being carried on from models, abstractions are a prerequisite.

Alignment: from Entropy to Abstraction

Whatever the creed, the alignment of systems architectures and capabilities with enterprise organization and business models is often seen as an intrinsic component of enterprise architecture. Yet, as noted above, changes on the two sides of the divide are governed by different factors: while adaptation to actual business environments is the rules of the game, systems architectures must both provide for the new opportunities and ensure the continuity and consistency of existing business assets. Adding the different time-frames in the picture, chances are for alignment to remain a fleeting (if not random) contingency.

A model-based approach to the problem would be to look for selective alignment based on architecture footprint. Instead of taking a global perspective and assuming comprehensive semantics for business and systems realms, one should look for the minimal set of architectural concepts necessary to deal with alignment. Contrary to a meta-modelling approach, the objective would not be to find some higher level of abstraction encompassing the whole of models, but more reasonably to isolate a core of architecture concepts and constructs with shared and unambiguous meanings that could to be used by both business and system analysts. That could be achieved within the UML/MDA framework:

• Contexts descriptions (UML, DSL, BPM, etc) are not meant to distinguish between architectural constructs and specific ones.
• Computation independent models (CIMs) describe business objects and processes combining core architectural constructs (using a generic language like UML), with specific business ones. The former can be mapped to functional architecture, the latter (e.g rules) directly transformed into design artifacts.
• Platform independent models (PIMs) describe functional architectures using core constructs and framework stereotypes, possibly enriched with specific artifacts managed separately.
• Platform specific models (PSMs) can be obtained through transformation from PIMs, generated using specific languages, or re-factored from legacy code.

From a somewhat theoretical aim, alignment would become a pragmatic undertaking for business and system analysts in charge of requirements:

• At users level the objective is to ensure that applications are consistent with business logic and provide the expected quality of service. That is what requirements traceability is meant to achieve.
• At system level the objective is to ensure that business functions and features can be directly mapped to systems functionalities. That is what services oriented architectures (SOA) are  meant to achieve.
• At enterprise level the objective is to ensure that the enterprise capabilities are congruent with its business objectives, i.e that they support its business processes through an effective use of assets. That is what maturity and capability models are meant to achieve.

That makes alignment a concrete endeavor whatever the level of abstraction of its targets, i.e not only for users and applications, but also for functions and capabilities.

Source : https://caminao.wordpress.com/overview/thread-ea