Carl Bruiners Agile / IT Development Consultant

1. Muse
   May 16th, 2012 - 19:30

   Let’s step back and look at the problem(s) aihcrtecture is supposed to solve (I may be completely wrong here, so feel free to correct me) * Reduce waste from rework * Increased changeability of code by avoiding writing frozen codeBoth of these are incredibly important in an enterprise with hundreds of developers working on interoperable systems.Traditional enterprise aihcrtecture tried to accomplish this with architects as gate keepers. They would somehow be responsible for the design of the entire aihcrtecture of an organizations software system, but be so involved in meetings that they wouldn’t get much opportunity to see how the code is actually interacting. Decisions which make perfectly rational sense at the architects abstraction layer could cost a lot of money and not provide any additional business value.Agile aihcrtecture requires architects to act as empowerers instead of gatekeepers. Their responsibility isn’t to prevent poor design choices, but to use their experience and skills to create communities of shared information.how does this happen?First, they must focus on making important information big and visible. * Code health (however you measure it) * I prefer to measure cyclomatic complexity and unit test coverage, and monitor for improvement over time as opposed to some absolute mandated metric. * Public API Specification * I prefer to use a tool like cucumber to create human readable examples exercising the public API.This is more difficult than it sounds. Making this information big and visible is *TOUGH*. The best way’s I’ve seen have involved using tools like github corporate accounts so that the wiki, build instructions, issue tracker, and source control are all tied into a single streamlined (yet highly adaptable) systemSecond, they must focus on providing the right education * The 4 rules of simple design are pretty crucial * So are code smells and refactorings * What are the common values you share as a dev organization (Small parts loosely joined? Boy Scout?)Flipping architects from gatekeepers to empowerers is by no means an easy task. It requires a hig level of respect and empathy from all involved parties, and a willingness to trust that everyone involved is doing their best to help the organization succeed.

   ( REPLY )
2. carl9167
   May 16th, 2012 - 20:18

   Hi Muse,

   Though not inline with the original blog, thanks for sharing this, particularly as you have touched on many issues.

   You’ve made some interesting and valid points, you clearly have mastery in the development department, statical code analysis, BDD, etc.. is all very much at more advanced end of development.

   My take is that it isn’t only the architect that needs to be empowered, it is important to empower the whole team; BA’s, QA, Developers / engineers, designers, UX, UI, etc…

   Architects should be fountains of knowledge and spread good architectural practice around the team/s they work with.
   It doesn’t mean that the architect doesn’t still act as a gate keeper, for example we still have architectural reviews (this for some teams happens at the peer review point as part of their workflow), but by the architects creating the communities of shared knowledge that you mention they are minimising the amount of ‘bad’ architectural code they encounter in their reviews.

   I’m all for team PR, leveraging on wiki’s, blogs, information radiators, etc.. it is definitely the way forward on advertising your teams hard work.

   Its certain useful to have a single application where you can view your SC data (commits, commit comments, etc…), team wiki, team blog, etc… but like an all in one hi-fi I have yet to find a tool that can do it all (Jira’s integration with Mercurial is pretty cool for example, but it struggles in other areas).

   I personally don’t like architecture by statical code analysis, as SCA can be misleading, but I certainly think it has a place, as long as its metrics are used as a tool which can help the architect zero in on the problem area.

   As you’ve mentioned, trust plays a big part in an Agile team, to geniunely empower a team you must trust them. Sadly I have found with many teams I have worked with over the years that this isn’t always the case, often trust is ‘lip service’ from the business. I wrote a post that touches on trust; Sovereign teams

   ( REPLY )

Leave a comment Cancel reply

Name(required)

Email(required)

Website

CAPTCHA Code *