Archive for the ‘Enterprise Architecture’ Category

Unified Architecture Framework Profile (UAFP): Lost in Translation ?

July 2, 2017

Synopsis

The intent of Unified Architecture Framework Profile (UAFP) is to “provide a Domain Meta-model usable by non UML/SysML tool vendors who may wish to implement the UAF within their own tool and metalanguage.”

Detached Architecture (Víctor Enrich)

But a meta-model trying to federate (instead of bypassing) the languages of tools providers has to climb up the abstraction scale above any domain of concerns, in that case systems architectures. Without direct consideration of the domain, the missing semantic contents has to be reintroduced through stereotypes.

Problems with that scheme appear at two critical junctures:

  • Between languages and meta-models, and the way semantics are introduced.
  • Between environments and systems, and the way abstractions are defined.

Caminao’s modeling paradigm is used to illustrate the alternative strategy, namely the direct stereotyping of systems architectures semantics.

Languages vs Stereotypes

Meta-Models are models of models: just like artifacts of the latter represent sets of instances from targeted domains, artifacts of the former represent sets of symbolic artifacts from the latter. So while set higher on the abstraction scale, meta-models still reflect the domain of concerns.

Meta-models takes a higher view of domains, meta-languages don’t.

Things are more complex for languages because linguistic constructs ( syntax and semantics) and pragmatic are meant to be defined independently of domain of discourse. Taking a simple example from the model above, it contains two kinds of relationships:

  • Linguistic constructs:  represents, between actual items and their symbolic counterparts; and inherits, between symbolic descriptions.
  • Domain specific: played by, operates, and supervises.

While meta-models can take into account both categories, that’s not the case for languages which only consider linguistic constructs and mechanisms. Stereotypes often appear as a painless way to span the semantic fault between what meta-models have to do and what languages use to do; but that is misguided because mixing domain specific semantics with language constructs can only breed confusion.

Stereotypes & Semantics

If profiles and stereotypes are meant to refine semantics along domains specifics, trying to conciliate UML/SysML languages and non UML/SysML models puts UAFP in a lopsided position by looking the other way, i.e towards one-fits-all meta-language instead of systems architecture semantics. Its way out of this conundrum is to combine stereotypes with UML constraint, as can be illustrated with PropertySet:

UAFP for PropertySet (italics are for abstract)

Behind the mixing of meta-modeling levels (class, classifier, meta-class, stereotype, meta-constraint) and the jumble of joint modeling concerns (property, measurement, condition), the PropertySet description suggests the overlapping of two different kinds of semantics, one looking at objects and behaviors identified in environments (e.g asset, capability, resource); the other focused on systems components (property, condition, measurement). But using stereotypes indifferently for both kind of semantics has consequences.

Stereotypes, while being the basic UML extension mechanism, comes without much formalism and can be applied extensively. As a corollary, their semantics must be clearly defined in line with the context of their use, in particular for meta-languages topping different contexts.

PropertySet for example is defined as an abstract element equivalent to a data type, simple or structured, a straightforward semantic that can be applied consistently for contexts, domains or languages.

That’s not the case for ActualPropertySet which is defined as an InstanceSpecification for a “set or collection of actual properties”. But properties defined for domains (as opposed to languages) have no instances of their own and can only occur as concrete states of objects, behaviors, or expectations, or as abstract ranges in conditions or constraints. And semantics ambiguities are compounded when inheritance is indifferently applied between a motley of stereotypes.

Properties epitomize the problems brought about by confusing language and domain stereotypes and point to a solution.

To begin with syntax, stereotypes are redundant because properties can be described with well-known language constructs.

As for semantics, stereotyped properties should meet clearly defined purposes; as far as systems architectures are concerned, that would be the mapping to architecture capabilities:

Property must be stereotyped with regard to induced architecture capabilities.

  • Properties that can be directly and immediately processed, symbolic (literal) or not (binary objects).
  • Properties whose processing depends on external resource, symbolic (reference) or not (numeric values).

Such stereotypes could be safely used at language level due to the homogeneity of property semantics. That’s not the case for objects and behaviors.

Languages Abstractions & Symbolic Representations

The confusion between language and domain semantics mirrors the one between enterprise and systems, as can be illustrated by UAFP’s understanding of abstraction.

In the context of programming languages, isAbstract applies to descriptions that are not meant to be instantiated: for UAFP “PhysicalResource” isAbstract because it cannot occur except as “NaturalResource” or “ResourceArtifact”, none of them isAbstract.

“isAbstract” has no bearing on horses and carts, only on the meaning of the class PhysicalResource.

Despite the appearances, it must be reminded that such semantics have nothing to do with the nature of resources, only with what can be said about it. In any case the distinction is irrelevant as long as the only semantics considered are confined to specification languages, which is the purpose of the UAFP.

As that’s not true for enterprise architects, confusion is to arise when the modeling Paradigm is extended as to include environments and their association with systems. Then, not only that two kinds of instances (and therefore abstractions) are to be described, but that the relationship between external and internal instances is to determine systems architectures capabilities. Extending the simple example above:

  • Overlooking the distinction between active and passive physical resources prevents a clear and reliable mapping to architecture technical capabilities.
  • Organizational resource lumps together collective (organization), individual and physical (person), individual and organizational (role), symbolic (responsibility), resources. But these distinctions have a direct consequences for architecture functional capabilities.

