But initiating an expansive governance programme with complex processes, detailed templates and a new organisation also can be counter-productive. The negative consequences could include lengthy delivery of the desired results, box-ticking for technical compliance but not producing what the business needs, and the development of antagonism between the governors and the governed.

This approach seems rather heavy-handed where, for the most part, non-compliance is the result of either doing the easiest thing at the time or a lack of awareness that the decisions being made contradict an established standard or policy.

Rather, any organisation with an enterprise architecture must develop a culture of consistent compliance through increased awareness and convenience of exercise.

Most compliant behaviour results from convenience and awareness, but focus on convenience

Discounting deliberate non-compliance as a contributor, there are two primary dimensions that drive compliant behaviour:

• Convenience of doing the right thing; if it’s easy to do, then your constituents are more likely to comply with the rules
• Awareness of what the right thing is; if you don’t know the rules, then only common sense prevails and technical decision-making isn’t always (rarely?) common sense.

The diagram illustrates the combination of these two dimensions to produce four general scenarios.

Chaos results from high barriers to compliance and low levels of awareness of rules & standards, as ignorant decision-makers choose the path of least resistance to achieve tactical outcomes.

Frustrated Disorder results when decision-makers are aware of the right way of doing things, but are faced with high barriers to achieving compliance; people are forced to knowingly do the wrong things as their decision making is channelled away from compliance.

Accidental Compliance is a state resulting from the condition where the barriers to compliance are low, making it easier to naturally do the right thing, but there is general ignorance of the rules; here, the right thing is done by default but, typically, inconsistently.

Deliberate Order is the Nirvana state, where compliance is as convenient, if not more, than doing the wrong thing and awareness of the rules is high; the right decisions are facilitated by reinforcing environmental conditions and an informed constituent acts as agents for compliance, with consistent and repeatable results.

Note that this model suggests that making people aware of the rules and guidelines without providing the facility to comply with relative ease will only result in a frustrated and disillusioned constituency. Surprisingly, many governance implementations feature a detailed communication of the rules and new processes that often disregard the current way of doing things. Perhaps this explains the poor reputation that architecture governance has earned – all it takes is one poor experience for a frustrated architect to tell his / her colleagues, fellow professionals and future employers, emulating the reputation network effect for marketing – it’s harder to go from good to great than to tumble down the league.

Haste and forced urgency results in inconsistency and tends compliance outcome toward chaos

We know the scenario all too well. A dictum from above increases the urgency for a project and applying normal procedures to ensure the outcome is compliant are now viewed as an impedement to the business. "Treat this one as an exception …" is the direction and the governance processes are circumvented. This signals a convenient alternative to other project managers who are always pressed to find faster ways of delivering. Before you know it, this ‘exception’ is being accepted as a norm, devaluing the enterprise architecture and, by ironic extension, resulting in a general failure to enable the business strategy.

Therefore, it is essential that any governance solution includes a defined ‘exception’ process that provides a convenient but procedural means of ensuring the same compliant outcome as for any other project. This would be achieved with an effective prioritisation framework that may accelerated the pace of decision-making for urgent projects, but in relation to the other priorities for the enterprise.

Develop a culture of acceptable behaviour to strengthen compliance

Communicate your enterprise architecture vision to every constituent group, ensuring that the message and benefits are relevant to each audience. Without a common vision that corresponds to the role of each member, the message will be lost and individuals will work towards their own interests and not that of the common good.

Once the common vision (and common good) has been articulated and accepted, then it will be easier to allow the natural social pressures of acceptable behaviour to help add weight to compliant behaviour. For example, specifying a new COTS solution application that has not been included on the EA roadmap for a project solution would result in a loss of reputation for the solution architect at the next architecture review board – not a good look. This pressure will also encourage architects to ask questions from domain engineers to ensure that their designs are compliant, improving collaboration and demolishing those ivory walls.

