Examples of Business Architecture Principles

Architecture Principles are a key component of Enterprise Architecture. They essentially help navigate to the Target State from the Current State. They are the guidelines component of Architecture.

Principles can and should exist for each of the Architecture Domains – Business, Data, Application, and Technology (and Security if you want to give the attention it is increasingly deserving).

It is easier to develop – or find and adapt – principles in the Data, Application, and Technology domains. For example, the “Reuse before buy before build” is a well-known Application Architecture principle, and rightly so. It has tremendous impact in terms of application choices, both and Enterprise and Solution Architecture levels. It is a pithy aphorism – arguably, even a cliché – that is very practical and translates to a very practical decision tree.

However, a quick search, does not really throw any good examples of Business Architecture principles. TOGAF does provide a list of “business principles”, that are useful but not in the real practical sense. While some provide and overarching guidance (“Primacy of principles” and “Compliance with Law”) others really do not belong in the business domain (“Common use applications”, which is actually reuse before buy/build).

So, what should good Business Architecture principles do? As we alluded to in the opening statement, they should guide the enterprise and solution architectures move towards (and validate) the desired target state business architecture elements.

And what are these elements? Archimate modelling language offers a good choice of these Business Architecture elements: Channels, Services/Capabilities, Processes and Functions, Roles and Actors, Information, Products. In other words, these are the choices we have to make as part of defining the Target State of Business Architecture and this is where we need guidance from related set of principles that guide the choice.

We could hence develop guiding principles around the various business architecture elements. Some examples are provided below.

Example 1

Business Architecture Element: Business Capability

Related Business Architecture Principle

Statement: We will build core sales and marketing capabilities in house and outsource manufacturing and distribution capabilities.

Rationale: Sales and marketing is our strength, and this is where we can differentiate ourselves in the marketplace.

Implications: Hiring more sales and marketing personnel; outsource supply chain functions to service providers.

Comments: Business capabilities are services that the enterprise offers to its external customers and partners and its internal employees. This principle is talking about which capabilities the enterprise will build in house and which it will outsource (as a business). This is the “buy before build” equivalent in the business domain, comparable to the application services choice in the application domain. This principles also provides guidance on roles/actors element – which remain in house and which are outsourced. Presumably from IT architecture perspective, we will have to spend a lot more effort and focus on sales and marketing capabilities rather than supply chain. How can IT drive competitive advantage in sales and marketing (build most likely) and cost reduction in supply chain (buy before build, and minimal customisation)?

Example 2

Business Architecture Element: Business Process

Related Business Architecture Principle

Statement: Where possible, we will use simplified, standardised, and shared business processes across the enterprise.

Rationale: Ease of doing business for both external and internal partners; reduce duplication and optimise costs.

Implications: Shared service processes for finance, procurement, and IT.

Comments: Business processes realise the delivery of business capabilities.  Business process design is the first step in the capability realisation (including building IT components, where required). The guidance is very clear; if we see two different procurement processes in two different business units, for example, we have a mandate to standardise them unless there is a strong business justification.

Example 3

Business Architecture Element: Business Channels

Related Business Architecture Principle

Statement: We will differentiate ourselves in the market place through exception customer service, delivered anytime, anywhere, and through any device.

Rationale: Retain and grow customers through exceptional customer service.

Implications: Build in-person, over the phone, and digital channels.

Comments: Business channels are the avenues through which the customers access the organisation’s services. This principle though ambitious is very clear in stating what channels need to be built. From IT architecture perspective, building digital channels – web and mobile, including chat – are clear standouts. Perhaps, this principle could do with a bit more clarity on what will be offered through digital channels vs phone-in / in-person, the latter have significant business costs.


As we can see these Business Architecture principles – when defined in collaboration with the business stakeholders – provide practical guidance for IT programs (through Enterprise Architecture) and projects (through Solution Architecture) to deliver the expected business outcomes.

Exploring Architecture Principles – Buy Before Build

One of the two pillars of “doing” Enterprise Architecture is the establishment of a set of architecture principles that guide design of systems in the organisation (the other pillar is understanding the system elements or components and their interplay). However, most organisations struggle to establish a coherent set of principles that are practical for interpretation on IT projects. In this and other blog posts I explore such principles; the one for today is the oft loved (and hated) principle of buying before building.

What is the principle?

The principle, in essence, declares the intent that the organisation in question will attempt to buy IT solutions “off the shelf” before starting to build.

Why is it useful?

At the outset this principle appears to be a “no brainer”. Why would anyone want to build an IT system from scratch when one can “plug and play” so to speak, especially considering the horrendous failure rate of custom development projects? While the strategic intent of this view is commendable, the implementation of this guideline is not so straightforward.

Digging deeper

As one starts to look at the application of this principle, several questions start popping up. Should this be applied in all situations? When might build be a better idea than buy? Gartner’s pace-layered application strategy, for example, can be used to answer this question: it makes obvious sense to build the so-called systems of innovation, buy systems of record (with minimal customisation), and customise an off-the-shelf solution for systems of differentiation.

The other angle to this principle is to explore what additional guidance needs to be applied for the kind of buy or build? For example:


aPaas vs SaaS vs On-Premise

Within aPaas: Multi-tenant vs dedicated instance


Choice of development frameworks / languages / toolsets

Containerised/serverless vs traditional applications

Obviously, the answers for these questions will largely depend on the organisation’s business and IT strategy and the drivers behind these strategies. And it will also depend on other architecture principles such as the appropriate hosting strategy (which cloud?).

A final point to explore in the case of buy-and-customise scenario is how much of customisation to do. For example, if you are customising more than 50% of the product (“bending it out of shape”) then alarm bells should start going off: perhaps the business sponsor had a system of innovation in mind and IT thought they were signing up for a system of record? Or perhaps the choice of SaaS / aPaaS was not a good fit. Also how do you estimate percentage of customisation before the project commences (topic for a future blog post)?

A body, such as the Architecture Review Board – with appropriate representation from business and IT – can deliberate on the specific circumstances of the organisation and arrive at a more practical interpretation of the principle to guide the project or solution in question.