An Integrated View on Business and System Architecture

A few weeks back, we had a short group discussion about enterprise architecture, business architecture and system architecture.  This conversation lead me to recall a presentation I gave at a SharePoint conference, back in 2010.  Although the presentation was specific to the life sciences industry, a couple of slides I showed were very much aligned with the conversation we had in class.  (For those who might be interested, the webinar was given the name of “Beyond Automation: Extracting Actionable Intelligence from SharePoint.”)

In this blog, I will recap the content I delivered in 2010 as it relates to enterprise, business and system architecture.  This will include my personal views on how they relate to each other’s and how they can be used in tandem to drive change.

Question 1: Enterprise, business and system architecture, is there a difference?

Answer 1: Yes, there is…

Enterprise Architecture (EA), Business Architecture (BA) and System Architecture (SA) are different but there are also overlap between them, which can lead to confusion.  Before we dig deeper on the subject, let’s review 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]
• System Architecture (SA) “is the conceptual model that defines the structure, behavior, and more views of a system.” [Ref 3]

Figure 1: EA, BA and SA Overview

So what is this telling us?  To make a long story short, very short in fact, BA is more focused toward defining how the business operates, or should operate to drive transformation, while SA is more focus toward defining how a system will be structured to meet business needs.  EA, on the other hands, is a more holistic view 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 strategists: Leads to the definition of a holistic transformation roadmap, and clear business strategies, to drive the enterprise toward its short and long term goals.
• BA -> The language of the business tacticians: 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 language”, we will often use terms like business structure, value-chain, actors, business process and business requirements.
• SA -> The language of the system implementers: Used to translate, optimise and enable business models by leveraging and integrating existing technologies while insuring sustainability of the defined systems (scalability, maintainability, performance, security, etc.).  In “SA language” we will often talk about service oriented architecture, technical components, system interfaces 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 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 no one needs or wants. 

BA is about defining the business environments, as it relates to your end users, and should 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, etc. but its primary objective is not to define what the business does, or what it should be doing.  Although System Architecture can help optimizing a said business process, it should not dictate it.  SA will confirm or infirm what is technically achievable, but problems occur when it tries to be prescriptive in nature.  You will face no smaller issues when the BA starts prescribing technical solutions… but let’s not go there today.  Let’s just say that both BA and SA play a vital role and that problems generally occurs when one steps out of its primary realm of responsibilities.   

My view of the definition lifecycle involving BA and SA is summarized in Figure 2:

Figure 2: A definition process for BA and SA integration

• Step 1:  Map BA -> Define your current business (“as is”).  How you are currently conducting business.  If it is already well defined, 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: Define SA -> Get the full picture by defining your SA in accordance with your BA.  Iterate and adapt BA where necessary or beneficial.  Plan your transition.

So that’s it for now! I hope I didn’t hurt any experts out there with this simple view.  I know full 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.  Agreeing or not, always feel free to drop me a line or two to share your views, or point 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.  

References

[1] 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

[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.

[3] 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

Can an incremental change cause radical impacts?

IToday’s global business environment is a prime habitat for change.  The thriving businesses of today understand the nature of the ever changing global market and the agility principles are not restricted to the software development manifesto  anymore.  As organizational giants are learning to dance, their ability to cope with change, at an increased speed, is becoming part of their operational strategy.  Those organizations that have successfully instilled a change culture have learned to monitor their environment.  They have learned to provide the correct managerial answer to this ever changing puzzle.  

Change can come from a multitude of sources and it can be incremental or radical in nature.  Radical changes are those that are disrupting the environment in a big way.   The telegram, division of labor and the free speech movement are prime examples of changes that were radical in nature.  Incremental changes are more subtle but it doesn't mean they are not just as significant, as any aging peer will attest.  As much as we like to think of change in this dichotomy, radical or incremental, it is too easy to make an error of causality when evaluating the nature of change in relation with its impacts.  This blog briefly explores this relationship.

 

Would you say that the smart phone is a breakthrough innovation or an incremental one?  Most people would probably say, instinctively, that the smart phone is a breakthrough innovation.  Now, what if I was to tell you that the technical complexity required to build a single smart phone requires the cooperation of a multitude of experts spread across multiple organizations, that no organization can, on its own, build a single one internally?  The incremental advancements that had to be made in portable energy sources (battery), digital processing, electronic and manufacturing to allow the smart phone idea to even exist are staggering.  With this in mind, would you still look at the smartphone as a radical technological advancement? 

As with the smart phone example above, we often make errors of association when thinking about change.  We too easily lump a multitude of incremental changes together to call it a radical change.  A dangerous consequence of this becomes apparent when business leaders see radical change as the only possible way to archive radical results.  Some leaders cannot foster the vision, or do not understand well enough the business model they are living in, to identify the minor tweaks (incremental changes) that could lead to big results (radical impacts).  It takes a lot of time and a keen mind to deeply understand a business model and time is turning into a rare commodity in today’s quickly changing market. 

To borrow from Malcolm Gladwell, understanding where the Tipping Point might be is the key to successful change.  This tipping point can be tripped by a single, meaningful, incremental change, a combination of incremental changes, or it may require a radical new approach.  While a radial change can lead to great improvements, it can just as easily deteriorate a system, or even have a marginal bottom-line impact at the cost of lot of wasted effort and change fatigue.  The only sure thing about a radical change is the amount of risk you are taking. 

So, if you are looking for radical improvements, the first step should be to understand your environment, and explore all possibilities for incremental changes, time permitting.  Change is much more manageable, and much less costly or risky, if you can successfully draw a solution based on incremental strategy than a radial one.