Collaboration does not mean my shouldering your responsibilities

 

OK, you got me, I do care because ultimately we are striving towards the same goal: realising some defined business benefit. There is an important caveat to my shocking statement: It only applies when I am working purely on the business architecture and not as a BA on the software development team, in which case I care a lot.

 

However, we all have to focus on playing our own part, so when I say: “I don’t care whether your deliver your software”, it’s mainly to shock some people into understanding that the realisation of a defined business benefit does not necessarily come down to the success about of one particular software project.

 

When I work on a technology-agnostic business architecture, I help the business understand and articulate what it needs, largely by modelling and testing those needs. I focus my attention on that purpose so that others who depend on understanding how the business needs to change can focus on their job. I do not concern myself with whether the change actually gets adopted – I leave that to the Change Manager. I do not concern myself with whether any consequent software gets delivered – I leave that to the Software Delivery Manager.

 

Business architecture is not about any one particular software project. Business architecture is essentially a set of models that describe how a business currently operates (As Is) or should be operating (I prefer the term “Should Be” over “To Be”). Implementing that Operating Model may require several software development projects (or even none); it may require a public relations campaign – in 2015 Ryanair’s changes to how it wants to operate involved a significant PR campaign; it may require a programme to train staff in new procedures and policies; it may require a programme of real estate sales and purchases and the consequent effects on staff, as at HMRC in 2016. Business architecture is bigger than any one software development project and it is certainly not about documenting software requirements, contrary to what many Product Owners and Scrum Masters assume (see “Business Architecture is about more than software requirements“).

That said, I have never met a Product Owner, Scrum Master or Software Delivery Manager who had ever seen a coherent set of business architecture models before, so their assumption that business analysis is nothing more than requirements elicitation is understandable.

 

My responsibility as a business architect ends once I have helped the business articulate and test its needs. I cannot also shoulder the responsibilities of other roles, such as to deliver the software that satisfies those needs. I make the same argument to change managers. It is up to them to deliver the needed changes that I have helped the business articulate.

 

Some see this as an unwillingness to collaborate. However, this is based on a misunderstanding of “collaboration”. Think of the medical staff who collaborate in an operating theatre: everybody has to focus on their own tasks in order for the whole team to succeed. However, the anaesthetist is not failing to collaborate for not grabbing a scalpel and mucking in with the surgeon.

 

It’s not just about understanding the boundaries of one’s own responsibilities, it’s also making sure you have the time to to fulfil those responsibilities.

 

Collaboration: know your job, do your job and thus help others to do theirs but let them worry about doing their own job.