What is software architecture? What is the role of a software architect? How do you define software architecture? How do you share software architecture? How do you deliver software architecture?

Delegation

Understand what's happening in just enough detail

I briefly mentioned delegation in my post yesterday about authority and I wanted to expand on this further. I talked about delegation in the context of having the authority to make decisions - you don't actually have to make all of the decisions yourself. Other examples of where delegation might be needed include :

  • Design : You've come up with a nice logical architecture that defines a collection of components and their interfaces. Taking these to the next level probably requires some lower level design effort, which you might not have time to do yourself across the entire system.
  • Coding : Unless the system is very small, there's no way you can code it on your own. Furthermore, there's probably little chance of you understanding how the entire system works at the code level.
  • Quality assurance : In a similar way to the code, do you really think you can code review the entire system on your own?

Delegation is an important part of a software architect's role and there's a middle ground somewhere between delegating everything and doing everything yourself. Either way, it's worth pointing out that delegation is different to ignoring/not being interested in what other team members are doing. The key points here are to trust your team, delegate where appropriate and make sure you have a handle on what's happening in, to use an agile term, "just enough" detail.

Responses[2] RSS feed for responses to this blog entry
Posted by Simon Brown on 22 May 2007 09:14:00 BST #


Reply

Re: Delegation

Comment from Brian Sondergaard on 23 May 2007 00:27:56 BST #
Great point Simon. This falls into the category of making sure we're spending our time on the things that really matter.

In Bredemeyer's "Guiding Principles for Enterprise Architects", he describes the "Minimalist Architecture Principle":

"Essentially, the Minimalist Architecture Principle says 'if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.' This means that architects only make decisions that require the overall perspective and authority that the architect has. If a decision has local impact, then the architect has no need to mess with it. If the decision has broad impact, and the impact has highly strategic consequences, then the decision fits the minimalist architecture criterion."

Of course, we'll want to keep in mind that delegation does not allow us to abdicate.

Brian
http://blog.softwarearchitecture.com
Reply

Re: Delegation

Comment from Dan on 29 May 2007 19:46:31 BST #
In government, this is known as the principle of subsidiarity: a central authority should have a subsidiary function, performing only those tasks which cannot be performed effectively at a more immediate or local level. So it takes a different, but complementary, viewpoint from the Minimalist Architecture Principle by asking what must be done at a higher level to ensure the effectiveness of local action. That's the flip side: what cannot be delegated. For more, see http://en.wikipedia.org/wiki/Subsidiarity

Add a comment Send a TrackBack
Software architecture for developers