Enterprise Architects are to jump across loops (Bruce Beasley)
When push comes to shove, deciding on a development process is to decide between instant or delayed returns, namely focusing on users needs with agile development, or taking extended features into consideration and weighting the benefits of reuse against additional costs, e.g.:
Designs to be reused as patterns.
Profiling configurations.
Structuring business process models so that they could be designed as business functions.
Formatting business logic for automated code generation.
The intricacies of stakes and decision-making processes can be set forth by applying the Observation-Orientation-Decision-Action (OODA) loop to the four views of changes: enterprise, business domains, business applications, systems:
At enterprise level the loops are triggered by changes in business environments pertaining to business model and objectives. They are supposed to affect different business domains.
Observations: Business opportunities
Orientation: Assessment of business opportunities with regard to business objectives.
Decision: Committing resources to changes in organization and processes
Action: Achieving changes in organization and processes
Changes initiated from business domains can be derived from enterprise level or the result of more specific objectives. They are supposed to affect different applications.
Observations: Business analysis
Orientation: Functional feasibility and assessment of transformation benefits.
Decision: Committing changes in functional architecture.
Action: Development, integration, tests
Changes at application level are initiated by organizational units, business or otherwise. They are supposed to be self-contained.
Observations: Users requirements
Orientation: Engineering feasibility and assessment of development options.
Decision: Choice of a development model.
Action: Development, integration, tests
Changes at system level are initiated by organizational units, including business ones (quality of service). They are supposed to affect different applications.
Observations: Process mining and operational requirements
Orientation: Operational feasibility and assessment of configurations.
Decision: Development model.
Action: Deployment and acceptance.
Given that sizeable companies with differentiated organization and business have to manage these different threads continuously and consistently, old fashioned imperative processes can only lead to paralysis. Hence the need of a declarative approach to EA workflows.
To become a discipline enterprise architecture has to contrive some shared modeling paradigm; that can be done from established ones like layers, MVC (Model-View-Controller), MDA (Model Driven Architecture), or the 4+1 views.
A Portable & Inter-operable Roof (Jonas Bendiksen)
Architecture Layers
To begin with, the basic layers of process, data, application, and technology layers can be rearranged as to make data orthogonal to other layers.
Then, Model Driven architecture (MDA) can be used as representative of model based systems engineering (MBSE) approaches:
Computation independent models (CIMs) describe organization and business processes independently of the role played by supporting systems.
Platform independent models (PIMs) describe the functionalities supported by systems independently of their implementation.
Platform specific models (PSMs) describe systems components depending on implementation platforms.
With regard to data bases modeling, there is a large consensus for the conceptual, logical, and physical distinction:
Conceptual models describe enterprises organization and business independently of supporting systems.
Logical models describe the symbolic objects managed by supporting systems as surrogates of business objects and activities.
Physical (nowadays digital) models describe the actual implementation of symbolic surrogates as binary objects.
As for systems functional modeling, the Model-View-Controller (MVC) is arguably the leading pattern whatever the guises:
Model: shared and a life-cycle independent of business processes. The continuity and consistency of business objects representation must be guaranteed independently of the applications using them.
View: what is not shared with a life-cycle set by user session. The continuity and consistency of representations is managed locally (interactions with external agents or devices independently of targeted applications.
Controller: shared with a life-cycle set by a business process. The continuity and consistency of representations is managed independently of the persistency of business objects and interactions with external agents or devices.
Services can be introduced to represent functions to be shared with no life-cycle.
Architecture engineering
Finally, the relationships between architecture blueprints and systems engineering can be derived from Philippe Kruchten’s “4+1”: View Model of Software Architecture”:
Logical view: design of software artifacts.
Process view: execution of activities.
Deployment (aka physical) view: mapping of software components across physical environments (platforms).
Development (aka implementation) view: organization of software artifacts in development environments.
A fifth view being added for use cases describing interactions between systems and environments.
At first, views at enterprise architecture level appear to be congruent with these ones, e.g: logical for data, process for applications, physical for technology. But labels may be misguiding when applied indifferently to software architecture (views) and enterprise architecture (layers): contrary to views, which are solely defined by concerns independently of targeted structures, layers reflect definitive assumptions about architectures. That confusion between views and layers, illustrated by a miscellany of tabular and pyramidal representations, would be of little consequence were the modeling of changes not a critical issue; not so for enterprise architecture.
As it happens the confusion can be worked out if views are redefined solely and comprehensibly in terms of engineering:
Domains modeling: conceptual, logical, and physical.
Applications development: business logic, systems functions, programs.
Systems deployment: locations, processes, configurations.
Enterprise organisation and operations.
That make views congruent with engineering workshops, enabling a seamless integration of enterprise architecture blueprints with evolutionary processes.
To be brief and to the point a presentation of enterprise architecture at decision-makers is to follow three principles:
Architecture is visual issue
Schemas should contain between 8 and 12 unrelated concepts.
Semantics should be non ambiguous and specific to the issue.
(Bridget Riley)
To that end, the focus should present architecture as an activity and its outcome. Applied to enterprise, architecture has to deal with more than actual edifices and contexts, and encompasses business environments and objectives on one side, organization, processes, and assets on the other side. Moreover, enterprise architecture is a continuous and dynamic endeavor because change and exchanges are part and parcel of enterprises life-cycle:
At enterprise level, architectures are needed to map organizations and systems to changing environments.
At system level, architectures are needed to map changing organizations and processes to supporting systems.
Enterprise architecture can therefore be defined in terms of the maps and territories (outcome), and the management of changes across and between (activity).
Mapping Territories
Compared to its bricks and mortar counterpart, enterprises architecture is a work in progress to be carried out all along enterprises life-cycle; hence the need of maps to figure out their environments, organization, assets, and processes:
At enterprise level maps are meant to describe business environments on one hand, concepts, objectives, organization and processes on the other hand.
At operational level maps are to describe physical and digital environments on one hand, interfaces and platforms on the other hand.
Then, a third level is introduced in between to describe systems and ensure transparency and consistency with regard to territories.
Enterprise Maps & Territories
For all intents and purposes that ternary view of enterprise architectures holds true independently of labels (layers, levels, tiers, etc), or perspective (business, data, applications, technologies, etc). That genericity appears clearly when maps are aligned with traditional models hierarchy: conceptual, logical and functional, and physical.
managing changes
Taking a leaf from Stafford Beer’s view of enterprises as viable systems, their sustainability depends on a continuous and timely adaptation to their environment; that cannot be achieved without a dynamic alignment of maps and territories; hence the need for enterprise architectures to provide for:
Continuous and consistent attachments between identified elements in maps and territories.
Transparency and traceability of changes across maps and territories.
Regarding continuity, ill-famed Waterfall epitomizes the detached conception of systems engineering and its implicit assumption that requirements are enough to ensure the alignment of systems with their business environments. To be sure, the plights of Waterfall have already marked a significant rip in the detached paradigm, a rift partially patched by agile development models. But while agile, and more generally iterative schemes, are at their best for business driven application with well defined scope and ownership, they fall short for architecture oriented ones with overlapping footprint and distributed stakeholders; that’s when maps are required.
Regarding transparency, enterprise architecture misconceptions come from mirroring its physical cousin, using geometrical patterns without being specific about their constitutive elements, and consequently the dynamics of interactions.
As it happens, both flaws can be mended by generalizing to systems the well accepted view model of software architecture:
Logical view: design of software artifacts.
Process view: captures the concurrency and synchronization aspects.
Physical view: describes the mapping(s) of software artifacts onto hardware.
Development view: describes the static organization of software artifacts in development environments.
One that basis changes in systems architectures would be managed in four workshops, two focused on territories (enterprise and operations) and two on maps (domains and applications).
Mapping changes to Enterprise Architectures
Defining engineering workflows in terms of maps and territories is to provide the foundations of model based systems engineering.
As demonstrated by a simple Google search, the MBSE acronym seems to be widely and consistently understood. Yet, the consensus about ‘M’ standing for models comes with different meanings for ‘S’ standing either for software or different kinds of systems.
Tools At Hand (Annette Messager)
In practice, the scope of model-based engineering has been mostly limited to design-to-code (‘S’ for software) and manufacturing (‘S’ for physical systems); leaving the engineering of symbolic systems like organizations largely overlooked.
Models, Software, & Systems
Models are symbolic representations of actual (descriptive models) or contrived (prescriptive models) domains. Applied to systems engineering, models are meant to serve specific purposes: requirements analysis, simulation, software design, etc. With software as the end-product of system engineering, design models can be seen as a special case of models characterized by target (computer code) and language (executable instructions). Hence the letter ‘S’ in the MBSE acronym, which can stand for ‘system’ as well as ‘software’,
As far as practicalities are considered, the latter is the usual understanding, specifically for the use of design models to generate code, either for software applications, or as part of devices combining software and hardware.
When enterprise systems are taken into consideration, such a limited perspective comes with consequences:
It puts the focus on domain specific implementations, ignoring the benefits for enterprise architecture.
It gives up on the conceptual debt between models of business and organization on one side, models of systems on the other side.
These stand in the path of the necessary integration of enterprises architectures immersed into digital environments.
Organizations as Symbolic Systems
As social entities enterprises are set in symbolic realms: organizational, legal, and monetary. Now, due the digital transformation, even their operations are taking a symbolic turn. So, assuming models could be reinstated as abstractions at enterprise level, MBSE would become the option of choice, providing a holistic view across organizations and systems (conceptual and logical models) while encapsulating projects and applications (design models).
MBSE provides a holistic view of organisations and systems.
That distinction between symbolic and actual alignments, the former with conceptual and logical models set between organization and systems, the latter with design models set between projects and applications, is the cornerstone of enterprise architecture. Hence the benefits of implementing it through model based system engineering.
Leveraging MBSE
While MBSE frameworks supporting the final cycle of engineering (from design downstream) come with a proven track record, there is nothing equivalent upstream linking business and organization to systems, except for engineering silos using domain specific languages. Redefined in terms of enterprise architecture abstractions, MBSE could bring leveraged benefits all along the development process independently of activity, skills, organization or methods, for enterprises as well as services and solutions providers.
As a modeling framework, it would enhance the traceability and transparency for products (quality) as well as processes (delays and budgets) along and across supply chains.
‘S’ For Service
Implemented as a service, MBSE could compound the benefits of cloud-based environments (accessibility, convenience, security, etc.), and could also be customized without undermining interoperability.
To that end, MBSE as a service could be reframed in terms of:
Customers (projects): services should address cross-organizational and architecture concerns, from business intelligence to code optimization, and from portfolio management to components release.
Policy (processes): services should support full neutrality with regard to organizations and methods, which implies that tasks and work units should be defined only with regard to the status of artifacts.
Contracts (work units and outcomes): services are to support the definition of work units and the assessment of outcomes:
Work units are to be defined bottom-up from artefacts.
Outcomes are to be assessed with regard to work units
Value in Models Transformations:
Transparency and Traceability: Two distinct model sets – Architecture Models and Implementation Models.
Endpoints (collaboration): if services are to be neutral with regard to the way they are provided, the collaboration between the wide range of is to be managed accordingly; that can only be achieved through a collaboration framework built on layered and profiled ontologies.
As a concluding remark, cross-breeding MBSE with Software as a Service (SaaS) could help to integrate systems and knowledge architectures, paving the way to a comprehensive deployment of machine learning technologies.
Hitting the ground running with Caminao is meant to be easy as it relies on a well-founded modeling paradigm (Stanford Symbolic Systems Program) and a solid and well established reference framework (Zachman’s).
Moving On (Moises Levy)
Secured by these foundations, teams could carry on with agile and MBSE development models, helped, if and when necessary, by a comprehensive and consistent documentation freely available online.
Symbolic Systems Paradigm
The Stanford Symbolic System Program (SSP) is built on clear and incontrovertible evidence: the purpose of computer systems is to manage the symbolic counterparts (aka surrogates) of business objects and activities. Based on that understanding, enterprise architectures can be wholly and consistently defined by maps (the models) and territories (relevant business objects and activities and their symbolic counterparts in systems).
That paradigm is at the same time straightforward and aligned with the formal distinction between extensional and intensional representations, the former for requirements analysis (descriptive models), the latter for systems design (prescriptive models).
Zachman’s Framework
Given its clarity of purpose and concepts, the Zachman Framework is arguably a reference of choice; its core is defined by six columns and five lines, each of them associated with well known concepts:
That simple transformation significantly improves the transparency of enterprise architectures while bringing a new light on dependencies set across layers and capabilities. As it happens, and not by chance, it neatly fits with the Pagoda architecture blueprint.
Digital Transformation & The Pagoda Blueprint
The generalization of digitical environments bears out the Symbolic System modeling paradigm: to stay competitive, enterprises have to manage a relevant, accurate, and up-to-date symbolic representation of their business context and concerns. On that account, consequences go well beyond a shallow transformation of business processes and call for an in-depth transformation of enterprise architectures that should put the focus on their capacity to refine business data flows into information assets supporting knowledge management and decision-making:
Ubiquitous, massive, and unrelenting digitized business flows cannot be dealt with lest a clear distinction is maintained between raw data acquired across platforms and the information (previously data) models ensuring the continuity and consistency of systems.
Once structured and refined, business data flows must be blended with information models sustaining systems functionalities.
A comprehensive and business driven integration of organization and knowledge could then support strategic and operational decision-making at enterprise level.
Such an information backbone set across architecture layers tallies with the Pagoda architecture blueprint well known for its resilience and adaptability in unsettled environments.
The Pagoda Architecture Blueprint is derived from the Zachman’s framework
That blueprint can be much more than metaphoric: applied to enterprise architectures it would greatly enhance the traceability of transformations induced by digital environments.
Proceed With Agile & MBSE
Once set on track with a reliable paradigm and a clear reference framework, teams can carry on with their choice of development models:
Agile schemes for business driven applications for which conditions of shared ownership and continuous delivery can be met.
Phased schemes for architecture developments set across business processes.
Whatever the development methods, the modeling paradigm will put enterprise architecture and projects management on a principled basis, and the framework will significantly enhance their integration.
Take a knowledge PERSPECTIVE
The success of knowledge graphs in AI applications is putting a new light on ontologies, first expounded by Greek philosophers as a general knowledge management scheme.
Hence the benefits of using ontologies to bring under a common roof the full range of data, information, and knowledge pertaining to enterprise architectures.
Deciding upon a framework is a choice that bears upon a wide range of enterprise activities and may induce profound transformations in organization and systems. It ensues that the outcome is practically settled at the outset: once on a wrong path the only option is often to cut the losses as soon as possible.
When the first step settles the issue for the whole journey (Gianni Motti)
As it happens, there is no reason to hurry and every reason to take the time before opting for a long-term and comprehensive commitment.
Taking simple litmus tests can be used to avert overhasty moves into quagmires. Compared to a comprehensive assessment, the objective would only be to establish a shortlist of frameworks worth of a further assessment. For that purpose forms (but not substance) are to be considered for the consistency of definitions, the specificity of value propositions, and the reliability of roadmaps.
Consistency of Definitions
Frameworks come with glossaries covering generic, specific, and standard terms in various proportions; the soundness of these glossaries can be assessed independently of their meanings.
For that purpose simple metrics can be applied to a sample of definitions of core concepts, (e.g: agent, role, actor, event, object, activity, process, device, system, architecture, enterprise):
Self-contained: terms directly and fully defined, i.e without referring to other glossary terms (c,a,m).
Number of references used.
Circular references: terms including at least one path to itself (d,e,f)
Average length of non-circular references
Overlaps (i and j)
Conflicts (w by (x><e)
Basic definitions graph (x contradict e)
Even computed on small samples (10 to 50), these metrics should be enough to provide a sound yardstick.
Value Proposition Specifics
Pledges about meeting stakeholder needs, holistic undertaking, or enhanced agility are part and parcel of every pitch; but as declarations of intent they give little information about frameworks.
To be given consideration a framework should also be specific about its value proposition, in particular with regard to its description of enterprise architecture and systems engineering processes.
Assuming that the specificity of a value proposition equals the likelihood of a contrary stance (no framework would purport ignoring business needs or being non agile), general commitments must be supported by schemes meant to make a difference.
Roadmap Reliability
Given what is at stake, adopting a framework should only be considered if it can significantly reduce uncertainty. On that account road-maps built from pre-defined activities are deceptive as they rely on the implicit assumption that things will always be as they are meant to be. So, taking for granted that positive outcomes can never be guaranteed independently of circumstances, a framework reliability is to be assessed through its governance apparatus.
Frames are meant to bring light on artifacts, not to cover them with veils; on that account, frameworks’ primary justification should be their leverage on engineering practices.
Frames are meant to bring light on artifacts (Y. Levin)
It ensues that enterprises frameworks should only be considered in relation to actual contents (organization, artifacts, processes, …), and their benefits for core governance issues, in particular measurements, processes integration, and economic intelligence.
Prerequisite: Measurements
The heterogeneity of metrics is clearly a major impediment to assessment at enterprise level due to the different yardsticks associated with business value, development costs, and processes maturity.
The least frameworks should do for enterprise architects is to provide common bearings at both application and enterprise levels:
Application level: a consolidated scale for the mapping of value points, function points, and development costs.
Enterprise level: a common basis for a reliable assessment of systems capabilities and processes maturity.
A detailed account of how a framework would support such bearings should therefore be a prerequisite.
Cornerstone: Business & Engineering Processes Integration
Except for the Zachman framework, providers haven’t much to say about how actual business and engineering processes are to be hung to the proposed framework, and more generally about the continuity with existing methods, tools, and practices.
Conversely, being specific about the hinges linking it to processes is to give credence to a framework leveraging impact:
Business: leveraged agility from the harnessing of users’ stories to business functions.
Engineering: leveraged transparency, traceability and reuse from model based systems engineering (MBSE).
As the cornerstone of any enterprise framework, integration is to support their ultimate purpose, namely economic intelligence.
Deal Breaker: Economic Intelligence
Economic intelligence is usually understood as a merge of data analytics, information architecture, business intelligence, and decision-making; as such it can be seen as a primary justification for enterprise architecture frameworks.
As a corollary, one would expect frameworks to be specific with regard to the integration of data analytics, information processing, and knowledge management:
To begin with, no framework should be considered without being explicit about the ways such integration could be achieved.
Then, integration schemes should aim at being neutral with regard to engineering or support environments deployed at architecture level.
When options are considered, that should be taken as a deal breaker.
Conclusion
Assuming that expectations about measurements and processes could be reasonably borne out, decisions would rest on economic intelligence strategies.
Depending on the weight of information systems legacy, full neutrality may deem a too ambitious strategy. In that case an enterprise architecture framework could be built bottom up from MBSE environments.
Given that proviso, a neutral framework designed on purpose would bring much more leverage due to the generalization of well-defined slots and interfaces for business and engineering platforms; that would also facilitate modernization and consolidate quality assurance across enterprise architectures.
Finally, for EA frameworks to ensure consistent metrics, processes integration, and economic intelligence, knowledge management must encompass a wide range of concerns (business, engineering, regulations, …), contexts (environments, enterprise, systems), and resources (texts, models, people, …); that can be best achieved with profiled ontologies.
European Union’s General Data Protection Regulation (GDPR), to come into effect this month, is a seminal and momentous milestone for data privacy .
Nothing Personal (Arthur Szyk)
Yet, as reported by Reuters correspondents, European enterprises and regulators are not ready; more worryingly, few (except consultants) are confident about GDPR direction.
Misgivings and uncertainties should come as no surprise considering GDPR’s two innate challenges:
Regulating privacy rights represents a very ambitious leap into a digital space now at the core of corporate business strategies.
Compliance will not be put under a single authority but be overseen by an assortment of national and regional authorities across the European Union.
On that account, ontologies appear as the best (if not the only) conceptual approach able to bring contexts (EU nations), concerns (business vs privacy), and enterprises (organization and systems) into a shared framework.
Enterprise Architectures & Regulations
Compared to domain specific regulations, GDPR is a governance-oriented regulation set across business concerns and enterprise organization; but unlike similarly oriented ones like accounting, GDPR is aiming at the nexus of business competition, namely the processing of data into information and knowledge. With such a strategic stake, compliance is bound to become a game-changer cutting across business intelligence, production systems, and decision-making. Hence the need for an integrated, comprehensive, and consistent approach to the different dimensions involved:
Concepts upholding businesses, organizations, and regulations.
Documentation with regard to contexts and statutory basis.
Regulatory options and compliance assessments
Enterprise systems architecture and operations
Moreover, as for most projects affecting enterprise architectures, carrying through GDPR compliance is to involve continuous, deep, and wide ranging changes that will have to be brought off without affecting overall enterprise performances.
Ontologies arguably provide a conclusive solution to the problem, if only because there is no other way to bring code, models, documents, and concepts under a single roof. That could be achieved by using ontologies profiles to frame GDPR categories along enterprise architectures models and components.
Basic GDPR categories and concepts (black color) as framed by the Caminao Kernel
Compliance implementation could then be carried out iteratively across four perspectives:
Personal data and managed information
Lawfulness of activities
Time and Events
Actors and organization.
Data & Information
To begin with, GDPR defines ‘personal data’ as “any information relating to an identified or identifiable natural person (‘data subject’)”. Insofar as logic is concerned that definition implies an equivalence between ‘data’ and ‘information’, an assumption clearly challenged by the onslaught of big data: if proofs were needed, the Cambridge Analytica episode demonstrates how easy raw data can become a personal affair.
Failing an enshrined distinction between data (directly associated to instances) and information (set according to categories or types), an ontological level of indirection should be managed between regulatory intents and the actual semantics of data as managed by information systems.
Managing the ontological gap between regulatory understandings and compliance footprints
Once lexical ambiguities set apart, the question is not so much about the data bases of well identified records than about the flows of data continuously processed: if identities and ownership are usually set upfront by business processes, attributions may have to be credited to enterprises know-how if and when carried out through data analytics.
Given that the distinctions are neither uniform, exclusive or final, ontologies will be needed to keep tabs on moves and motives. OWL 2 constructs (cf annex) could also help, first to map GDPR categories to relevant information managed by systems, second to sort out natural data from nurtured knowledge.
Activities & Purposes
Given footprints of personal data, the objective is to ensure the transparency and traceability of the processing activities subject to compliance.
Setting apart (see below for events) specific add-ons for notification and personal accesses, charting compliance footprints is to be a complex endeavor: as there is no reason to assume some innate alignment of intended (regulation) and actual (enterprise) definitions, deciding where and when compliance should apply potentially calls for a review of all processing activities.
After taking into account the nature of activities, their lawfulness is to be determined by contexts (‘purpose limitation’ and ‘data minimization’) and time-frames (‘accuracy’ and ‘storage limitation’). And since lawfulness is meant to be transitive, a comprehensive map of the GDPR footprint is to rely on the logical traceability and transparency of the whole information systems, independently of GDPR.
That is arguably a challenging long-term endeavor, all the more so given that some kind of Chinese Wall has to be maintained around enterprise strategies, know-how, and operations. It ensues that an ontological level of indirection is again necessary between regulatory intents and effective processing activities.
Along that reasoning compliance categories, defined on their own, are first mapped to categories of functionalities (e.g authorization) or models (e.g use cases).
Compliance categories are associated upfront to categories of functionalities (e.g authorization) or models (e.g use cases).
Then, actual activities (e.g “rateCustomerCredit”) can be progressively brought into the compliance fold, either with direct associations with regulations or indirectly through associated models (e.g “ucRateCustomerCredit” use case).
Compliance as carried out through Use Case
The compliance backbone can be fleshed out using OWL 2 mechanisms (see annex) in order to:
Clarify the logical or functional dependencies between processing activities subject to compliance.
Qualify their lawfulness.
Draw equivalence, logical, or functional links between compliance alternatives.
That is to deal with the functional compliance of processing activities; but the most far-reaching impact of the regulation may come from the way time and events are taken into account.
Time & Events
As noted above, time is what makes the difference between data and information, and setting rules for notification makes that difference lawful. Moreover, by adding time constraints to the notifications of changes in personal data, regulators put systems’ internal events on the same standing as external ones. That apparently incidental departure echoes the immersion of systems into digitized business environments, making all time-scales equal whatever their nature. Such flattening is to induce crucial consequences for enterprise architectures.
That shift together with the regulatory intent are best taken into account by modeling events as changes in expectations, physical objects, processes execution, and symbolic objects, with personal data change belonging to the latter.
Mapping internal (symbolic) and external (actual) events is a critical element of GDPR compliance
Putting apart events specific to GDPR (e.g data breaches), compliance with regard to accuracy and storage limitation regulations will require that all events affecting personal data:
Are set in time-frames, possibly overlapping.
Have notification constraints properly documented.
Have likelihood and costs of potential risks assessed.
As with data and activities, OWL 2 constructs are to be used to qualify compliance requirements.
Actors & Organization
GDPR introduces two specific categories of actors (aka roles): one (data subject) for natural persons, and one for actors set by organizations, either specifically for GDPR assignment, or by delegation to already defined actors.
GDPR roles can be set specifically or delegated
OWL 2 can then be used to detail how regulatory roles can be delegated to existing ones, enabling a smooth transition and a dynamic adjustment of enterprise organization with regulatory compliance.
It must be stressed that the semantic distinction between identified agents (e.g natural persons) and the roles (aka UML actors) they play in processes is of particular importance for GDPR compliance because who (or even what) is behind an actor interacting with a system is to remain unknown to the system until the actor can be authentically identified. If that ontological lapse is overlooked there is no way to define and deal with security, confidentiality or privacy regulations.
Conclusion
The use of ontologies brings clear benefits for regulators, enterprise governance, and systems architects.
Without shared conceptual guidelines chances are for the European regulatory orchestra to get lost in squabbles about minutiae before sliding into cacophony.
With regard to governance, bringing systems and regulations into a common conceptual framework is to enable clear and consistent compliance strategies and policies, as well as smooth learning curves.
With regard to architects, ontology-based compliance is to bring cross benefits and externalities, e.g from improved traceability and transparency of systems and applications.
Annex A: Mapping Regulations to Models (sample)
To begin with, OWL 2 can be used to map GDPR categories to relevant resources as managed by information systems:
Equivalence: GDPR and enterprise definitions coincide.
Logical intersection, union, complement: GDPR categories defined by, respectively, a cross, merge, or difference of enterprise definitions.
Qualified association between GDPR and enterprise categories.
Assuming the categories properly identified, the language can then be employed to define the sets of regulated instances:
Logical property restrictions, using existential and universal quantification.
Functional property restrictions, using joints on attributes values.
Other constructs, e.g cardinality or enumerations, could also be used for specific regulatory constraints.
Finally, some OWL 2 built-in mechanisms can significantly improve the assessment of alternative compliance policies by expounding regulations with regard to:
Equivalence, overlap, or complementarity.
Symmetry or asymmetry.
Transitivity
etc.
Annex B: Mapping Regulations to Capabilities
GDPR can be mapped to systems capabilities using well established Zachman’s taxonomy set by crossing architectures functionalities (Who,What,How, Where, When) and layers (business and organization), systems (logical structures and functionalities), and platforms (technologies).
Regulatory Compliance vs Architectures Capabilities
These layers can be extended as to apply uniformly across external ontologies, from well-defined (e.g regulations) to fuzzy (e.g business prospects or new technologies) ones, e.g:
Ontologies, capabilities (Who,What,How, Where, When), and architectures (enterprise, systems, platforms).
Such mapping is to significantly enhance the transparency of regulatory policies.
As the world turns digital,traditional fences between social, businesses, and systems realms are progressively crumbling. That brings new challenges for enterprises governance, in particular when manifold business stakes and IT systems are concerned.
Layers & labels (T. Cragg)
Supposedly, enterprise architecture would deal with the framing of enterprises and systems concerns into a single paradigm. Yet spirited controversies persist between bottom up and top down approaches, the former trying to upgrade the footprint of IT systems to enterprise level, the latter ready to downgrade these systems to equipment level. But dissent in that case means unfinished business: like diggers tunneling from opposite directions, both groups are to succeed together or fail together. For that to be achieved common sense dictates that both teams agree on target, with each one getting its specific orientation right.
What to look for
Issue (information systems) and circumstances (digitization of business environment) put the focus on the relationship between business processes and enterprises organization and how to capture, manage, and use information.
On that account, and not surprisingly, understandings differ between EA proponents:
Bottom-up approaches are focused on the distinction between processes, applications, and data, overlooking key enterprise architecture concerns (a).
Top-down approaches come with a better understanding of EA stakes but fall short of the conceptual bridge between organization and business environments (b) .
Bottom-up (a) and top-down (b) approaches to EA
These shortcomings can be mended and approaches made to converge.
How to get there
As already noted, EA can only succeed as a discipline if systems and enterprise perspectives can be crossed, i.e if bottom-up and top-down approaches can be joined. That cannot be achieved along the outdated Process/Application/Data layers:
To begin with, the distinction between application and data, inherited from traditional programming, goes against both object-oriented design and service oriented architectures; then, processes don’t describe architectures but the way they are used.
On a broader perspective, if the impact of digitized business environments on EA is to be taken into account, data and information are to be redefined in a new paradigm, the former associated with a raw input, to be mined from the business environment and processed into the latter. It ensues that (1) data becomes irrelevant for architecture concerns and, (2) information becomes a key asset for enterprise architecture.
Merging applications and data into a logical/functional layer between business and engineering processes also critically redefines the perspective: instead of a being a collection of applications, business processes become the nexus of the architecture.
Introducing a functional layer between business and engineering processes
With a bottom-up EA perspective focused on business and engineering processes, a top-down counterpart has to be set from enterprise perspective that would ensure a meeting of minds around business processes.
That can be readily achieved by keeping processes as pivot between business environments and objectives on one side, enterprise organization on the other side:
Processes are the nexus of enterprise and engineering concerns.
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.
Why It Matters
A proper understanding of architecture layers is not an academic concern to be overlooked. As a matter of fact, what is at stake is the very practical purpose of EA: display of boxes and arrows or effective handling of the spindle between business processes and architectural assets. Whereas anything will do for the former, the latter cannot be achieved without a principled and effective coupling between enterprise models and systems engineering.
Requirements is what to feed engineering processes. As such they are to be presented under a wide range of forms, and nothing should be assumed upfront about forms or semantics.
What is to be reused: Sketches or Models ? (John Devlin)
Answering the question of reuse therefore depends on what is to be reused, and for what purpose.
Documentation vs Reuse
Until some analysis can be carried out, requirements are best seen as documents; whether such documents are to be ephemeral or managed would be decided depending on method (agile or phased), contents (business, supporting systems, implementation, or quality of services), or purpose (e.g governance, regulations, etc).
What is to be reused.
Setting apart external conditions, requirements documentation could be justified by:
Traceability of decision-making linking initial requests with actual implementation.
Acceptance.
Maintenance of deliverables during their life-cycle.
Depending on development approaches, documentation could limited to archives (agile development models) or managed as intermediate products (phased development models). In the latter case reuse would entail some formatting of requirements.
The Cases for Requirements Reuse
Assuming that requirements have been properly formatted, e.g as analysis models (with technical ones managed internally at system level), reuse could be justified by changes in business, functional, or quality of services requirements:
Business processes are meant to change with opportunities. With requirements available as analysis models, changes would be more easily managed (a) if they could be fine-grained. Business rules are a clear example, but that could also be the case for new features added to business objects.
Functional requirements may change even without change of business ones, e.g if new channels and users are introduced addressing existing business functions. In that case reusable business requirements (b) would dispense with a repeat of business analysis.
Finally, quality of service could be affected by operational changes like localization, number of users, volumes, or frequency. Adjusting architecture capabilities would be much easier with functional (c) and business (d) requirements properly documented as analysis models.
Cases for Reuse
Along that perspective, requirements reuse appears to revolve around two pivots, documents and analysis models. Ontologies could be used to bind them.
Requirements & Ontologies
Reusing artifacts means using them in contexts or for purposes different of native ones. That may come by design, when specifications can anticipate on shared concerns, or as an afterthought, when initially unexpected similarities are identified later on. In any case, reuse policies have to overcome a twofold difficulty:
Visibility: business and functional analysts must be made aware of potential reuse without having to spend too much time on research.
Overheads: ensuring transparency, traceability, and consistency checks on requirements (documents or analysis models) cannot be achieved without costs.
Ontologies could help to achieve greater visibility with acceptable overheads by framing requirements with regard to nature (documents or models) and context:
With regard to nature, the critical distinction is between document management and model based engineering systems. When framed as ontologies, the former is to be implemented as thesaurus targeting terms and documents, the latter as ontologies targeting categories specific to organizations and business domains.
Documents, models, and capabilities should be managed separately
With regard to context the objective should be to manage reusable requirements depending on the kind of jurisdiction and stability of categories, e.g:
Institutional: Regulatory authority, steady, changes subject to established procedures.
Professional: Agreed upon between parties, steady, changes subject to accord.
Corporate: Defined by enterprises, changes subject to internal decision-making.
Social: Defined by usage, volatile, continuous and informal changes.
Personal: Customary, defined by named individuals (e.g research paper).
Combining contexts of reuse with architectures layers (enterprise, systems, platforms) and capabilities (Who,What,How, Where, When).
Combined with artificial intelligence, ontology archetypes could crucially extend the benefits of requirements reuse, notably through the impact of deep learning for visibility.
On a broader perspective requirements should be seen as a source of knowledge, and their reuse managed accordingly.
