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.
Conclusion
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.
Practice of EA 