Reference Architectures - standard constructions from standard parts

Until only a few years ago I could be found arguing passionately that "all you need is ABBs".  Give a solution designer a good collection of ABBs, across a broad enough range of areas (standard components, nodes, actors) and stand back...

But in an earlier blog I also extolled the virtues of Gartner's five client server models - so there must be is more to Architecture than just ABBs:  there's something to do with templates...

Consider the following:  what if project A in your enterprise adopts "distributed presentation", and another "remote data access"?  OK, so your architecture governance processes help ensure both solutions will work on the users' standard workstations (they've both chosen the same workstation ABB!), and maybe both use the same access control services (“authentication” and “authorisation”) but... oh boy... how many different systems management mechanisms will you need?  How "universal" will the workstation need to be to support both (and other) styles of solution  that are made available to the user?

The trouble is, and not withstanding those "simple architectures" from Gartner, our industry does not have a stable, manageable set of "Reference Architectures".  We do not have "7 tried and tested ways of designing a bridge".   Yes, I can hear some of you screaming "yes we do - it's called cloud!!!".  Fiddlesticks! Cloud can "do" all 5 client-server layouts!  The challenge is to use "cloud" in a consistent and compatible way for all the enterprises solutions.  This sounds so like the late 1990s and Warp... "The answer's OS/2, what's the problem?"!

The problem is – how do we Architects ensure the enterprise’s Solution Designers’ designs work for the enterprise (let’s call that “architectural conformance”), as well as for their direct sponsors (which we can call “solution assurance”)?  The answer is Reference Architectures – standard constructions of our standard parts, that we are confident will work together when used for the myriad of applications our SDers are designing solutions for.  And, since there is no “universal set of seven” RAs, each enterprise will – at least for the foreseeable future – decide on their set of RAs that work fore them, within their industry and in ways that match their business models.  

The real difficulty, particularly for RAs created by a supplier which are then adopted by an enterprise, is the “standard parts” bit.  I know of many organisations (including those who design systems for their clients) in which an SDer is trying to use one RA in concert with – or simply alongside – another RA; and the commonality of parts between then is… zero.  It’s a bit like a child trying to build a model house or car, in which some aspects of their construction use parts from the LEGO® box… and other parts from the MECCANO box…

Is this “foolishness” common?  Yes.  In my experience it’s more the case inside vendors (even if their RAs are all made from their own products), whose focus can be “design and build”, than it is in enterprise’s who understand the full systems life cycle of design, build, run, maintain, change and decommission.