Abstraction & Symbolic representation

Hence the importance of the distinction between domain and language semantics, the former for the capabilities of the systems under consideration, the latter for the capabilities of the specification languages.

Systems Never Walk Alone

Profiles are supposed to be handy, reliable, and effective guides for the management of specific domains, in that case the modeling of enterprise architectures. As it happens, the UAF profile seems to set out the other way, forsaking architects’ concerns for tools providers’ ones; that can be seen as a lose-lose venture because:

  • There isn’t much for enterprise architects along that path.
  • Tools interoperability would be better served by a parser focused on languages semantics independently of domain specifics.

Hopefully, new thinking about architecture frameworks (e.g DoDAF) tends to restyle them as EA profiles, which may help to reinstate basic requirements:

  • Explicit modeling of environment, enterprise, and systems.
  • Clear distinction between domain (enterprise and systems architecture) and languages.
  • Unambiguous stereotypes with clear purposes

A simple profile for enterprise architecture

On a broader perspective such a profile would help with the alignment of purposes (enterprise architects vs tools providers), scope (enterprise vs systems), and languages (modeling vs programming).

Further Reading

Models
Architectures
Enterprise Architecture
UML#

External Links

Advertisements

EA’s Merry-go-round

June 14, 2017

Preamble

All too often EA is planned as a big bang project to be carried out step by step until completion. That understanding is misguided as it confuses EA with IT systems and implies that enterprises could change their architectures as if they were apparel.

EA is a never-ending endeavor (Robert Doisneau)

But enterprise architecture is part and parcel of enterprises, a combination of culture, organization, and systems; whatever the changes, they must keep the continuity, integrity, and consistency of the whole.

Capabilities

Compared to usual projects, architectural ones are not meant to address specific business needs but architecture capabilities that may or may not be specific to business functions. Taking a leaf from the Zachman Framework, those capabilities can be organized around five pillars supporting enterprise, systems, and platform architectures:

  • Who: enterprise roles, system users, platform entry points.
  • What: business objects, symbolic representations, objects implementation.
  • How: business logic, system applications, software components.
  • When: processes synchronization, communication architecture, communication mechanisms.
  • Where: business sites, systems locations, platform resources.

These capabilities are set across architecture layers and support business, engineering, and operational processes.

Enterprise architecture capabilities

Enterprise architects are to continuously assess and improve these capabilities with regard to current weaknesses (organizational bottlenecks, technical debt) or future developments (new business, M&A, new technologies).

Work Units

Given the increased dependencies between business, engineering, and operations, defining EA workflows in terms of work units defined bottom-up from capabilities is to provide clear benefits with regard to EA versatility and plasticity.

Contrary to top-down (aka activity based) ones, bottom-up schemes don’t rely on one-fits-all procedures; as a consequence work units can be directly defined by capabilities and therefore mapped to engineering workshops:

Iterative development of architecture capabilities across workshops

Moreover, dependency constraints can be directly defined as declarative assertions attached to capabilities and managed dynamically instead of having to be hard-wired into phased processes.

That approach is to ensure two agile conditions critical for the development of architectural features:

  • Shared ownership: lest the whole enterprise be paralyzed by decision-making procedures, work units must be carried out under the sole responsibility of project teams.
  • Continuous delivery: architecture driven developments are by nature transverse but the delivery of building blocs cannot be put off by the decision of all parties concerned; instead it should be decoupled from integration.

Enterprise architecture projects could then be organized as a merry-go-round of capabilities-based work units to be set up, developed, and delivered according to needs and time-frames.

Time Frames

Enterprise architecture is about governance more than engineering. As such it has to ensure continuity and consistency between business objectives and strategies on one side, engineering resources and projects on the other side.

Assuming that capability-based work units will do the job for internal dependencies (application contents and engineering), the problem is to deal with external ones (business objectives and enterprise organization) without introducing phased processes. Beyond differences in monikers, such dependencies can generally be classified along three reasoned categories:

  • Operational: whatever can be observed and acted upon within a given envelope of assets and capabilities.
  • Tactical: whatever can be observed and acted upon by adjusting assets, resources and organization without altering the business plans and anticipations.
  • Strategic: decisions regarding assets, resources and organization contingent on anticipations regarding business environments.

The role of enterprise architects will then to manage the deployment of updated architecture capabilities according to their respective time-frames.

Portfolio Management

As noted before, EA workflows by nature can seldom be carried out in isolation as they are meant to deal with functional features across business domains. Instead, a portfolio of architecture (as opposed to development) work units should be managed according to their time-frame, the nature of their objective, and the kind of models to be used:

EA portfolio

  • Strategic features affect the concepts defining business objectives and processes. The corresponding business objects and processes are primarily defined with descriptive models; changes will have cascading effects for engineering and operations.
  • Tactical features affect the definition of artifacts, logical or physical. The corresponding engineering processes are primarily defined with prescriptive models; changes are to affect operational features but not the strategic ones.
  • Operational features affect the deployment of resources, logical or physical. The corresponding processes are primarily defined with predictive models derived from descriptive ones; changes are not meant to affect strategic or tactical features.

