Archive for the ‘Software Engineering’ Category

EA: Legacy & Latency

June 7, 2018

 “For things to remain the same, everything must change”

Lampedusa, “The Leopard”

Preamble

Whatever the understanding of the discipline, most EA schemes implicitly assume that enterprise architectures, like their physical cousins, can be built from blueprints. But they are not because enterprises have no “Pause” and “Reset” buttons: business cannot be put on stand-by and must be carried on while work is in progress.

hans-vredeman-de-vries-2

Dealing with EA’s Legacy: WIP or RIP ? (Hans Vredeman de Vries)

Systems & Enterprises

Systems are variously defined as:

  • “A regularly interacting or interdependent group of items forming a unified whole” (Merriam-Webster).
  • “A set of connected things or devices  that operate  together” (Cambridge Dictionary).
  • “A way of working, organizing, or doing something which follows a fixed plan or set of rules” (Collins Dictionary)
  • “A collection of components organized to accomplish a specific function or set of functions” (TOGAF from ISO/IEC 42010:2007)

While differing in focus, most understandings mention items and rules, purpose, and the ability to interact; none explicitly mention social structures or interactions with humans. That suggests where the line should be drawn between systems and enterprises, and consequently between corresponding architectures.

Architectures & Changes

Enterprises are live social entities made of corporate culture, organization, and supporting systems; their ultimate purpose is to maintain their identity and integrity while interacting with environments. As a corollary, changes cannot be carried out as if architectures were just apparel, but must ensure the continuity and consistency of enterprises’ structures and behaviors.

That cannot be achieved by off-soil schemes made of blueprints and step-by-step processes detached from actual organization, systems, and processes. Instead, enterprise architectures must be grown bottom up from actual legacies whatever their nature: technical, functional, organizational, business, or cultural.

EA’s Legacy

Insofar as enterprise architectures are concerned, legacies are usually taken into account through one of three implicit assumptions:

No legacy assumptions ignore the issue, as if the case of start-ups could be generalized. These assumptions are logically flawed because enterprises without legacy are like embryos growing their own inherent architecture, and in that case there would be no need for architects.

En Bloc legacy assumptions take for granted that architectures as a whole could be replaced through some Big Bang operation without having a significant impact on business activities. These assumptions are empirically deceptive because, even limited to software architectures, Big Bang solutions cannot cope with the functional and generational heterogeneity of software components characterizing large organizations. Not to mention that enterprise architectures are much more that software and IT.

Piecemeal legacies can be seen as the default assumption, based on the belief that architectures can be re-factored or modernized step by step. While that assumption may be empirically valid, it may also miss the point: assuming that all legacies can be dealt with piecemeal rubs out the distinction pointed above between systems and enterprises.

So, the question remains of what is to be changed, and how ?

EA as a Work In Progress

As with leopard’s spots and identity, the first step would be to set apart what is to change (architectures) from what is to carry on (enterprise).

Maps and territories do provide an overview of spots’ arrangement, but they are static views of architectures, whereas enterprises are dynamic entities that rely on architectures to interact with their environment. So, for maps and territories to serve that purpose they should enable continuous updates and adjustments without impairing enterprises’ awareness and ability to compete.

That shift from system architecture to enterprise behavior implies that:

  • The scope of changes cannot be fully defined up-front, if only because the whole enterprise, including its organization and business model, could possibly be of concern.
  • Fixed schedules are to be avoided, lest each and every unit, business or otherwise, would have to be shackled into a web of hopeless reciprocal commitments.
  • Different stakeholders may come as interested parties, some more equal than others, possibly with overlapped prerogatives.

So, instead of procedural and phased approaches supposed to start from blank pages, EA ventures must be carried out iteratively with the planning, monitoring, assessment, and adjustment of changes across enterprises’ businesses, organizations, and systems. That can be represented as an extension of the OODA (Observation, Orientation, Decision, Action) loop:

  • Actual observations from operations (a)
  • Data analysis with regard to architectures as currently documented (b).
  • Changes in business processes (c).
  • Changes in architectures (d).
DataInfoKnow_OODA

EA decision-making as an extension of the OODA loop

Moreover, due to the generalization of digital flows between enterprises and their environment, decision-making processes used to be set along separate time-frames (operational, tactical, strategic, …), must now be weaved together along a common time-scale encompassing internal (symbolic) as well as external (actual) events.

It ensues that EA processes must not only be continuous, but they also must deal with latency constraints.

Changes & Latency

Architectures are by nature shared across organizational units (enterprise level) and business processes (system level). As a corollary, architecture changes are bound to introduce mismatches and frictions across business-specific applications. Hence the need of sorting out the factors affecting the alignment of maps and territories:

  • Elapsed time between changes in territories and maps updates (a>b) depends on data analytics and operational architecture.
  • Elapsed time between changes in maps and revised objectives (b>c) depends on business analysis and organization.
  • Elapsed time between changes in objectives and their implementation (c>d) depends on engineering processes and systems architecture.
  • Elapsed time between changes in systems and changes in territories (d>a) depends on applications deployment and technical architectures.

Latency constraints can then be associated with systems engineering tasks and workshops.

DataInfoKnow_Worshops

EA changes & Latency

On that basis it’s possible to define four critical lags:

  • Operational: data analytics can be impeded by delayed, partial, or inaccurate feedback from processes.
  • Mapping: business analysis can be impeded by delays or discrepancies in data analytics.
  • Engineering: development of applications can be impeded by delays or discrepancies in business analysis.
  • Processes: deployment of business processes can be impeded by delays in the delivery of supporting applications.

