Archive for the ‘Software Engineering’ Category

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

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.
  • Architectures: engineering deals with supporting assets at enterprise level. Engineering units are associated with shared functionalities without specific life-spans.

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

iStar and the Requirements Conundrum

December 12, 2016

Synopsis

Whenever software engineering problems are looked at, the blame is generally put on requirements, with each side of the business/system divide holding the other responsible.

vvvv

Figuring Concepts (Ai Weiwei)

The iStar approach tries to tackle the problem with a conceptual language focused on interactions between business processes and supporting systems.

Dilemma

Conceptual approaches to requirements try to breach the dilemma between phased and agile development schemes: the former takes for granted that requirements can be fully and definitively set upfront; the latter takes a more pragmatic path and tries to reconcile business and system analysts through direct and continuous collaboration.

Setting apart frictions between specific methods, the benefits of agile principles and practices are now well-recognized, contingent on the limits of agile scope. Summarily, agile development is at its best when requirements capture and analysis can be weaved with development and tests. The question remains of what happens when requirements are to be dealt with separately.

The iStar’s answer shares with agile a focus on collaboration and doesn’t take side for business (e.g users’ stories) or systems (e.g use cases). Instead, iStar modeling language is meant to support a conceptual description of interactions between business processes and supporting systems in terms of actors’ goals and commitments, and the associated dependencies.

Actors & Goals

The defining aspect of the iStar modeling approach is to replace one-sided perspectives (business or system) by a systemic one focused on the interactions between agents. The interactive part of a requirement will therefore comprise three basic items:

  • A primary actor trigger an interaction in order to meet some goal; e.g a car owner want his car repaired.
  • Secondary actors may be involved during the ensuing exchanges: e.g body shop, appraiser, insurance company.
  • Functions to be performed: actual task; e.g appraise damages; qualification (soft goal), e.g fair appraisal; and resources, e.g premium payment.
Actors & dependencies

Actors & Dependencies

Dependencies Semantics

The factual description of interactions is both detailed and enriched by elements set within a broader scope:

  • Goal (strong) dependency: assertions about actual state of affairs: object, activity, or expectations.
  • Soft-goal dependency: assertions about expected outcomes.
  • Task dependency: organizational, functional, or technical constraints pertaining to the execution of activities.
  • Resource dependency: constraints or conditions on the availability of inputs, actual or symbolic.

It would be tempting to generalize the strong/soft distinction to dependencies as to make use of modal logic, strong dependencies associated with deontic rules, soft dependencies with alethic ones. That would .

iStar & Caminao

Since iStar modeling categories are directly aligned with UML Use Cases, they can easily mapped to core Caminao stereotypes for actors, objects, events, and activities.

Actors & dependencies

iStar with Caminao Stereotypes

Interestingly, the iStar strong/soft distinction could translate to the actual/symbolic one which constitute the conceptual backbone of the Caminao paradigm.

Assessment

From the business perspective, iStar must be credited with two critical tenets:

  • The focus on interactions between agents is essential for business and system analysts to collaborate. Such benefits appear clearly for the definition of primary and secondary roles (aka actors), intents (business) and capabilities (supporting environments).
  • The distinction between strong and soft goals, even if the logical basis remains unexploited.

Yet, the system perspective lacks a functional dimension, e.g:

  • Architecture levels (enterprise and organization, systems and functionalities, platforms and technologies) are not taken into consideration, nor the nature of capabilities, e.g strategic and operational.
  • The strong/soft dependencies distinction is not explicitly associated with systems capabilities.

On the whole these pros and cons reflect iStar’s declared intent on conceptual modeling; as a corollary these flaws mark also the limits of conceptual modeling when it is detached from the symbolic description of supporting systems functionalities.

Nonetheless, as illustrated by the research quoted below, iStar remains a sound basis for the specification of interactions between users and systems, either as use cases or users’ stories.

Further Reading

External Links

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

 

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.

 

 

Zebras cannot be saddled or harnessed

September 23, 2016

As far as standards go, the more they are, the less they’re worth.

nn

Read my code, if you can …

What have we got

Assuming that modeling languages are meant to build abstractions, one would expect their respective ladders converging somewhere up in some conceptual or meta cloud.

Assuming that standards are meant to introduce similarities into diversity, one would expect clear-cut taxonomies to be applied to artifacts designs.

Instead one will find bounty of committees, bloated specifications, and an open-minded if clumsy language confronted to a number of specific ones.

What is missing

