Understanding Architecture Accessibility

The topic of Architecture Accessibility may sound a bit abstract upon first glance, but it is in fact one of the most important considerations as to whether an architecture effort will add value or not to an enterprise (or any particular solution lifecycle). It is also directly related (or perhaps a part of) the most important consideration for any architecture - its usability.

Let's step back for a moment and paint the background a bit.

IT Architecture has progressed in fits and starts over the past 20 years or so partially because of the widely varied results or outcomes associated with its practice under various scenarios. This is to be expected when considering that this is a fairly new aspect of Information Technology - it appeared rapidly and has been evolving ever since.

But why has IT Architecture sometimes gotten a bad reputation? The common causes for this include the following:

• A lack of clear expectations as to what the Architecture activity would really provide.
• A lack of connection between different types of Architecture efforts - for example Solution Architecture being managed separately from Enterprise Architecture or Data Modeling or application design not being considered as architecture.
• A lack of integration with governance and portfolio planning and management processes. 
• A lack of detail and / or specific implementation-level guidance.
• A lack of integration between architecture activities and ALMs / SDLCs (Software Development Lifecycles) 

You may have recognized a common thread in most of these problems - that organizations which produce Architecture in a vacuum seldom succeed. A variation of that theme is directly related to our core thesis on architecture accessibly.

Making Architecture accessible requires clear organization and a componentized, targeted approach

What is Architecture Accessibility and Why is it Important?
Accessibility in this context refers both to how people can reach the Architecture but also to how it is structured. So, here is a fundamental consideration - if an Architecture is produced yet few within the larger organization have access to it - how likely is it that the Architecture will achieve its originally intended purpose? Taken a step further, if we examine the structure issue; how likely is it that an Architecture will be exploited efficiently if it is difficult to find the pertinent information within it that any given stakeholder might need?

As Architectures grow in complexity, there tends to be a larger and larger potential audience associated with it. For nearly everyone in that audience, only a portion of the Architecture will be relevant to them. Thus the idea of a monolithic architecture artifact (say, a giant MS Word doc) becomes highly problematic. Use of a formal Enterprise Architecture repository can become equally problematic if added licensing is required for anyone who needs to view the Architecture (which in my view is a highly counter-intuitive strategy on the part of companies which produce such software).

What is at risk if Architecture becomes inaccessible is "Shelfware Syndrome." Architecture like software can provide no value if isn't applied to something - it has to be used. And this is how we begin to make the connection between Architecture Accessibility and Usability.

Architecture Usability, Defined
"Architecture Usability" refers to the ability for the Architecture to communicate the right level of information to specific stakeholder groups. Architecture must generally support multiple stakeholder groups simultaneously. What proves to be 'usable' in one specific organization may be different than in another, but generally it will involve a mix of descriptive (design explanation) and prescriptive (implementation guidance) content. Usable Architecture then is technical design content which is structured such that it can be easily accessed by the right audience at varying levels of detail.

Architecture is a continuum - it provides a mechanism whereby any number of projects and systems can be tracked and managed in context with one another. It represents a sort of meta-integration mechanism if used properly and the best architectures are those which are fully integrated within the organizations they serve. Good Architecture is Democratic as well in that the wider the shared designs are disseminated, the more likely it will be used effectively to guide the enterprise towards a unified set of goals (and some tangible end-state payoffs).

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc