EA and analogies with the built environment

(prompted by erroneous analogies)

EA can be seen to have a parallels with architecture in the built environment. One can examine this analogy from a number of perspectives: functions, roles, frameworks, relationships etc.

Functions

• Property Portfolio Manager - Enterprise Portfolio Manager
• Enterprise Architecture - Town planning
• Solution Architecture - Architecture
• Iterface (UI/SI) Architecture - Interior design and landscaping
• Technical Architecture(s) - Design of: Plumbing, Electrical, HVAC, Structural/Civil engineering, etc.
• Integration Architecture - Roading, Reticulation water/power/telecom, waste/sewerage
• Security Architecture - Security systems
• Developers/systems engineers - Craftsmen, artisans and construction trades - carpenter, brick layer, plumber etc.
• Operations - Facilities management and cleaning
• etc.

Roles

• Community/Town - Enterprise
• Property developer - Business owners (focused on their immediate need/benefits)
• Enterprise Architect - Town planner (focused on the broader interests over time, across all business owners)
• Solution Architect - Architect designs a solution for a business owner
• Interface Architecture - Design within constraints defined by the Architect and their detailed designs create new constraints
• Technical Architecture(s) - Develop detailed design and inform the Architect of new constraints
• Project managers (same role - different focuses) - built environments where the industry is mature and specification clear, focuses on managing plans (costs, time), change and exceptions; ICT focuses on managing scope (which is not well enough defined) and interactions between technologies and disciplines that are immature in themselves (and with respect how they interact with each other (of course they also pretend to manage plans, change, risks etc.)
• etc.

Frameworks
Frameworks that allow the different aspects of the solution to be examined (Cf. Zachman) are co-ordinate systems/map projects and measurement systems (that allow relative placements and replacements and spatial relationships to be understood), established division of work by function (lighting plans, electrical plans, floor plans etc.), etc. Frameworks define processes (Cf. TOGAF) are defined within each trade and by the overall pattern of engagement - briefing, sketch design, bulk and location, premit/approval, working drawings, supervision, as-builts etc. Frameworks which define reference models (Cf. TRMs) are defined in many codes and standards and common reference works e.g. Metric handbook (AJ Metric handbook).

Relationships
These analogies also explain the nature of the relationships e.g.

* conflicts between the immediate needs of the property developer and the broader needs of the community (and the property developers desire to circumvent constraints)
* the technician's/tradesman's views that because they know more about the detail of some technology than the town planner (and architect) the town planner (and architect) don't know what they are talking about and don't add value.
* etc.

Architecture
EA is often compared to building architecture. I think this analogy is weak if not misleading. Even if EA was like building architecture a good architect does not start from scratch. The site (slope, location, views, noise, boundaries, egress, soil/sub-soil, drainage, vegitation etc.), and its services (electrical, roading, water, drainage etc.), then there are all the codes (which codify standards of interconnection, styles/patterns of construction etc. exist). The codes make clear that even an individual building is not built in isolation. Buildings will usually be built to specific support a set of functions, an organisation, sometimes extant furnishing/equipment/plant etc. It is true that sometimes building are built to support generic functions/organisations (but these are more analogous more to OTS SW).

(This analogy could be extended considerably)