Synopsis
Taking a cue from a recent discussion about the Enterprise Architecture Center Of Excellence (EACOE), the intent of this article is to apply EACOE criteria to the Caminao framework:
- Business Initiatives (Projects): Initiatives should address cross-organizational or individual concerns.
- Directed Guidance: Explicit methods, tools, and artifacts.
- Consistency and Simplicity: Single frame of symbolic representation and reference.
- Structured and Precise Definitions: Frame built from a compact, complete, and consistent set of concepts to be logically extended.
- Clarity and Reason in Modeling: Two distinct model sets – Architecture Models and Implementation Models.
- Value in Models Transformations: Why develop artifacts that do not lead anywhere?
- Skills Acquisition: Enterprise Architecture skills are acquired through practice and experience.
- Multiple Architect Roles: Collaboration between the many architect roles in contemporary business.
Business Initiatives: Managing Expectations & Commitments
Enterprise architecture is meant to serve business purposes set across organizational units. If intents and values of corresponding initiatives are to be properly measured and prioritized, portfolios management must tackle two inherent difficulties:
- How to rank a motley of expectations and commitments possibly subject to cross-dependencies.
- How to plan and schedule projects whose outcomes are set within changing environments governed along different time-frames.
That can be made easier if initiatives are classified and documented according to scope (enterprise, systems, platforms) and purpose (business processes, systems engineering, operations).
Frame of Reference: A Comprehensive and Consistent Modeling Paradigm
Enterprise architecture as a corporate discipline is upheld by the needs of large and complex organizations, which implies a wide range of units carrying out their projects according to their own concerns, organization, and methods.
As it’s safe to assume that different modeling languages are also involved, a frame of reference must be supported by a modeling paradigm covering the shared semantics of the basic domains of concern, namely: business processes, enterprise organization, systems functional architectures, and software engineering. That can be done with the conceptual backbone of the Caminao framework.
Directed Guidance: Model Driven Architecture
To be of any use, methods and tools should not become a constraint, introduce cumbersome procedures, or induce unjustified overheads. Hence the benefit of model based blueprints that could be adjusted according to the nature of problems (business value, assets, operations) and contexts (enterprise, systems, technologies), e.g:
- Agile processes will combine requirements with development and bypass analysis phases (a).
- Projects meant to be implemented by Commercial-Off-The-Shelf Software (COTS) will start with business requirements, possibly using BPM, then carry on directly to platform implementation, bypassing system analysis and design phases (b).
- Changes in enterprise architecture capabilities will be rooted in analysis of enterprise objectives, possibly but not necessarily with inputs from business and operational requirements, continue with analysis and design of systems functionalities, and implement the corresponding resources at platform level (c).
- Projects dealing with operational concerns will be conducted directly through systems design and platform implementation (d).
That scheme illustrates the benefits of combining EA with model based engineering schemes.
Consistency and Simplicity: Seven Concepts & Three layers
As far as architectures are concerned, consistency and simplicity are best achieved through a clear understanding of architecture capabilities as defined by the Zachman framework: who, what, how, where, and when.
The semantics are to be defined in relation to architecture level: business, systems, and platforms. The role of enterprise architects is then to see how assets can best realize capabilities, and to align processes to supporting capabilities.
Structured and Precise Definitions: Formal Operators uniformly applied across Modeling Lanes
As illustrated a-contrario by the plenty of “universal” standards, combining simplicity, consistency, and all-inclusive relevancy is not easily achieved.
A way out of the conundrum is to delineate a small set of formal constructs and operators to be uniformly, comprehensively and consistently applied across models to connect, structure, and specialize conceptual nodes independently of their semantics:
On one hand such constructs provide a syntactic glue between the building blocs defined from basic concepts. On the other hand the semantics of these blocs can be extended and refined along the four standard modeling lanes (aka perspectives): objects, symbolic representations, activities, and execution states.
Clarity and Reason: Descriptive (extensional) vs Prescriptive (intensional) Models
Clarity for enterprise architects should begin with a distinction between environments and enterprise, the former given as realms of changing opportunities subordinate to external factors, the latter supposedly governed according to purposes and plans. Reason is needed to manage the relationship between environments and enterprise architectures, and that endeavor fully depends on architects’ ability to build serviceable symbolic representations (aka models).
That makes for two distinct model sets:
- Business environments are represented by extensional models, i.e ones describing actual objects and activities with regard to the categories set by enterprise business model.
- Enterprise architectures are described by intensional models, i.e ones prescribing how organization and systems are to be built.
Depending on size, complexity of organizations and systems, a level of indirection can be managed in between, as illustrated by MDA distinction between computation independent (CIM), platform independent PIM), and platform specific (PSM) models. PIMs and PSMs would correspond respectively to EACOE architecture and implementation.
Value in Models Transformation: Lean, Users Driven, & Knowledge Based
EA being a management discipline, it is bound to induce a motley of models to be shared and distributed across business and supporting units. In order to avoid a glut of redundant models, cumbersome procedures, and poor return on investment, processes have to remain lean and cut to the bone.
That can be achieved if models are justified by clearly identified purpose (governance or engineering), and set with clear semantics (descriptive, prescriptive, or mixed):
- Descriptive (extensional) ones are supposed to be computation independent models (CIMs) and used to support transformations into other descriptive models, e.g analytical or conceptual ones.
- Prescriptive (intensional) ones target platform specific models (PSMs), their purpose is to support crossed transformations or code generation targeting different platforms.
- Mixed ones (PIMs) stand in-between and describe platform independent (aka functional) architectures meant to support business processes and be supported by systems platforms.
Models can then be understood as intermediate products to be processed “just-in-time” depending on users’ drive and artifacts’ status.
With artifacts “inventories” organized along layers, the traceability and transparency of inputs would be set with regard to embedded knowledge: business, organization and supporting systems, and platform technologies. The value of transformations could then be assessed on that basis.
Skills Acquisition: Modular & Smooth Learning Curve
The range of enterprise architecture skills is by nature multi-faceted and volatile:
- Multi-faceted: Enterprise architects have to deal with the variety of business domains, the singularity of human organizations, and the technicality of systems architectures.
- Volatile: enterprise architecture is essentially a work in progress whose purpose is to combine changing environments, emerging structures and behaviors, and planned organization.
If they are to tally with such disparate needs, skills are best defined with regard to a limited number of stable characteristics:
- Target: Enterprise and business oriented, or systems and technology oriented.
- Purpose: Architectures or business value.
Given the diversity and transformations of challenges, the relevant skills have to be adjusted, expanded, and deepened continuously; that can only be achieved through a cross-reinforcement of practical and theoretical abilities combined with a modular and smooth learning curve.
Frameworks built from meticulously detailed processes, or sketched from broadly defined principles are ill-fitted to such pedagogy. By contrast, Caminao is built from a small and robust backbone of formally defined concepts that can be fleshed out with enterprise concrete semantics and decorated with customized terminology. That is to enable a step-by-step and open approach to EA.
Multiple Architect Roles: Responsibilities & Decision-making
As already mentioned, the raison d’être of enterprise architecture is to bring under a single roof business processes, enterprise organization, and IT systems. After dealing with criteria related to artifacts and communication, the last to consider is the way EA frameworks should support the integrity and consistency of decision-making.
The Caminao framework define responsibilities of enterprise architects along two dimensions: models and change management.
Regarding models, the dual perspective (actual vs symbolic) remains at the core of EA decision-making: business environments and processes should never be confused with their symbolic representations as systems surrogates. As a matter of fact managing that relationship is at the core of enterprise architecture, and these models are critical for the definition of responsibilities as well as for the support of collaboration. Bluntly speaking, without that distinction enterprise architects would find nothing to manage.
Regarding change and decision-making, differentiated models will help enterprise architects with the evolution of structures (objectives and assets) and the conduct of operations (processes and configurations), the former shared across business processes and time-frames, the latter set for specific processes and time cycles.
Concluding Remark: EA as Entropy Antidote
The emergence of EA as a discipline is not happening by chance but as a consequence of the crumbling of the traditional boundaries between enterprises and their environment. Faced with the new challenges of competition in seamless digital environments, enterprises success is conditioned by the plasticity and versatility of their architectures, more precisely on their ability to “digest” the variety of data, process it into serviceable information, to be distributed as knowledge towards the different units depending on purposes and time-scales : assets and organization, business value, systems capabilities.
Along that reasoning EA can be seen as a natural antidote to entropy: like corporate cousins of Maxwell’s demon, enterprise architects are to stand at enterprise data gates, looking for changes that could decrease internal complexity relative to the external one.
Further Reading
- Where to Begin with EA
- How to choose Frameworks & Methods
- EA Frameworks: Non Negotiable Features
- Thread: Enterprise Architecture
- Models, Architectures, Perspectives (MAPs)
- Architecture Capabilities
- Capabilities vs Processes
- Enterprise Governance & Knowledge
- Enterprise Architectures & Separation of Concerns
- From Processes to Services
- EA & MDA
- EA Documentation: Taking Words for Systems
- Abstractions & Emerging Architectures
- EA: Entropy Antidote
- Alignment: from Entropy to Abstraction
- Enterprise Systems & the OS Kernel Paradigm