Business Architecture, Defined

There are a number of disciplines within IT Architecture that tend to overlap, part of this is because the definitions haven't achieved industry wide status (for example, various EA Frameworks define similar functions with different terms and they also often use the same terms differently). Part of the problem in this case though, has to do with the relative ambiguity regarding how and where IT Technology and Business drivers can or should mix. There is also some confusion in relation to where Business Analysis ends (as a practice) and where Business Architecture begins. We will help to answer some of these questions in this post.

Business Architecture has many potential components and drivers

First, let's attempt to apply a standard definition to the practice area:

Business Architecture - This represents the entire set of design activities associated with translating business needs and expectations into technical solutions. Those design activities include the following typical tasks and / or artifacts: Context Maps, Concept Mapping, Process Engineering, Capability Maps, Business Rule Definition, Conceptual Data Modeling, Domain Modeling, Class Definition, Object Definition and Business Glossaries. This list is not exhaustive but it does highlight that Business Architecture includes both analysis and design. It also shows that there are clear intersections with data and application (system) architecture. Business Architecture tends to be the first area of design focus within the overall lifecycle of any given solution or set of solutions.   

So, in reality there are many people who work as Business Analysts that in fact perform Architecture tasks. On the flip side, many architects are asked to define and manage requirements or otherwise work side by side with business stakeholders and analysts to help better understand workflows and data contexts. The lines here are indeed fuzzy as the type of architect asked to do all of this may be referred to variously as a Solution Architect, Data Architect, Project Architect or perhaps even something else. Use of the term "Business Architect" is still relatively uncommon. The reason for this is most likely that many organizations want Architects who can perform those upfront Business design activities but also follow that with more specific types of solution design tasks and artifacts.

Business Architects often use EA tools to perform these types of activities; products like Mega or Troux allow Business Architecture to managed in the context of TOGAF driven enterprise. Other tools can be used to manage governance, application policies, business rules and other types of design artifacts.

Another important aspect of the role of Business Architects is their focus on Lifecycle Management. Now, we will address Lifecycle Management in more detail in another upcoming post, but the key elements involved are Governance and Portfolio coordination. So, Business Architects also often help to oversee Governance processes, help develop Business Cases, estimate project costs and schedules and otherwise support portfolio planning processes.

When we view all of this in the larger context of IT Architecture, it is worth considering the larger question whether all architects ought to have some experience working on the "business side" of solutions in order to better understand why some projects fail and how to better align business goals with IT reality. Another facet of this topic is the notion of what an Architecture Manager does. That is a role that isn't necessarily associated with Business Architecture per se but nevertheless includes quite a number of similar tasks and artifacts. Any IT Architecture manager (regardless of the type of architecture being performed) must be able to manage project planning, cost estimation and other types of team collaboration activities.

We will examine many of the terms and concepts introduced here in greater depth in upcoming posts.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc