In Black Sheep or Shepherd, I introduced the idea that Business Architecture isn’t aligned with Enterprise Architecture as well as we may expect from looking at traditional structures for Enterprise Architecture.

I’ve had several conversations about that topic since, all raised by the person I was talking with, rather than me asking them. And we’re all coming to similar set of conclusions:

1. Business Architecture doesn’t fit well within Enterprise Architecture (more on this below)
2. Business Architecture as a profession is maturing
3. Organisations who are using Business Architects are using them differently
4. Business Architecture may be better defined as a peer capability to Enterprise Architecture, rather than within EA.

Let’s take each in turn.

1. Business Architecture doesn’t fit well within Enterprise Architecture

I covered a lot of this in Black Sheep or Shepherd. The traditional implementation of EA originates from an IT perspective. Enterprise Architecture is typically initiated from with the IT function. While EA is meant to include Business Architecture in parallel to Technical Architecture, etc, Business Architecture is typically the last to be included and takes a position following Technical Architecture.

Enterprise Architecture structure

A typical Enterprise Architecture structure would include Application Architecture, Infrastructure Architecture, Data/Information Architecture and Business Architecture. Usually implemented in that order when originating from an IT perspective. In fact, I’ve often seen the sub-architecture of Process Architecture being implemented before Business Architecture.

EA implementation

This is opposite to what we would expect if we were able to plan it logically. In that case, we’d apply Business Architecture first in order to understand the aims and vision of the organisation, then organise everything around that vision. That’s where the other architecture domains come in. That’s the method as described (but often not followed) within TOGAF ADM. Start with the agreements, architectural principles, then business architecture to define the requirements for the other architecture domains.

2. Business Architecture as a profession is maturing

While we could say this of almost any profession, the rate of progress and thought-leadership in Business Architecture has progressed noticeably over the last few years. Prospects and clients are more aware of what it can do for them, internally within organisations there are more allies for the need for Business Architecture. It’s not all rosy, but it is improving.

Not only are the consultancies improving in their offer and the clients are improving in their knowledge and their requests, but short-term resource agencies are also improving in their placement of business architecture. More people involved in the wider enterprise are now talking about the value of business architecture. It’s still not prevalent and there’s often sales activity involved in influencing clients and prospects in the value, but it is increasing.

3. Organisations who are using Business Architects are using them differently.

Many of my requests for work come from portfolios or programmes rather than central, corporate enterprise functions. It is the change function of the business that is seeing a need to create order within the organisation and hence wanting the services of a Business Architect to assist with that. Typically, these assignments also stretch into guidance on business analysis although that can be considered separate. The indication though is that’s how the clients are seeing the tasks at hand. They see that the technology is taken care of through technical design authorities, etc and want a similar structure for business decisions.

This can be extended to a point where a change programme uses business architecture which then informs a corporate function. That corporate function realises the value and initiates their own business architecture initiative. When done well, these two different business architecture functions concentrate on their own objectives while ensuring alignment between corporate and change function. When done badly, they compete.

4. Business Architecture may be a peer capability to Enterprise Architecture

I find myself discussing future designs with Enterprise Architects, not because the designs have to go through them in terms of governance, but as a peer review. It does raise the question of whether they’re should be a consolidated governance route and review boards, not just technical design authorities. I have created design authorities that focus on business design (including the use of technology) rather than the technology solutions as would often appear before a technical design authority.

In addition, if we take the EA implementation diagram mentioned earlier, we can see that there are several transition states; one after each phase where only a subset of the Enterprise Architecture has been implemented. The typical transition state follows phase 2, where we see EA comprising Infrastructure and Application Architectures, all governed through an EA route. But with Business Architecture and Data/Information Architecture governed through other routes.

Enterprise Architecture and Business Architecture as Peers

That combined, with the multiple design authorities, is indicative of an immature EA function, leaving us with two choices:

1. Improve the maturity of the EA function and the role of Business Architecture within it.
2. Engage Business Architects as peers to Enterprise Architecture

(1) only works if the initiatives are not IT focussed and that there’s more well-rounded support and engagement for that function.

(2) is what many clients are doing. They’re seeing EA as not performing what they require of the function, so they engage a Business Architect to provide and cover that gap.

Where to go from here?

That leads me to my premise. Even though EA is mature as a concept, it’s implementation is poor in a number of organisations, especially those that treat EA as a subset of IT.

Wherever EA is a subset of IT, then Business Architecture should short-term be driven by change portfolios. In parallel, the organisation should consider how to achieve wider adoption of the EA function within the organisation. Ironically, that task is most suited to Business Architects.

Whichever route, there has to be single point at which all designs come together for review. Not necessarily reviewing the designs themselves, but at least the design principles behind them. That review function is the start of a homogenous Enterprise Architecture function.

Moreover, we should concentrate on Business Architecture first where possible. Relying on existing architects is fraught with issues, most of all leading the organisation down a technology-driven path, rather than a business-vision/purpose path as would be more appropriate.

So consider a revised implementation timeline to reflect the earlier presence of Business Architecture, whether within or as a peer to EA.

EA implementation – revised

Any comments? Get in touch @alanward