Business Architecture and Related Domains

The following post is an extract from my draft eBook Business Architecture Viewpoints, available from @Leanpub

---

There are some things I don't regard as part of the Business Architecture but as part of some other domain.

One reason for these exclusions is that am trying to avoid scope-creep - putting everything into the Business Architecture that has (or should have) a good link to business. I regard it as the task of Enterprise Architecture to coordinate between Business Architecture, Solution Architecture, Technology Architecture and whatever other domains the enterprise might need.

Which is why I am reluctant to add a Technology View to the Business Architecture. I am also unwilling to extend the Motivation View to include business case, because I regard the business case (despite its name) as belonging to the Solution Architecture. Documents are also part of the Solution Architecture.

Solution Architecture

Key Elements: Business Case (for Solution), Solution, System (including both Sociotechnical System and Software Application), Transformation, Use Case, Workflow.

Note that the Solution domain covers the whole sociotechnical solution space, not just the software application.

Note also that some frameworks (notably RM-ODP) define an enterprise viewpoint covering the purpose, scope and policies of a system. Because of the specific reference to a system, I do not regard the RM-ODP notion of enterprise viewpoint as equivalent to Business Architecture. It could be understood either as a business-oriented viewpoint within the Solution Architecture or as a mapping between the Business Architecture and the Solution Architecture.

Technology Architecture

Key Elements: Business Case (for Infrastructure or Product or Technology), Technical Commodity/Service, Technical Device/Mechanism

Within the Technology Architecture, there is a clear distinction between the abstract technology (for example "middleware", "SOA") and a specific technical product or platform (for example "IBM Websphere"). There is also a distinction between the technology-as-built and the technology-in-use.

Development Architecture

Key Elements: Project, Requirement, Development Lifecycle

Tom Mochal defines development architecture in a broad sense to include three major areas:

* The development life cycle and processes used to build business applications
   
* The application models that show the appropriate technical design that will best fit the business requirements

* The inventory and categorization of the business applications that exist within the organization today.

Physical Architecture / Environment

Key Elements: Building, Location, Equipment

Many IT people use such terms as Physical Architecture or Environment to refer to computer hardware. But I'm using the term to refer to all aspects of the physical environment, such as office buildings and physical equipment.

Where does Location belong? Traditionally this is regarded as part of the Business Architecture, but I believe it belongs somewhere else, along with buildings and working space and the kind of architecture associated with Le Corbusier and Frank Lloyd Wright. Ideally I'd want to call this the Physical Architecture, which would include a Geographical View or what Stewart Brand calls Site. I'd also include something I call Consilience.

Of course, location doesn't disappear in a global organization, but it doesn't dominate business processes in the way it once did, and is often merely a cost factor or speed factor. It is not geographical distance that matters any more, but abstract notions of distance, including commercial, semantic and cultural distance.