These lags condition the whole of EA undertakings because legacy structures, mechanisms, and organizations are to be continuously morphed into architectures without introducing misrepresentations that would shackle activities and stray decision-making.

EA Latency & Augmented Reality

Insofar as architectural changes are concerned, discrepancies and frictions are rooted in latency, i.e the elapsed time between actual changes in territories and the updating of relevant maps.

As noted above, these lags have to be weighted according to time-frames, from operational days to strategic years, so that the different agents could be presented with the relevant and up-to-date views befitting to each context and concerns.

DataInfoKnow_intervs

EA views must be set according to contexts and concerns, with relevant lags weighted appropriately.

That could be achieved if enterprises architectures were presented through augmented reality technologies.

Compared to virtual reality (VR) which overlooks the whole issue of reality and operates only on similes and avatars, augmented reality (AR) brings together virtual and physical realms, operating on apparatuses that weaves actual substrates, observations, and interventions with made-up descriptive, predictive, or prescriptive layers.

On that basis, users would be presented with actual territories (EA legacy) augmented with maps and prospective territories.

DataInfoKnow_esh3

Augmented EA: Actual territory (left), Map (center), Prospective territory (right)

Composition and dynamics of maps and territories (actual and prospective) could be set and edited appropriately, subject to latency constraints.

Further Reading

 

Advertisements

Collaborative Systems Engineering: From Models to Ontologies

April 9, 2018

Given the digitization of enterprises environments, engineering processes have to be entwined with business ones while kept in sync with enterprise architectures. That calls for new threads of collaboration taking into account the integration of business and engineering processes as well as the extension to business environments.

Wang-Qingsong_scaffold

Collaboration can be personal and direct, or collective and mediated (Wang Qingsong)

Whereas models are meant to support communication, traditional approaches are already straining when used beyond software generation, that is collaboration between humans and CASE tools. Ontologies, which can be seen as a higher form of models, could enable a qualitative leap for systems collaborative engineering at enterprise level.

Systems Engineering: Contexts & Concerns

To begin with contents, collaborations should be defined along three axes:

  1. Requirements: business objectives, enterprise organization, and processes, with regard to systems functionalities.
  2. Feasibility: business requirements with regard to architectures capabilities.
  3. Architectures: supporting functionalities with regard to architecture capabilities.
RekReuse_BFCo

Engineering Collaborations at Enterprise Level

Since these axes are usually governed by different organizational structures and set along different time-frames, collaborations must be supported by documentation, especially models.

Shared Models

In order to support collaborations across organizational units and time-frames, models have to bring together perspectives which are by nature orthogonal:

  • Contexts, concerns, and languages: business vs engineering.
  • Time-frames and life-cycle: business opportunities vs architecture stability.
EASquare2_eam.jpg

Harnessing MBSE to EA

That could be achieved if engineering models could be harnessed to enterprise ones for contexts and concerns. That is to be achieved through the integration of processes.

 Processes Integration

As already noted, the integration of business and engineering processes is becoming a key success factor.

For that purpose collaborations would have to take into account the different time-frames governing changes in business processes (driven by business value) and engineering ones (governed by assets life-cycles):

  • Business requirements engineering is synchronic: changes must be kept in line with architectures capabilities (full line).
  • Software engineering is diachronic: developments can be carried out along their own time-frame (dashed line).
EASq2_wrkflw

Synchronic (full) vs diachronic (dashed) processes.

Application-driven projects usually focus on users’ value and just-in-time delivery; that can be best achieved with personal collaboration within teams. Architecture-driven projects usually affect assets and non-functional features and therefore collaboration between organizational units.

Collaboration: Direct or Mediated

Collaboration can be achieved directly or through some mediation, the former being a default option for applications, the latter a necessary one for architectures.

Cycles_collabs00

Both can be defined according to basic cognitive and organizational mechanisms and supported by a mix of physical and virtual spaces to be dynamically redefined depending on activities, projects, locations, and organisation.

Direct collaborations are carried out between individuals with or without documentation:

  • Immediate and personal: direct collaboration between 5 to 15 participants with shared objectives and responsibilities. That would correspond to agile project teams (a).
  • Delayed and personal: direct collaboration across teams with shared knowledge but with different objectives and responsibilities. That would tally with social networks circles (c).
Cycles_collabs.jpg

Collaborations

Mediated collaborations are carried out between organizational units through unspecified individual members, hence the need of documentation, models or otherwise:

  • Direct and Code generation from platform or domain specific models (b).
  • Model transformation across architecture layers and business domains (d)

Depending on scope and mediation, three basic types of collaboration can be defined for applications, architecture, and business intelligence projects.

EASq2_collabs

Projects & Collaborations

As it happens, collaboration archetypes can be associated with these profiles.

Collaboration Mechanisms

Agile development model (under various guises) is the option of choice whenever shared ownership and continuous delivery are possible. Application projects can so be carried out autonomously, with collaborations circumscribed to team members and relying on the backlog mechanism.

The OODA (Observation, Orientation, Decision, Action) loop (and avatars) can epitomize projects combining operations, data analytics, and decision-making.

EASquare2_collaMechas

Collaboration archetypes

Projects set across enterprise architectures cannot be carried out without taking into account phasing constraints. While ill-fated Waterfall methods have demonstrated the pitfalls of procedural solutions, phasing constraints can be dealt with a roundabout mechanism combining iterative and declarative schemes.