Clearly, architectures and technical designs that are discordant with the enterprise architecture will produce consequences felt at the business management level. Establishing a culture for compliance across the organisation will ensure that non-compliance will be unacceptable at ever level – it will no longer be non-compliance within IT, it will be non-compliance with the business as a whole, raising the stakes for anyone bold enough to defy the EA.

Conclusion – make convenience for compliance a priority and reinforce compliant behaviours with a postive culture

• Make it convenient to do the right thing first, then improve awareness of the rules to drive compliant behaviour
• Ensure urgent ‘exceptions’ don’t derail your governance initiative by establishing a process for managing exceptions in a prioritisation framework
• Develop a strong culture of acceptability and make everyone a stakeholder in the outcome, encouraging the connection with business enablement.

Common sense, isn’t it?

NB., this replaces an earlier article ‘Understand why governance is needed before deciding on how to govern’

Wikipedia eloquently describes ‘Architecture’ as the marriage between the art & science of designing physical structures. When confronted by well-designed architecture, one detects the sophistication & quality of design through all senses … it isn’t judged purely on the function of the structure. 

This careful attention to the completeness of design is rarely encountered in information and technical systems architecture. Why? Well, the common failures may be analysed by dissecting three simple points of balance:

• Design vs. engineering; because solution architecture is typically a function of IT, the tendency is to hire technical engineers as solution architects; design, as a qualification & outlook, is ignored and it shows in the product – the engineering of the technology may be excellent, but there is a lack of coherency in the wholeness of the product and absence of the characteristics of design
• Experience vs. function; too often time, budget, skill of the architect, and a focus on function results in a solution architecture that incompletely (if at all) addresses the experience aspect of architecture – it’s functionally complete, but it simply doesn’t feel right!
• Myopia vs. vision; without vision and imagination, the architecture will focus on the immediate context of the problem, relying solely on the conditions brought to the attention of the ‘designer’, without the stimulation of creative insight and innovation – it does what was asked explicitly, but ignores what was implied or needed.

Architecture is a creative science (yes, those words can be used together!). The distinction between engineering & architecture must be recognised in information technology and business systems design so that the right people are employed to produce architectural designs that are complete in both function and aesthetics.

Dedicate time & effort toward making a design product feel right, and the audience will applaud the result as well as appreciate its function. Apple have demonstrated this very effectively with products that not only function well but, more importantly, feel beautiful. The response from the market qualifies this approach. In fact, it seems that experience has been more important than function, since there are many available competing products that are functionally superior … they just don’t have that, well, "je ne c’est quoi".

But actually we do know what – don’t we?

Consider how often you have read an architectural design and, although technically good, you intuitively knew that something was missing.

Now gauge the number of times you read a design that was technically sound and felt it was comprehensive & inspiring.

If your experiences are anything like mine, then the cases of the former outweighed the latter, which inevitably leads to lengthy clarification workshops, issues during implementation as design assumptions are flushed out, and a large volume of high severity faults during testing.

So how can the balance be tipped in favour of good design to limit these potential issues? The answer is notionally simple: test the output of architecture against the recognisable, principle qualities of architectural design before proceeding to engineering and implementation stages.

There are seven principle qualities of technical design that, although individually distinguishable, together characterise comprehensive & balanced architecture:

• Cohesion
• Completeness
• Elegance
• Equivalence
• Hierarchy
• Modularity
• Vision.

These don’t define how to achieve an architectural design, but they do describe what architecture output feels like (architecture vs. specification vs. shambolic nonsense).

Cohesion

The action or fact of forming a unified whole.

The independent elements of the architecture function in harmony to fulfil a clear, common purpose; no element is left ‘orphaned’ from the rest of the architecture. The whole is an orchestration of the parts.

Cohesion runs within functional sub-components of an architecture (e.g., how related the functions are within a module) as well across the entire architecture (e.g., the solution architecture fulfils a clear value for the business that defines the cohesion of its elements). Failing to ensure common purpose and coherency in the elements of a design results in fractured experience that frequently requires manual intervention where automation would be expected. This defeats the purpose of employing technology and introduces risk & cost to the enterprise operation.

