business architecture: How is this different than conceptual architecture?_问答_开发者

I am hearing a lot about business archite开发者_JAVA百科cture, wondering how is this different than conceptual architecture? Many thanks in advance.

All concepts in the software architectural and EA world are generally difficult to pin down, these answers are per Wikipedia and my own understanding, but your mileage may vary.

The term "Business Architecture" does not apply to software. It's a more holistic view of the business, and includes business processes, governance, and information. An Enterprise Architect at a company may be responsible for this, and some of the processes described in it may be software artifacts or be supported by software systems, but in general it is a higher level business-focused view. The Business Architecture would be used by executives at a company to help them make high-level decisions and plans related to their company's systemic operations.

The term "Conceptual Architecture" (in software terms) refers to the logical and other higher level architectural views of a software system. This would be the type of architectural documentation you would find in a software architecture document. The "Conceptual Architecture" should be high-level enough to be understandable by non-technical audiences.

Business Architecture is part of an Enterprise Architecture. Technical Architecture encompasses Infrastructure and Applications domains. But they are all part of the whole "thing." A Business Architecture describes the people, processes/methods and standards/techniques that define and guide the business in whatever it does (without specific reference to "technologies" that ostensibly provide productivity enhancements). There are business criteria, measures and metrics that can be used to make business decisions about what to do, when to do it, and at what cost. Much of this could possibly (and maybe should at times) be performed without automated support (pen/paper, thought/reason, face to face discussion).

Automation (technical infrastructure, systems/applications/databases)--if I could so sweepingly refer to "IT," ideally supports the business. But how can you tell if and how well without a Technical Architecture and a way to show how it maps to needed business capabilities (described by the business architecture)? The mapping is done through a Conceptual Architecture "layer" between the Business and Technical Architectures.

A Conceptual Architecture boils the Business Architecture (ever how much of it exists--plans, process flows, org charts, activity descriptions, regulations, penalties, etc) to a set of essential business strategies and information requirements, principles, constraints, and assumptions that can be compared to technical architecture/IT initiatives (portfolio/apps) and operational requirements, principles, constraints, and assumptions. It is essentially a set of concepts that link what the business should be doing with what IT should be doing. Above the Conceptual Architecture is the "business." Likewise, "below" it, in IT, the Conceptual Architecture must reflect truth as IT sees it. Yes, it is a politically sensitive thing!

Conceptual Architecture allows planners to advise IT leadership of most useful efforts to the business. It can be very useful for complex modernizations with many moving parts--at least to prioritize and identify quick wins. From the business POV, It can also provide assessments of automated support when contemplating business changes. However, architects must carefully coordinate its message with IT leadership to minimize misinterpretations.

An architecture can be thought of as consistent related set of abstractions. There are different sets in a design. One set describes the business context. Another might describe the data context.

Object-oriented design often falls apart when people aren't careful to avoid confusing abstraction sets. (See "high cohesion/low coupling".) Because they aren't isolated; your code will reflect aspects of each.