Given the constitutive role of mathematical logic in computing systems, its quasi absence in modeling methods of their functional behavior is dumbfounding. Formal logic, set theory, semiotics, name it, every aspect of systems modeling can rely on a well established corpus of concepts and constructs. And yet, these scientific assets may be used in labs for research purposes but they remain overlooked for any practical use; as if the laser technology had been kept out of consumers markets for almost a century.

What should be done

The current state of affairs can be illustrated by a Horse vs Zebra metaphor: the former with a long and proved track record of varied, effective and practical usages, the latter with almost nothing to its credit except its archetypal idiosyncrasy.

Like horses, logic can be harnessed or saddled to serve a wide range of purposes without loosing anything of its universality. By contrast, concurrent standards and modeling languages can be likened to zebras: they may be of some use for their owner, but from an outward perspective, what remains is their distinctive stripes.

So the way out of the conundrum seems obvious: get rid of the stripes and put back the harness of logic on all the modeling horses.

Further Readings

Models as Parachutes

August 31, 2016

Preamble

The recent crash of Delta Airlines’ reservation system, following a number of similar incidents, have raised new concerns about the reliability of a whole generation of large and critical IT systems.

László Moholy-Nagy-para

Models as Parachutes (László Moholy-Nagy)

Particularly at risk are airlines or banking systems, whose seasoned infrastructures, at the cutting edge when introduced half a century ago, have been strained to their limit by waves of extensive networked new functionalities. Confronted to the magnitude and complexity of overall modernization, most enterprises have preferred piecemeal updates to architectural leaps. Such policies may bring some respite, but they may also turn into aggravating factors, increasing stakes and urgency as well as shortening odds.

Assuming some consensus about stakes, hazards, and options, the priority should be to overcome jumping fears by charting a reassuring perspective in continuity with current situation. For that purpose models may provide heartening parachutes.

Models: Intents & Doubts

Models can serve two kinds of purposes:

  • Describe business contexts according to enterprise objectives, foretell evolution, and simulate policies.
  • Prescribe the architecture of supporting systems and the design of software components.
Business analyst figure maps from territories, software architects create territories from maps

Models Purposes: Describe contexts & concerns, Design supporting systems

Frameworks were supposed to combine the two perspectives, providing a comprehensive and robust basis to systems governance. But if prescriptive models do play a significant role in engineering processes, in particular for code generation, they are seldom fed by their descriptive counterpart.

Broadly speaking, the noncommittal attitudes toward descriptive models comes from a rooted mistrust in non executable models: as far as business analysts and software engineers are concerned, such models can only serve as documentary evidence. And since prescriptive models are by nature grounded to systems’ inner making, there is no secure conceptual apparatus linking systemic changes with their technical consequences. Hence the jumping frights.

Overcoming those frights could be achieved by showing the benefits of secure and soft landings.

Models for Secure Landings

As any tools, models must be assessed with regard to their purpose: prescriptive ones with regard to feasibility and reliability of architectures and design, descriptive ones with regard to correctness and consistency. As already noted, compared to what has been achieved for the former, nothing much has been done about the validity of the latter.

Yet, and contrary to customary beliefs, the rigorous verification of descriptive (aka extensional) models is not a dead-end. Of course these models can never be proven true because there is no finite scope against which they could be checked; but it doesn’t mean that nothing can be done to improve their reliability:

Models must be assessed with regard to their purpose

How to Check for secure landings

  • Correctness: How to verify that all the relevant individuals and features are taken into account. That can only be achieved empirically by building models open to falsification.
  • Consistency: How to verify that the symbolic descriptions (categories and connectors) are complete, coherent and non redundant across models and abstraction levels. That can be formally verified.
  • Alignment: How to verify that current and required business processes are to be seamlessly and effectively supported by systems architectures. That can be managed by introducing a level of indirection, as illustrated by MDA with platform independent models (PIMs) set between computation independent (CIMs) and platform specific (PSMs) ones.

Once established on secure grounds, models can be used to ensure soft landings.

Models for Soft Landings

Set within model based system engineering frameworks, models will help to replace piecemeal applications updates by seamless architectures modernization:

  • Systems: using models shift the focus of change from hardware to software.
  • Enterprise: models help to factor out the role of organization and regulations.
  • Project management: models provide the necessary hinge between agile and phased projects, the former for business driven applications, the latter for architecture oriented ones. Combining both approaches will ensure than lean and just-in-time processes will not be sacrificed to system modernization.
Seamless architectures modernization (a) vs Piecemeal applications updates (b).

Seamless architectures modernization (a) vs Piecemeal applications updates (b).