Architectural projects could then be managed as a dynamic backlog of self-contained work units continuously added (a) or delivered (b).

EA projects: a merry-go-round of work units.

That would bring together agile development processes and enterprise architecture.

Further Reading

Squaring EA Governance

April 18, 2017

Preamble

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.

Squaring Governance in Space and Time (Jasenka Tucan-Vaillant)

So, despite (or because of) the exponential ability of intelligent systems to learn from circumstances, enterprise governance is not to cope with such dynamic complexities without a reliable compass set with regard to key primary factors: time-frames of concerns; control of processes; administration of artifacts.

Concerns & Time-frames

Confronted to massive and continuous waves of stochastic data flows, the priority is to position external events and decision-making with regard to business and assets time-frames:

  • Business value is to be driven by market opportunities which cannot be coerced into predefined fixed time-frames.
  • Assets management is governed by continuity and consistency constraints on enterprise identity, objectives, and investments along time.

Governance Square and its four corners

Enterprises, once understood as standalone entities, must now be redefined as living organisms in continuous adaptation with their environment. Governance schemes must therefore be broadened to business environments and layered as to take into account the duality of time-frames: operational for business value, strategic for assets.

Control of processes and administration of artifacts can then be defined accordingly.

Time & Control: Processes

Architectures being by nature shared and persistent, their layers are meant to reflect different time-frames, from operational cycles to long-term assets:

  • At enterprise level the role of architectures is to integrate shared assets and align various objectives set along different time-frames. At this level it’s safe to assume some cross dependencies between processes, which would call for phased governance.
  • By contrast, business units are meant to be defined as self-governing entities pursuing specific objectives within their own time-frame. From a competitive perspective markets opportunities and competitors moves are best assumed unpredictable, and processes best governed by circumstances.

Enterprise Processes have to align business and engineering objectives

Processes can then be defined vertically (business or Systems) as well as horizontally (enterprise architecture or application development), and governance set accordingly:

  • At enterprise level processes are phased: stakeholders and architects plan and manage the development and deployment of assets (organization and systems).
  • At business units level processes are lean and just-in-time: business analysts and software engineers design and develop applications supporting users needs as defined by users stories or use cases.

Models are then to be introduced to describe shared assets (organization and systems) across the enterprise. They may also support business analysis and software engineering.

Spaces & Administration: Models and Artifacts

Whatever the targets and terminologies, architecture is best defined as a relationship between concrete territories (processes and systems) and abstract maps (blueprints or models).

Carrying on with the four corners of governance square:

  • Business analysts are to set users’ narratives (concrete) in line with the business plots (blueprints) set by stakeholders.
  • Software engineers designing applications (concrete) in line with systems functional architectures (blueprints).

Enterprise Architecture uses maps to manage territories

As for the overlapping of business and development time-frames, the direct mapping between concrete business and system corners (e.g though agile development) is to facilitate the governance of integrated actual and numeric flows across business and systems.

Conclusion: A Compass for Enterprise Architects

Behind turfs perimeters and jobs descriptions, roles and responsibilities involved in enterprise architecture can be summarized by four drives:

  • Business stakeholders (top left): adjust organization as to maximize the versatility and plasticity of architectures.
  • Business analysts (bottom left): define business processes with regard to broader objectives and engineering efficiency.
  • Software engineers (bottom right): maximize the value for users and the quality of applications.
  • Systems architects (top right): dynamically align systems with regard to business models and engineering processes.

Orientation should come before job descriptions

Whereas roles and responsibilities will generally differ depending on enterprise environment, business, and culture, such a compass would ensure that the governance of enterprise architectures hinges on reliable pillars and is driven by clear principles.

Further Reading

Focus: Business Cases for Use Cases

February 27, 2017

Preamble

As originally defined by Ivar Jacobson, uses cases (UCs) are focused on the interactions between users and systems. The question is how to associate UC requirements, by nature local, concrete, and changing, with broader business objectives set along different time-frames.

Sigmar-Polke-Hope-Clouds

Cases, Kites, and Clouds (Sigmar Polke)

Backing Use Cases

On the system side UCs can be neatly traced through the other UML diagrams for classes, activities, sequence, and states. The task is more challenging on the business side due to the diversity of concerns to be defined with other languages like Business Process Modeling Notation (BPMN).

Use cases at the hub of UML diagrams

Use Cases contexts

Broadly speaking, tracing use cases to their business environments have been undertaken with two approaches:

  • Differentiated use cases, as epitomized by Alister Cockburn’s seminal book (Readings).
  • Business use cases, to be introduced beside standard (often renamed as “system”) use cases.

As it appears, whereas Cockburn stays with UCs as defined by Jacobson but refines them to deal specifically with generalization, scaling, and extension, the second approach introduces a somewhat ill-defined concept without setting apart the different concerns.

Differentiated Use Cases

Being neatly defined by purposes (aka goals), Cockburn’s levels provide a good starting point:

  • Users: sea level (blue).
  • Summary: sky, cloud and kite (white).
  • Functions: underwater, fish and clam (indigo).

As such they can be associated with specific concerns:

Cockburn’s differentiated use cases

  • Blue level UCs are concrete; that’s where interactions are identified with regard to actual agents, place, and time.
  • White level UCs are abstract and cannot be instanciated; cloud ones are shared across business processes, kite ones are specific.
  • Indigo level UCs are concrete but not necessarily the primary source of instanciation; fish ones may or may not be associated with business functions supported by systems (grey), e.g services , clam ones are supposed to be directly implemented by system operations.

As illustrated by the example below, use cases set at enterprise or business unit level can also be concrete:

Example with actors for users and legacy systems (bold arrows for primary interactions)

UC abstraction connectors can then be used to define higher business objectives.

Business “Use” Cases

Compared to Cockburn’s efficient (no new concept) and clear (qualitative distinctions) scheme, the business use case alternative adds to the complexity with a fuzzy new concept based on quantitative distinctions like abstraction levels (lower for use cases, higher for business use cases) or granularity (respectively fine- and coarse-grained).

At first sight, using scales instead of concepts may allow a seamless modeling with the same notations and tools; but arguing for unified modeling goes against the introduction of a new concept. More critically, that seamless approach seems to overlook the semantic gap between business and system modeling languages. Instead of three-lane blacktops set along differentiated use cases, the alignment of business and system concerns is meant to be achieved through a medley of stereotypes, templates, and profiles supporting the transformation of BPMN models into UML ones.

But as far as business use cases are concerned, transformation schemes would come with serious drawbacks because the objective would not be to generate use cases from their business parent but to dynamically maintain and align business and users concerns. That brings back the question of the purpose of business use cases:

  • Are BUCs targeting business logic ? that would be redundant because mapping business rules with applications can already be achieved through UML or BPMN diagrams.
  • Are BUCs targeting business objectives ? but without a conceptual definition of “high levels” BUCs are to remain nondescript practices. As for the “lower levels” of business objectives, users’ stories already offer a better defined and accepted solution.

If that makes the concept of BUC irrelevant as well as confusing, the underlying issue of anchoring UCs to broader business objectives still remains.

Conclusion: Business Case for Use Cases

With the purposes clearly identified, the debate about BUC appears as a diversion: the key issue is to set apart stable long-term business objectives from short-term opportunistic users’ stories or use cases. So, instead of blurring the semantics of interactions by adding a business qualifier to the concept of use case, “business cases” would be better documented with the standard UC constructs for abstraction. Taking Cockburn’s example:

Abstract use cases: no actor (19), no trigger (20), no execution (21)

Different levels of abstraction can be combined, e.g:

  • Business rules at enterprise level: “Handle Claim” (19) is focused on claims independently of actual use cases.
  • Interactions at process level: “Handle Claim” (21) is focused on interactions with Customer independently of claims’ details.

Broader enterprise and business considerations can then be documented depending on scope.

Further Reading

External Links

Focus: Analysis vs Design

January 4, 2017

Preamble

Definitions should never turn into wages of words as they should only be judged on their purpose and utility, with  such assessment best achieved by comparing and adjusting the meaning of neighboring concepts with regard to tasks at hand.

GChirico_prodigal-son

Analysis & Design as Duet (Giorgio de Chirico)

That approach can be applied to the terms “analysis” and “design” as used in systems engineering.

What: Logic & Engineering

Whatever the idiosyncrasies and fuzziness of business concerns and contexts, at the end of the day business and functional requirements of supporting systems will have to be coerced into the uncompromising logic of computers. Assuming that analysis and design are set along that path, they could be characterized accordingly.

As a matter of fact, a fact all too often ignored, a formal basis can be used to distinguish between analysis and design models, the former for the consolidation of requirements across business domains and enterprise organization, the latter for systems and software designs:

  • Business analysis models are descriptive (aka extensional); they try to put actual objects, events, and processes into categories.
  • System engineering models are prescriptive (aka intensional); they define what is expected of systems components and how to develop them.

Squaring Logic with Engineering

As a confirmation of its validity, that classification along the logic basis of models can be neatly crossed with engineering concerns:

  • Applications: engineering deals with the realization of business needs expressed as use cases or users’ stories. Engineering units are self-contained with specific life-spans, and may consequently be developed on a continuous basis.
  • Architectures: engineering deals with supporting assets at enterprise level. Engineering units are associated with shared functionalities without specific life-spans, with their development subject to some phasing constraints.

That taxonomy can be used to square the understanding of analysis, designs, and architectures.

Where: Business unit or Corporate

Reversing the perspective from content to context, the formal basis of analysis and design can also be crossed with their organizational framework:

  • Analysis is to be carried out locally within business units.
  • Designs are to be set both locally for applications, and at enterprise level for architectures.

Organizational dependencies will determine the roles, responsibilities, and time-frames associated with analysis and design.

Who: Analysts, Architects, Engineers

Contents and contexts are to determine the skills and responsibility for stakeholders, architects, analysts and engineers. On that account:

  • Analysis should be the shared responsibility of business and system analysts.
  • Designs would be solely under the authority of architects and engineers.

The possibility for agents to collaborate and share responsibility will determine the time-frames of analysis and design .

When: Continuous or Discrete

