Team leaders should focus on providing ‘just enough’ early architecture guidance to developers, long-time software architect Jon Kern told attendees at TheServerSide Java Symposium this week in Las Vegas. Kern told the audience to gather enough requirements to begin architecture work – but not more than enough. Early 'releases' are important for gaining feedback on how the architecture will work, he added. When faced with the need to build a new software architecture, said Kern, “the problem is one of balance.” “People can do an excessive amount of [architecting],” he said. The important thing is to get enough information to get started – but just enough.” Read the rest at http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1351335,00.html .
- Posted by: Peter Varhol
- Posted on: March 19 2009 12:40 EDT
- Agreed by Ethan Allen on March 19 2009 17:14 EDT
- Re: TSSJS 2009: Kern promotes ''just enough'' architecture by anthony rivera on March 19 2009 21:52 EDT
- Couldn't agree more by Martijn Verburg on March 20 2009 07:24 EDT
- Re: TSSJS 2009: Kern promotes ''just enough'' architecture by James Watson on March 20 2009 10:11 EDT
- Re: TSSJS 2009: Kern promotes ''just enough'' architecture by Jonathan Kern on March 21 2009 08:31 EDT
- This is revolutionary by Bj??rn Caroll on March 23 2009 05:17 EDT
This is good thinking. In my opinion this builds on the idea of "writing just enough code - but not more than enough", which was itself later extended into the idea of "applying just enough design patterns - but not more than enough". At this juncture I suppose I should recall the idea about using "just enough sarcasm" ...
It's all about finding the right amount (breadth and depth) and quality (most critical and high value) of requirements info that will generate the necessary design minimum. Simply, the classic Pareto principle and Occam's Razor. A similar extension is applicable to doing the right set of activities of a project. Architecting (designing) for one is a high-level activity that needs to happen quickly (given the right set and quality of inputs already available) as possible so as not to hinder immediately developing (and releasing) useful and working software. Low-level activities such as documentation and building loads of design diagrams should be avoided for the simple reason that your fundamental goal is the software (system as solution) you are trying to build. This is not to say that documentation is not important, as it should happen eventually. But it shouldn't hinder progress towards the goal (software/solution), or worse, give the illusion of progress that's sometimes unconsciously happening or subconsciously, to avoid dealing with the difficult but important and urgent issues upfront. (http://www.agilemodeling.com/essays/agileArchitecture.htm, Chapter 7) Anthony Manila, Philippines
Definitely have been involved in too many projects that are over architected for no purpose! That's why I usually prefer working with architects who get their hands dirty in the code on a regular basis, they tend to get that balance right more often.
My feeling is that architecture is basically like an outline for an essay. You have a goal and you plan out the high-level structure of the system. Design is the next part of the process and works the same way. You take each of the above components and plan out their structure and make sure they fit into architecture. If you find the architecture is not adequate, you go back. Coding is the last part of this. You have the design which describes the parts and what they should do. You implement those parts and if things aren't working you go back to design, which might mean going back to the architecture. One of the problems I see is that people think this should be a strictly top-down process. That you can define the architecture and design once without having to look back. This just isn't realistic.
One of the problems I see is that people think this should be a strictly top-down process. That you can define the architecture and design once without having to look back. This just isn't realistic.You are correct, IMHO. One other thing I mentioned is that architecting is not a once and done phase. Rather, it is an ongoing process that has emphasis and levels of activity that ebb and flow as dictated by how the project unfolds. In addition, I always try to wire up performance monitoring harnesses to keep an eye on how the system is trending in regards to meeting key non-functional drivers. If things go awry, quickly look to solve via redesign or re-architecting. Naturally, re-architecting or tweaking is greatly simplified if you have built your architectural pieces consistently. Trust, but verify.
Why have not anyone told me this before. All the time I have thought that the goal was to do too much or too little!!! The whole Agile movement has been sold with the argument that every thing that is "right" is Agile and everything that is wrong is "the other stuff". Unless someone tells what is "just enough" this is a completely useless information.