Updated: Apr 27
A few months back, I had a short group discussion about enterprise architecture (EA), business architecture (BA) and system architecture (SA), three knowledge areas that are often intermingled and misunderstood. This conversation led me to recall a presentation I gave at a conference, way back in 2010... Although the presentation was geared toward the use of Business Intelligence (BI) in the life sciences industry, some of its content was very much aligned with clarifying how those three frameworks (EA, BA and SA) meshed together as strategic and transformative business tools.
In this blog, I will recap the key differences and touch points between enterprise, business and system architecture. This will also include my personal views on how they relate to each other and how they can be used in tandem to drive change.
Question 1: Is there a difference between enterprise, business and system architecture?
Answer 1: Yes, there is…
Enterprise Architecture (EA), Business Architecture (BA) and System Architecture (SA) are different but there is also overlap between them, which can lead to confusion. Before we dig deeper on the subject, let us take a moment to review each of their definitions:
Enterprise Architecture (EA) is "a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes." [Ref 1]
Business Architecture (BA) is “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands." [Ref 2]
What is this telling us? To make a long story short, very short in fact, BA is primarily focused towards defining how the business operates, or should operate to drive transformation, while SA is more focused towards defining how a system will be structured to meet business needs. EA, on the other hand, is a more holistic framework that focuses on implementing the business vision while tying all of this together.
Here is another simplified way to look at this:
EA -> The language of the business strategist: Leads to the definition of a holistic transformation road map, clear business strategies and, drives the enterprise towards its short and long term goals.
BA -> The language of the business tactician: Leads to the transformation of business strategies into implementable business models. Used to reach common understanding across business experts and to communicate business needs to system specialists. In “BA-Speak” terms like business structure, value-chain, actors, business process and business requirements will often be used.
SA -> The language of the system implementer: Used to translate, optimise, and enable business models by leveraging and integrating existing technologies while ensuring sustainability of the defined systems (scalability, maintainability, performance, security, etc.). In “SA-Speak”, you will hear about service-oriented architecture (SOA), technical components, system interfaces, logical architecture, physical topology and design specifications.
Question 2: Should I first define BA or SA, and is it a chicken and egg question?
Answer 2: No, sorry, it is not that philosophical...
Assuming you already defined your strategic approach to enterprise management (your enterprise architecture), the next step should be to start defining your business architecture (BA) in accordance with your business strategies. The reason to start with BA, and not SA, is simple: you can waste a lot of time defining a very cool system that does not add business value to justify its implementation.
BA is about defining the business environment, as it relates to your end users, and should initially have little to do with how this new model will be technically implemented. System architecture, on the other hand, is largely there to define the technical requirements of your system. How it is built, secured, maintained, scaled or upgraded. Its primary objective is not to define what the business does, or what it should be doing. Although System Architecture can help optimize a business process, it should not dictate it. SA will instead confirm what is technically achievable.
My view of the definition life-cycle involving BA and SA can be summarized as follows:
Step 1: Map BA -> Define your current business (“as is”) by confirming how you are currently conducting business. In this step, you should consider your existing processes, usually defined within your existing procedures. If your operations are already well defined, you could skip this step.
Step 2: Optimize BA -> Define what you would want your business “to be” and transform your business strategies into implementable business models. Optimize this “to be” BA by leveraging anything relevant: existing systems (SA), existing technologies, regulations, new quality management principles, etc.
Step 3: Map SA -> Get the full picture by defining your SA in order to meet the requirements of your BA. Iterate and adapt the BA where necessary or beneficial. Plan your transition.
So that’s it for now! Hopefully, my interpretation and simplification of these complex scenarios didn’t go too far. I know very well that all three bodies of knowledge are a lot more complex than this short blog could convey but I hope it was helpful to some. Whether you agree or disagree, always feel free to drop me a line to share your views, or to point me toward interesting EA, BA or SA resources. I am always up for a good discussion and I will be delighted by an opportunity to learn from you.
 Business Architecture Guild, A Guide to the Business Architecture Body of Knowledge™, v 4.1 (BIZBOK® Guide), 2014. Part 1, Section N/A & Page 2
 OMG Business Architecture Special Interest Group "What Is Business Architecture?" at bawg.omg.org, 2008 (archive.org). Accessed 04-03-2015; Cited in: William M. Ulrich, Philip Newcomb Information Systems Transformation: Architecture-Driven Modernization Case Studies. (2010), p. 4.
 Hannu Jaakkola and Bernhard Thalheim. (2011) "Architecture-driven modelling methodologies." In: Proceedings of the 2011 conference on Information Modelling and Knowledge Bases XXII. Anneli Heimbürger et al. (eds). IOS Press. p. 98