Nick Malik wrote blog post “The culture of art vs. the culture of engineering” that described the problem of architects and developers being caught up in invention rather than reusing software system definitions and concepts.
I wholeheartedly agree with Nick. We’ve all struggled with this problem it seems. The situation I observe is when I point Architects and Dev Leads to reference material with the intention of pointing them to reusable content (albeit a design pattern, a design process, reference architecture, reference model, or a theoretical concept), 9 times out of 10 they don’t readily see what it is I meant for them to learn from it. Btw, by learn I mean; a) becoming aware, b) gaining an understanding and b) applying what was understood. A lot of this is dependent on me not being able to convey a message clearly but much of it depends on the recipient not understanding the purpose and context of the problem they have nor being familiar with the material out there to see how the material can help.
Reusing architectural references is not as easy as pointing people to a published copy of documentation. It often involves a lot of handholding and a bit of luck. Only when there is a fully complete, prescriptive methodology to follow that surrounds the nugget of knowledge I find important, do most feel comfortable.
It is rather confusing, let’s face it. There are plenty of proprietary and public concepts, frameworks, processes, models and other material that covers bits of the overall knowledge a senior software system architect needs. The problem is that in the nascent world of software system architecture, there simply is no such thing as the uber methodology that explains how it all fits together and be used for all software system architecture planning, designing, building and operation activities from the Enterprise Architecture to Solution Delivery to Operations Support points of view. To top it all off, when a new good idea comes into the fray (eg SOA, ESB, MDM, S+S, System Quality), rarely do people understand how it fits into the overall software system architecture picture. The result is building yet another methodology, process, framework, etc and the opportunity for old concepts to be renamed and tagged as being ‘new’. Confusion compounds.
There have been attempts in the scope of software engineering such as the Software Engineering Book of Knowledge (SWEBOK) found here http://www.swebok.org/. This is an interesting attempt at building the uber reference for software engineering. I wonder if we could build on top of or expand SWEBOK to include all software system architecture stuff and reuse SWEBOK to form a Software Architecture Book of Knowledge (SWABOK). Essentially, it would be a place that hosts best practices that is anchored to an information metamodel to help connect them together and help readers navigate between the references in a structured, hierarchical model.
Alternatively, we could build a site structured on the encyclopedia metaphor – sort of like Archipedia that is a wiki-format software system architecture site that hosts all best practices and links them together. This approach is a little less intentional and a bit more open but maybe the right path to take.
Or, maybe we need to go down the path of building another framework or methodology. But instead of inventing a new concept we invent only what we have to and then point to best practices already out there. This would give us the opportunity to build out a comprehensive and prescriptive framework including team model, process model, and risk management, templates, and examples. Of course, this would require a lot more work and a tighter community to ensure consistency.
It very well could be we need a combination of all of the above at varying levels of depth. I don’t really know the answer but am interested to hear from others that have an opinion.