System modeling is all too often a flight for abstraction, when business analysts should instead look for the proper level of representation, ie the one with the best fit to business concerns.
Caminao’s blog (see Topics Guide) will try to set a path to Architecture Driven System Modelling. The guiding principle is to look at systems as sets of symbolic representations and identify the core archetypes defining how they must be coupled to their actual counterparts. That would provide for lean (need-to-know specs) and fit (architecture driven) models, architecture traceability, and built-in consistency checks.
This blog is meant to be a work in progress, with the basic concepts set open to suggestions or even refutation:
The way tests are designed and executed is being doubly affected by development methods and AI technologies. On one hand well-founded approaches (e.g test-driven development) are often confined to faith-based niches; on the other hand automated schemes and agile methods push many testers out of their comfort zone.
Resetting the issue within a knowledge-based enterprise architecture would pave the way for sound methods and open new doors for their users.
Tests can be understood in terms of preventive and predictive purposes, the former with regard to actual products, the latter with regard to their forthcoming employ. On that account policies are to distinguish between:
Test plans, to be derived from requirements.
Test cases, to be collected from environments.
Test execution, to be run and monitored in simulated environments.
The objective is to cross these pursuits with knowledge architecture layers.
Test plans are derived from business requirements, either on their own at process level (e.g as users stories or activities), or combined with functional requirements at application level (e.g as use cases). Both plans describe sequences of actions meant to be performed by organizational entities identified at enterprise level. Circumstances are then specified with regard to quality of service and technical requirements.
Test cases’ backbones are built from business scenarii fleshed out with instances mimicking identified entities from business environment, and hypothetical decisions taken by entitled users. The generation of actual instances and decisions could be automated depending on the thoroughness and consistency of business requirements.
To be actually tested, business scenarii have to be embedded into functional ones, yet the distinction must be maintained between what pertains to business logic and what pertains to the part played by supporting systems.
By contrast, despite being built from functional scenarii, integration and acceptance ones are meant to be blind to business or functional contents, and cases can therefore be generated independently.
Unit and components tests are the building blocks of all test cases, the former rooted in business requirements, the latter in functional ones. As such they can be used to a built-in integration of tests and development.
TDD in the loop
Whatever its merits for phased projects, the development V-model suffers from a structural bias because flaws rooted in requirements, arguably the most damaging, tend to be diagnosed after designs are encoded. Test driven development (TDD) takes a somewhat opposite approach as code specifications are governed by testability. But reversing priorities may also introduce reverse issues: where the V-model’s verification and validation come too late and too wide, TDD’s may come hasty and blinkered, with local issues masking global ones. Applying the OODA (Observation, Orientation, Decision, Action) loop to test cases offers a way out of the dilemma:
Observation (West): test and assessment for component, integration, and acceptance test cases.
Orientation (North): assessment in the broader context of requirements space (business, functional, Quality of Service), or in the local context of application (East).
Decision (East): confirm or adjust the development paths with regard to functional scenarii, development backlog, or integration constraints.
Action (South): develop code at unit, component, or process levels.
As each station is meant to deal with business, functional, and operational test cases, the challenge is to ensure a seamless integration and reuse across iterations and layers.
managing Tests cases
Whatever the method, tests plans are meant to mirror requirements scope and structure. For architecture oriented projects, tests should be directly aligned with the targeted capabilities of architecture layers:
For business driven projects, test plans should be set along business scenarii, with development units and associated test cases defined with regard to activities. When use cases, which cover the subset of activities supported by systems, are introduced upfront for both business and functional requirements, test plans should keep the distinction between business and functional requirements.
All things considered, test cases are to be comprehensively and consistently run against requirements distinct in goals (business vs architecture), layers (business, functions, platforms), or formalism (text, stories, use cases, …).
In contrast, test cases are by nature homogeneous as made of instances of objects, events, and behaviors; ontologies can therefore be used to define and manage these instances directly from models. The example below make use of instances for types (propulsion, body), car model (Renault Clio), and car (58642).
The primary and direct benefit of representing test cases as instances in ontologies is to ensures a seamless integration and reuse of development, integration, and acceptance test cases independently of requirements context.
But the ontological approach have broader and deeper consequences: by defining test cases as instances in line with environment data, it opens the door to their enrichment through deep-learning.
knowledgeable test cases
Names may vary but tests are meant to serve a two-facet objective: on one hand to verify the intrinsic qualities of artefacts as they are, independently of context and usage; on the other hand to validate their features with regard to extrinsic circumstances, present or in a foreseeable future.
That duality has logical implications for test cases:
The verification of intrinsic properties can be circumscribed and therefore by carried out based on available information, e.g: design, programing language syntax and semantics, systems configurations, etc.
The validation of functional features and behaviors is by nature open-ended with regard to scope and time-frame; it ensues that test cases have to rely on incomplete or uncertain information.
Without practical applications that distinction has been of little consequence, until now: while the digital transformation removes the barriers between test cases and environment data, the spreading of machine learning technologies multiplies the possibilities of exchanges.
Along the traditional approach, test cases relies on three basic sources of information:
Syntax and semantics of programing languages are used to check software components (a)
Logical and functional models (including patterns) are used to check applications designs (b).
Requirements are used to check applications compliance (c).
With barriers removed, test cases as instances can be directly aligned with environment data, opening doors to their enrichment, e.g:
Random data samples can be mined from environments and used to deal with human instinctive or erratic behaviors. By nature knee jerks or latent behavior cannot be checked with reasoned test cases, yet they neither occur in a void but within known operational of functional or circumstances; data analytics can be used to identify these quirks (d).
Systems being designed artifacts, components are meant to tally with models for structures as well as behaviors. Crossing operational data with design models will help to refine and hone integration and acceptance test cases (e).
Whereas integration tests put the focus on models and code, acceptance tests also involve the mapping of models to business and organizational concepts. As a corollary, test cases are to rely on a broader range of knowledge: external regulations, mined from environments, or embedded in organization through individual and collective skills (f).
Given the immersion of enterprises in digital environments, and assuming representing test cases as ontological instances, these are already practical opportunities. But the real benefits of knowledge based test cases are to come from leveraging machine learning technologies across enterprise and knowledge architectures.
To hear the buzz around business capabilities one would expect some consensus about basic principles as well as an established track record. Since there is little to be found on either account, should the notion be seen as a modern philosophers’ stone ?
Clear evidence can be found by asking two questions: what should be looked for, and why it can’t be found.
What is looked for
Business capabilities can be understood as a modern avatar of the medieval philosophers’ stone, a alchemical substance capable of turning base metals into gold.
In the context of corporate governance, that would mean a combination of assets blueprints and managing principles paving the way to success.
But such a quest is to err between the sands of businesses specificities and the clouds of accounting generalities.
At ground level enterprises have to mark their territory and keep it safe from competitors. Whatever the means they use (niche segments, effective organization, monopolistic situations, …,) success comes from making a difference.
With hindsight, revealing singularities may be discovered among the idiosyncrasies of business successes, but that can only be done from accounting heights, where capabilities are clouded by numbers.
why it can’t be found
The fallacy of a notion can also be established a contrario if, assuming the existence of a philosophers’ stone, the same logic would also demonstrate the futility of the quest.
Such a reasoning appears more like a truism when applied to business capabilities: insofar as business competition is concerned success is exclusive and cutting edges are not shared. It ensues that assuming business capabilities could be found, they would by the same move become obsolete and be instantly dissolved.
What should be looked for
As far as business environments are concerned, success is by nature singular and transient, and it consequently depends on sustaining a balancing act between assets and opportunities. To that end business capabilities should be understood as a hub between value chains and enterprise architectures.
As defined by thermodynamics entropy is a measure of the energy within a system that cannot be harnessed to useful use; cybernetics has took over, making entropy a pillar of information theory.
Notwithstanding the focus put on viable systems and organizations (as epitomized by the pioneering work of Stafford Beer), cybernetics’ actual imprint on corporate governance has been frustrated by the correspondence assumed between information and energy. But the immersion of enterprises into digital environments brings entropy back in front, along with a paradigmatic shift out of thermodynamics.
domain: Physics vs Economics
The second law of thermodynamics states that entropy within a system is constant, and so is information as defined by cybernetics. But economics laws, if there is such a thing, are to differ: as far as business is concerned information is not to be found in commons but comes from the processing of raw data.
As a matter of fact, thermodynamic stability is meaningless in economics because business information is not a given and uniform quantity but a fluctuating and polymorph one. It ensues that for enterprises in competitive environments measures of entropy set in isolation are pointless: taking a leaf from Lewis Carroll’s Red Queen, the entropy of any given enterprise can only be assessed in relation with its competitors.
Taking a general perspective, entropy is meant to be observed either between the two ends of communication channels, or at the boundaries of complex systems (animals, machines, or organizations). While the former can be seen as a formal coding issue, the latter is of particular relevance for enterprises immersed in digital environments.
Departing from thermodynamics view of entropy measuring a system’s thermal energy unavailable for conversion into mechanical work, economics will consider unexplained information, i.e which cannot be acted upon.
But leaving physics also means forsaking the comfort of its metrics. That’s not a problem for communication entropy, which can be dealt with as a coding issue; but the difficulty appears when counts of digits have to be replaced by measures of knowledge.
complexity: microstates vs macrostates
When there are no clear and reliable metrics to put light on it, entropy becomes a black hole defined by disorder of randomness, the former in reference to the order borne out by classifications, the latter in reference to the predictability borne out by probabilities. Since both approaches deal with the relationship between configurations and information, the issue can be summarized with:
A quantum of hypothetical information (dashed line).
The complexity of identified items (aka microstates).
The complexity of representations (aka macrostates).
The quantum of information accounted for, ordered or predicted.
As stated by the basic law of thermodynamics, to be of any energetic use the internal heat of a system has to be lower than the external one. Generalized in terms of complexity, it means that the quantum of information accounted for will first increase with the number of configurations considered, reach a maximum, and then decrease until the complexity of configurations (aka internal heat) equates the complexity of the target (aka external heat).
Translated to economics, that scheme must be restated in terms of digital environments and business information.
Representation: whether the exchanges are carried out at digital level (data observations of microstates) or in association with symbolic representations (models of macrostates) of managed information.
Coupling: whether the processing of data is tied to operations or carried out independently.
The issue of entropy can be restated accordingly:
The direct consequence of the digital transformation is to increase osmosis between enterprises and their environment, with data flows bypassing traditional boundaries and feeding directly operational processes (bottom right).
As a result, data analytics can be integrated with business processes, improving operational decision-making. In terms of entropy the outcome would be a more effective use of information models (bottom left).
Next, information models (aka symbolic representations) can themselves be changed as to improve their effectiveness, i.e reduce entropy at process as well as architecture level (top left).
Last but not least, deep learning could be applied to digitalized contexts (aka microstates) in order to derive new symbolic representations (aka macrostates) (top right).
On that basis entropy policies should be set at operational and strategic levels, the former dealing with processes, the latter with architectures.
Homeostasis: from Data to knowledge
As far as enterprises are concerned, homeostasis means the adaptation of organizations and systems to changes in competitive environments. To that end, policies set along the entropy paradigm could draw on improving the perception of microstates (data level) as well as the representation of macrostates (information level).
At data level, the perception of changes depends on the osmosis between systems and environments. To that end data mining is to be used to hone the sampling of populations and refine microstates.
At symbolic level (representations), the economics perspective differs from physics on two critical aspects:
Contrary to heat, economic information is not a constant, which means that macrostates are to be continuously updated.
Moreover, the economic playground is not homogenous but combines physical (e.g demographics or climate), socio-economic (e.g income or education) and symbolic (e.g politics or culture) microstates, which means that macrostates are to be differentiated.
With or without differentiated macrostates, policies are to rely on two categories of models:
Extensional ones target environments, dealing with the analysis of business context, operations, and changes (descriptive models), as well as what should be expected (predictive models).
Intensional ones deal with enterprise architectures, current or planned, at processes as well as architecture level (prescriptive models).
As figured above, representations and policies are to be combined, hence the need to anchor them to enterprise architectures, as can be illustrated with the Pagoda blueprint:
Populations of instances (microstates) are obtained from digital environments as well as from processes execution (1). Data analytics are used to improve descriptive and predictive models (operational macrostates), and consequently the osmosis between processes and environment (2).
Architecture improvements can be achieved through changes in prescriptive models (structural macrostates). Compared to strategic planning carried out top-down from business models and requirements, homeostasis also relies on bottom-up forces which can combine with business models and coalesce into emerging architectures (3).
Business and organization models are arguably a primary factor in sorting out data, respectively from environments and systems; and being by nature essentially symbolic, they are more pliable than systems models (0). Homeostasis could therefore bypass architectural macrostates, with models of business and organization emerging directly from digital environments through data mining and deep learning (4).
Such alignment of enterprise architectures and symbolic representations is to greatly enhance the transparency and traceability of digital transformations by organising changes and policies with regard to their nature (physical, functional, organizational, or business) and decision-making horizon (operational or strategic).
As a capability of live organisms, languages are best understood in terms of communication.
That understanding is of particular interest for enterprises immersed in digital environments inhabited by hybrids with deep learning capabilities.
Languages begin with the need of direct (here) and immediate (now) communication. While there is no time for explanations, messages must convey some meaning, if only to distinguish friends from foes. Hence the use of signs pointing to categories of objects or phenomena. That’s the language lexical layer linking instantly observations (data) to information (bottom right).
Rules governing the combination of signs follow soon because more has to be communicated about circumstances and what is to be done with. That’s the language syntactic layer linking observations (data) to current information (top right).
The breakthrough comes with symbolic representation: once disentangled from immediate circumstances, communications can encompass whatever is deemed relevant in contexts and concerns; That’s the language semantic layer that weave together information and knowledge (top left).
The cognitive ability to “manipulate” symbolic representations (aka models) independently of circumstances opens the door to any kind of constructions. That’s the language pragmatic layer meant to put knowledge to actual use (bottom left).
That functional taxonomy can be usefully applied to the digital transformation of enterprise architectures, the first layer aligned with data, the second and third with information, and the fourth with knowledge.
Strategic planning can be summarily defined as the alignment of two kinds of horizons:
External horizons are set on markets, competition, and technologies, with views and anticipations coming through data analytics and game theory.
Internal horizons are set on enterprise architectures, with business models and policies on one hand, organization and systems on the other. Both are set on purposes, the former aiming at specificity and edge, the latter at sharing and stability.
As far as the strategic alignment of means (internal horizons) and ends (external horizons) are concerned, time is of the essence; that’s where is the fault line: whatever enterprise planned time-frames, they can only be mapped to fuzzy or unreliable ones outside. As a corollary, alignments have to be carried out either as a continuum, or through discrete and periodic adjustments to predictive models.
The future begins now
As suggested by Lewis Carroll’s Red Queen, the survival of enterprises in their evolutionary arms race doesn’t depend on their absolute speed set against some universal time-frame but on the relative one set by markets and competitors. Taking into account the role of a reliable and up-to-date basis for decision-making, strategic schemes can be characterized in terms of virtual and augmented reality:
Strategies set along predefined time-frames are by construct loosely tied to business environments since discrepancies are bound to develop during the intervals between anticipations (virtual reality) and realizations (actual reality). Hence the need of overall and planned adjustments.
By contrast, strategies set dynamically through OODA (observations, orientation, decision, action) loops can be carried out without overall anticipations; like augmented reality (AR) they mix fine-grained data observations and business intelligence with additional layers of information deemed to be relevant.
The first category has for long been a cornerstone of established strategic planning, with its implicit assumption of a conceptual gap between ‘Here and Now’ and future visions. But the induced latencies and discrepancies may become liabilities if enterprises have to continuously adjust representations and policies.
For mammals such awareness is a biological capability: any discrepancy between perceived movements and their counterpart in the vestibular system is to generate motion sickness or vertigo.
Enterprises have no such built-in mechanism yet their awareness is nonetheless contingent on the alignment of representations with observations and orientations. As a corollary, out-of-kilter time-frames and outdated schemes may remain unnoticed, introducing governance dizziness and strategic missteps.
Such drawbacks can be limited with decision-making set along differentiated time-frames, e.g:
Operational decisions, to be carried out within processes time-frame (a).
Architecture decisions, for changes in assets affecting the design of business processes and supporting platforms (b).
Organizational decisions, for changes affecting roles and processes (c).
That would allow the weaving of fine-grained policies across enterprise architectures and along consistent time-frames, mixing actual observations, representations of current and planned assets and resources, and anticipations of markets changes a competitors moves.
On that basis strategic alignments would not have to be set at fixed time for overall models, but could be managed continuously, with decision-making finely tuned for targets and timing:
External horizons: business decisions could be balanced by the need to know with the reliability of available information.
Internal horizons: decisions about organization and systems could be taken at the “last responsible moment”, i.e until not taking side could change the possible options.
Strategic planning could then be defined by crossing these rationales at the relevant granularity.
Enterprise governance has to face combined changes in the way business times and spaces are to be taken into account. On one hand social networks put well-thought-out market segments and well planned campaigns at the mercy of consumers’ weekly whims. On the other hand traditional fences between environments and IT systems are crumbling under combined markets and technological waves.
To overcome these challenges enterprises strategies should focus on four pillars:
Data and Information: massive and continuous inflows of data calls for a seamless integration of data analytics (perception), information models (reasoning), and knowledge (decision-making).
Security & Confidentiality: new regulatory environments and costs of privacy breaches call for a clear distinction between data tied to identified individuals and information associated to designed categories.
Innovation: digital environments induces a new order of magnitude for the pace of technological change. Making opportunities from changes can only be achieved through collaboration mechanisms harnessing enterprise knowledge management to environments intakes.
Despite (or because) their ubiquity across powerpoint presentations, business capabilities appear under a wide range of guises. Putting them in perspectives could clarify the issue.
To begin with, business capabilities should not be confused with systems ones as they are supposed to be driven by changing environments and opportunities, in contrast to continuity, integrity, and returns on investments. Were it not for the need to juggle with both there would be no need of chief “whatever” officers.
Then, if they are to be assessed across changing contexts and concerns, business capabilities should not be tied to specific ones but focus on enterprise wherewithal :
Material: capacity and maturity of platforms with regard to changes in business processes and environments.
Functional: capacity and maturity of supporting systems with regard to changes in business processes.
Organizational: versatility and plasticity of roles and processes in dealing with changes in business opportunities.
Intelligence: information assets and ability of people to use them.
These could then be adjusted with regard to finance and time:
Strategic: assets, to be deployed and paid for across a number of business exercices.
Tactical: resources, to be deployed and paid for within single business exercices.
Particular: combined assets and resources needed to support specific value chains.
The role of enterprise architects would then to plan, assess, and manage the dynamic alignment of business and architecture capabilities.