As a business architect, I feel like I’m sometimes the black sheep and sometimes the shepherd of the Enterprise Architecture function.

Sheep

The Black Sheep

1: Uncovering the rationale

I feel like the black sheep because I find myself regularly asking why. Why did you make that decision? Why did you choose that approach? Why caused you to think that way?

I tend to use different, phrasing which is more approachable and open, such as “tell me the story so far. How did we get to where we are now?”, etc. But underneath it all, I’m aiming to understand the motivation behind the changes that are progressing in front of me.

It’s not so much a position of devil’s advocate, more of one of uncovering the rationale behind decisions and evaluating whether that decision is still a valid one. Many long-term programmes are governed against a set of principles which were decided and approved over 18 months before. The world has changed in that time so is it still appropriate to continue with those principles.

2: Focus on business

I also feel like the black sheep because we, as business architects, are rarer than technical architects, solution architects and even enterprise architects. To the point that there may be a team comprising many technical architects and solution architects and I can be the only business architect. I’d guess that, before I arrived, there was no business architect presence.

Unfortunately, I find that those who have come directly from the technology route will have less of grasp on issues and potential solutions within the business domain. That includes the vast majority of enterprise architects I’ve met, even though they’ll be responsible for business architecture as well. Typical enterprise architects lean naturally towards the technology domain. Not all, but most as it’s seen as a promotion route from technical architect. If we have more technical architects, then it’s likely that we’ll see more enterprise architects with a technology background and a technology focus.

The Shepherd

3: Initiator

I feel like the shepherd since business architecture should come first. Look at TOGAF’s ADM, which architecture element comes first? It’s Business Architecture.

TOGAF ADM

Admittedly, that assumes a linear process from 12 o’clock and progressing clockwise. But for many clients, the initiating event is that a programme requires a technical architect, so they start around Steps C or D on the ADM (if they’re following ADM or similar).

Even before you get to Business Architecture, there’s the process of approving the concepts of enterprise architecture, what it will focus on and how it will be done. It’s that stakeholder management within the preliminary activities that, when you look at the skills involved, align more closely with that of the business architect than of the other architects.

Back to corollary to point 1 above, if we start with a business architect, then the preliminary steps and step B of the TOGAF ADM fall into place. A large chunk of A can be developed by the business architecture, since we’d still want the changes to be focussed on the goals and motives of the business.

From then on, e.g. C onwards, we design the architecture (and subsequent technology decisions) based on the business you want to be, rather than the more typical way of having to hammer an organisation into a technology refit.