As far as project management is concerned, time is the crux of the matter: paraphrasing Einstein, the only reason for processes [time] is so that everything doesn’t happen at once. Hence the importance of characterizing analysis and design according to the nature of their time-scale:

  • At application level analysis and design can be carried out iteratively along a continuously time-scale.
  • At enterprise level the analysis of business objectives and the design of architectures will require milestones set along discrete time-scales.

The combination of organizational and timing constraints will determine analysis and design modus operandi.

How: Agile or Phased

Finally, the distinction between analysis and design will depend on the software engineering MO, as epitomized by the agile vs phased debate:

  • The agile development model combines analysis, design, and development into a single activity carried out iteratively. It is arguably the option of choice providing the two conditions about shared ownership and continuous delivery can be met.
  • Phased development models may rely on different arrangements but most will include a distinction between requirements analysis and software design.

That makes for an obvious conclusion: whether analysis and design are phased or carried out collaboratively, understanding their purpose and nature is a key success factor for systems and software engineering.

PS: Darwin vs Turing

As pointed out by Daniel Dennett (“From Bacteria to Bach, and Back“), the meaning of analysis and design can be neatly rooted in the theoretical foundations of evolution and computer science.

Darwin built his model of Natural Selection bottom up from the analysis of actual live beings. Roundly refuting the hypothesis of some “intelligent designer”, Darwin’s work epitomizes how ontologies built from observations (aka analysis models) can account for the origin, structure and behaviors of individuals.

Conversely, Turing’s thesis of computation is built top-down from established formal principles to software artifacts. In that case prior logical ontologies are applied to design models meant to realize intended capabilities.

Further Reading

Business Agility vs Systems Entropy

November 28, 2016

Synopsis

As already noted, the seamless integration of business processes and IT systems may bring new relevancy to the OOAD (Observation, Orientation, Decision, Action) loop, a real-time decision-making paradigm originally developed by Colonel John Boyd for USAF fighter jets.

Agility: Orientation (Lazlo Moholo-Nagy)

Agility & Orientation (Lazlo Moholo-Nagy)

Of particular interest for today’s business operational decision-making is the orientation step, i.e the actual positioning of actors and the associated cognitive representations; the point being to use AI deep learning capabilities to surmise opponents plans and misdirect their anticipations. That new dimension and its focus on information brings back cybernetics as a tool for enterprise governance.

In the Loop: OOAD & Information Processing

Whatever the topic (engineering, business, or architecture), the concept of agility cannot be understood without defining some supporting context. For OODA that would include: territories (markets) for observations (data); maps for orientation (analytics); business objectives for decisions; and supporting systems for action.

OODA loop and its actual (red) and symbolic (blue) contexts.

OODA loop and its actual (red) and symbolic (blue) contexts.

One step further, contexts may be readily matched with systems description:

  • Business contexts (territories) for observations.
  • Models of business objects (maps) for orientation.
  • Business logic (objectives) for decisions.
  • Business processes (supporting systems) for action.
ccc

The OODA loop and System Perspectives

That provides a unified description of the different aspects of business agility, from the OODA loop and operations to architectures and engineering.

Architectures & Business Agility

Once the contexts are identified, agility in the OODA loop will depend on architecture consistency, plasticity, and versatility.

Architecture consistency (left) is supposed to be achieved by systems engineering out of the OODA loop:

  • Technical architecture: alignment of actual systems and territories (red) so that actions and observations can be kept congruent.
  • Software architecture: alignment of symbolic maps and objectives (blue) so that orientation and decisions can be continuously adjusted.

Functional architecture (right) is to bridge the gap between technical and software architectures and provides for operational coupling.

Business Agility: systems architectures and business operations

Business Agility: systems architectures and business operations

Operational coupling depends on functional architecture and is carried on within the OODA loop. The challenge is to change tack on-the-fly with minimum frictions between actual and symbolic contexts, i.e:

  • Discrepancies between business objects (maps and orientation) and business contexts (territories and observation).
  • Departure between business logic (objectives and decisions) and business processes (systems and actions)

When positive, operational coupling associates business agility with its architecture counterpart, namely plasticity and versatility; when negative, it suffers from frictions, or what cybernetics calls entropy.

Systems & Entropy

Taking a leaf from thermodynamics, cybernetics defines entropy as a measure of the (supposedly negative) variation in the value of the information supporting the control of viable systems.

With regard to corporate governance and operational decision-making, entropy arises from faults between environments and symbolic surrogates, either for objects (misleading orientations from actual observations) or activities (unforeseen consequences of decisions when carried out as actions).

So long as architectures and operations were set along different time-frames (e.g strategic and tactical), cybernetics were of limited relevancy. But the seamless integration of data analytics, operational decision-making, and IT supporting systems puts a new light on the role of entropy, as illustrated by Boyd’s OODA and its orientation component.

Orientation & Agility

While much has been written about how data analytics and operational decision-making can be neatly and easily fitted in the OODA paradigm, a particular attention is to be paid to orientation.

As noted before, the concept of Orientation comes with a twofold meaning, actual and symbolic:

  • Actual: the positioning of an agent with regard to external (e.g spacial) coordinates, possibly qualified with the agent’s abilities to observe, move, or act.
  • Symbolic: the positioning of an agent with regard to his own internal (e.g beliefs or aims) references, possibly mixed with the known or presumed orientation of other agents, opponents or associates.

