Been following a very flouncy thread on *structure smells* in an EA, and the guy starting the thread couldn’t define sufficiently well the starting point for what he meant by *enterprise* and *application* architectures. Here is the [TOGAF](http://www.opengroup.org/togaf/) definition, which most sane people would accept, along with some examples of the other stuff that was coming out, for …. comparative value.##TOGAF:
There are four architecture domains that are commonly accepted as subsets of
an overall enterprise architecture, all of which TOGAF is designed to support:
* The Business Architecture defines the business strategy, governance,
organization, and key business processes.
* The Data Architecture describes the structure of an organization’s logical and
physical data assets and data management resources.
* The Application Architecture provides a blueprint for the individual application
systems to be deployed, their interactions, and their relationships to the core
business processes of the organization.
* The Technology Architecture describes the logical software and hardware
capabilities that are required to support the deployment of business, data, and
application services. This includes IT infrastructure, middleware, networks,
communications, processing, standards, etc.
Seems pretty straightforward, yes? Here is one stab from the thread at defining some of the above:
>Enterprise Architecture – this defines the architectural characteristics of an organization’s overall technical infrastructure. It would be the basis of a SOA implementation, hiding implementation details for accessing legacy systems, external services, and shared technical assets such as rules engines and data warehouse facilities. From the point of view of any given application in the environment, this looks like a set of APIs and/or service requests. Ideally, we want most of the “-ilities” to be baked into the enterprise architecture, so that individual applications don’t have to reinvent those wheels and so that we can support multiple SLA levels for business units that have different requirements.
>Application Architecture or Solution Architecture – this defines the overall structure of an application at a higher level of abstraction that we typically mean when we talk about “software design.” The same basic software design principles apply, but at larger scope. The key thing is the notion of high cohesion and low coupling. Components, tiers, and layers have to have well-defined roles and exhibit the quality of cohesion, while being loosely coupled to one another. There are some useful rules of thumb that help us with this, and I think that’s part of the pattern-based model Marvin is working on.
>Software Design – this is the application of sound design principles at a lower level of detail than application architecture. In an object-oriented system, it would include ideas like the SOLID principles. In a system based on functional programming, it would include ideas like pure functions (within practical limits) and so forth. We’re still mainly looking at cohesion vs. coupling; most of the other stuff that’s been published about software design really boils down to that in the end, anyway.
which was followed with this:
>* Infrastructure Topology (Application Architecture agnostic)
* Application Architecture (Use-Case Agnostic structuring [or organizing] of the code-base specifically to enable unknown or unknowable future use cases)
* Software Design (Use-Case Dependent)
* Code Implementation (Language Dependent)
In the ‘real-world’ the precise definition for each grouping can vary… what would be helpful is if we had a shared understanding of the coupling or relationship or role of each layer of the technology stack.
This, it was claimed, was less than clear, so the [following](http://www.linkedin.com/redirect?url=http%3A%2F%2Fpatternenabled%2Ecom%2F%3Fpage_id%3D450&urlhash=q6Tg&_t=tracking_disc) was offered:
>* Reactive: Code Implementation establishes the (reactive) unit tests that reflect known use cases with scope boundaries for ‘just enough’ functionality.
* Reactive: Software Design emergently (or reactively) eliminates duplicate code to promote ‘global readability’ for known use cases.
* Proactive: Application Architecture structures (proactively) the code for “unknown or unknowable” future use case.
* Proactive: Infrastructure Topology satisfies current enterprise compute needs while establishing a (proactive) migration path toward greater future agility.
1. Code Implementation – Can be considered language semantics.
2. Software Design – Can be considered interaction (contract) between objects.
3. Application Architecture – Can be considered the packaging and archival structure that formulates dependency groupings.
4. W. Edwards Deming – “The most important things are unknown or unknowable.”
5. Infrastructure Topology – Can be considered the enterprise hardware devices and accompanying device software.
No, I am not making this stuff up. I am still amazed at the number of IT professionals working with architecture in one form or another who are not aware of TOGAF.