Engineering vs Business Driven Collaborations

With collaborative engineering upgraded at enterprise level, the main challenge is to iron out frictions between application and architecture projects and ensure the continuity, consistency and effectiveness of enterprise activities. That can be achieved with roundabouts used as a collaboration mechanism between projects, whatever their nature:

  • Shared models are managed at roundabout level.
  • Phasing dependencies are set in terms of assertions on shared models.
  • Depending on constraints projects are carried out directly (1,3) or enter roundabouts (2), with exits conditioned by the availability of models.

Engineering driven collaboration: roundabout and backlogs

Moreover, with engineering embedded in business processes, collaborations must also bring together operational analytics, decision-making, and business intelligence. Here again, shared models are to play a critical role:

  • Enterprise descriptive and prescriptive models for information maps and objectives
  • Environment predictive models for data and business understanding.
OKBI_BIDM

Business driven collaboration: operations and business intelligence

Whereas both engineering and business driven collaborations depend on sharing information  and knowledge, the latter have to deal with open and heterogeneous semantics. As a consequence, collaborations must be supported by shared representations and proficient communication languages.

Ontologies & Representations

Ontologies are best understood as models’ backbones, to be fleshed out or detailed according to context and objectives, e.g:

  • Thesaurus, with a focus on terms and documents.
  • Systems modeling,  with a focus on integration, e.g Zachman Framework.
  • Classifications, with a focus on range, e.g Dewey Decimal System.
  • Meta-models, with a focus on model based engineering, e.g models transformation.
  • Conceptual models, with a focus on understanding, e.g legislation.
  • Knowledge management, with a focus on reasoning, e.g semantic web.

As such they can provide the pillars supporting the representation of the whole range of enterprise concerns:

KM_OntosCapabs

Taking a leaf from Zachman’s matrix, ontologies can also be used to differentiate concerns with regard to architecture layers: enterprise, systems, platforms.

Last but not least, ontologies can be profiled with regard to the nature of external contexts, e.g:

  • Institutional: Regulatory authority, steady, changes subject to established procedures.
  • Professional: Agreed upon between parties, steady, changes subject to established procedures.
  • Corporate: Defined by enterprises, changes subject to internal decision-making.
  • Social: Defined by usage, volatile, continuous and informal changes.
  • Personal: Customary, defined by named individuals (e.g research paper).

Cross profiles: capabilities, enterprise architectures, and contexts.

Ontologies & Communication

If collaborations have to cover engineering as well as business descriptions, communication channels and interfaces will have to combine the homogeneous and well-defined syntax and semantics of the former with the heterogeneous and ambiguous ones of the latter.

With ontologies represented as RDF (Resource Description Framework) graphs, the first step would be to sort out truth-preserving syntax (applied independently of domains) from domain specific semantics.

KM_CaseRaw

RDF graphs (top) support formal (bottom left) and domain specific (bottom right) semantics.

On that basis it would be possible to separate representation syntax from contents semantics, and to design communication channels and interfaces accordingly.

That would greatly facilitate collaborations across externally defined ontologies as well as their mapping to enterprise architecture models.

Conclusion

To summarize, the benefits of ontological frames for collaborative engineering can be articulated around four points:

  1. A clear-cut distinction between representation semantics and truth-preserving syntax.
  2. A common functional architecture for all users interfaces, humans or otherwise.
  3. Modular functionalities for specific semantics on one hand, generic truth-preserving and cognitive operations on the other hand.
  4. Profiled ontologies according to concerns and contexts.
KM_OntosCollabs

Clear-cut distinction (1), unified interfaces architecture (2), functional alignment (3), crossed profiles (4).

A critical fifth benefit could be added with regard to business intelligence: combined with deep learning capabilities, ontologies would extend the scope of collaboration to explicit as well as implicit knowledge, the former already framed by languages, the latter still open to interpretation and discovery.

Further Reading

 

Focus: Requirements Reuse

February 22, 2018

Preamble

Requirements is what to feed engineering processes. As such they are to be presented under a wide range of forms, and nothing should be assumed upfront about forms or semantics.

What is to be reused: Sketches or Models  ? (John Devlin)

Answering the question of reuse therefore depends on what is to be reused, and for what purpose.

Documentation vs Reuse

Until some analysis can be carried out, requirements are best seen as documents;  whether such documents are to be ephemeral or managed would be decided depending on method (agile or phased), contents (business, supporting systems, implementation, or quality of services), or purpose (e.g governance, regulations, etc).

What is to be reused.

Setting apart external conditions, requirements documentation could be justified by:

  • Traceability of decision-making linking initial requests with actual implementation.
  • Acceptance.
  • Maintenance of deliverables during their life-cycle.

Depending on development approaches, documentation could limited to archives (agile development models) or managed as intermediate products (phased development models). In the latter case reuse would entail some formatting of requirements.

The Cases for Requirements Reuse

Assuming that requirements have been properly formatted, e.g as analysis models (with technical ones managed internally at system level), reuse could be justified by changes in business, functional, or quality of services requirements:

  • Business processes are meant to change with opportunities. With requirements available as analysis models, changes would be more easily managed (a) if they could be fine-grained. Business rules are a clear example, but that could also be the case for new features added to business objects.
  • Functional requirements may change even without change of business ones, e.g if new channels and users are introduced addressing existing business functions. In that case reusable business requirements (b) would dispense with a repeat of business analysis.
  • Finally, quality of service could be affected by operational changes like localization, number of users, volumes, or frequency. Adjusting architecture capabilities would be much easier with functional (c) and business (d) requirements properly documented as analysis models.

