Talking about EA - Architecture vs. Engineering

I have the feeling that we need to be very clear in our thinking and definitions when talking about Enterprise Architecture, or we run the risk of confusing levels and overlooking important issues that will reduce our effectiveness in moving forward.

One distinction I think is important to make is the difference between Architecture and
Engineering.

Architecture takes a holistic view of the organisation and tries to work out what kind of support (procedural, structural, technological) this organisation needs to be able to realise its vision, goals and strategies (i.e. its desired future state). Engineering, on the other hand, takes specific problems and solves those within the strict boundaries of the problem definition and requirement specifications, without having to look at the larger context in which these problems occur.

The focus of engineering is on improving the parts, whereas architecture focuses on developing the whole.

This may sound trivial, but when this distinction is lost when planning Enterprise Architecture initiatives there is a tendency to skip the important step of actually designing a new and better architecture (i.e. an architecture that supports and enables the organisation to realise its desired future state) and instead dive straight into optimising what is already there, without a clear understanding of how much that will actually support the future organisation.
Doing this brings the risk of getting priorities wrong and tackling things in the wrong order, or worse, tackling things that are not actually relevant in the bigger picture. The worst risk, however, lies in developing constructs and solutions that are contrary to the direction the business needs to go to reach its goals.

When architecture and engineering are in balance, architecture provides the roadmap, frameworks and guidelines, while the engineers provide the best possible way to build the roads that architecture specifies.

One of the remarks made during the discussion about producing results soon enough to satisfy the expectations of the organisation was that it is not necessary to wait for the high-level architecture to be complete but that "we can start in the middle" - meaning we can optimise and fix things without waiting for the architects - that way we can produce 'quick wins' and buy time (and support) to do the more strategic work.
This may well be possible and there may be cases in which a solid business reason can be given to go ahead. But this is not architecture, it is engineering: a strictly local optimisation without the strategic context to determine the longer-term impact and relevance.

This means that extreme caution should be taken when approving such optimisations and at least the following conditions must be met:
- the ROI must be demonstrated over a relatively short time span;
- the effort required must be small;
- the impact must be localised; and
- the optimisation must be removable.

After all, without the strategic context that architecture provides there is a very real chance that the effort will turn out to be misaligned with the future needs of the organisation. This can be compared to the various efforts to improve tank designs in WWII without (yet) understanding the changed strategic imperatives of modern warfare and the different terrains the tanks were to be deployed in. Some of those improvements seemed great in isolation (e.g. using a lighter, more maneuverable gun) but failed dramatically in actual battle situations (when faced with heavily armoured opponents).