That dual understanding underlines the importance of symbolic representations in getting competitive edges, either directly through accurate and up-to-date orientation, or indirectly by inducing opponents’ disorientation.

Agility vs Entropy

Competition in networked digital markets is carried out at enterprise gates, which puts the OODA loop at the nexus of information flows. As a corollary, what is at stake is not limited to immediate business gains but extends to corporate knowledge and enterprise governance; translated into cybernetics parlance, a competitive edge would depend on enterprise ability to export entropy, that is to decrease confusion and disorder inside, and increase it outside.

Working on that assumption, one should first characterize the flows of information to be considered:

  • Territories and observations: identification of business objects and events, collection and analysis of associated data.
  • Maps and orientations: structured and consistent description of business domains.
  • Objectives and decisions: structured and consistent description of business activities and rules.
  • Systems and actions: business processes and capabilities of supporting systems.
cccc

Static assessment of technical and software architectures for respectively observation and decision

Then, a static assessment of information flows would start with the standing of technical and software architecture with regard to competition:

  • Technical architecture: how the alignment of operations and resources facilitate actions and observations.
  • Software architecture: how the combined descriptions of business objects and logic facilitate orientation and decision.

A dynamic assessment would be carried out within the OODA loop and deal with the role of functional architecture in support of operational coupling:

  • How the mapping of territories’ identities and features help observation and orientation.
  • How decision-making and the realization of business objectives are supported by processes’ designs.
ccccc

Dynamic assessment of decision-making and the realization of business objectives’ as supported by processes’ designs.

Assuming a corporate cousin of  Maxwell’s demon with deep learning capabilities standing at the gates in its OODA loop, his job would be to analyze the flows and discover ways to decrease internal complexity (i.e enterprise representations) and increase external one (i.e competitors’ representations).

Further Readings

Business Agility & the OODA Loop

November 21, 2016

Preamble

The OOAD (Observation, Orientation, Decision, Action) loop is a real-time decision-making paradigm developed in the sixties by Colonel John Boyd from his experience as fighter pilot and military strategist.

(Moholy Nagy)

How to get inside opponent’s loop (Lazlo Moholy-Nagy)

The relevancy of OODA for today’s operational decision-making comes from the seamless integration of IT systems with business operations and the resulting merits of agile development processes.

Business: End of Discrete Time-Frames

Business governance was used to be phased: analyze the market, select opportunities, build capabilities, launch operations. No more. With the melting of the fences between actual and symbolic realms, periodic transitional events have lost most of their relevancy. Deprived of discrete and robust time-frames, the weaving of observed facts with business plans has to be managed on the fly. Success now comes from continuous readiness, quicker tempo, and the ability to operate inside adversaries’ time-scales, for defense (force competitor out of favorable position) as well as offense (get a competitive edge). Hence the reference to dogfights.

Dogfights & Agile Primacy

John Boyd train of thoughts started with the observation that, despite the apparent superiority of the soviet Mig 15 on US F-86 during the Korea war, US fighters stood their ground. From that factual observation it took Boyd’s comprehensive engineering work to demonstrate that as far as dogfights were concerned fast transients between maneuvers (aka agility) was more important than technical capabilities. Pushed up Pentagon’s reluctant ladders by Boyd’s sturdy determination, that conclusion have had wide-ranging consequences in the design of USAF fighters and pilots formation for the following generations. Its influence also spread to management, even if theories’ turnover is much faster there, and shelf-life much shorter.

Nowadays, with the accelerated integration of business processes with IT systems, agility is making a comeback from the software engineering corner. Reflecting business and IT convergence, principles like iterative development, just-in-time delivery, and lean processes, all epitomized by the agile software development model, are progressively mingling into business practices with strong resemblances to dogfights; and the resemblances are not only symbolic.

IT Systems & Business Competition

While some similarities between dogfights and business competition may seem metaphorical, one critical aspect is all too real, namely the increasing importance of supporting machines, IT systems or fighter jets.

Basically, IT systems, like fighters’ electronics, are tasked to observe environments, analyse changes in relation to position and objectives, and support decision-making. But today’s systems go further with two qualitative leaps:

  • The seamless integration of physical and symbolic flows let systems manage some overlapping between supporting decisions and carrying out actions.
  • Due to their artificial intelligence capabilities, systems can learn on-the-job and improve their performances in real-time feedback loops.

When combined, these two trends have drastic impact on the way machines can support human activities in real-time competitive situations. More to the point, they bring new light on business agility.

Business Agility

As illustrated by the radical transformation of fighter cockpits, the merging of analog and digital flows leaves little room for human mediation: data must be processed into information and presented instantly along two critical dimensions, one for decision-making, the other for information life-cycle:

  • Man/Machine interfaces have to materialize the merging of actual and symbolic realms as to support just-in-time decision-making.
  • The replacement of phased selected updates of environment data by continuous changes in raw and massive data means that the status of information has to be incorporated with the information itself, yet without impairing decision-making.

Beyond obvious differences between dogfights and business competition, that double exigence is to characterize business agility:

  1. Instant understanding of changes in business opportunities (Observation) .
  2. Simultaneous assessment of the reliability and shelf-life of pertaining information with regard to current positions and operations (Orientation).
  3. Weighting of options with regard to enterprise capabilities and broader objectives (Decision).
  4. Carrying out of decisions within the relevant time-span (Action).