Cases for Reuse

Along that perspective, requirements reuse appears to revolve around two pivots, documents and analysis models. Ontologies could be used to bind them.

Requirements & Ontologies

Reusing artifacts means using them in contexts or for purposes different of native ones. That may come by design, when specifications can anticipate on shared concerns, or as an afterthought, when initially unexpected similarities are identified later on. In any case, reuse policies have to overcome a twofold difficulty:

  • Visibility: business and functional analysts must be made aware of potential reuse without having to spend too much time on research.
  • Overheads: ensuring transparency, traceability, and consistency checks on requirements (documents or analysis models) cannot be achieved without costs.

Ontologies could help to achieve greater visibility with acceptable overheads by framing requirements with regard to nature (documents or models) and context:

With regard to nature, the critical distinction is between document management and model based engineering systems. When framed as ontologies, the former is to be implemented as thesaurus targeting terms and documents, the latter as ontologies targeting categories specific to organizations and business domains.

Documents, models, and capabilities should be managed separately

With regard to context the objective should be to manage reusable requirements depending on the kind of jurisdiction and stability of categories, e.g:

  • Institutional: Regulatory authority, steady, changes subject to established procedures.
  • Professional: Agreed upon between parties, steady, changes subject to accord.
  • Corporate: Defined by enterprises, changes subject to internal decision-making.
  • Social: Defined by usage, volatile, continuous and informal changes.
  • Personal: Customary, defined by named individuals (e.g research paper).

Combining contexts of reuse with architectures layers (enterprise, systems, platforms) and capabilities (Who,What,How, Where, When).

Combined with artificial intelligence, ontology archetypes could crucially extend the benefits of requirements reuse, notably through the impact of deep learning for visibility.

On a broader perspective requirements should be seen as a source of knowledge, and their reuse managed accordingly.

Further Reading

Focus: Business Analyst Booklet

November 6, 2017

Objective

Business analysts stand between unbounded and moving business landscapes on one hand, distinctive and steady enterprise organization and culture on the other hand.

How to align enterprise resources and business opportunities (Patrick Zachmann)

Assuming that BAs’ primary concern is to keep ahead of the competition, framing business undertakings into universal guidelines could be counterproductive. By contrast, harnessing together versatile business processes and reliable systems architectures will clearly enhance business agility; hence the benefits of lining up enterprise architects’ and business analysts’ conceptual toolboxes:

  1. Concepts : eight exclusive and unambiguous definitions provide the conceptual building blocks.
  2. Models: how the concepts are used to consolidate business requirements and convey them to enterprise architects and software engineers.
  3. Processes: how to harness organization and business objectives and align applications with business value.
  4. Architectures: how to contrive along time the continuity and consistency of business concepts and objectives, and their congruence with systems capabilities.
  5. Governance: assessment of business value and risks.

On that basis, the objective here is not to detail BAs’ tasks or methods but to focus on core issues to be addressed by business analysts.

Concepts

Whereas systems architecture is not their primary concern, business analysts should nonetheless share the same modeling paradigm:

  • Analysis models for business environments and objectives.
  • Design models for the architecture of systems and the specification of components.

