Where to Begin
Enterprise architecture objective is to provide a shared framework for problems and solutions at enterprise (business processes), systems (supporting functionalities), and platforms (technologies) levels. The consolidation of the concerns and boundaries of the corresponding architectures could then make the whole of EA greater than the sum of its parts.
Beyond that broadly accepted objective, there isn’t much of a consensus about it as a discipline. Hence the interest of figuring it out from basic guidelines:
Be Specific: Compared to the abundance of advice about EA management, there is a dearth of specifics about what is to be managed, apart from the Zachman framework. So the best approach is to begin with actual practice and try to characterize the specifics of what is actually done.
Separate Structures from Processes: Architecture is about shared assets whose life cycle is not limited to specific activities. Hence the need to set apart processes, which have to change depending on business environments and opportunities, and structures (e.g organization and systems) whose life cycle is meant to be set along a corporate time frame.
Separate Symbolic from Actual: To be of any use EA has to rely on some consensus regarding what is to be managed, and by who. That can only be achieved if some distinction is kept between symbolic descriptions (the equivalent of blueprints) of information and processes on one hand, actual objects (e.g legacy) or activities on the other hand.
Add Time Frames: At the end of the day success will be decided by the fruitful combination of enterprise assets (financial, physical, logical, human) and business context and objectives. Defining their respective life cycles and planning the necessary changes could be seen as the primary responsibility of enterprise architects.
Add Responsibilities: Last and least, allocating responsibilities is probably better carried out on a case by case basis depending on each organization and corporate culture.
Those few principles may seem unassuming but they provide a sound basis that takes full advantage of what staff and management know about their enterprise resources and practices. And never forget that continuity is a critical factor of EA success.
EA: Maps & Territories
Enterprise architecture can be defined in terms of territories and maps, the former materialized by the realities of enterprise organization and business operations, the latter by the assortment of charts, blueprints, or models used to describe enterprise organization, business processes, IT systems, and software applications.
As already explained, models used to describe systems are best organized according to their purpose:
- Descriptive models tried to capture relevant aspects of actual things or behaviors.
- Prescriptive models describe how to build things or carry out behaviors.
As far as enterprises are concerned, descriptive models are meant to provide serviceable representations of business environment; such models are said extensional as their objective is to classify observed occurrences of things and behaviors (aka extensions) into relevant categories. Predictive models can be seen as an executable subset of descriptive ones designed to foretell what could happen to selected aspects of actual things or behaviors. Considering that environments are given but relevant categories are defined according to enterprise concerns, these models are built along a nominalist perspective, i.e from territories to maps.
Prescriptive models go the other way as their purpose is to build systems’ components; corresponding models are intensional as they have to fully describe intended artifacts (aka intensions). Since concepts are being used as blueprints directed at concrete realizations, prescriptive models are set along a platonic perspective, i.e from maps to territories.
Assuming that the main purpose of enterprise architects is to manage the operational and strategic alignment of business objectives with architectures capabilities, the map/territory paradigm will provide the conceptual workbench on which to shape descriptive (business processes) and prescriptive (system architectures) models.
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 pillars supporting enterprise, systems, and platform architectures:
- 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.
One step further, the “Why” of business and operational objectives (the last column of the Zachman framework) could be reset as a line that would cross the original five columns instead of the architecture layers. Using the pentagonal representation it would appear at the outer range and mapped to architecture capabilities.
It must be noted that this outer range is of a different nature as it is not about actual processes, symbolic artifacts, or technical resources, but about objectives. Moreover, setting objectives on a line crossing the columns of capabilities instead of a column crossing the lines of layers means that objectives are set at enterprise level and their cascading impact traced and managed through layers.
EA: Work Units & Workflows
Enterprise architectures are a combination of culture, organization, and systems with a life of their own. As a corollary, phased processes based on top-down predefined procedures are ill-fitted and changes to capabilities should be carried out on a continuous basis.
That shift of paradigm (from phased to iterative) is a key success factor as it does away with a discrete understanding of enterprise architectures processes, in particular:
- Scope cannot be fully defined up-front, if only because the whole enterprise could possibly be of concern.
- Fixed schedule is to be avoided, lest each and every unit, business or otherwise, would have to be shackled into a web of hopeless reciprocal commitments.
- Different stakeholders may come as interested parties, some more equal than others, but none with undisputed prerogatives.
So, instead of procedural and phased approaches which are supposed to start from scratch, EA workflows are to weave business and engineering concerns across architecture layers (enterprise, systems, and platforms) and time-frames (operational, tactical, strategic).
The business side of workflows being tasked with the mapping of contexts and objectives (territories>maps) and the monitoring of their deployment by operational units (territories>territories); the engineering side of workflows being tasked with monitoring the development of applications (maps>maps) and their delivery to operational units (maps>territories).
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:
- Requirements: processes deal with organizational and business objectives. They starts with portfolio management; are carried on with systems functionalities; and complete with platforms operational requirements.
- Problems Analysis: processes deal with symbolic representations of enterprise environment, objectives, and activities. They start with the consolidation of symbolic representations for objects (power-types) and activities (scenarii); are carried on with functional architectures; and complete with platforms non-functional features. Contrary to requirements processes which are meant to convey changes and manage frictions (dashed lines) between actual architecture layers, the aim of solutions analysis processes is to consolidate symbolic representations and guarantee their consistency and continuity. As a corollary, analysis at system level must be aligned (continuous lines) with its enterprise counterpart before functional requirements are taken into account.
- Solutions Design: processes deal with operational concerns and resources deployment. They starts with locations and resources; are carried on with systems configurations; and complete with platforms deployments. 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.
Enterprise Systems & the OS Kernel Paradigm
Given the ubiquity of information and communication technologies on one hand, the falling apart of technical fences between systems, enterprises, and business environments on the other hand, applying the operating system (OS) paradigm to enterprise architectures seems a logical move.
Borrowing the blueprint of computers operating systems, enterprise operating systems (EOS) would be organized around a kernel managing shared resources providing services to business, engineering or operational processes.
Resources would be managed along architecture levels:
- At enterprise level services are bound to assets to be used by business, engineering, or operational processes.
- At systems level services are bound to functions supporting business, engineering, or operational processes.
- At platform level services are bound to resources used by business, engineering, or operational processes.
As services will usually rely on different functions across layers, the complexity will be dealt with by kernel primitives and masked behind interfaces.
EA: Pagoda Architecture Blueprint
The impact of digital environments goes well beyond a shallow transformation of digitized business processes and requires a deep integration of enterprises ability to refine data flows into information assets to be put to use as knowledge:
- At platform level: acquisition of business data flows.
- At functional elevel: integration of data analytics and information models.
- At enterprise level: integration of information systems with knowledge management and operatioonal decision-making.
Such an information backbone supporting architecture layers tallies with the Pagoda architecture blueprint whose ubiquity all around the world demonstrates the effectiveness in ensuring resilience and adaptability to external upsets.
EA Frameworks: Non Negotiable Features
Frameworks are meant to abet the design and governance of enterprises’ organization and systems, not to add any methodological layer of complexity. If that entry-level is to be attained preconditions are to be checked out for comprehensiveness, modularity, clarity of principle, and consistency.
Comprehensiveness: The primary objective of an enterprise framework is to bring under a common management roof different contexts and concerns (business, technical, organizational), and synchronize their respective time-frames. That can only be achieved through an all-inclusive and unified conceptual perspective.
Modularity: On one hand enterprise frameworks must deal with strategic issues without being sidetracked by enterprises idiosyncrasies. On the other hand swift and specific adaptations to changing environments should not be hampered by cumbersome procedures or steep learning curve. That can only be achieved by lean and versatile frameworks built from a clear and compact set of architecture artifacts, to be readily extended, specialized or implemented through the enactment of dedicated processes.
Clarity of Principle: Comprehensiveness and modularity are pointless without a principled backbone supporting incremental changes and a smooth learning curve. For that purpose a clear separation should be maintained between the semantics of the core patterns used to describe architectures and the processes to be carried out for their evolution.
Consistency: EA frameworks should be more compass than textbook, drawing clear lines of action before providing details of implementation. Lest architects been lost in compilations of ambiguous or overlapping definitions and rules, core meanings must remain unaffected when put to use across the framework.
These basic requirements get their full meaning when set in the broader context of EA evolution. Contrary to their IT component, enterprise architectures cannot be reduced to planned designs but grow from a mix of organization, culture, business environments, technology constraints, and strategic planning. As EA evolution is by nature incremental, supporting frameworks should provide for iterative development based on declarative knowledge of their organizational or technical constituents. That could be achieved by combining EA with model based systems engineering.
Further Reading
Systems & Architectures
- Modeling Paradigm
- EA: Maps & Territories
- EA: Work Units & Workflows
- Focus: Enterprise Architect Booklet
- From Processes to Services
- Architecture Capabilities
- Capabilities vs Processes
- Alignment for Dummies
- Alignment: from Empathy to Abstraction
- Abstractions & Emerging Architectures
- EA & MDA
- Enterprise Systems & the OS Kernel Paradigm
EA as a Discipline
- Where to Begin with EA
- Models, Architectures, Perspectives (MAPs)
- Enterprise Architectures & Separation of Concerns
- EA Frameworks: Non Negotiable Features
- Caminao & EACOE