That understanding of business agility is to be compared with its development and architecture cousins. Yet it doesn’t seem to add much to data analytics and operational decision-making. That is until the concept of orientation is reassessed.

Agility & Orientation: Task vs Tack

To begin with basics, the concept of Orientation comes with a twofold meaning, actual and symbolic:

  • Actual: a position with regard to external (e.g spacial) coordinates, possibly qualified with abilities to observe, move, or act.
  • Symbolic: a position with regard to internal (e.g beliefs or aims) references, possibly mixed with known or presumed orientation of other agents, opponents or associates.

When business is considered, data analytics is supposed to deal comprehensively and accurately with markets’ actual orientations. But the symbolic facet is left largely unexplored.

Boyd’s contribution is to bring together both aspects and combine them into actual practice, namely how to foretell the tack of your opponents from their actual tracks as well as their surmised plans, while fooling them about your own moves, actual or planned.

Such ambitions once out of reach, can now be fulfilled due to the combination of big data, artificial intelligence, and the exponential growth on computing power.

Further Readings

 

Focus: MDA & UML

November 9, 2016

Preamble

UML (Unified Modeling Language) and MDA (Model Driven Architecture) epitomize the lack of focus and consistency of the OMG’s strategy. As it’s safe to assume that there can be no architectures without models, MDA and UML arguably bring sensible (if not perfect) schemes without significant competition.

MarcelBroodthaers-2Pipes

Unified language for Business and System Modeling (Marcel Broodthaers)

 

Unfortunately, not much has been made to play on their obvious complementarity and to exploit their synergies.

MDA & the Nature of Models

Model driven architecture (MDA) can be seen as the main (only ?) documented example of model based systems engineering. Its taxonomy organizes models within three layers:

  • 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.

Engineering can then be managed along architecture layers (a), or carried out as a whole for each application (b).

mapsterrits_landingschar

Managing changes at architecture (a) or application (b) level.

It’s important to note that the MDA framework is completely neutral with regard to methods: engineering processes can be organized as phased activities (procedural), iterations (agile), or artifacts transformation (declarative).

Logic & The Matter of Models

Whatever the idiosyncrasies and fuzziness of business concerns and contexts, at the end of the day requirements will have to be coerced into the strict logic of computer systems. That may be a challenging task to be carried out directly, but less so if upheld by models.

As it happens, a fact all too often ignored, models come with sound logical foundations that can be used to formalize the mapping of requirements into specifications; schematically, models are to be set in two formal categories:

  • Descriptive (aka extensional) ones try to classify actual objects, events, and processes into categories.
  • Prescriptive (aka intensional) ones specify what is expected of systems components and how to develop them.
The logical basis of models

The logical basis of models

Interestingly, that distinction provides a formal justification to the one between analysis and design models, the former for the consolidation of requirements across business domains and enterprise organization, the latter for systems and software designs. Such logical foundations could help to manage the mapping of business processes and systems architectures.

UML & the Anatomy of Models

Except scientific computation, there is no reason to assume a-priori congruence between the description of business objects and processes and the specification of the software components. As a corollary, their respective structures and features are better to be dealt with separately.

But that’s not the case at architecture level, where domains and identities have to be managed continuously and consistency on the two sides of the business/system divide. At this level (aka enterprise architecture), responsibilities and identification and communication mechanisms must be defined uniformly.

Compared to MDA set at architecture level, UML describes the corresponding artifacts for business, systems, and platform layers. Regardless of the confusing terminology (layers or levels), that puts MDA and UML along orthogonal dimensions: the former (layers) deals with the nature of contents, the latter (levels) with their structures and features.

MDA is only concerned with architectures, UML describe the structure of architecture components.

MDA is only concerned with architectures, UML describe the structure of architecture components.

Using the same unified modeling language across business, systems, and platform layers is to clearly and directly enhance transparency and traceability; but the full extent of MDA/UML cross-benefits is to appear when models logic is taken into account.

Models & Systems Evolution

As illustrated by the increasing number of systemic crashes, systems obsolescence is no longer a matter of long-term planning but of operational continuity: change has become the rule and as far as complex and perennial systems are concerned, architectures are to evolve while supporting their functional duties seamlessly. If that is to be achieved, modularity and a degree of consistency are necessary between the nature of changes and their engineering. That’s where MDA is to help.

As pointed to above, modularity is best achieved with regard to level (architecture, element) and models contents (business, systems, platforms).

At architecture level, changes in domains, identification, and categories must be aligned between descriptive (enterprise) and prescriptive (systems) models. That will be best achieved with UML models across all MDA layers.

Using UML and MDA helps to align descriptive and prescriptive models at architecture level.

Using UML and MDA helps to align descriptive and prescriptive models at architecture level.

The constraints of continuity and consistency can be somewhat eased at element level: if descriptive (business) and prescriptive (systems) models of structures and features are to be consistent, they are not necessarily congruent. On component (prescriptive/design) side, UML and object-oriented design (OOD) are to keep them encapsulated. As for the business (descriptive/analysis) side, since structures and features can be modeled separately (and OOD not necessarily the best option), any language (UML, BPMN, DSL,etc.) can be used. In between, the structure (aka signature) of messages passed at architecture level is to be specified depending on communication framework.