More generally, and more importantly, models are the option of choice (if not the only one) for enterprise knowledge management:

  • Business: Computation independent models (CIMs), employed to trace, justify and rationalize business strategies and processes portfolios.
  • Systems: Platform specific models (PSMs), employed to trace, justify and rationalize technical alternatives and decisions.
  • Decision-making and learning: Platform independent models (PIMs), employed to align business and systems and support enterprise architecture governance.

And knowledge management is arguably the primary factor for successful comprehensive modernization.

Strategic Decision-making: Cash or Crash

Governance is all about risks and decision-making, but investing on truly fail-safe systems for airlines or air traffic control can be likened to a short bet on the Armageddon, and that cannot be easily framed in a neat cost-benefit analysis. But that may be the very nature of strategic decision-making: not amenable to ROI but aiming at risks assessment and the development of the policies apt to contain and manage them. That would be impossible without models.

Further Reading

Focus: Business Processes & Abstraction

July 16, 2016

Preamble

Abstractions, and corollary inheritance, are primarily understood with objects. Yet, since business processes are meant to focus on activities, semantics may have to be refined when abstraction and inheritance are directly used for behaviors.

enrique_gimenez-velilla

How to apply abstraction to processes ?  (E. Gimenez Velilla)

Considering that the primary purpose of abstractions is to tackle business variants with regard to supporting systems, their representation with use cases provides a good starting point.

Business Variants: Use case’s <extend> & <include>

