|
Diagram
|
|
|
|
|
Title
|
|
|
Abstraction Layers
|
|
Building Architecture
|
|
|
Architecture involves 3 abstraction layers - theory, design and construction. These abstract layers of thinking can be applied to almost any discipline, including business management. In the day to day situations faced by managers, this could be applied to viewing problems beyond the events, to find solutions that address problems more likely associated with patterns and structures. In team building and organisational structures, we refer to layers of values, principles and practices rather than a set of standards and procedures. It does not matter how one views or identifies these abstraction layers as they will differ in application. What is essential is that we think beyond the simplified parts that we use to deal with complexity.
|
|
Architecture Intensive Disciplines
|
|
|
In order to think in terms of “wholes” rather than “parts”, we would have to think in terms of abstraction “layers” rather than “compositions”. If we were to view the “bigger” picture” we would have to “step back”. In the case of abstraction layers, we would have to “step out” of a layer of abstraction. For instance, we could spend much of our time in technically diagramming “physical” software components and lose sight of their functional and aesthectic relevance to the end user or client. To gain a broader perspective we would have to step out into the “logical” and “conceptual” layers. In turn, if we never ventured deeper than the “conceptual” layer, we could be sacrificing structural integrity for user aesthetics and feature-rich functions.
|
|
Case Study A: Large Corporate IT
|
|
|
|
|
|
One of the central part of the systems architecture built in this environment was a database repository which stored artifacts and meta data on 3 layers of abstraction - conceptual analysis, logical design and physical construction components. The repository catered for both Upper CASE (Computer Aided Software Engineering) and Lower CASE in that it provided artifacts for web based UML diagrams and could forward or reverse engineer classes and database scripts (and any other source code file or documentation). These tools were built in-house. The central concept underlying this approach was artifact gathering based on the above pattern. Although, artifacts are a form of abstraction and attacking complexity through a break down of parts, the association across layers of abstraction helped to facilitate views of wholes. You could map a glossary of terms and analysis documents to physical software dependencies.
|
|
Case Study B: Small Commercial Team
|
|
|
|
|
|
The approach taken here was through the values, principles and practices of Extreme Programming. There was a greater emphasis on human values and interaction. Instead of artifact gathering and visual modeling, stories and metaphors were used. We took a view of communicating openly and trying to convey the larger picture at all times.
|
|
|