Business objects and processes must be consistently identified (#) across business and system realms.

It is worth to remind that the distinction between descriptive (aka analysis) and prescriptive (aka design) models is not arbitrary but based on logic principles: the former are extensional as they classify actual instances of business objects and activities; in contrast, the latter are intensional as they define the features and behaviors of required system artifacts.

The distinction also brings organizational benefits as it tallies with BAs’ responsibility regarding the consistency and continuity of identities and semantics of actual objects and processes (business extensions) and their symbolic counterparts (system intensions):

Relevant categories at architecture level can be neatly and unambiguously defined.

  • Actual containers represent address spaces or time frames; symbolic ones represent authorities governing symbolic representations. System are actual realizations of symbolic containers managing symbolic artifacts.
  • Actual objects (passive or active) have physical identities; symbolic objects have social identities; messages are symbolic objects identified within communications. Power-types (²) are used to partition objects.
  • Roles (aka actors) are parts played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents meant to be identified independently of their behavior.
  • Events are changes in the state of business objects, processes, or expectations.
  • Activities are symbolic descriptions of operations and flows (data and control) independently of supporting systems; execution states (aka modes) are operational descriptions of activities with regard to processes’ control and execution. Power-types (²) are used to partition execution paths.

While business analysts should only be tasked with the continuous and consistent mapping of business individuals to their system surrogates, and not with their implementations, that cannot be achieved without a full and unambiguous specification of the variants and abstractions for the business objects and processes to be represented.

Languages & Models

Being in charge of requirements, business analysts can be seen as the gate-keepers of the whole engineering process. To begin with, and depending on the nature of domains, BAs can capture requirements using formal (e.g for scientific domains), specific, or natural languages. Then, requirements analysis can be carried out:

  • Iteratively in unison with development and in collaboration with software engineers (agile approach). In that case models are not necessary as requirements are expressed in natural language (users’ stories), possibly combined with domain specific languages (DSLs) for development.
  • As phased undertakings carried out independently, using a dedicated modeling language (e.g BPMN).
  • As phased undertakings carried out jointly with system analysts using a general purpose modeling language (e.g UML).

Three ways to deal with requirements analysis: business oriented and phased (BPMN), system oriented and phased (use cases), or business driven and iterative (users’ stories).

These schemes are therefore best understood as tools whose employ may overlap or be combined:

  • BPMN and UML activity diagrams have much in common.
  • Class diagram can complement BPMN for business objects, and State diagrams for processes control.
  • Use cases can be seen as describing the part of users’ stories to be supported by systems.

How BAs will employ them is to depend on business processes and projects’ objectives.

Business & Development Processes

The responsibility of BAs is about business processes, the choice of development model being left to project managers; hence the need for business analysts to be familiar with basic options:

  • Agile: business analysts collaborate with software engineers in project teams and share responsibilities from requirements to delivery.
  • Phased: roles and responsibilities are defined specifically with regard to development tasks.

With agile schemes BAs share roles and responsibilities all along, with phased ones roles and responsibilities are defined with regard to tasks.

Agile or phased, the contribution of business analysts can be defined around three core issues, corresponding to three typical modus operandi:

  • Concepts associated to business objects and activities that are to be represented. Assuming that conceptual models are meant to be stable and shared across processes, they should be under the responsibility of business analysts independently of applications.
  • Actors (users, devices, or systems) and activities. Insofar as the impact on organization and system functional features can be localized (users interfaces) or circumscribed (business rules), business analysts can collaborate and share responsibility with software engineers all along an iterative process. Otherwise (changes in organization or business functions) business analysts will have to consolidate their work with enterprise architects.
  • Processes execution. Often labelled as non functional capabilities, they essentially deal with the different aspects of user’s experience and the synchronization of changes in business environments and supporting systems. For that purpose business analysts will have to check requirements against systems capabilities.

Business analysts core concerns and MO: conceptual model, activities, and processes.

While these issues are often interwoven, sorting them out can help to match development models with projects objectives and scope: agile for projects facing business users, phased for the ones dealing with architectures; that will also help to characterize the role of BAs depending on focus: business processes (BPM, use cases, users’ stories), functional architecture (services, conceptual models), or quality of services.

Business Analysis & Systems Architectures

When considering business opportunities, business analysts have to define requirements’ footprint with regard to system capabilities:

  • Confined: applications can be developed in collaboration with software engineers from users’ stories to code, without modeling. Assuming agile conditions about shared ownership and continuous delivery are met, that would be the default option.
  • Distributed: some modeling is needed for communication and consolidation purposes. But business processes modeling languages like BPMN make no distinction between processes’ details and the shared features of supporting systems. That puts a challenging toll on business analysts (complexity, ambiguity) with limited benefits (no easy mapping to system functions).

A primary concern for business analysts should therefore to frame projects accordingly: self-contained and business driven on one hand, shared and architecture driven on the other hand, with use cases set in between if and when necessary. For that purpose shared concerns will have to be clearly identified; taking BPMN for example:

BPEA_ArchiProc

Separation of concerns: architecture backbone and processes’ details

  • Containers for physical (locations) and logical (organizations and domains) objects have no BPMN explicit equivalents.
  • Active objects have no BPMN explicit equivalent.
  • Swimlanes and pool tally with roles (aka actors)
  • Data stores tally with entities (persistent representation of business objects).
  • Tasks, transactions, and sub-processes can be translated as activities description and processes execution.

Given backbones shared with enterprise architects, the next step is to flesh them out with specific details. Depending on methods and tools, that can be done using a domain specific language (DSL) with direct implementation, or through a generic subset of BPMN that could be unambiguously mapped to design constructs, for instance:

  • Anchors (#): instances (objects or activities) directly and consistently identified across businesses and system.
  • Collections (*): set of individuals with shared features.
  • Features: attributes or operations without identity of their own.
  • Structures (diamond): composition (black) for individual components (objects or activities) whose life-cycle is bound to their owner, i.e they have no identity of their own; aggregation (white) for components identified independently but used in the context of their owner.
  • Connectors: associate individuals; their semantics is set by context: communication channel, reference, data or control flow, transition. They can bear identification (#).
  • Power-types (2): define subsets of individuals objects or activities. Depending on context and modeling language, power-types correspond to classifications, extension points, gateways, branch and joins, etc.
  • Inheritance (triangle): contrary to structure and functional connectors that deal with instances, inheritance connectors are used to describe relationships between descriptors. Strong inheritance (black) is the counterpart of composition (inheritance of structural features), and weak inheritance (white) the counterpart of aggregation (inheritance functional features).

Separation of concerns: architecture backbone and anchors details

Using the same set of well accepted and unambiguous logical constructs for both objects and behaviors can greatly enhance the consistency of analysis models as well as their traceability to designs.

Business Analysis & Knowledge Management

As noted above, while business analysts may have to consolidate functional requirements or check the feasibility of non functional ones with enterprise architects, they should take responsibility for conceptual models, and more generally for enterprise knowledge architecture. Taking a leaf from Davis, Shrobe, and Szolovits, that will cover:

  1. Surrogates: description of symbolic counterparts (aka) of actual objects, events and relationships.
  2. Ontological commitments: statements about the categories of things that may exist in the domain under consideration.
  3. Fragmentary theory of intelligent reasoning: model of what the things can do or can be done with.
  4. Medium for efficient computation: knowledge understandable by computers.
  5. Medium for human expression: communication between specific domain experts on one hand, generic knowledge managers on the other hand.

Putting apart users interfaces (point 5), two typical approaches can be considered:

  • Domain Driven Design (DDD), which deals with domains representation and computation from a system perspective (point 4).
  • Ontologies, which put the focus on knowledge oriented languages independently of computation (points 1-3).

Besides their simplex orientation, both fall short of business analysts needs, the former being too technical, the latter too open-ended. Instead, a conceptual framework should combine bounded domains with a compact and unambiguous knowledge oriented language.

As it happens, mapping the symbolic footprint of business domains and knowledge into systems may be dictated by the generalization of networked environments and digital business flows. Along that reasoning, BAs will have to deal with knowledge from domains as well process perspectives.

With regard to domains, a distinction should be maintained between institutional (external, statutory), business specific (external, agreed), and enterprise specific (internal).

Domains_BOCs

A conceptual approach to domain layers: institutional, business specific (e.g HR management) and enterprise specific (e.g supply, sales).

With regard to processes, knowledge must be understood as the dynamic and multi-faceted outcome of data analytics, production systems, and decision-making. Taking a (revised) leaf of Zachman’s framework, business and operational objectives would be reset as to cross architecture layers instead of being aligned. Using a pentagonal representation of enterprise architecture, Zachman’s sixth column (“Why” ) would be rounded as an outer range.

Knowledge: timely and multi-faceted information put to use

Along that perspective embedding IT systems in business processes is to become a key success factor, which is to bring business intelligence up on the list of business analysts’ concerns.

Business Intelligence

If business intelligence is to take into account the ubiquity of digitized business processes and the integration of enterprises with their environments, a seamless integration of data analytics and decision-making is to be a primary concern for BAs.

Data analytics (sometimes known as data mining) is best understood as a refining activity whose purpose is to process raw data into meaningful information:

  • Data understanding gives form and semantics to raw material.
  • Business understanding charts business contexts and concerns in terms of objects and processes descriptions.
  • Modeling consolidates data and business understanding into descriptive, predictive, or operational models.
  • Evaluation assesses and improves accuracy and effectiveness with regard to objectives and decision-making.

Decision-making processes in open and digitized environment are best described with the well established OODA (Observation, Orientation, Decision, Action) loop:

  1. Observation: understanding of changes in business environments (aka territories).
  2. Orientation: assessment of the reliability and shelf-life of pertaining information (aka maps) with regard to current positions and operations.
  3. Decision: weighting of options with regard to enterprise capabilities and broader objectives.
  4. Action: carrying out of decisions within the relevant time-frame.

The integration of data analytics and decision-making would be a key benefit of enterprise architecture.

OKBI_BIDM

Seamless integration of data analytics and decision-making.

On a broader perspective data analytics and decision-making can be seen as the front-offices of business intelligence, and  knowledge management as its back-office. That organization can be reinforced with ontologies set with regard to governance and stability of contexts:

  • Institutional: Regulatory authority, steady, changes subject to established procedures.
  • Professional: Agreed upon between parties, steady, changes subject to accords.
  • Corporate: Defined by enterprises, changes subject to internal decision-making.
  • Social: Defined by usage, volatile, continuous and informal changes.
  • Personal: Customary, defined by named individuals (e.g research paper).

Ontologies set along that taxonomy of contexts could also be refined as to be aligned with enterprise architecture layers: enterprise, systems, platforms, e.g:

Ontologies, capabilities (Who,What,How, Where, When), and architectures (enterprise, systems, platforms).

Crossing business taxonomies with enterprise architecture capabilities could significantly improve the integration of business processes and supporting systems.

Governance: Metrics, Quality, & Risks

As gate-keepers, business analysts have to rank projects with regard to business value, risks, and return on investment. Assuming that business value is set independently of supporting systems, projects’ assessment and ranking should be set according to the nature of problems:

  • Intrinsic business size and complexity: requirements can be estimated from individuals (objects and activities), features, relationships, and partitions.
  • Supporting systems functionalities: intrinsic business metrics are to be combined with what is expected from supporting systems: processes and transactions, triggering events, users and devices interfaces, etc.
  • Business and functional measurements can then be weighted by non-functional (aka Quality of Service) requirements.

Assessment should be aligned with problems: business, supporting systems, operations.

If returns on investment (ROI) and risks are to be assessed consistently and decision-making carried out accordingly, value, costs, quality, and hazards have to be set within the same framework, in particular for quality and risks management:

  • Business environment: risks are external and quality is to check for timely and relevant analysis models.
  • Engineering:  risks are internal and quality is to focus on processes maturity.
  • Technologies: risks are external and quality is to address versatility, plasticity, and effectiveness of solutions.

To conclude, whereas business risks remain the primary concern of business analysts, the fusion of business and systems processes means that they can no longer ignore engineering pitfalls and the importance of quality for risks management.

Further Reading

On The Holistic Nature of MBSE

October 1, 2017

Preamble

Interestingly, variants of MBSE/MDSE acronyms put the focus on the duality of the concept, software on one side, systems on the other.

MBSE is by nature a two-faced endeavor (Sand Painting Navajo Rug)

As that duality operates for models, systems, and organizations, MBSE offers a holistic view on enterprise architecture.

Models and Software

Models are symbolic representations of actual contexts in line with specific purposes: requirements analysis, simulation, software design, etc. Software is a subset of models characterized by target (computer code) and language (executable instructions). Based on that understanding, MBSE should not be limited to DSLs silos and code generation but employed to bring together and manage the whole range of concerns and artifacts.

Systems and Applications

The hapless track record of Waterfall and the parallel ascent of Agile have clouded the grounds for phased development processes. But whereas agile schemes are the default option when applications can be developed independently, external dependencies prevent their scaling up to system level. That’s when system engineering takes precedence on applications development, with MBSE introduced to manage shared models and support collaboration between teams.

Organization and Projects

As epitomized by agile development models, projects can be driven by specific business needs or shared architecture capabilities. Whereas the former are best carried out iteratively by autonomous teams sharing skills and responsibility, the latter entail collaboration between organizational units along time. MBSE provides the link between standalone projects, phased processes, and enterprise organization.

MBSE provides a holistic view of organisations and systems.

By providing a holistic view of changes in organizations, systems, and software, MBSE should be a key component of enterprise architecture.

Further Reading

 

EA’s Merry-go-round

June 14, 2017

Preamble

All too often Enterprise Architecture (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 architectures are 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

Views, Models, & Architectures

May 27, 2017

Preamble

Views can take different meanings, from windows opening on specific data contexts (e.g DB relational theory), to assortments of diagrams dedicated to particular concerns (e.g UML).

Fortunato Depero tunnels

Deconstructing the Universe along Contexts and Concerns (Depero Fortunato)

Models for their part have also been understood as views, on DB contents as well as systems’ architecture and components, the difference being on the focus put on engineering. Due to their association with phased processes, models has been relegated to a back-burner by agile approaches; yet it may resurface in terms of granularity with model-based engineering frameworks.

Views & Architectures

As far as systems engineering is concerned, understandings of views usually refer to Philippe Kruchten’s “4+1” View Model of Software Architecture” :

  • Logical view: design of software artifacts.
  • Process view: captures the concurrency and synchronization aspects.
  • Physical view: describes the mapping(s) of software artifacts onto hardware.
  • Development view: describes the static organization of software artifacts in development environments.

A fifth is added for use cases describing the interactions between systems and business environments.

Whereas these views have been originally defined with regard to UML diagrams, they may stand on their own meanings and merits, and be assessed or amended as such.

Apart from labeling differences, there isn’t much to argue about use cases (for requirements), process (for operations), and physical (for deployment) views; each can be directly associated to well identified parts of systems engineering that are to be carried out independently of organizations, architectures or methods.

Logical and development views raise more questions because they imply a distinction between design and implementation. That implicit assumption induces two kinds of limitations:

  • They introduce a strong bias toward phased approaches, in contrast to agile development models that combine requirements, development and acceptance into iterations.
  • They classify development processes with regard to predefined activities, overlooking a more critical taxonomy based on objectives, architectures and life-cycles: user driven and short-term (applications ) vs data-based and long-term (business functions).

These flaws can be corrected if logical and development views are redefined respectively as functional and application views, the former targeting business objects and functions, the latter business logic and users’ interfaces.

Architecture based views

Architecture based views

That make views congruent with architecture levels and consequently with engineering workshops. More importantly, since workshops make possible the alignment of products with work units, they are a much better fit to model-based engineering and a shift from procedural to declarative paradigm.

Model-based Systems Engineering & Granularity

At least in theory, model-based systems engineering (MBSE) should free developers from one-fits-all procedural schemes and support iterative as well as declarative approaches. In practice that would require matching tasks with outcomes, which could be done if responsibilities on the former can be aligned with models granularity of the latter.

With coarse-grained phased schemes like MDA’s CIM/PIM/PSM (a), dependencies between tasks would have to be managed with regard to a significantly finer artifacts’ granularity.

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

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

For agile schemes, assuming conditions on shared ownership and continuous deliveries are met, projects would put locks on “models” at both ends (users’ stories and deliveries) of development cycles (b), with backlogs items defining engineering granularity.

Backlogs mechanism can be used to manage customized granularity and hierarchical dependencies across model layers

From the enterprise perspective it would be possible to unify the management of changes in architectures across layers and responsibilities: business concepts and organization, functional architecture, and systems capabilities:

EAGovern_EA

Functional architecture as symbolic bridge between business needs and system capabilities.

From the engineering perspective it would be possible to unify the management of changes in artifacts at the appropriate level of granularity: static and explicit using milestones (phased), dynamic and implicit using backlogs (agile).

Fine grained model based frameworks could support phased as well as agile development solutions

Such a declarative repository would greatly enhance exchanges and integration across projects  and help to align heterogeneous processes independently of the methodologies used.

Further Reading

External Links

Beans must be Counted, one way And the other

May 2, 2017

Preamble

Conversations across software engineering forums sometimes reveal unexpected views, as it’s the case for the benefits of accountability.

Counting Paper Beans (Pieter Brueghel the Younger)

One would assume that competition would impel enterprises to scrutiny with regard to resources employed and product outcomes, pushing for the assessment of internal activities based on some agreed metrics. And yet, now and again, software development is viewed as a boutique occupation, if not an art pursuit, carried out by creative craftsmen for enlightened if demanding patrons; a vocation too distinctive to be gauged by common yardsticks.

Difficulties of Oversight

Setting apart creative delusions, the assessment of software development is effectively confronted with rational as well as practical obstacles.

To begin with rationality, and unlike traditional products, there is no market pricing mechanism that could match software development costs with customers’ value. As a consequence business stakeholders and systems engineers prefer to play safe and keep their respective assessments on the opposed banks of the customer/provider divide.

As for the practicality of assessments, the choice is between idiosyncratic approaches (e.g users’ points) and reasoned ones (essentially function points). The former ones being by nature specific and subject to changes in business opportunities, whereas the latter ones are being plagued by implementation plights that make them both costly and unreliable.

Yet, the diluting of IT systems in business environments is making that conundrum irrelevant: the fusing of business processes and supporting software is blanketing the discontinuities between business value and development costs.

Perils of Oversight

Given the digital integration between systems and business environments and the part played by software in production, marketing and operations, enterprises can no longer ignore the economics of software development.

As far as enterprises are concerned, economics use prices for two key purposes, external and internal.

With regard to their business environment, enterprises need metrics to price the resources they could buy and the products they could sell; their competitive edge fully depends on the thoroughness and accuracy of both.

With regard to their internal governance, enterprises need metrics to gauge the efficiency of their factors and the maturity of their processes, and allocate resources accordingly. That internal assessment is the basis of their versatility and plasticity:

  • Confronted to continuous, frequent, and often abrupt changes in business environments, enterprise must be able to adapt their activities without having to change its architectures. That cannot be achieved without timely and accurate assessments of the way their resources are put to use.
  • Conversely, enterprises may have to change their architectures without affecting their performances; that cannot be achieved without a comprehensive and accurate assessments of alternative options, organizational as well as technical.

To summarize, the spread and intricacy of software footprint over both sides of the crumbling fences between enterprise systems and business environments makes software economics a necessary component of enterprises governance, so a tally of software beans should not be an option.

Further Reading

Deep Blind Testing

March 21, 2017

Preamble

Tests are meant to ensure that nothing will go amiss. Assuming that expected hazards can be duly dealt with beforehand, the challenge is to guard against unexpected ones.

Unexpected Outcome (Ariel Schlesinger)

That would require the scripting of every possible outcomes in an unlimited range of unknown circumstances, and that’s where Deep Learning may help.

What to Look For

As Donald Rumsfeld once famously said, there are things that we know we don’t know, and things we don’t know we don’t know; hence the need of setting things apart depending on what can be known and how, and build the scripts accordingly:

  • Business requirements: tests can be designed with respect to explicit specifications; yet some room should also be left for changes in business circumstances.
  • Functional requirements: assuming business requirements are satisfied, the part played by supporting systems can be comprehensively tested with respect to well-defined boundaries and operations.
  • Quality of service: assuming business and functional requirements are satisfied, tests will have to check how human interfaces and resources are to cope with users behaviors and expectations which, by nature, cannot be fully anticipated.
  • Technical requirements: assuming business and functional requirements are satisfied as well as users’ expectations for service, deployment, maintenance, and operations are to be tested with regard to feasibility and costs.

Automated testing has to take into account these differences between scope and nature, from bounded and defined specifications to boundless, fuzzy and changing circumstances.

Automated Software Testing

Automated software testing encompasses two basic components: first the design of test cases (events, operations, and circumstances), then their scripted execution. Leading frameworks already integrate most of the latter together with the parts of the former targeting technical aspects like graphical user interfaces or system APIs. Artificial intelligence (AI) and machine learning (ML) have also been tried for automated test generation, yet with a scope limited by dependency on explicit knowledge, and consequently by the need of some “manual” teaching. That hurdle may be overcame by the deep learning ability to get direct (aka automated) access to implicit knowledge.

Reconnaissance: Known Knowns

Systems are designed artifacts, with the corollary that their components are fully defined and their behavior predictable. The design of technical test cases can therefore be derived from what is known of software and systems architectures, the former for test units, the latter for integration and acceptance tests. Deep learning could then mine recorded log-files in order to identify critical cases’ events and circumstances.

Exploration: Known Unknowns

Assuming that applications must be tested for use during their expected shelf life, some uncertainty has to be factored in for future business circumstances. Yet, assuming applications are designed to meet specific business objectives, such hypothetical circumstances should remain within known boundaries. In that context deep learning could be applied to exploration as well as policies:

  • Compared to technical test cases that can rely on the content of systems log-files, business and functional ones have to look outside and mine raw data from business environments.
  • In return, the relevancy of observations can be assessed with regard to business objectives, improved, and feed the policy module in charge of defining test cases.

Blind Errands: Unknown Unknowns

Even with functional and technical capabilities well-tested and secured, quality of service may remain contingent on human quirks: instinctive or erratic behaviors that could thwart the best designed handrails. On one hand, and due to their very nature, such hazards are not to be easily forestalled by reasoned test cases; but on the other hand they don’t take place in a void but within known functional circumstances. Given that porosity of functional and cognitive layers, the validity of functional test cases may be compromised by unfathomable cognitive associations, and that could open the door to unmanageable regression. Enter deep learning and its ability to extract knowledge from insignificance.

Compared to business and functional test cases, hazards are not directly related to business activities. As a consequence, the learning process cannot be guided by business and functional test cases but has to chart unpredictable human behaviors. As it happens, that kind of learning combining random simulation with automated reinforcement is what makes the specificity of deep learning.

From Non-regression to Self-improvement

As a conclusion, if non-regression is to be the cornerstone of quality management, test cases are to be set along clear swim-lanes: business logic (independently of systems), supporting systems functionalities (for shared applications), users interfaces (for non shared interactions). Then, since test cases are also run across swim-lanes, it opens the door to feedback, e.g unit test cases reassessed directly from business rules independently of systems functionalities, or functional test cases reassessed from users’ behaviors.

Considering that well-defined objectives, sound feedback mechanisms, and the availability of massive data from systems logs (internal) and business environment (external) are the main pillars of deep learning technologies, their combination in integrated frameworks could result in a qualitative leap toward self-improving automated test cases.

Further Reading

 

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