Business Architecture?

My past experience has included stints as an 'Architect', rather than 'Analyst', and one of those titles was truly involved in Architecture, with a focus on Models and the Zachman Framework.

That was a few years ago, but I was recently asked for my views on what "Business Architecture" is, and here is what I wrote:

Three key aspects of Architecture:
1) It is not an end in itself; Architecture exists because things need to be built.
2) Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.
3) Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

The most common and oldest form of architecture is construction of buildings: dwellings, work-places, etc.. The need for Architecture arose centuries ago when construction failed or the end result collapsed. All of the above three aspects are inherent in this field: the known and desired end product, defining and integrating all components needed, and the layering: from a high-level floor plan, to blueprints, to wiring diagrams and other detailed specifications.

A Business, any Business, has the same need for Architecture, and presents further challenges than constructing a building. Buildings are complicated, being made up of many pieces that have to fit together, but they are finite; you can count and describe all the pieces which will be in place when the building is complete. A Business, and really Enterprises of any kind, are complex, meaning that they change over time; pieces may be re-arranged to fit together in a different way (e.g. org chart re-organizations or process improvements), and some pieces may be revamped or enhanced (like Information Systems), while other pieces are retired/discarded and new pieces added to the Enterprise (like Equipment).

In the end, the most commonly identified pieces of an Enterprise are its resources (people, capital, raw material) and the systems/processes that use the resources to produce an end product or service. Enterprises use many different kinds of systems in their operations, many of which are highly cohesive and de-coupled (their relationships to other pieces are few and well-defined), e.g. different assembly lines of a manufacturing company.

On the other hand, Information Systems used by an Enterprise in support of its operations increasingly need to be aware of the full scope of the Business, across all resources and processes. This presents its own Architectural requirements, such that a complete, all-encompassing Enterprise Architecture for Information Systems is needed, if systems and technologies (the “pieces” of the Information Systems) are to built/acquired, deployed and used effectively, without the redundancy, duplication and inconsistency of information systems delivered in the past.

Architecture within a discipline comes to depend on common practices and standards over time to increase efficiency and eliminate unnecessary re-invention; it is commonly stated that Information Systems delivery as a discipline is still too young to have developed such commonality, but work has begun, notably by John Zachman and his and his Enterprise Architecture Framework of the late 1980’s.

See http://www.zifa.com/ .

Here are your Resources (the columns) and your layered views (the rows) that will take a Business from its highest-level context through to functioning Information Systems.

They key row to me is Row 2, the Business Model. Row 1 provides, as its says context/scope. It is very important to understand the scope/boundary of the Enterprise for which the architecture is being created, especially when large Businesses define themselves as being constituted of multiple ‘Enterprises’. Once that is defined, which should not take very long, the critical development of the Row 2 Business Models can proceed; these must accurately represent the in-scope enterprise/business at a detail level, otherwise the remaining lower rows (where most of the money is spent) will not lead to building the right Information Systems for the Business.

Finally, Zachman always states that he has defined a Framework, not a methodology to populate the cells, or define what types of models should be used. Given the framework, different methods/models can be used for creating (and communicating!) an Enterprise Architecture for a Business, often with a focus on accelerated or prioritized delivery; most owe some debt to the original Information Engineering developed by Finklestein in the 70’s and popularized by Martin in the 80’s. The key point here (and the last one in this dissertation) is that it does not matter which methodology you use, as long as you pick one and use it for all it is worth, both to create systems, and as a language common to all participants in the Systems Delivery Process (SDP).