Completeness

Having all the necessary or appropriate parts.

There are no missing parts to the design and there are no elements of the design that have been left with a weaker description than the rest. The solution is complete and the architecture balanced.

Organisation & process are often overlooked as valid elements of an architecture. These should to be included as part in the architectural design. Ignoring this frequently results in paper ‘solutions’ that cannot be integrated with the enterprise properly. 

Elegance

Pleasingly ingenious and simple.

The architecture weaves together the ingenious use of technology with processes & organisation to complete tasks and fulfil business objectives. The architecture oozes innovation without confusing the observer, the solutions infuriatingly simple (“why didn’t I think of that?”). Achieving this degree of quality requires dedication, time and bags of experience. Elegance in architecture design is a prize accolade and a characteristic one recognises instantly – this is the x-factor.

Frequently, the time-pressure imperatives of the sponsor limit the architect from dedicating the necessary time to strive towards the goal of elegance. This results in complex or over-engineered solutions that must be unravelled by the implementation team. Complex solutions often result in misinterpretation or redundant features, causing waste or even dysfunction … a costly outcome for a cost-saving measure.

Equivalence

Equal in value, amount, function, meaning, etc.

The architecture separates the design along distinct levels of equivalent concern of its constituents. Therefore, the levels of abstraction are easily distinguished within the design, allowing development at a parity of detail (e.g., conceptual vs. logical). Similarly, functional equivalence can be distinguished and other concerns isolated out of the design consideration (e.g., infrastructure vs. applications). This results in uncluttered and clear designs for each design concern. The principle levels of abstraction concentrate design effort efficiently.

Without equivalence in the composition of architecture, the designs become heavily coupled across boundaries of logical divide (e.g., defining physical servers in a business architecture). This can result in duplicity in the design, which may produce inconsistency (one part of the design is changed but its coupled designs elsewhere are forgotten about) and inevitably lead to ambiguity in its interpretation for implementation. 

Hierarchy

An arrangement or classification of things according to relative importance or inclusiveness.

The architecture demonstrates the inheritance of properties from higher levels of abstraction to lower levels of detail. This order of inheritance recognises patterns to simplify complex problems, using hierarchical relationships to avoid repetition and confusion in detail. As a result, designs that use hierarchy properly are ‘clean’, easier to understand and the relationships between higher and lower levels of detail clear.

Not properly recognising the patterns that indicate hierarchy and repetitive properties in a design can result in duplicity and complexity. This has then risks producing an architecture that is neither elegant nor exhibits the characteristic of equivalence.

Modularity

Employing or involving a module or modules as the basis of design or construction (where module is each of a set of standardised parts of independent units that can be used to construct a more complex structure).

The architecture utilises a science of patterns (either standardised or bespoke) to establish repeatability in the design. The repeatable patterns may vary for each instance, but common characteristics are cleverly recognised and used to produce an efficient architecture. This results in efficient construction, which reflects in better cost, time & resource effectiveness in achieving the design outcome.

Ignoring the benefits of modularising repeatable patterns in design will invariably result in higher cost of design, construction and, ultimately, maintenance. Eventually, this lack of modularity will limit the scalability & extensibility for the implemented design, driving replacement of the construction. Duplicity, complexity and poor maintainability are hallmarks of designs that did not leverage the power of modularity.

Vision

A mental image of what the future will or could be like.

The architecture conveys an inspiring outline of the future of the enterprise within the bounds of the scope of the problem being solved. Inspiration is born of creative innovation in the solution, justification in the language & context of the business and, occasionally, solving more than just immediate problems, but lateral or future issues, thus producing unexpected advantage for the business.

Too often architecture output is dry specification that does not inspire. Project teams are more willing to pull together when excited by the work they will be doing and business sponsors more supportive of initiatives driven by an architecture they can perceive as being more than just ‘bits’ & ‘bytes’. The vision needs to be articulated from the perspective of each key stakeholder group.