Humans often expect concepts to come with innate if vague meanings before being compelled to withstand endless and futile controversies around definitions. Going the other way would be a better option: start with differences, weed out irrelevant ones, and use remaining ones to advance.
Concerning enterprise, it would start with the difference between business and architecture, and proceed with the wholeness of data, information, and knowledge.
Business Architecture is an Oxymoron
Business being about time and competition, success is not to be found in recipes but would depend on particularities with regard to objectives, use of resources, and timing. These drives are clearly at odds with architectures rationales for shared, persistent, and efficient structures and mechanisms. As a matter of fact, dealing with the conflicting nature of business and architecture concerns can be seen as a key success factor for enterprise architects, with information standing at the nexus.
Data as Resource, Information as Asset, Knowledge as Service
Paradoxically, the need of a seamless integration of data, information, and knowledge means that the distinction between them can no longer be overlooked.
Data is captured through continuous and heterogeneous flows from a wide range of sources.
Information is built by adding identity, structure, and semantics to data. Given its shared and persistent nature it is best understood as asset.
Knowledge is information put to use through decision-making. As such it is best understood as a service.
Ensuring the distinction as well as the integration must be a primary concern of enterprise architects.
Sustainable Success Depends on a Balancing Act
Success in business is an unfolding affair, on one hand challenged by circumstances and competition, on the other hand to be consolidated by experience and lessons learnt. Meeting challenges while warding off growing complexity will depend on business agility and the versatility and plasticity of organizations and systems. That should be the primary objective of enterprise architects.
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:
Concepts : eight exclusive and unambiguous definitions provide the conceptual building blocks.
Models: how the concepts are used to analyze business requirements and design systems architectures and software artifacts.
Processes: how to organize business and engineering processes.
Architectures: how to align systems capabilities with business objectives.
Governance: assessment and decision-making.
The objective being to define the core issues that need to be addressed by enterprise architects.
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.
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 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.
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.
Pagoda Blueprint: Resilience and adaptability to changes
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.