Considering the new challenges brought about by the comprehensive interoperability of heterogeneous systems, the OMG should reassess the full range of latent possibilities to be found in its engineering portfolio.

Further Reading

Business Problems shouldn’t sleep with IT Solutions

October 8, 2016

Preamble

The often mentioned distinction between problem and solution levels may make sense from an analyst’s particular point of view, whether business or system.  But blending problems and solutions independently of their nature becomes a serious over simplification for enterprise architects considering that one of their prime responsibility is to keep apart business problems from IT solutions.

(Mircea Cantor)

Functional problem with technical solution (Mircea Cantor)

That issue is relevant from engineering as well as business perspective.

Engineering View: Problem Levels & Architecture Layers

As long as computers are used to solve problems the only concern is to find the best solution, and the only architecture of concern is software’s.

But enterprise architects have to deal with systems, not computers, namely how to best serve business objectives with corporate resources, across business units and along business cycles. For that purpose resources (financial, human, technical) and their use are to be layered according to the nature of problems and solutions: business processes (enterprise), supporting functionalities (systems), and technologies (platforms).

From an engineering perspective, the intended congruence between problems levels and architecture layers can be illustrated with the OMG’s model driven architecture (MDA) framework:

  • Computation independent models (CIMs) deal with business processes solutions, to be translated into functional problems for supporting systems.
  • Platform independent models (PIMs) deal with functional solutions, to be translated into technical problems for supporting platforms.
  • Platform specific models (PSMs) deal with technical solutions, to be implemented as code.
MDA layers correspond to a clear hierarchy of problems and solutions

MDA layers can be mapped to a clear hierarchy of problems and solutions

Along that understanding, architectures can be seen as solutions, and the primary responsibility of enterprise architects is to see that problems/solutions brace remain in their respective swim-lanes.

Business View: Business Value & Enterprise Assets

Whereas the engineering perspective may appear technical or specific to a model based approach, the same issue is all the more significant when expressed with regard to business concerns and corporate governance. In that case the critical distinction is between business value and assets:

  • Business value: Problems are set by business opportunities, and solutions by processes and applications. The critical factor is reactivity and time-to-market.
  • Assets: Problems are set by business objectives and strategy, and solutions are to be supported by organization and systems capabilities. The critical factor is reuse and ROI.
Decision-making must distinguish between business opportunities and enterprise governance

Decision-making must distinguish between business opportunities and enterprise governance

If opportunities are to be seized and operations managed on the fly  yet tally with strategic decisions, respective problems and solutions should be kept apart. Juggling with their dynamic alignment is at the core of enterprise architects’ job description.

Enterprise Architects & Governance

Engineering and business perspectives are not to be seen as the terms of an alternative to be picked by enterprise architects. As a matter of fact they must be crossed and governance policies selected depending on the point of view:

  • Looking at EA from an engineering perspective,  the business one will focus on systems governance and assets management as epitomized by model based systems engineering schemes.
  • Looking at EA from a business perspective, the engineering one will focus on lean and just-in-time solutions, as epitomized by agile development models.

As far as governance of large and complex corporate entities, supposedly EA’s primary target, must deal with tactical, operational, and strategic concerns, the nexus between business and engineering perspectives is where enterprise architects are to stand.

 

 

Caminao & EACOE

September 19, 2016

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:

(M.Kippenberger)


How to assess EA frameworks and methodologies (M. Kippenberger)

  1. Business Initiatives (Projects): Initiatives should address cross-organizational or individual concerns.
  2. Directed Guidance: Explicit methods, tools, and artifacts.
  3. Consistency and Simplicity: Single frame of symbolic representation and reference.
  4. Structured and Precise Definitions: Frame built from a compact, complete, and consistent set of concepts to be logically extended.
  5. Clarity and Reason in Modeling: Two distinct model sets – Architecture Models and Implementation Models.
  6. Value in Models Transformations: Why develop artifacts that do not lead anywhere?
  7. Skills Acquisition: Enterprise Architecture skills are acquired through practice and experience.
  8. 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.
Qualified Information Flows across Architectures and Processes

Enterprise Architecture & Separation of Concerns

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.

Targets and Modeling Languages

All-inclusive Modeling Paradigm: Scope and Languages

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).
Processes should be devised according enterprise concerns and engineering contexts

Blueprints set according to layers and purpose

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.

ccc

Well established concepts are used to describe architecture capabilities

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:

vvv

Conceptual nodes are connected, structured, and specialized using a single set of formal constructs.

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.
vvv

Two distinct model sets: descriptive for business environments, prescriptive for systems architectures and artifacts.

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.

cccc

Just-in-time processes & Knowledge Based Models: Computation independent (blue), Platform independent (yellow), Platform specific (grey).

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.
cc

Skills should be primary defined with regard to purpose and target

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.

What moves first: actual contexts and processes or enterprise abstractions

EA Decision-making

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.

KEA: Knowledge is the Key to EA

KEA: Knowledge as the Key to EA

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

External Links