Enterprise architecture is a fairly well-known and established concept in larger companies. The role of Business Architecture and how it fits in is a hot mess. In fact, most companies don’t have a business architecture function, and many of those don’t understand what it is, how to employ it, and so create role confusion. There are organisations that detail how it operates, but even many companies are aware of this and have staff who are trained members. They don’t appear to have any or much voice. In my last Business Architect role, it was relegated to an IT function, but let’s not digress.
On this note, I was browsing on LinkedIn recently, and someone had shared a meta diagram similar to the one on the blog for this segment—only he had placed strategy below objectives. Plus he had goals, a concept I eschew in favour of objectives.
One significant challenge is that many of these concepts and terms have different meanings to different people, and I am under no illusion that I will be the one to rein this in and tame the beast. If I can convey my perspective, I’ll consider it to be a win.
Vision & Mission
Regarding ILLUSTRATION A, item 1 is the vision and the mission of the company, which is inherited by architects as an input or constraint. For many companies, these aren’t very strong—especially in terms of vision, but a good vision can make a huge difference on the way the public view the company and how employees view their roles and boundaries (or not). Although it’s outside the scope of this segment, a vision should constrain somewhat, but it shouldn’t become a fetter that cripples exploration and innovation.
Mission is more mundane. Rather than the aspirational vision of what the company wants to be, it captures what a company does and rather how. These can serve as sort of guiding principles.
Strategy belongs after the vision and mission pair. Whilst most companies at least have a phone-in version of a vision and understand their missions relatively well, too many companies are rudderless in the strategy realm. This is also where Business Architecture makes its entrance onto the stage. But let’s give it some definition first.
When it comes to defining strategy, I am old school. I like Michael Porter’s perspective of Competitive Advantage. How are you differentiating yourself from others in the marketplace? There are some companies who do not care to differentiate, per se, they just want to follow some leader. Lowes following Home Depot in the home improvement space and Avis following Hertz in the auto rental space fall into this category.
Porter promotes “deliberately choosing a different set of activities to deliver a unique mix of value”. In 2015, as published in the Harvard Business Review, strategy generally boils down to one of two things: “Do what everyone else is doing (but spend less money doing it), or do something no one else can do.” The strategy comes down to how you intend to do this.
Business Architects don’t create strategy, they enable it. In companies with weak or non-existent strategy, they may formulate and articulate a proxy version; otherwise, there is nothing meaningful to align objectives to. They need to align to the what and how of the strategy.
This strategy is what I call the capital-S Strategy. This is a top-level strategy. I use the capital-S nomenclature to distinguish it from the lowercase-s version that I also call approach or strategic approach.
Objectives come next. These are measurable goals, so-called SMART goals. Including goals, which is to say unmeasurable objectives, is pointless. A goal is, “We want to increase profits” or “We want more customers”. Besides no company has ever asked for the opposite, did you succeed if you eked out one more shekel or one more customer? We need objectives, not goals. “We want to increase profits by 10 per cent” or “We want 10 per cent more customers”. At the end of the day, you know whether or not you were successful.
It might be a better idea to simplify Strategic Approach to Approach. That way, you don’t even need to entertain the lowercase-s conversation. Otherwise, that’s where we are—lowercase-s territory. Whatever you end up calling it, this expresses how you intend to map your objectives to whatever strategic pillars have been established. It’s pretty simple.
A company may opt to combine items 4 and 5 into a single Strategic Planning box, which may be just fine. Tactical Planning is just the nitty gritty of how all of this is going to be executed, on what timeline and budget—and who is going to do what, where, and when? To be fair, Tactical Planning needs to be done, but it’s not a Business Architecture function. And to be honest, the aforementioned Strategic Approach isn’t really either. To be even more honest, the Business Architect defines how all of this is done or linked rather than to do any of it. But the Business Architect needs to know the elemental pieces in order to formulate an approach and a framework.
Even if Business Architects step out of the room for items 3 through 5 and are only recipients of items 1 and 2, the need to architect item 6, Business Capabilities, brings them back into the room and at the head of the table. These capabilities are broken out into three components in ILLUSTRATION 2 into People, Process, and Technology.
People are a capability with a competency element. People also need to fall into an org structure. This may be handled by a Human Resources or Talent and Organisation function, but it needs to be accounted for.
Process includes macro aspects such as the operating model and governance as well as business processes. Business Architects don’t create business processes, but they are responsible for mapping the high-level end-to-end processes and identifying prospects for rationalisation and value realisation. They may help to orchestrate or provide guidance, but they are not necessarily in the weeds.
As a matter of full disclosure, sometimes weeds are involved. Value Stream Mapping is a prime example. In an immature organisation, perhaps there are no competent process people with whom to collaborate. In these cases, the responsibility may fall onto the Business Architect. Ideally, the Business Architect would be more of a custodian and understand how the processes stitch together at a higher level.
Before moving to Technology, it’s important to note that there are business processes and tech processes, just as tech people are a subset of the aforementioned people, so there is some overlap, but IT should have no say in people outside of its domain nor of processes that it does not directly control or interface with.
Obviously, Technology is not in the realm of Business Architecture. This is Enterprise Architecture and Technical Architecture. This technology enables the enterprise in a similar manner to people and process. Once the business informs the tech group—I’ll employ the term IT generically to denote this function— of the WHAT and the WHY, the IT group determines the WHAT and the HOW. The Business WHAT is the what of the problem whilst the IT WHAT is the what of the solution, and IT is in the best position to know how to implement it—experiential matters notwithstanding.
Business Architecture extends from the tail end of the capital-S Strategy component to the middle of the Business Capabilities element. Vertically, a goal is to encapsulate all of this to ensure it runs smoothly and as expected. Horizontally (not displayed), a goal is to ensure cross-discipline and cross-functional processes are efficient if not optimised. Friction is the nemesis of any organisation and a bane to customer and employee experience, so reducing friction should always be a goal—diminishing marginal returns notwithstanding.
Strategies and approaches should permeate all organisations. Most of these are by their very nature the lowercase cousins of enterprise strategy, but it’s important to distinguish between the two and understand that no amount of lowercase strategies can sum up to a capital-S Strategy.