veryard projects - innovation for demanding change

engineering notions

notion finder
home page contact us
notion finderother notions
systems engineering for business process change
system notions
engineering roles
on this page

[analysis] [application] [architecture] [bricolage] [design] [enterprise architecture] [failure] [legacy] [maintenance] [model, modelling] [pattern] [requirements]



see also Design, Modelling

An attempt to understand the underlying structure or process or causality of an existing situation or artefact, or of a projected intention or demand.
Veryard Project Papers Three Levels of Analysis


see also Legacy, System

Literally: the process of applying technology to support the business.

Once: a fixed solution, captured as a stable lump of software.

Increasingly: a dynamically reconfigurable set of information and communication services.


see also Data, Technology

Much time is spent at conferences discussing such questions as: What is an architecture? Academics and would-be industry gurus trade rival definitions, in terms of the composition of an architecture from other (also ill-defined) terms, or in terms of the distinction between an architecture and something else.

Sometimes this is displaced - architecture is what architects do. This leads to discussions about what differentiates an architect from other people, or from ordinary engineers.

What interests me much more is the process of architecting. There are people who are playing an architecting role, and it is not important whether they call themselves architects. What is important is what they do when they are architecting, how they do it, with whom and for what purpose. From time to time, this process produces things, which we may call architectures (for want of a better word), but this is of secondary interest only.


A form of improvisation practised by some engineers, using whatever resources and repertoire come to hand, in order to perform the immediate task. A person who practises bricolage is called a bricoleur.
Veryard Project Papers Karl Weick on Bricolage

Mary Catherine Bateson on Improvisation


Design is an attempt to create a structured solution to a given problem or requirement, that achieves a reasonable balance (trade-off) between conflicting demands.
Veryard Project Papers Design Page

Design Pitfalls as Negative Patterns

Designing Software Components (pdf)

Enterprise Architecture

A What the term enterprise architecture MEANS is the way that the enterprise is structured (or articulated) - independently of IT.
B What the term enterprise architecture usually REFERS TO is the way that IT people IMAGINE that the enterprise is structured or articulated.

Obviously IT people cannot recognize any difference between A and B.  There are "holes" in the IT version, which cause deep and radical problems for both sides.

IT people often fall into the trap of thinking that they can see the whole enterprise from an IT perspective.  They then believe that there is (or should be) an exact one-to-one mapping between the structure of the enterprise and the structure of the information and systems supporting the enterprise.  They construct IT models of the enterprise, which they call ARCHITECTURES, as a base for planning future IT systems.

I believe it is POSSIBLE - even sometimes NECESSARY - to think architecturally about business.  (This is what I'm trying to do in my work on the component-based business.) IT people often imagine that they are the best equipped to do this.


A failure is a mismatch between an intention and a perceived outcome. Both the intentions and the perceptions of the outcome are subjective.

Explanations of failure often explore the causes of failure in great detail, without addressing the more fundamental question: was this indeed a failure at all, and for whom?

Veryard Project Papers Notes on Failure Includes a review of book by Petroski.

Six Sigma

Crisis Management


Implementation literally means finishing the job. For computer programmers, therefore, it means coding - building a lump of software that satisfies a specification. This is an exercise in software engineering.

But when the programmer's job ends, someone else's job begins - the installation and operation of a software system to achieve some business goals. This is an exercise in technology change management.


There are three ways of understanding legacy systems.  
Veryard Project Papers Legacy: Asset or Liability?

Reusing Legacy: Models, Data and Systems (pdf)

Component-Based Development for Y2K and Euro


If you think of development as building some artefact, then it may be natural to think of maintenance as building a new version of an artefact.  This means that maintenance is like development, but with some additional complications - such as reverse engineering, reengineering and transition.  Then a maintenance method is merely a somewhat complicated version of a standard development method. That's exactly how many formal software processes and methods regard maintenance.

From a software engineering perspective, "maintenance" refers to a piece of work that takes an existing software artefact and produces a new version, either to better satisfy the old requirements, or to satisfy some new requirements.  This is not the same thing as producing new artefacts to satisfy new requirements, and demands rather different techniques - although perhaps the same notations.

From a business point of view, the purpose of a software project is to alter the characteristics of some business process. Practically all business processes these days already contain a considerable degree of software automation and electronically mediated communication.  So from a business point of view, practically all software projects are carrying out a maintenance activity on a business system, regardless how many new software artefacts they may generate.  To describe such a project as a development project, or to use a method that is primarily designed for development, implies a restricted view of the project, foregrounding the new software elements and pushing the existing stuff (with which it must interoperate) to the background.

Veryard Project Papers Maintenance: The New Software Paradigm

Model, Modelling

A model is a communication of structure and properties. It usually presents itself as representing something, either in the 'real' world, or in the intentions of people (managers or engineers, planners or designers). Sometimes a model merely represents itself.

A model always has a scope, purpose and perspective. Sometimes these are stated explicitly, often they are implicit or assumed.

Formal models are expressed in a strict modelling language or notation. The vocabulary and grammar of this modelling language may themselves be expressed as a model, which software engineers usually call a metamodel. Such models are used for building support tools, such as diagramming tools and repositories.

For many purposes, informal models are as good as formal models - indeed, sometimes better.


A judgement of some kind typically, but not necessarily a design judgement - partially abstracted from its context.

May be positive or negative, and may apply across multiple domains.

Veryard Project Papers Pattern catalogue: Business, Distributed Systems, Managed Change

How to implement a pattern programme

Design pitfalls as negative patterns

Other Resources Books on Patterns


A requirement is a declaration of intent, demand or desire, by an agent, on behalf of some person or group or company or community. "WE REQUIRE THIS".
Veryard Project Papers Requirements
Internet Links BCS Requirements Engineering SIG



home page

contact us

veryard projects - innovation for demanding change
This page last updated on December 5th, 2003
Copyright © 1999-2003 Veryard Projects Ltd