Taking use cases as a modeling nexus between business and systems realms, <extend> and <include> appear as the default candidates for the initial description of behaviors’ specialization and generalization.

  • <include>: to be compared to composition semantics, with the included behaviors performed  by instances identified (#) by the owner UC (a).
  • <extend>: to be compared to aggregation semantics, with the extending behaviors performed  by separate instances with reference to the owner ones (b).
Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Included UCs are meant to be triggered by owners (a); that cannot be clearly established for abstract use cases and generalization (c).

Abstract use cases and generalization have also been mentioned by UML before being curiously overlooked in following versions. Since none has been explicitly discarded, some confusion remains about hypothetical semantics. Notionally, abstract UCs would represent behaviors never to be performed on their own (c). Compared to inclusion, used for variants of operations along execution paths, abstract use cases would describe the generic mechanisms to be applied to triggering events at UC inception independently of actual business operations carried out along execution paths.

Nonetheless, and more importantly, the mix-up surrounding the generalization of use cases points to a critical fault-line running under UML concepts: since both use cases and classes are defined as qualifiers, they are supposed to be similarly subject to generalization and specialization. That is misguided because use cases describe the business behaviors to be supported by systems, not to be confused with the software components that will do the job. The mapping between the former and the latter is to be set by design, and there is no reason to assume a full and direct correspondence between functional requirements and functional architecture.

Use Cases Distilled

As far as use cases are considered, mapping business behaviors to supporting systems functionalities can be carried out at two levels:

  • Objects: UCs being identified by triggering agents, events, and goals, they are to be matched with corresponding users interfaces and controllers, the former for the description of I/O flows, the latter for the continuity and integrity of interactions.
  • Methods: As it’s safe to assume that use cases are underpinned by shared business functions and system features, a significant part of their operations are to be realized by methods of shared business entities or services.
vv

Setting apart UIs and controllers, no direct mapping should be assumed between use cases and functional qualifiers.

The business variants distilled into objects’ or services’ methods can be generalized and specialized according to OOD principles; and the same principles can be applied to specific users’ interfaces. But since purely behavioral aspects of UCs can neither be distilled into objects’ methods, nor directly translated into controller objects, their abstraction semantics have to be reconsidered.

Inheritance Semantics: Structural vs Functional

As far as software artifacts are concerned, abstraction semantics are set by programming languages, and while they may differ, the object-oriented (OO) paradigm provides some good enough consolidation. Along that perspective, inheritance emerges as a critical issue due to its direct impact on the validity of programs.

Generally speaking, inheritance describes how structural or behavioral traits are passed from ancestors to descendants, either at individual or type level. OO design is more specific and puts the focus on the intrinsic features (attributes and operations) supported by types or classes, which ensues that behaviors are not considered as such but through the objects’ methods that realize them:

  • Structural inheritance deals with attributes and operations set for the whole life-cycle of instances. As a consequence corresponding inheritance is bound to identities (#) and multiple ascendants (i.e identities) are ruled out.
  • Functional inheritance deal with objects behaviors which may or may not be frozen to whole life-cycles. Features can therefore be inherited from multiple ascendants.

That structural vs functional distinction matches the one between composition and aggregation used to characterize the links between objects and parts which, as noted above, can also be applied to uses cases.

Use Cases & Abstraction

Assuming that the structural/functional distinction defined for objects can also be applied to behaviors, use cases provide a modeling path from variants in business processes to OOD of controllers:

  • Behaviors included by UCs (a) are to be set along the execution paths triggered by UC primary events (#). Inheritance is structural, from UCs base controllers to corresponding (local) ones, and covers features (e.g views on business objects) and associated states (e.g authorizations) defined by use case triggering circumstances.
  • Behaviors extending UCs (b) are triggered by secondary events generated along execution paths. Inheritance is functional, from extending UCs (e.g text messaging) to UCs primary controllers.

Yet this dual scheme may not be fully satisfactory as it suffers from two limitations:

  • It only considers the relationships between UCs, not with the characteristics of the use cases themselves.
  • It ignores the critical difference between the variants of business logic and the variants of triggering conditions.

Both flaws can be patched up if abstract use cases are specifically introduced to factor out triggering circumstances (c):

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

Use cases provide a principled modeling path from variants in business processes to the OOD of corresponding controllers.

  • Undefined triggering circumstances is the only way to characterize abstraction independently of what happens along execution paths.
  • Abstract use cases can then be used to specify inception mechanisms to be inherited by concrete use cases.

That understanding of abstract use cases comes with clear benefits with regard to security and confidentiality.

What is at Stake

Factoring out authentication and authorization epitomizes the benefits of abstract UCs:

  • Concrete schemes with included UC will give access to all registered users with the particulars of managers or customers checked later (a).
  • Alternatively, abstract schemes will use inheritance of inception mechanisms in order to explicitly prevent separate access (c).
  • Applying <include> with abstract UC should be ruled out because it would make room for the execution of operations with undefined triggering circumstances.
Interactions can only be triggered by concrete actors.

Interactions can only be triggered by concrete actors.

As a conclusion, by enabling a clear distinction between business logic and operational circumstances, abstraction can reinforce the security of functional architectures.

Further Reading

 

Business Stories: Stakeholders’ Plots & Users’ Narratives

July 4, 2016

Preamble

As Aristotle noted some time ago, plots are the backbone of any story as they uphold the causal sequence of events and actions: they provide the “why” of what happens, compared to narratives, which tell “how” what happened is being told.

cccc

Only shadows will tell: as far as stories are concerned, possibilities remain unknown until their realization.

So, in principle, plots deal with possibilities and narratives with realizations. But in fact plots remain unknown until being narrated; in other words fictions are like Schrödinger’s cat: there is no way to set possibilities and realizations apart.

That literary conundrum may convey some useful clues for business analysis, with stakeholders objectives seen as plots, and users’ stories as narratives.

Stakeholders’ Plots vs Users’ Narratives

With regard to the functionalities of supporting systems, a key issue for business analysts is to accommodate specific and short-lived opportunities identified by business units with broader and long-standing objectives defined at corporate level.

Assuming a fictional view of business expectations, that issue can be charted in terms of plots and narratives:

  • Business objectives (as plots) are meant to apply continuously and consistently to different agents, different concerns, and different contexts. As such they are best defined as rules and constraints (declarative schemes).
  • Users’ stories (as narratives) are supposed to translate as soon as possible into business transactions. As such they are best defined as sequences of operations governed by users’ choices (procedural schemes).

Then, just like narratives are meant to carry out the plots, users’ stories are supposed to follow the paths set by business objectives. But if confusion is to be avoided between strategic orientations, regulatory directives, and opportunist moves, the walk of business objectives and the talk of users’ stories should be termed differently.

Business Objectives (Plots): Symbolic & Allochronic

The definition of business objectives has to find its terms between the Charybdis of abstractions and the Scylla of specific business processes, the former to be avoided because they are by nature detached from reality and only make sense with regard to models, the latter because they would be too specific and restrictive. In-between, business objectives would be best defined through:

  • Strategic and financial objectives expressed using symbolic categories applied to environments, products, and resources.
  • Modal time-frames identified in reference to events and qualified by assumptions with regard to symbolic categories.
  • Business functions to be optimized given a set of constraints.

These could be comprehensively and consistently expressed with declarative languages.

Users’ Stories (Narratives): Actual & Contemporaneous

Users’ stories are at their best when tied to specific circumstances and purposes without being led away by modeling concerns. As narratives they should stick to agents, triggering events, and scripted sequences of options, operations, and outcomes:

  • Compared to the symbolic categories used for business objectives, users stories should refer to actual subsets of objects and events defined on contexts.
  • Contrary to the modal time-frames of business objectives, the scripts of users’ stories must be fully timed with regard to their triggering events.

That can only be expressed as procedures.

From Fiction to Artifacts: Aligning Business Objectives & Enterprise Architectures

Likening business analysis to its distant literary kin goes beyond the metaphor as it points to a practical organization of business objectives and users’ stories.

And the benefits of the distinction between declarative (for business plots) and procedural (for users’ narratives) blueprints is not limited to business analysis but can be extended to systems architecture (as plots) and software design (as narratives). On that basis declarative schemes could be applied to business functions and architectures capabilities, and procedural ones to users’ stories (or use cases) and software design.

XBredModels_PlotsNarrs

On a broader perspective such a fictional approach may help to align enterprise architectures to business objectives.

Further Reading

External Links

Focus: UML Reenacted

June 26, 2016

Overview

After a promising inception twenty years ago by the OMG (Object Management Group), UML (Unified Modeling Language) seems to have lost part of its steam and fallen short of initial expectations.

(Marta Minujin)

UML library: too many books, too specific languages (Marta Minujin)

On a general perspective that may be due to the primacy given to the agendas of tools providers, at the expense of users concerns. More specifically, UML practices have been hamstrung by two opposed misconceptions: on one side UML has been associated to OO methods and as a result demoted by non-devotees; on the other side it has been taken as a substitute for programming languages, and so confined to class diagrams and code generation. Hopefully, two major advances in methods and development frameworks, respectively agile and MBSE, could correct those biases and renew UML appeal.

UML Core Artifacts

UML diagrams target five primary artifacts:

  • Use cases, events, and actors describe what happens between systems and active agents in their environments.
  • Activities describe what systems are supposed to do when use cases are triggered.
  • Classes describe systems components.
  • Sequences describe how systems components collaborate to perform activities.
  • States and transitions describe the behaviors and synchronization of systems components.
ccc

UML Backbone

While those diagrams cover the whole of enterprise systems, UML is all too often limited to the description of software components.

UML and Enterprise Systems

As noted above, the lack of clear users guidelines can be seen as a main cause of UML piecemeal and biased adoption. That can be illustrated by the use of activity and class diagrams:

  • Whereas activity and state diagrams could have been tailored to fully and consistently describe business processes, an alternative notation (BPMN) with arguable benefits is often preferred by business analysts.
  • Whereas UML is meant to deal with the whole of systems, successful implementations like domain specific languages (DSL) focus on class diagrams and code generation.
Targets and Modeling Languages

UML in Context

But both negative trends could be reversed if changes in methodological or technical environments could put UML users on sounder grounds and give them clearer guidelines.

Methods: Use Cases & Agile

As it happened, use cases have been the main UML innovation, other artifacts having been already introduced by modeling languages. And more to the point, they were meant to be the cornerstone of the “unified” construction, a modeling bridge between business processes and supporting systems. That clearly didn’t happen with traditional (and failed) methods like waterfall, but agile could be more welcoming.

Use cases at the hub of UML diagrams

Use cases as a modeling bridge between business processes and supporting systems.

Agile principles put the focus on collaboration and iterative code development, with only sparse mentions of models or processes. But as requirements don’t always come as clear-cut short stories told by well identified business units, use cases may help agile teams to deal with organizational or architectural dependencies:

  • Open minded and Versatile: use cases are not limited to users because actors (aka roles) are meant to hide the actual agents involved: people, devices, or other systems. As a consequence, the scope of UCs is not limited to dialog with users but may also includes batch (as one-step interactions) and real-time transactions.
  • Modular and inter-operable: given their simplicity and clarity of purpose, use cases can be easily processed by a wide array of modeling tools on both sides of the business/engineering divide, e.g BPM and UML.
  • Iterative: given their modularity, use cases can be easily tailored to the iterative paradigm. Once a context is set by business process or user’s story, development iterations can be defined with regard to invariants (use case), iterations (extension points and scenarii), backlog units (activities), and exit condition.
  • Scalable: use cases provide a sound and pragmatic transition between domain specific stories and architectural features.

That could be the basis of an open relationship between agile development models and UML.

Frameworks: Classes & MBSE

Beyond the various labels (based/driven, system/software, development/engineering), all model based approaches to systems engineering and software development try to replace procedural approaches by declarative ones, and to redefine processes in terms of artifacts transformation.

Model Based Engineering Processes are governed by the status of artifacts

UML could be used to define and manage engineered artifacts.

The benefits of that approach have already been demonstrated at design level through the use of domain specific languages (DSLs). Since effective DSLs usually rely on class diagrams, UML could be used to leverage their success beyond code generation and across the whole of the engineering process.

With artifacts seamlessly and consistently defined and managed within a single engineering framework, procedural schemes could be replaced by declarative ones reusing, editing, or transforming artifacts depending on constraints.

Further Reading