In the beginning
In the beginning, there was enterprise business architecture.
No. That’s not quite right. A new business is not likely to have a formal business architecture defined, let alone managed. So, let’s talk about what we mean when we talk about enterprise business architecture, and where it fits into the scheme of things.
The raison d’être of BarcVox is enterprise business architecture, which serves as the centre for discussion, so let’s start there.
What is enterprise business architecture? Enterprise business architecture is a relatively new discipline, so the definition is evolving. And parsing the phrase doesn’t get you very far.
There is something about an enterprise and something about business. But aren’t these the same thing?
When we’re talking about ‘enterprise’, we are talking about the expanse of the business, It’s about the scale and ensuring that the solution covers the purview of the entire organisation.
And business. That’s the business of the enterprise—the mechanics and mechanisms of the organisations—the operations. This relates to the business of the business, if I may. This is about the functional part of the organisation—from product and service ideation to operations and delivery of products and services to marketing and sales to service; possibly supply chain, manufacturing, inventory, and logistics; and all of the attendant capabilities that allow this.
And, so what about architecture? The architecture is the framework. The schematic that maps how an enterprise is structured. It informs what capabilities an organisation has, how functions interoperate, and what it doesn’t have but needs. It should also inform one about relative maturity and what it might take to optimise the organisation.
So, let’s step back and hear how all of this comprises the discipline of enterprise business architecture.
Big picture
Before we continue, let’s step back to capture the bigger picture. Enterprise business architecture is a shared part of enterprise architecture. As we just discovered, it’s the part focused on the business. But let’s see where enterprise architecture fits into the equation.
Enterprise architecture is the bridge between an organisation’s vision and strategy and its operations and execution. Enterprise architecture has a longer history than its business subcomponent and so has a more developed orthodoxy, even if there are still a lot of variation among companies.
Let’s consider how enterprise architecture can be deconstructed. The oldest and most prominent component of enterprise architecture is enterprise solution architecture, or what some call, enterprise technical architecture. In fact, when some people hear the term enterprise architecture, they may consider it to be synonymous with enterprise solution or technical architecture. And given that many organisations don’t have a formal business architecture element, this is not unreasonable.
Digging even deeper, enterprise solution architecture may be comprised of subcomponents:
- Infrastructure Architecture
- Application Architecture
- Data Architecture, and
- Information Architecture
each performed at the enterprise level. Each of these constituents operate at their own level of maturity. Some organisations don’t formally distinguish between the roles. They just fall under some umbrella of enterprise solution architecture.
I’m not going to discuss these subcomponents here. I’ll defer these for future segments.
In Focus
Ostensibly, the difference between solution architecture and business architecture is a matter of focus. It would not be unusual for a person in either of these roles to have a depth of both business and technical knowledge.
Solution architects are primarily concerned with technology systems and their processes whilst business architects are primarily concerned with business operations and processes.
Business architects and solution architects fit together by complementing each other in solutioning, by being the sounding board for their privileged perspectives, and by creating whole solutions with a 360° perspective. In practice, it wouldn’t be unusual for these groups to share many of the same artefacts, though each having a deeper view into their own disciplines.
The enterprise architecture practice provides the metastructure for solution architecture and business architecture. And there is more than one way to implement it within an organisation.
Depending on how it’s instantiated, enterprise architecture could be implemented as a managed entity within the organisation structure. Or it may be implemented as a governance function and operate with steering and operating committees, rather than be part of the organisational structure. In any case, the function of enterprise architecture is to provide an escalation path and resolution mediator for differences of opinions between business architects and solution architects. This may be a discussion for another day.
Tiers of a clown
Larger organisations tend to have tiers of architects. Strictly speaking, although these architects may be contained within the same reporting organisation, the enterprise prefix only pertains to the top tier with a full enterprise vantage.
And, if there are levels of business architects and solution architects, then each should be an ordered pair, each business architect having a corresponding solution architect in their domain space to ensure full coverage all the way down.
Let’s rewind a bit. What is business architecture in the first place? What does a business architect do?
The primary goal of a business architect is to be a catalyst to operationalise business strategy. I like to think of the business architect as generating the what and the why. The solution architect provides the how. As the focus of this segment is on enterprise business architecture, we’ll leave the solution architecture conversation for another day.
In key
The enterprise business architect has several key functional activities:
One. To translate organisational strategy into an architectural design and into language workaday business operators can consume. This design may either serve to construct a new architecture or to rationalise some existing implementation.
Two. To guide the conversation between enterprise solution architects, business operators, and program management, and to some extent development resources—though this may occur by proxy.
Three. To serve as knowledge managers. Information and artefacts need to be human consumable and digestible. It needs to be relevant and current, so it needs to be updated as progress is made.
I don’t want to spend time discussing the artefacts in depth here, but a business architect might be expected to work with capability models, organisational design documents, opportunity roadmaps, gap analysis, and impact assessments. I’ll save the drill-down on these for another time.
The last topic I want to touch on in this segment is how and where enterprise business architecture interfaces with upstream organisational strategy and downstream activation resources.
Strategy rules
Enterprises have their own implementations of organisation strategy functions. Some companies have fully-developed organisation strategy functions. But for many companies organisation strategy is managed by a single title, perhaps even one role of many by a specific person.
Many companies don’t create their own organisation strategy. That’s a topic for another segment. These companies rely on external partners to develop strategy and roadmaps, which are vetted by internal resources. And enterprise business architects rely on these strategy outputs.
Downstream activation resources rely on business architects to convey the foundation and narrative necessary to implement the architecture. Program management resources take roadmaps as inputs to coordinate planning and execution. They may work with functional architects, product owners or product managers, and possibly technical architects.
It should go without saying that business architects also interface with business managers and operators in order to understand the needs of the business and gain insights related to effectiveness and optimisation opportunities.
Business exists for one purpose. To serve the customer. So, I’ve saved the best for last: customer Experience. Without customers or the potential for customers, a company has no reason to exist. So, without filtering solution perspectives through a customer lens, we’d be missing a key element. The importance of customer experience is a topic of its own.
It’s a wrap
To wrap up this segment, let’s circle back to how business architects are the yin to the yang of solution architects. These two functions are complementary. Business architects are closer to the business, and solution architects are closer to the technology. But a business architect without a strong foundation in technology and a solution architect without a strong grounding in business are likely to produce weaker solutions. And the business architect is more likely to be closer to customer needs than a technologist.
2 thoughts on “Defining Enterprise Business Architecture”