engineering notions
|
engineering notions |
|
| Veryard Project Papers | Three Levels of Analysis |
Once: a fixed solution, captured as a stable lump of software.
Increasingly: a dynamically reconfigurable set of information and communication services.
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.
| Veryard Project Papers | Karl Weick on Bricolage |
| Veryard Project Papers | Design Page |
| 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.
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. |
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.
| PAST | Legacy as an artefact, the product of a past development process/project. Or perhaps the product of a sequence of maintenance actions on such an artefact. |
| PRESENT | Legacy as a system-in-use. In the users' hands, the system moves away from the development intentions. The users often find ways to do things that were not anticipated by the developers, or even that the developers specifically sought to prevent. |
| FUTURE | Legacy as an asset with ongoing value, with the potential to survive and evolve, relative to emerging intentions. |
(For OO fans, of course, inheritance is a Good Thing, while legacy is a Bad Thing. Got that?)
| Veryard Project Papers | Legacy: Asset or Liability? |
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 |
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.
May be positive or negative, and may apply across multiple domains.
| Veryard Project Papers | Pattern catalogue: Business, Distributed Systems, Managed Change |
| Other Resources | Books on Patterns |
| Veryard Project Papers | Requirements |
| Internet Links | BCS Requirements Engineering SIG |
| top |  |
|
Copyright © 1999-2003 Veryard Projects Ltd http://www.veryard.com/sebpc/engnotions.htm |
