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.

Enterprise Architecture is Dead, Long Live Enterprise Architecture!

Okay, at the outset let me admit the title was a clickbait! Now that I have your interest, I will in this article argue that Enterprise Architecture (EA) long from being dead, is just about maturing into a discipline of strategic importance to all organisations, and I hope the best of EA is yet to come!

I first heard about EA way back in 2006 when I attended a couple of workshops including the one on TOGAF. I remember concluding at the end of these explorations that the field appears promising, but its time has not yet come – at least for me. For, I was working in manufacturing industry and the then IT landscape in such organisations had only a few boxes on the diagram (typically an ERP at the middle).  In hindsight, I would argue EA was relevant even if you had a simple landscape (and ERP by no means is simple, being a core system for a manufacturing organisation). The challenge was mainly seen as a technical implementation of a so-called off-the-shelf software, and that there was nothing there to design (and the rest, as they say, is history).

Fast forward 15 years and the number of organisations seeking EAs is growing, and rightly so, with all the complexities arising out multiple clouds, data proliferation, business complexity, and the speed of change in general. And yet there is scepticism in some quarters around the value of EA. Here are I wish to point out that the issue is not EA itself but our understanding of what it means and more importantly where, when, and how it is done, and also who does it. If the terms why, what, where, when, how, and who do not ring a bell, they are the so called “primitives” that the Zachman Framework for EA advocates. And what better way to explain EA than its own framework? So here we go.

What: So what is EA? As explained in my earlier post, EA as it is commonly understood in the IT world, is the alignment of IT strategy with the business strategy and guiding the IT systems development to align with this overall organisational objectives. However, purists like Zachman treat EA as literally architecting the enterprise – the all of it not just the IT part – essentially as a framework for representing and guiding the design of an enterprise.

Why: So why architect when you can build? I think the Why already follows from the What. Who would not want to align their IT strategy and delivery to the overall objectives of the organisation? Everyone has limited resources and the best outcome from IT spend comes from aligning with – and one could argue, leading – the business strategy.

How: This is where the EA rubber hits the road and this is also where it often skids off the road. EA is best done by understanding the constituent elements (business, application, data, technology) and defining principles that guide the evolution of these elements – the focus is on overall benefit of the organisation not just the individual product, project, or solution.

Who: It is tempting to say that the Enterprise Architect architects the enterprise. However, the reality is much more complex. I have seen in my over two decades of work at the coalface of IT projects, that there are varying levels of design and different domain expertise that can contribute to the overall EA objectives. In effect EA is a team effort. Often a full time Enterprise Architect role can bring these differing perspectives together, but at times it is not affordable (or necessary) as long as there is a mechanism equivalent of the Architecture Review Board to guide the design.

When: The short answer is all the time. But there are some critical points in organisational journey when it is most effective. Core systems replacement programmes are the typical territory of EA. So are times when several interdependent projects are in flight with the need to ensure cross-project design alignment. Finally, any major IT project would benefit from (and will benefit the organisation in turn) aligning to EA before, during, and at the end of the project. Special callouts to agile projects that prefer to “design on the fly” that may result in “operation successful, patient dead” outcomes.

Where: EA is a function that typically sits in IT under the sponsorship of the CIO, which makes sense considering that the bulk of EA’s attention is on getting the design right for all the IT programmes. However, in not so distant future I am predicting it will sit under the sponsorship of the CEO as more organisations see the blurring of the distinction between technology and business – particularly in service-based organisations.

What is Enterprise Architecture?

Enterprise Architecture (EA) is often seen as too complex and academic to be of practical use in business settings. Sure, a formal vocabulary is unavoidable when describing a generic framework, but at the core of EA is alignment of IT strategy to the business strategy.

So let us start with some basic definitions. What is an Enterprise in the context of EA? It can be anything – a single business unit, a collection of business units or just a single department. Preferably it is the “entire” organisation, but in practice, it can be whatever the organisation in question wants to apply the EA rigour to. As for Architecture, I think the best definition is the one provided by TOGAF: “A formal descripton of a system, or a detailed plan of a system at a component level to guide its implementaton.”

So what then is EA? Again TOGAF gives a simple definition: “Enterprise Architecture provides a conceptual blueprint that defines the structure and operation of an organisation.” The intent of EA is to provids a strategic context for IT to evolve and support the business strategy.

Whether organisations formally embrace EA or not, the reality is that their IT is always evolving to its business strategy and needs. But instead of leaving this evolution to chance and point decisions, EA can provide a framework to avoid the “spaghetti” state. In this context, EA is often cited as analogous to town planning. A well planned town is a delight to visit and live in. On the other hand a collection of badly built (even with a few individually well designed) buildings often results in a mess that prevents the growth of a city from evolving into what it could potentially have been.

With this strategic intent, the EA becomes more of an investment than a cost. The EA outputs are no longer a necessary evil but valuable foundation for a sound enterprise. The business strategy is formally defined first (Business Architecture) which defines and drives IT Strategy (Application, Data and Technology Architecture). The principles and guidelines drive the solution designs in individual IT projects, reusing the building blocks already delivered. Also by following a formal architectural development method (like the TOGAF ADM) and a governance structure (Architecture Review Board), organisations further increase the chance of a coherent IT evolution that is not left to chance.